Contents
VoLTE MO and MT Call Flow :- Covering VoLTE to VoLTE SIP IMS Call flow for Mobile Originating & Mobile Terminating Calls . It Provides extract of 3GPP / GSMA Specs simplified way
Originating Call Flow Sequence described in Video :-
SIP INVITE message : UE –> IMS
SIP 100 Trying : UE <– IMS
SIP 183 Progress SDP : UE <– IMS
SIP PRACK : UE –> IMS
SIP 200 OK PRACK : UE <– IMS
SIP UPDATE SDP : UE –> IMS
SIP 200 OK UPDATE : UE <– IMS
SIP 180 Ringing : UE <– IMS
SIP 200 OK INVITE : UE <– IMS
SIP ACK : UE –> IMS
Along with SIP Call flow , We will also cover Codec Negotiation in Detail in the End where We will be covering AMR , AMR-WB & EVS Codec which supports both super-wideband and full-band speech communication and provide crystal clear HD Voice
VoLTE Call Flow – Introduction
This Video is all about SIP Signaling & Codec Negotiation happens in VoLTE where we will go thru Complete Mobile Originating & Mobile Terminating call flow for VoLTE to VoLTE Calls .
SIP stands for Session Initiation Protocol (SIP) , In a VoLTE call SIP protocol is used to create, modify and terminate sessions, essentially negotiating a session between two users. SIP does not perform transport layer (delivering data) those are done by RTP/RTCP . SIP is a sequential protocol with request/response similar to HTTP both in functionality and format
VoLTE Call Flow Steps Involved
This figure shows high Level steps involved in VoLTE Call . Prior to Ringing called Party User , It is required to includes negotiation of Codecs & allocation of necessary resources . This requires communication between End points to indicate whether local resources have been allocated successfully under Precondition framework RFC 3312 . Both UE must decide what type of Media they are going to exchange which can be Audio or Video or Any IMS App .
Point 1 is Media Handshake ( which includes SDP Offer & Answer ) : SDP Stands for session description protocol . This works on handshake of Media Bearers & Codes Negotiation for HD Voice call between A Party & B Party . This SDP Message is carried inside SIP Messages . This helps in Exchange of many critical & Important messages such as IP Address , Bandwidth Required & Codecs supported by User . These parameters are Negotiated on basis of SDP Offer & Answer mechanism used .. Both UE communicate with each other via SDP Offer / Answer Model to Negotiate QOS & Codec Information
As shown in Point. No 2 … During , This Negotiation & Media Handshake , The Dedicated Bearer needs to be established for this voice call on QCI=1 . This Dedicated bearer is used to carry voice Payload & Interconnect user and LTE network for carrying voice Bits n Bytes . This is done with help of Network Node PCRF which enables communication between IMS & LTE Network to establish & tear down these Dedicated Bearers for Voice Calls between User and LTE Network .
Only after satisfying QOS Pre-Conditions , Call can proceed with Ringing user as mentioned in 3rd Step . This communication happens over SIP Protocol
As mentioned in 4th point , Once the called party picks the call , Both UE begin exchanging Media Packets
Please Note : Media Packets may be sent directly and don’t traverse the same path as signaling
Messages Exchanged in VoLTE Call flow
Here , I am going to cover brief overview of SIP Call flow just to give you High level Idea on How SIP Works , We will cover same call flow again much detail in coming Slides
SIP INVITE : The VoLTE Calling (A) Party User initiates a Voice Call by sending SIP INVITE request, This SIP Invite containing the SDP offer with IMS media capabilities. The SDP offer shall contain the Required codec , Bandwidth details etc.. Required for HD Call
100 trying : The Receiving (B) Party Acknowledge SIP Invite by Sending 100 trying
SIP 183 Progress : The terminating (B) party user will respond with an SDP answer in a SIP 183 Progress message. This SDP answer should contain Codec supported and indicates that preconditions are also desired but not met yet at the terminating side . During this SDP 183 , Dedicated Bearers are created at both A Party & B Party Side on LTE Networks . This is done with help of PCRF connecting both P-CSCF & LTE Network
PRACK : The Originator (A) Party sends Provisional Response ACKnowledgement , It is provisional acknowledgement. As name says, it is used to acknowledge SIP provisional responses like 180 Ringing, 183 Session Progress etc.
200 OK for PRACK : This PRACK is responded by Called (B) Party with 200 OK
SIP Update : Now, The Calling (A) Party 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 (A) Party side and that the media stream is now set to active.
200 OK for Update : The 200 OK for the SIP UPDATE response with the SDP answer contains in a Agreed voice codec and confirmation that the preconditions are met at the terminating (B) Party side too and that the media stream is active
SIP 180 Ringing : The Called (B) Party can start to ring and replies back with SIP 180 Ringing response
200 OK for INVITE : Now , Called (B) Party has answered the call , it responds with a 200 OK to the Calling (A) Party
ACK : Last ACK shows that the call has been established. The voice traffic goes over the dedicated bearer to A Party IMS to B Party IMS to B Party to Called Party User via dedicated LTE bearer of B Party
SIP Call Flow – SIP Invite
Here , We are again going to run thru Call flow & will try to cover Parameter level details which will bring some more clarity
SIP Invite : The UE sends an INVITE request through the originating leg , This message contains Request-URI with details of destination subscriber . This SIP Invite is sent using with Route header that contains both the P-CSCF and S-CSCF addresses obtained during registration . This SIP INVITE contains an SDP which is used for carrying & Negotiating Media Information . Critical key information included in SIP Invite is :-
SDP offer
This contains IMS media capabilities (<media type><port><protocol>)
This contains Bandwidth Information Requested (AS (application specific) – maximum RTP session bandwidth (kbytes))
Codec Supported information (<payload type><encoding name><clock rate><encoding parameters>)
This SDP Offer Preconditions indicated resource reservation is required for the originating network , but resources have not yet been reserved
Other important Information such as A Party Details – IMPU , IMPI
SIP Invite also contains information on B Party details such as tel-URI etc..
SIP Call Flow – 100 Trying
After receiving SIP-Invite , Every Hop in Network responds back with a 100 Trying provisional response. The provisional response is a one-way response sent back to the originating side used as generic Information . It is not necessarily guaranteed for its safe arrival
SIP Call Flow – 183 Session in progress
183 Session in progress
Till now , The Preconditions of call are not satisfied . Due to this B-Party UE can’t begin to alert the user for incoming call & can’t send back 180 Ringing response , Instead it sends 183 Session Progress message also includes SDP Answer as response to Original SIP Invite SDP Offer
The terminating UE locally allocates resources, generates the 183 Session In Progress along with SDP answer and sends it back towards the originating UE. The 183 Session In Progress arrives the originating S-CSCF following the reverse path of the SIP messages
The SDP Answer indicates support of relevant Codecs by Called Party subscriber .This helps both Users to selects Common Code which are mutually supported by both A Party and B Party User
Dedicated Bearer Creation on QCI=1
Dedicated bearers are now created on both Originating Side & Terminating Side
Upon receiving the 183 Session In Progress, the P-CSCF of respective Origination or Terminating Party triggers the Authentication & Authorization request (AAR) towards the PCRF to inform that there is new IPCAN Session required . This is done over Rx Protocol connecting P-CSCF & PCRF
Upon receiving the AAR, the PCRF generates PCC rules which triggers SGW/PGW to perform bearer creation on QCI=1 for Voice Calls . This is done over Gx interface between PCRF & PGW
The PGW initiates the EPS bearer creation procedure and responds with the Re-Auth-Answer (RAA) to the PCRF , Similarly PCRF reply back to P-CSCF with AAA Message
Now , P-CSCF continues the SIP signaling by forwarding the 183 towards Originating Party
SIP Call Flow – SIP PRACK , 200 OK PRACK
PRACK : PRACK is defined in RFC 3262 , This is used for Reliability of Provisional Responses, i.e. A Party sends PRACK to acknowledge 183 Session Progress Message received earlier . The PRACK request plays the same role as ACK, but for provisional responses. To avoid Missing of these Provisional response such as 183 Session Progress , ‘100rel’ extension is used during call setup which indicates called party to send provisional response reliably and keep re-transmitting until PRACK message is received or timeout happens
Also , A Party also uses this PRACK to communicate Final Selected Codec which is decided for Voice Call via 2nd Offer
200 OK (PRACK) : With 200 OK , B Party Accepts Final selected Codec Offered by A Party in PRACK Request . Now , Final Agreement on Codec to be used have been completed . Both A & B Party Agree that Reservation of Resources are required but resources have not yet been reserved
With this , Codec Negotiation have been done by both Parties but Resource reservation is still pending
SIP Call Flow – SIP UPDATE , 200 OK UPDATE
UPDATE
Now , Originator (A) Party user sends 3rd Offer Request to B party with Update Request depicting Resource Reservation status . Here , Originator will perform critical Task of Reserving resources & Will send Update request without changing rest of Parameters such as Codec etc.. . Since Codec have been already Agreed between both Parties via PRACK Message discussed Earlier , Same Selected Codec will be used in this Offer without Any further changes .
200 OK (UPDATE)
With 200 OK , B Party also reserves resources & confirm back to Originator
SIP Call Flow – 180 Ringing , SIP 200 OK INVITE , SIP ACK
180 Ringing
The 180 Ringing provisional response is received by the UE. It indicates the voice call setup request is being notified to the recipient. The Called (B) Party Started Ringing
SIP 200 OK (INVITE)
Now , Called (B) Party has answered the call , it responds with a 200 OK to the Calling (A) Party . Upon receiving the message , The originator UE allocates the media resource
SIP ACK
The UE sends SIP ACK towards the terminating user as acknowledgment . Last ACK shows that the call has been established. The voice traffic goes over the dedicated bearer to A Party IMS to B Party IMS to B Party to Called Party
SIP Call Flow – Actual IMS Nodes – MO / MT Call Flow
This is only Pictorial diagram of Whatever we discussed this now , This represents actual flow of Packets between various IMS Nodes
We can clearly see SIP Invite Going from Originator to A Party P-CSCF to S-CSCF , Every Node Provides back Acknowledgement back to Previous Node by 100 Trying Message . This Cycle continues in B Party Network as well .
Calling Party SCSCF involves TAS to process the Outgoing call & to execute originating service , Post this , S-CSCF tries to find out terminating subscriber network. so it sends ENUM query for B party number and finds out details of B party Network here
Now , Traffic get’s handed over to B Party Network where I-CSCF does Interrogation with HSS & Finds appropriate B Party S-CSCF to be used . Here B Party S-CSCF triggers TAS to Process Incoming Call & Execute Terminating Service
Here , TAS is involved in almost all transactions passing thru both A Party S-CSCF and B Party S-CSCF , We are not showing same keeping away clutter from Screen
Finally , SIP Invite is forwarded to B Party I-CSCF to S-CSCF to P-CSCF & Finally to B Party User
B Party User responds back with 183 Session in Progress to B party P-CSCF
Here P-CSCF creates Dedicated bearer on QCI=1 for Voice Call for B Party on LTE Network with help of PCRF
P-CSCF forwards this 183 Session in Progress containing SDP Answer back to B Party S-CSCF to I-CSCF & Ultimately its handed over back to A Party S-CSCF & P-CSCF
Now , A Party P-CSCF also creates Dedicated Bearer for A Party user over LTE Network using PCRF Node
Finally , This 183 Session in Progress is sent back to A Party User
The Originator (A) Party sends Provisional Response ACKnowledgement with PRACK Message . Pls Note , For Simplicity .. We have removed LTE Networks & B Party I-CSCF from this Slide as they are no more required for further processing of Signaling
This PRACK is responded by Called (B) Party with 200 OK
Now, The Calling (A) Party reserves internal resources to reflect the SDP answer and confirms resource reservation by sending a SIP UPDATE message with a 3rd SDP Offer
The 200 OK for the SIP UPDATE response with the SDP answer
The Called (B) Party can start to ring and replies back with SIP 180 Ringing response
Now , Called (B) Party has answered the call , it responds with a 200 OK to the Calling (A) Party
Last ACK shows that the call has been established. The voice traffic goes over the dedicated bearers
Now , We have closed the Entire chain for VoLTE to VoLTE voice call . We will cover or last section on Codec used in VoLTE moving ahead
SIP Call Flow – VoLTE Codecs
For many operators the HD voice quality was one of the market drivers for 4G . Let’s understand , What is Codec & How VoLTE uses these codecs to offer HD Voice .
VoLTE uses RTP ( which is Real time transfer Protocol ) . This is widely used protocol for real time communications such as Voice or Video . RTP ensures Reliable delivery . As far as speech codecs are concerned, the basic Adaptive Multi Rate (AMR) speech codec is mandatory; the popular data rate for good speech quality is 12.2 kbps . AMR is old codec & in use since few Years now after 3G Era . RTP over UDP is used to transport AMR speech.
For AMR : The UE & IMS Network must support the AMR with all eight codec modes
By launching HD voice using AMR-WB (Adaptive Multi-Rate Wideband) the subscribers could feel the Real difference . GSMA PRD IR.92 has also 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.
For AMR-WB : The UE & IMS Network must support AMR-WB including all nine modes
Now , Last Comes the New Codec by Name of EVS which supports both super-wideband and full-band speech communication . If the EVS codec is supported, These may be used as an alternative implementation of AMR-WB . Although EVS May requires higher bandwidth , But It ensures absolutely crystal clear voice Quality .
Please Note : All these Specs are Governed by 3GPP Specs .. I have shown 3GPP Website link on screen where all required information is readily available with Specs Detail