SIP Illustrated 4: SIP Session

To describe a single SIP Session in IMS is not that easy as it maybe sounds and in the beginning it requires a lot of simplification. The purpose of the signaling over SIP is to establish a multimedia session over RTP (or MSRP). That means that SIP helps to locate the recipient and to negotiate the parameters of the RTP session. To do that we need one more protocol, called Session Description Protocol (SDP) which SIP carries in its body. The procedures for IMS describing this mechanism can be found in 3GPP 24.229.

SIP 3 Way Handshake

To set up a session the SIP protocol mandates the SIP INVITE request. It has to be answered by some final response – ideally with 200 OK. To confirm, that the client received the 200 OK message, it sends a special request SIP ACK. The SIP ACK is the only SIP request which doesn’t trigger any response on the server side. The procedure is also known as SIP 3-way handshake.

In this post we will go through a basic VoLTE flow from the SIP and SDP point of view.

Continue reading

SIP Illustrated 3: Routing and IMS Registration

In the last post I promised that this time we will take a closer look on SIP headers which are related to routing. SIP routing is very flexible and most of the SIP textbooks are explaining it in a very general way. Here we focus only on routing in IMS context. We should also point out that there are two methods how to route SIP messages – so called strict routing and loose routing. As the strict rooting is obsolete since 2002 and 3GPP mandates only the loose routing for IMS, we will talk just about the loose routing.

The first and the most important header is the Request-Line, which contains the Request-URI. It allows us to route a SIP request directly to a Server. The response then follows the Via header. SIP Client and each proxy which wants to intercept the response adds itself into Via headers of the SIP request. During the processing of the response then each proxy removes its own Via record from the message. The Via header is also used to detect possible loops in signalling.

SIP Request - Response

SIP Request – Response

 

In practice the UAs can’t see directly one each other and we have to use the IMS network to provide the routing. The first scenario we should go through is the IMS Registration. A VoLTE UE initiates a SIP REGISTER to the P-CSCF, using the P-CSCF IP that was made available during the LTE Attach. The Request-URI is set to the SIP-URI of the domain name of the home network.

Continue reading

SIP Illustrated 2: SIP Message

The general structure of a SIP message is based on Internet Message Format (RFC5322, RFC2822). With some minor differences in character sets the SIP message syntax is identical to HTTP 1.1 (but surely the SIP is not an extension of HTTP).

SIP Message

SIP Message

The SIP messages start with the Start-line, which is followed by a number of header fields in the format name:value. An empty line separates the header fields from the optional message body. As the SIP is a textual protocol, with just a little practice with Wireshark or a similar tool, it is not that difficult to analyze the massages. But to truly understand the headers in the context of IMS requires some experience. In this post we will highlight the most important message parameters.
Continue reading

SIP Illustrated 1: Basics

In November 2000, the Session Initiation Protocol (SIP) was accepted by 3GPP as a signaling protocol of the IP Multimedia Subsystem (IMS) network for IP-based streaming multimedia services. Later it was extended for video conferencing, streaming multimedia distribution, instant messaging, presence information, file transfer, etc.

SIP in VoLTE

SIP in VoLTE

The SIP protocol is easy to understand as it is text-based and practically derived from the Hypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP). SIP is very flexible and well designed for Internet telephony, on the other hand it has also some disadvantages and limitations. If you’re new to IMS signalling or you just need some brief introduction into SIP, I hope you’ll find this post useful.

Continue reading

GSMA Advanced Messaging – RCS Universal Profile

Rich Communication Services (RCS) has been around for a couple of years without any major success (actually the number of RCS deployments has been declining). There were many reasons. From the technical point of view it was caused by very ambitious design at the times where there was a little experience with IP-based technologies in operators’ networks, along with the lack of good enough RCS clients. That has changed and in the November 2016 we got a new standard called RCS Universal Profile (RCS UP) created by GSMA.

