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 – Registration, Third party registration, Sh, ..). In the VoLTE the flow looks like this:
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:
- Alphanumeric SIP-URI: g. user@example.com
- MSISDN as a SIP-URI: g. sip:+4206000900123@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
- 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
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
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.
VoLTE Codecs
For many operators the voice quality was one of the market drivers for 4G. Most of the VoLTE functionality is transparent for end users. But by launching HD voice using AMR-WB (Adaptive Multi-Rate Wideband) the subscribers could feel the difference.
GSMA PRD IR.92 has mandated AMR / AMR-WB codecs to be used for VoLTE. These codecs have to be implemented by all equipment manufactures to ensure a good voice quality as well as facilitating inter-operability and avoiding transcoding. Other voice codecs can be also supported by operators in addition to the AMR codecs.
- The UE must support the AMR, including all 8 modes and source rate controlled operations (3GPP TS 26.093). Moreover the UE has to be capable of operating with any subset of these eight codec modes.
- The UE must support AMR-WB including all nine modes and source controlled rate operation (3GPP TS 26.193). Again the UE has to be capable of operating with any subset of these nine codec modes.
- If the EVS codec is supported, then the EVS AMR-WB IO mode may be used as an alternative implementation of AMR-WB.
- If super-wideband or fullband speech communication is offered, then the UE must support the EVS codec.
The EVS codec supports:
| Bandwidth | Bit Rate (kbps) |
| Narrowband (NB) | 5.9, 7.2, 8, 9.6, 13.2, 16.4, 24.4 |
| Wideband (WB) | 5.9, 7.2, 8, 9.6, 13.2, 13.2 channel-aware, 16.4, 24.4, 32, 48, 64, 96, 128
(6.6 ~ 23.85 for AMR-WB IO) |
| Super-wideband (SWB) | 9.6, 13.2, 13.2 channel-aware, 16.4, 24.4, 32, 48, 64, 96, 128 |
| Fullband (FB) | 16.4, 24.4, 32, 48, 64, 96, 128 |
From the practical point of view the Initial SDP offer contains the AMR Narrowband codec, and it is recommended that the AMR-WB codec is included too. The SDP answer should contain only one codec. Both the initial offer and answer should indicate that preconditions are also desired but not yet met as we have seen above.
In case of CS break-in/break-out the IMS-MGW may be required to perform transcoding between AMR-NB/AMR/WB codecs and other codecs supported within the CS network (e.g. GSM-HR, GSM-FR, GSM-EFR, etc.).
More over of Network-to-Network Interface (NNI):
- The NNI must support the AMR and the AMR-WB for both roaming and interworking between PMNs
- If super-wideband or full band voice interworking is offered then the EVS codec must be supported
- In case of interworking with fixed networks, NNI should additionally support the G.711 for narrowband voice interworking, G.722 for wideband voice interworking, and G.719 for super-wideband and full band voice interworking.
- For super-wideband and full band voice interworking if G.719 is not supported, AAC-LD should be supported
Other related posts:
Real Time Communication 