Even in 2017 the telephone number remains the most universal identifier for real-time communication. And as the word is moving to be All-IP, we have to be able to translate the number into something more meaningful for routing in IP networks. The GSMA organization selected for this purpose the Electronic Number Mapping System (ENUM) and in 2007 released the first version of PRD IR.67.
ENUM based Routing
Moreover Mobile Operators in over 50 countries have to support Mobile Number Portability (MNP). Although for MNP is a great feature for end subscribers, it makes the signalling more complex and costly for the Operators. The MNP is not just a problem for signalling (routing) but also for billing and management of interconnect agreements. Last but not least it can be a significant issue for content and application providers who may not be aware of the change of the operator for a particular user.
In the last post we have seen a basic SIP (VoLTE) session. This time we should analyze in more detail, what headers are used by network elements for their routing decisions and how they discover what port and IP to use. In practice that’s what people are not always sure about. They know the flow, order of signalling messages, but when something goes wrong, they are just guessing what could be the reason.
SIP Message Routing
Let’s recap what we have learnt so far. We use loose routing. So if a SIP message contains a Route header, we will use the top most one for the routing. If there is no Route header the routing is done based on the Request-URI, which contains the address of the final recipient. Don’t forget, network elements are able to add and modify the headers. The way how we handle the messages and modify their content within the IMS is described in 3GPP standards.
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.
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).
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.
There are mobile operators who have RCS in their network but practically no one really use it. The number of RCS deployments – in contrast to VoLTE or VoWifi is decreasing and more than once I’ve heard that RCS is a zombie. These days when it comes to texting over 4G we mostly still rely on the old good SMS, using IPSMGW. Of course, we can choose from plenty of OTT technologies as WeChat, WhatsApp, Line, etc. However SMS is still a must to have for all the mobile carriers, even though they are not making much money on it.
RCS standard is everything but simple and straightforward. The operators were that afraid, that they’ll become only connectivity providers that they created an omnipotent service which no one was able to implement. For many years we struggled during the integrations and to find a really working RCS client was close to impossible. One of the better clients was Jibe. Jibe was bought by Google the last year and many were wondering what is the Google up to..
Recently Google along with Sprint in US and Rogers in Canada announced that they’re rolling out with their RCS Messaging. More info in RCS Universal Profile post. Hard to predict how successful it will be this time, but chances are, we will see RCS around in 2017.
Presence sharing is a very important functionality when it comes to Rich Communication. We know it from many communicators such as Skype, Google Hangout, Facebook, Jabber, etc. But maybe you noticed that each of these applications has a different set of statuses, allows to share a different type of hard-state data (e.g. avatar, idea of the the day, web link ..). Mobile operators require some more unified approach as a particular status should be interpreted in the same way in all the networks (‘busy’ should have the same meaning in T-Mobile, Vodafone, or any other network).
That’s why Open Mobile Alliance (OMA) standardized Presence sharing for RCS using SIMPLE – Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (see http://technical.openmobilealliance.org/Technical/technical-information/release-program/historic-releases/presence-simple-v2-0). But that can be quite confusing, as the presence system is not simple at all. It is very complex and sometimes a bit difficult to grasp.
Let’s start from the beginning – what is the presence?
What is Presence?
Based on the recent numbers from GSMA it seems that over 50 % of the world population is now in a reach of 4G services. The number of VoLTE deployments in 2016 (May) is already close to the number of all the deployments for the year 2015.