SIP Illustrated 5: SIP Session Routing

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.

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.



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


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 ePC part aside and take a look on the IMS flows.

We’ve already discussed VoLTE a bit in the VoLTE or RCS voice call post, so we know that the most important specifications are the GSMA IR.92 and IR.94 which are then referencing other documents. If you think it seriously with VoLTE, don’t waste your time on any blog and read the VoLTE Service Description and Implementation Guide. On the other hand for real beginners we have VoLTE Illustrated: Beginners Guide.

The very basic architecture of IMS for VoLTE can look like this:



Except the I/S-CSCF, which cares about authentication, session routing and management, we need an Application Server for voice and video telephony. This application server is called TAS – Telephony Application Server or MMTel AS – Multimedia Telephony AS. The application server is responsible for all the services which can be applied – 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.

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 – 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 – 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 VoLTE to VoLTE callflow.


Continue reading

Call-ID and Other Message Identifiers

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 |xna|<ε for all nN.

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.

SIP Call-Id

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.





Much Ado about Registration

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.

IMS Registration

IMS Registration

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.

Contact: <sip:119560022547@;transport=tcp>;

Continue reading