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.
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.
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.
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.
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.
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.
In telco tracing has always been very important. It helps us to understand the flows, the content and – sure – to find bugs. SS7 used to be much more strict and we didn’t need to go in the detail traces that often. The flow and a few fields was usually enough. With SIP and SDP it is a different story. SIP is a very flexible protocol. That means powerful but also complex and sometimes quite confusing.
Let’s take a look on IMS Registration. I’m sure you remember the idea behind from a previous posts about Registration and 3rd party registration and at least the basic flow:
The registration flow is very important – in practice if something goes wrong, it is most probably registration. Once is a subscriber correctly registered, the other flows (call, sms, fileshare) usually works fine.
The year 2015 is definitely a year of VoLTE. VoLTE is everywhere and operators are rolling out as crazy. There are plenty of articles describing how the LTE or LTE-A do work. We’ll put the LTE Packet Core part aside and take a look on the IMS related VoLTE architecture and VoLTE call flows.
Communicates with access network (e.g. LTE) and is responsible for QoS
Handles Media Services, provides transcoding if needed
For the end-2-end signalling (voice call setup) we use SIP protocol. The multimedia then goes out-of-band using RTP protocol.
The heart of IMS network is IMS Core. It consists of often collocated I/S-CSCF, which cares about authentication, session routing and management.
I-CSCF (Interrogating Call Session Control Function)
I-CSCF provides a Location service. That means that for each subscriber (or public service) I-CSCF is able to locate the right S-CSCF.
I-CSCF also represents IMS network to peers. E.g. for peer networks the I-CSCF is the first point of contact.
S-CSCF (Serving Call Session Control Function)
The S-CSCF is responsible for basic IMS services. It is a SIP server providing session set-up, session tear-down, session control and routing functions.
S-CSCF acts as SIP Registrar – stores the binding between Public User Identity (e.g. sip uri or tel uri) and its actual point of presence (Contact IP address) and maintains user registration status. During VoLTE registration procedure S-CSCF performs user authentication.
S-CSCF also invokes Application Servers (TAS, IPSMGW) based on rules (IFCs) received from the HSS.
The IMS Core however doesn’t know anything about Voice or SMS service. That is a task for Application servers. The Application Server for voice and video telephony is called TAS – Telephony Application Server or MMTel AS – Multimedia Telephony AS.
Telephony Application Server (TAS)
The application server responsible for all the services as address normalization, call diverting, call forwarding, barring, etc.
In a nutshell TAS is what makes the VoLTE enhancements on top of the pure VoIP.
VoLTE specification also defines SMS interworking. To support SMS over SIP we have a dedicated Application Server called IPSMGW. In more detail it is described in IPSMGW – Transport Level Interworking post.
IMS Core and Application Servers don’t have any persistent storage. All the information about subscribers and their services is stored in HSS (Home Subscriber Server). The communication between HSS and I/S-CSCF or TAS makes use of Diameter protocol.
Other IMS elements are:
MRF – Media Resource Function
Can be used as a media mixer or as a media server for playing of tones and announcements.
MGCF – Media Gateway Control Function
MGCF is used for the breakout to and from CS network. Usually the MGCF and MGW – Media GW is a part of enhanced MSC.
BGCF – Breakout Gateway Control Function
BGCF might be used in case when S-CSCF is not able to find the routing based on ENUM/DNS (e.g. PSTN number). Usually it is a part of IMS Core (along with S-CSCF and I-CSCF).
The IMS definition is very broad and flexible. GSMA VoLTE standard restricts it and defines what services are mandatory and how we should implement them. E.g. it defines how to implement Emergency Services, SRVCC, Roaming, SMS interworking, etc. In our post we will go through the basic LTE to LTE callflow.
I remember when we were learning the limits in math analysis:
Definition Let (xn) be a sequence of real numbers. The sequence (xn) is said to converge to a real number a, if for all ε>0, there exists N in N such that |xn–a|<ε for all n≥N.
Take your time. Human brain simply have a problem to process more than two variables. Three is sometimes too much.
When I tell during a training that each dialog is identified by the triple Call-ID, From-tag and To-tag sometimes people start to experience the same kind of discomfort. So what are these headers for?
Call-ID (described in RFC 3261) is identifying a session. So in a common session the Call-ID will be the same in INVITE, PRACK, REFER, ACK, BYE and all the responses. Let’s say someone wants to establish a video chat with me. I have several active devices. Then I’ll receive the INVITE on each of them and they will contain the same Call-ID.
In SIP any dialog is possible between two end points – UAC/UAS only. If more parties are involved we can’t call it a dialog anymore (true :)). That means that the dialog is a subset of a session for particular UAs. And that is actually the reason why we need to add the tags into the identification of the dialog.
The SIP client adds the From-tag into the request. The recipient than adds the To-tag in the response. This helps to better identify the originator and recipient.
In case of the recipient the main reason is forking. Simply the recipient can use more devices and the one which will send 200 OK as the first (including its own To-tag) will be the one which will continue in the dialog.
In case of originator it can be the situation that originator is in a dialog with itself (because of testing purposes or so-called “hairpinning” of calls in PSTN gateways) and needs to distinguish between the originating and terminating end.
The identifiers have to be unique (across the time and space 🙂 ). Besides the requirement for global uniqueness, the algorithm for generating a tag is implementation-specific. Tags are also helpful in fault tolerant systems, where a dialog is to be recovered on an alternate server after a failure.
And last but not least it also explains another famous triple – INVITE, 200 OK, ACK. In the call flow above we can see why a 200 OK is not enough to start a media session. The most obvious reason for ACK is that the link is unreliable.
But it can also happen that more devices send 200 OK and the responding UAS can’t be sure that the 200 OK will arrive to UAC as the first one. So only the first UAC will receive the ACK and can start RTP session.
Mind that if any B2BUA is involved it can change Call-ID value and we need to follow two dialogs (UAC-B2BUA, B2BUA-UAS).
Authors of SIP and IMS were maybe very smart. But definitely they were not operation engineers. In practice it is not easy to trace all the messages which belong to a particular flow. Mostly we use the P-Asserted-Identity (and its equivalents such as X-XCAP-Asserted-Indentity or x-3gpp-asserted-identity) and we incrementally add new conditions in the filter. That’s why it is also kind of difficult to find a really good trace tools and many operators create them on their own.
Registration is something what was missing in the times of wires. Ok, not completely but it was done more or less once when an MSISDN was assigned to some line.
In contrast to the previous types of the networks the 4G network is ‘user-centric’. It means the user can use multiple devices and identities and we have to deal with it. The main purpose of the registration is to create a binding between user (her public identity) and IP address of the device, so we know where we can send the data to. That’s why there is a Contact header in the SIP REGISTER message. The Contact header contains an address which identifies the current location of the user (Point-of-Presence – e.g. IP/FQDN of a particular client). During the registration is the Contact Address is linked to a Public Identity (IMPU, AOR in SIP terminology). The IMPU is an equivalent to MSISDN in GSM and has to be present in the To header of the SIP REGISTER. One identity can by used by more terminals and as each terminal can have different capabilities this has to be also taken into account. This information is part of the Contact header.