It contains a set of Advanced Calling and Messaging features and agreed enablers – such as application to person messaging (chatbots) and conversational commerce (the seamless integration of transactions and messaging).

Update: GSMA in June, 2017 released the version 2 of RCS Universal Profile. This document also introduces the key enablers for Messaging as a Platform (MaaP). MaaP includes support for Application-to-Person messaging, Rich Cards, privacy control and spam protection to open up an A2P RCS business.

 

To date 46 Mobile Network Operators and 12 manufacturers, covering a subscriber base of 4.7 billion people globally, have committed to supporting a single, standard implementation of the Universal Profile. That means that the profile will be implemented by most smartphones makers (similarly as in the case of VoLTE/VoWifi). They are Alcatel, ASUS, General Mobile, HTC, Intex Technologies, Lava International Ltd., LG Electronics, Lenovo/Motorola, Samsung Electronics and ZTE,. Moreover the standard is supported by mobile OS providers Google and Microsoft. Therefore the devices will be equipped (as from Q2 2017) with a built-in Advanced Messaging app, so consumers will be able to text, chat and share media without the need to download any special application. (However a usage of app is also an option supported by RCS Universal Profile.)

Update: We have got the first smartphone with RCS UP support – more here

It is worthwhile to mention that Google is playing an important role because it bought Jibe – one of a few useful RCS clients, and has developed a universal Android client based on the GSMA RCS UP. Google along with Sprint in US and Rogers in Canada announced that they’re rolling out with their RCS Messaging based on RCS UP at the end of the last year. Besides, as GSMA says, Google is offering a carrier hosted service for Operators to launch and manage Advanced Messaging services to their customers without deploying the RCS or even IMS infrastructure.

Update: We have got some more RCS  UP deployments in Europe and Asia this year – more here

Update: Sprint and Rogers now support RCS Interconnect! – more here

Continue reading

News: 2016 Summary

The year 2016 was in many ways the year of VoLTE and VoWifi. IP-based communication became an established standard and mobile operators are getting confident with the new technology. GSMA has just published the numbers for 2016.

IP deployments in 2016

IP deployments in 2016

One thing is the official announcement that an operator offers VoLTE/VoWifi, the other thing how much compliant it is and what services are really supported. We can see a big progress here as well. More and more operators are trying to interwork over IP, provide IP-based emergency services, IP voice and video mail, enhanced voice quality such as HD or EVS, support real multi-device feature or self-provisioning.

Operators are also trying to offer web-based access using WebRTC, which seems to be a must for enterprise integration and communication in context. RCS was not that popular in 2016, operators mostly use IPSMGW to provide SMS over IP. But seems it starts to change as can’t rely on SMS forever.

If the 2016 was about calling over IP, the 2017 can be about M2M (again). In the last 12 months we have seen many Sigfox and LoRaWAN deployments, and finally we got the log-awaited ‘so-called’ specification NB-IoT and we could see its first deployment. I planned to write a post about LPWANs, but then I read and article written by Nick Hunn, which is much better than anything I could put together: nb-iot is dead long live nb-iot.

Although we made a big step forward it doesn’t make our life any easier. In 2017 we can expect Artificial Intelligence everywhere, but I doubt it will allow us to relax either 🙂 Happy new year everyone!

 

News: Finally 4G?

IMS was designed in a very a general way. As a service network which is access independent, supports multiple identities and it is very expensive to implement. Sometimes less is more – at least in the beginning. That’s also why we have the VoLTE – a minimum IMS profile which reduces the scope into something manageable and more practical.

As the VoLTE has been around for a couple of years already and works fine, the early adopters are looking for more – HD Voice, EVS, WebRTC and other technologies. Recently T-Mobile USA (DIGITS) and AT&T (NumberSync) announced their solutions for multi-device feature. Not all the features are always successful or truly practical – but this time I’d think more operators will follow. Btw. with IoT to come I wonder when exactly we will see a first virtual entity (agent) seamlessly moving from one devices to another 🙂