VoLTE SIP Call Flow – Mobile Originating (MO) & Terminating (MT)

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


Youtube Views : 46,395
Download PDF / PPT Download Video / MP4

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


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


Hope this information is useful for you . Please feel free to Mail me ( vikas.shokeen@gmail.com ) . Please Like , Comment , Share & subscribe to my Youtube channel for more Tutorials & Technical Videos


Leave Comment on my Youtube Channel Video Page to Ask your Queries , I will get back to you as soon as possible

18 Comments:

  1. what is different between normal sip call flow and PRACK sip call flow.
    is prack mandatory in each sip call flow. what is purpose of prack in sip call flow.

  2. Such High concepts have been explained so well in such simple language and terms.
    very Nice and just can not be matched with anyone.Thanks a lot.

  3. Thanks Vikas,
    I have one question which is why dedicated EPS bearer were allocated to both UEs while B Party sending 183 Session Progression?
    A Party even doesn’t confirm the final codecs.
    Is the reason to speed-up call setup time and EPC/IMS NW use Bearer Modification if final codecs was not fulfilled?

Comments are closed.