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.
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:-
- “+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:
- Alphanumeric SIP-URI: g. firstname.lastname@example.org
- MSISDN as a SIP-URI: g. sip:+email@example.com;user=phone
- MSISDN as Tel-URI: g. tel:+4206000900123
- 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
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:
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:
- 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:
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.