VoLTE flows – close encounters

If you know a bit about SIP and IMS you are probably aware that they are quite flexible. There are many ways how to do some solution and different vendors can easily come up with different implementation for the same thing.

In trainings people are asking very often – is this SIP message mandatory, what will happen if our client will not support this feature, what header attribute is the right one to identify xyz?

Well we have a huge number of specifications (from different organizations and bodies as 3GPP, IETF, OMA, GSMA, …). To avoid the confusion for VoLTE service GSMA created (yes another) document called VoLTE Service Description and Implementation Guide. This is not a classical spec, rather a guide what are the exact call flows and what message fields are relevant for the VoLTE.

We already know the registration from other posts (Registration, How to read tcpdump – RegistrationThird party registration, Sh, ..). In the VoLTE the flow looks like this:

VoLTE registration

VoLTE registration

The VoLTE UE initiates a SIP REGISTER to the P-CSCF, using the P-CSCF IP Address that was made available during the LTE Attach.

The registration contains:

  • Within the Contact header, the IMS Communication Service Identifier’s (ICSI) for IMS Multimedia Telephony:-
    • urn:urn-7:3gpp-service.ims.icsi.mmtel
    • “+sip.instance” containing an IMEI URN
    • The feature tag for SMS over IP: +g.3gpp.smsip
  • The IMS Public User Identity  is in one of the forms:
    • The IMS Private User Identity as an NAI: g. username@realm
  • P-Access-Network-Info with:
    • access-type= 3GPP-E-UTRAN-FDD or 3GPP-E-UTRAN-TDD
    • UTRAN-cell-id-3gpp parameter
  • Request-URI set to the SIP-URI of the domain name of the home network
  • Related headers for IMS AKA parameters
  • etc.

Where an ISIM is present on the UICC, ISIM based authentication and IMS-AKA is used. The ISIM application shall be preconfigured with the related IMS Identities as defined in 3GPP TS 31.103.

Where no ISIM is present on the UICC, USIM based authentication and IMS-AKA is used. The UE shall generate the Private User Identity and the Public User Identity from the IMSI as defined in 3GPP TS 23.003.

After the successful registration the VoLTE UE, P-CSCF and TAS shall subscribe to the registration event package using the SIP SUBSCRIBE message.

 

The basic LTE-LTE flow was explained in the VoLTE in IMS post. A more detail flow from the O-TAS point of view looks like:

VoLTE originating side

VoLTE originating side

 

The VoLTE UE-A initiates a SIP INVITE request, containing the SDP offer with IMS media capabilities. The SDP offer shall contain the AMR Narrowband codec, and it is recommended that the AMR Wideband codec is included to provide support for HD Voice and shall indicate that local preconditions for QoS are desired but not met yet.

The INVITE request contains:

  • Within the Contact header and the P-Preferred-Service header, the IMS Communication Service Identifier’s (ICSI) for IMS Multimedia Telephony:

urn:urn-7:3gpp-service.ims.icsi.mmtel

  • Within the Supported header, the P-Early-Media, 100rel& precondition option tags are present.

The S-CSCF receives the SIP INVITE from the P-CSCF and triggers O-TAS for originating services. The S-CSCF also validates the P-Preferred-Service header and if the user is authorized it will change it for P-Asserted-Service.

The TAS can do address translation, retrieve data from HSS via Sh interface, apply supplementary services. Then routes the SIP INVITE back to the S-CSCF. The S-CSCF finds the routing to the terminating network based on the R-URI.

The terminating UE will respond with an SDP answer in a SIP 183 Progress message. According the VoLTE Guideline the SDP answer should contain only one codec and indicates that preconditions are also desired but not met yet at the terminating side and that a confirmation should be sent when QoS preconditions have been met by the originater.

The P-CSCF forwards the SIP 183 Progress response to the originating VoLTE UE. This message shall utilize 100rel. Therefore the originator sends a  PRACK.

After receiving the 200 OK for the PRACK the originating UE reserves internal resources to reflect the SDP answer and confirms resource reservation  by sending a SIP UPDATE message with a new SDP Offer. The offer contains the selected codec and  information that the local preconditions have been met at the originating end (due to the establishment of the dedicated bearer) and that the media stream is now set to active.

The 200 OK for the SIP UPDATE response  with the SDP answer contains in a sunny-day scenario a single voice codec and confirmation that the preconditions are met at the terminating side too and that the media stream is active. Now the terminating UE can also start to ring (SIP 180 Ringing response) as it knows that it is possible to establish the session per the SDP parameters.

Finally when the called party has answered the call, it responds with a 200 OK to the originator. The following ACK acknowledges that the call has been established. The voice traffic goes over the dedicated bearer and via the IMS-AGW. The IMS Signalling is sent over the default bearer. As you maybe noticed we intentionally skipped all the communication between P-CSCF and PCRF.

The same flow from the terminating side point of view:

VoLTE terminating side

VoLTE terminating side

So these are the three main flows which we should see in the IMS VoLTE network. Are these flows complete? No, e.g. for SRVCC support we need to add some more elements and messages. Are there any other flows? Of course, e.g. for CS breakout, flows for call clearing, Supplementary Services, etc.

Advertisements

6 thoughts on “VoLTE flows – close encounters

  1. Pingback: Much Ado about Registration | Real Time Communication

  2. Pingback: Mind the coverage hole! | Real Time Communication

  3. Pingback: VoLTE in IMS | Real Time Communication

  4. Pingback: Sh Interface – What Is It Good for? | Real Time Communication

  5. Pingback: VoLTE Illustrated: Beginners Guide | Real Time Communication

  6. Pingback: SIP Illustrated 4: SIP Session | Real Time Communication

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s