4. Volte call flow - SIP Call Flow - IMS Call procedure

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
This is VoLTE SIP IMS Call Flow Video . I will be covering complete VoLTE outgoing and Incoming call flow here also known as Mobile Originating (MO)and Mobile Terminating (MT) This Video is crisp summary of SIP Call flow mentioned in the VoLTE GSMA Document : "VoLTE Service Description and Implementation Guidelines" By End of this Video , You will become Expert in understanding SIP and VoLTE call scenarios This Video shows complete call flow in Pictorial view so that you can remember it for a longer duration Let's start our journey This Video is all about SIP Signalling and Codec Negotiation happens in VoLTE where we will go thru complete Mobile Originating and 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 such as Delivering data , These transport layer function are done by RTP/RTCP . SIP is a sequential Protocol with request/response similar to HTTP both in functionality and in format . We will go thru SIP call flow in the Beginning and finally cover codec in the End of this Video Please watch this Video till End , Where I will be sharing 3GPP and GSMA document links for further studies This figure shows high Level steps involved in VoLTE Call . Prior to Ringing the called Party User , It is required to includes negotiation of Codecs & allocation of necessary resources . This requires communication between End points to indicate whether a 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 Application Point 1 is Media Handshake ( This 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 the communication between IMS & LTE Network to establish & tear down these Dedicated Bearers for Voice Calls Only after satisfying QOS Pre-Conditions , Call can proceed with Ringing 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 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 The 1st Message is 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 the HD VoLTE Call The 2nd message is 100 trying : The Receiving (B) Party Acknowledge the 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 the 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 200 OK for Update : The 200 OK for the SIP UPDATE response with he SDP answer contains in a Agreed voice codec and confirmation that the preconditions are met at the terminating (B) Party side too .. Now 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 Now , Since we are clear on high level flow of VoLTE Call , Now Let's cover parameter level details of all these SIP Messages which will build you fundamentals on conceptual level on SIP Call Flow SIP Invite : The UE which is A Party sends an INVITE request through the originating leg This message contains SIP Request-URI with details of destination subscriber . This SIP Invite is sent using Route header that contains both the P-CSCF and S-CSCF addresses obtained during the registration of VoLTE User 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 SDF Offer contains IMS media capabilities This contains Bandwidth Information Requested It also contains very critical information of Codec Supported . It will basically tell to the B Party that these are list of Codecs which are going to be supported by A Party Now , B Party can choose One of the Codec or few of Codecs and reply back On basis of which a final codec is being Negotiated between A-Party and B-Party during the course of the call flow This SDP Offer Preconditions indicated resource reservation is required for the originating network , but resources have not yet been reserved yet Other important Information is also there in this SIP invite which is typically A Party Details which is IMPU & IMPI The Private and Public entities of a calling party It also contains information of B Party such as TEL-URI which is typically the B Number which is being dialed by the user the 2nd Message is 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. 183 Session in progress Till now , The Preconditions of call are not satisfied . Due to this , The 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 which also includes SDP Answer as response to Original SIP Invite SDP Offer The terminating user locally allocates the resources, generates the 183 Session In Progress along with SDP answer and sends it back towards the originating user. The 183 Session In Progress arrives at 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 Now , Let's also discuss the Dedicated Bearer Creation on QCI=1 which is very very critical part Which basically allows a bearer to be created for A Party and B party Users on the LTE Network Dedicated bearers are now created on both Originating Side & Terminating Side Upon receiving the 183 Session In Progress, the P-CSCF of respective Origination and Terminating Party triggers the Authentication & Authorization request (AAR) towards the PCRF to inform that there is new IPCAN Session which is required . This is done over Rx Protocol connecting P-CSCF & PCRF Upon receiving the AAR, the PCRF generates PCC rules which triggers SAEGW to perform bearer creation on QCI=1 for Voice Calls . This is done over Gx interface between PCRF & PGW . The PGW indicated the EPS bearer creation procedure and responds with the Re-Auth-Answer which is RAA . Similarly PCRF reply back P-CSCF with AAA Message Now , P-CSCF continues the SIP signaling by forwarding the 183 towards Originating Party PRACK PRACK is defined in RFC 3262 , This is used for Reliability of Provisional Responses, . Let's take example .. A Party sends PRACK to acknowledge 183 Session Progress Message received earlier . The PRACK request plays the same role as ACK, but its used 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-transmission 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 using 2nd Offer 200 OK (PRACK) With 200 OK , The B Party Accepts Final selected Codec Offered by A Party in PRACK Request . Now , Final Agreement on the Codec to be used have been completed . Both A & B Party Agrees that Reservation of Resources are required but resources have not yet been reserved yet With this , Codec Negotiation have been done by both Parties but Resource reservation is still pending 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 which is discussed Earlier , Same Selected Codec will be used in this Offer without Any further changes I mean to say the main the main role of Update is to reserve the resource and confirm next B Party Ok I am ready the ... Resources have been allocated at my End ... You also align your Resources .. Allocate & Reserve your resources so that the call can be proceeded The B Party sends back .. 200 OK (UPDATE) With 200 OK , B Party also reserves resources & confirm back to the Originator 180 Ringing The 180 Ringing provisional response is received by the user . 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 in the mean time It responds with a 200 OK to the Calling (A) Party . Upon receiving the message , The originator user allocates the media resource The Last Message is .. SIP ACK The UE sends SIP ACK Message 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 user This is only Pictorial diagram of Whatever we have discussed this now This represents the actual flow of Packets between various IMS Nodes On Left hand side , these are A Party Nodes , On Right hand side , These are Terminating or B Party Nodes You can clearly see , There is an LTE Network .. There is P-CSCF , There is S-CSCF .. which is lying on both A Party Side as well as on B Party Side 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 gets handed over to B Party Network where I-CSCF does Interrogation with HSS & It 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 TAS everywhere everytime because I want to remove the clutter away from the 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 Network , And the Node is S-CSCF Now , A Party S-CSCF forwards the Packet to A-Party S-CSCF which 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 SIP-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 here . We will cover the last section on Codec used in VoLTE moving ahead 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 last 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 user & 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 very High bandwidth , But It ensures absolutely crystal clear HD voice Quality . Please Note : All these Specs are Governed by 3GPP here.. I have shown 3GPP Website link on screen where all required information is readily available with Specs Detail There is also One more link I have provided just below this 3GPP which is a GSMA Link , Its a Link to Great GSMA document "VoLTE Service description and Implementation Guidelines" This is a very very useful document for learning VoLTE concepts
Info
Channel: TelecomTutorial info
Views: 146,938
Rating: 4.8567042 out of 5
Keywords: volte MO and MT Call flow, Volte call flow, ims call flow, sip call flow, volte ims call flow, Volte MO MT call flow, Volte call, Volte to volte call, ims call, volte mo call flow, volte mt call flow, volte, volte call, volte outgoing call, volte codec, volte flo, volte call flow end to end, volte call flow and procedures, volte call flow explained, end to end volte call flow, ims call flow video, sip procedure, sip flow, sip, ims, sip call
Id: sMPGH4Ag5b4
Channel Id: undefined
Length: 21min 37sec (1297 seconds)
Published: Sat May 19 2018
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.