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

Advertisements

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

VoLTE in IMS

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 flows.

Voice over LTE service specified in GSMA IR.92. 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 real beginners can try our VoLTE Illustrated: Beginners Guide.

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

VoLTE network architecture – simplified

During the LTE attach procedure VoLTE client receives IP address of P-CSCF.

  • P-CSCF (Proxy Call Session Control Function)
    • An entry point for IMS signalling. It is directly connected to the VoLTE device (UE) over SIP protocol.
    • P-CSCF maintains the security associations between itself and the UE.

The P-CSCF is usually a part of A-SBC.

  • A-SBC (Access Session Border Controller)
    • Provides connectivity for two or more IP networks, including IPv4 and IPv6 interworking, NAT traversal, etc.
    • Implements Security features, e.g. DoS, DDoS attack prevention, Topology Hiding, Encryption, CAC, ..
    • 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.

 

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@152.67.235.234:49635;transport=tcp>;
   expires=3200;
   +g.oma.sip-im;
   language="en,fr";
   +u.asmc.apn="6a6044869e2aba3d23d4cfc0ef1384d00da28854c2408ddbbf";
   +sip.instance="<urn:uuid:D4196919-ED8A-4E00-9436-B9CDD1E76813>"

Continue reading