04_CN61134EN16GLA0_VoLTE Voice&Vedio call setup procedure.pptx

Volte voice & video call setup

1. VoLTE Call Procedures

2. Copyright and confidentiality The contents of this document are proprietary and confidential property of Nokia Networks. This document is provided subject to confidentiality obligations of the applicable agreement(s). This document is intended for use of Nokia Networks customers and collaborators only for the purpose for which this document is submitted by Nokia Networks. No part of this document may be reproduced or made available to the public or to any third party in any form or means without the prior written permission of Nokia Networks. This document is to be used by properly trained professional personnel. Any use of the contents in this document is limited strictly to the use(s) specifically created in the applicable agreement(s) under which the document is submitted. The user of this document may voluntarily provide suggestions, comments or other feedback to Nokia Networks in respect of the contents of this document ("Feedback"). Such Feedback may be used in Nokia Networks products and related specifications or other documentation. Accordingly, if the user of this document gives Nokia Networks feedback on the contents of this document, Nokia Networks may freely use, disclose, reproduce, license, distribute and otherwise commercialize the feedback in any Nokia Networks product, technology, service, specification or other documentation. Nokia Networks operates a policy of ongoing development. Nokia Networks reserves the right to make changes and improvements to any of the products and/or services described in this document or withdraw this document at any time without prior notice. The contents of this document are provided "as is". Except as required by applicable law, no warranties of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose, are made in relation to the accuracy, reliability or contents of this document. NOKIA NETWORKS SHALL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENT or for any loss of data or income or any special, incidental, consequential, indirect or direct damages howsoever caused, that might arise from the use of this document or any contents of this document. This document and the product(s) it describes are protected by copyright according to the applicable laws. Nokia is a registered trademark of Nokia Corporation. Other product and company names mentioned herein may be trademarks or trade names of their respective owners.

3. Document Change H istory Date Version Name Change comment May 2016 1.0 An Donghong 1 st Version

4. After this module, the participants should be able to: Interpret VoLTE UE voice/video call signaling procedures Explain Homing & T-ADS signaling procedures Understand the key signaling IEs which related to VoLTE call handling Objectives

5. Voice/Vedio Call: VoLTE VoLTE UEa P-CSCF / ATCFa S- CSCFa I- CSCFb HSS-IMS INVITE(SDP1) INVITE(SDP3) INVITE(SDP3) HSS-EPC TASa INVITE(SDP3) S-CSCFb TASb P-CSCF / ATCFb UEb INVITE(SDP3) INVITE(SDP3) INVITE(SDP3) LIR LIA INVITE(SDP3) INVITE(SDP3) INVITE(SDP4) UDR UDA 183(SDP6) 183(SDP5) 183(SDP5) 183(SDP5) 183(SDP5) 183(SDP5) 183(SDP5) 183(SDP5) 183(SDP5) 183(SDP2) BGW: AddReq/Reply: Access: SDP2 Core: SDP3 BGW: AddReq/Reply: Access: SDP4 Core: SDP5 PCRF: AAR/AAA(QCI=1) PCRF: AAR/AAA(QCI=1) PRACK PRACK PRACK PRACK PRACK PRACK PRACK PRACK PRACK PRACK 200OK(PRACK) 200OK(PRACK) 200OK(PRACK) 200OK(PRACK) 200OK(PRACK) 200OK(PRACK) 200OK(PRACK) 200OK(PRACK) 200OK(PRACK) 200OK(PRACK) 200OK(PRACK) Suppress ringing. ENUM qurey

6. Voice/Vedio Call: VoLTE VoLTE Cont. UEa P-CSCF / ATCFa S-CSCFa I-CSCFb HSS-IMS HSS-EPC TASa S-CSCFb TASb P-CSCF / ATCFb UEb UPDATE 200OK(UPDATE) 200OK(UPDATE) 200OK(UPDATE) 200OK(UPDATE) 200OK(UPDATE) 200OK(UPDATE) 200OK(UPDATE) 200OK(UPDATE) 200OK(UPDATE) 200OK(UPDATE) 200OK(UPDATE) UPDATE UPDATE UPDATE UPDATE UPDATE UPDATE UPDATE UPDATE UPDATE 180ringing 180ringing 180ringing 180ringing 180ringing 180ringing 180ringing 180ringing 180ringing 180ringing 200OK(INVITE) 200OK(INVITE) 200OK(INVITE) 200OK(INVITE) 200OK(INVITE) 200OK(INVITE) 200OK(INVITE) 200OK(INVITE) 200OK(INVITE) PCRF: AAR/AAA(QCI=1) Flow status change PCRF: AAR/AAA(QCI=1) Flow status change ACK ACK ACK ACK ACK ACK ACK ACK ACK ACK 200OK(INVITE)

7. SIP:INVITE (UEa P-CSCForig) Originating UE initiates the call based on user input. The SIP INVITE contains the SDP offer (including the media type audio, codec(s), bit rate(s), direction info, and so on). The address of the terminating UE is based on user input. The INVITE is sent to the same P-CSCF used at registration time. The P-CSCF identifies the connection information needed (IP address of the down link IP flow(s), port numbers to be used, media type “audio”, and so on) and define downlink connection info. Called Party P-CSCF S-CSCF(coming from the service-route in SIP:REGISTER 200OK.) P-Preferred-Identity header field is used from a UA to a trusted proxy to carry the identity the user sending the SIP message wishes to be used for the P-Asserted-Header field value that the trusted element will insert.

8. SDP offer in SIP:INVITE (UE P-CSCF orig ) Owner Username: root Session ID: 5000 Session Version: 1000 Owner Network Type: IN(internet) Owner Address Type: IP4 Owner Address: 172.18.132.34 SDP in SIP:INVITE Connection Network Type: IN(internet) Connection Address Type:IP4 Connection Address: 172.18.132.34 Media Type: audio Media Port:50010 Media Protocol: RTP/AVP Media Format: DynamicRTP-Type-104 Media Format: DynamicRTP-Type-102 Media Format: DynamicRTP-Type-105 Media Format: DynamicRTP-Type-100 Media level Session level Media Attribute Fieldname: rtpmap Media Format: 104 MIME Type: AMR-WB Sample Rate: 16000 Media Attribute Fieldname: fmtp Media Format: 104(AMR-WB) Media format specific parameters: mode-set=8 Media format specific parameters: mode-change-capability=2 Media format specific parameters: max-red=0 MIME: multipurpose internet mail extension f mtp: format specific parameters Pre-condition parameters AS: application specific maximum Total bandwidth for a single media stream from 1 site RS: RTCP bandwidth allocated to sender RR: RTCP bandwidth allocated to receiver m axptime: maximum amount of packet time(ms) in 1 RTP packet. ptime: 1 media packet time(ms) mode-change-period : Specifies a number of frame-blocks, 40ms interval at which codec mode changes are allowed.              23.85kbps max-red: The maximum redundant transmission time. 0 means no redundancy will be used.

9. MEGACO:AddReq (Voice Call) SDP in SIP:INVITE Access realm Core realm inactive

10. MEGACO:AddReply (Voice Call) Access realm Core realm Inactive AddReply AddRequest

11. MEGACO:AddReq/Rep ( Video Call) AddReply Access realm Core realm Audio stream Video stream AddRequest Audio codecs Video codecs

12. SIP:INVITE ( P-CSCF orig S-CSCF orig ) Forwards the SDP offer from the originating P-CSCF to the termination P-CSCF. BGW core realm termination Originating call Via header added by UE Via header added by P-CSCForig. Process identifier for the P-CSCF, I-CSCF, and S-CSCF is coded within the lskpmc parameter. P-Asserted-Identity header field is used among trusted SIP entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication.

13. SIP:INVITE ( S -CSCF orig TAS orig ) Originating Loop

14. SIP:INVITE ( TAS orig S-CSCF orig ) TAS Private FQDN New call id assigned by TASorig ISC call Change the called party No to INT format

15. Domain-based-routing or Number-based-routing in S-CSCF orig S-CSCFa TASa P -CSCFa UEa SIP-Invite(E164) SIP-Invite(E164) SIP-Invite(E164) SIP-Invite (E164) ENUM ENUM QUERY(E164) RESPONSE Domain Name included? Domain-based-routing Number-based-routing DNS DNS QUERY(DN) RESPONSE(IP) I-BCF/ I-CSCF SIP-Invite Yes No MGCF BGCF SIP-Invite SIP-Invite cs IAM

16. ENUM Query Example

17. Cx: LIR/ LIA LIR LIA

18. SIP:INVITE ( S-CSCF term TAS term ) terminating Loop

19. T-ADS Query ISC: SIP-Invite IDR(T-ADS) Sh: UDA (VoIP support: yes/ no/ unknown) MAP: ATI If VoiP support=yes If VoIP support=no/unk ISC: SIP-Invite (IPMU) No Yes Sh: UDR (T-ADS) SGSN Name included? IMS-VOICE-OVER-PS Supported Unknown Not supported Sh: UDR ( CSRN ) SRI ( MSISDN ) MME TAS(b) S-CSCF(b) HSS HLR MAP: ATI Res. MSS/ VLR PRN ( IMSI ) PRN ACK ( MSRN ) SRI ACK ( MSRN ) Sh: UDA ( MSRN ) ISC: SIP-Invite(MSRN) ‘Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions’ information in HSS DB ? Yes No Support? No Yes ‘ IMS-VOICE-OVER-PS-SUPPORTED’ present? IDA Support? Yes No Yes No SIP-Invite

20. 3GPP 29.272 ULR/NOR Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions NOT_SUPPORTED (0) This value indicates that "IMS Voice over PS Sessions" is not supported, homogeneously, in any of the TAs or RAs associated to the serving node. SUPPORTED (1) This value indicates that "IMS Voice over PS Sessions" is supported, homogeneously, in all of the TAs or RAs associated to the serving node . This value may suppress HSS send T-ADS IDR to MME. If this AVP is not present in the command, it indicates that there is no homogeneous support of IMS Voice Over PS Sessions on all the TA/RAs of the serving node, or that the homogeneity of this support is unknown to the serving node . IDA IMS-Voice-Over-PS-Sessions-Supported NOT_SUPPORTED (0) This value indicates that " IMS Voice over PS Sessions " is not supported by the UE's most recently used TA or RA in the serving node. SUPPORTED (1) This value indicates that " IMS Voice over PS Sessions " is supported by the UE's most recently used TA or RA in the serving node . ‘IMS Voice over PS Sessions’ Capability in MME/SGSN

21. SGSN Address Query No SGSN address SGSN address returned from NT-HLR VoIP not supported

22. IMS Voice Over PS Session Support Status VoIP NOT support VoIP support VoIP: Unknown IMSVoiceOverPSSessionSupport 0 Not support 1 Support 2 Unknown

23. ‘Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions’ Present in ULR S6a: ULR Sh: T-ADS result in UDA, without T-ADS query from MME

24. ‘Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions’ NOT Present in ULR-Part 1 S6a: ULR S6a: IDR

25. ‘Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions’ NOT Present in ULR-Part2 S6a: IDA Sh: T-ADS result in UDA(copy from IDA)

26. ‘IMS-Voice-Over-PS-Sessions-Supported’ in IDA P resent NOT Present IDA IDA IDR

27. UDR & UDA (CSRN) Note: if IMS Voice Over PS Session Support= 0 or 2, CSRN is needed for CS Domain Routing. Ask CSRN from HSS or Add CS prefix to the Called Party No.

28. SIP:INVITE ( TAS term S-CSCF term ) New call id assigned by TASterm ISC call Change the called party ID to sip uri.

29. SIP:INVITE ( S-CSCF term P-CSCF term ) R-URI is changed to T-IMPU by S-CSCFterm if T-IMPU is in the Contact Header in the SIP:Register message.

30. MEGACO:AddReq /AddReply in A- BCF term Access realm Core realm Remote port Stream mode: Inactive Add local ports AddRequest AddReply

31. SIP:INVITE ( P -CSCF term UEb) Access realm port SDP offer

32. SDP answer in SIP:183 & ModReq in P-CSCF term /A-BCF term Pre-condition parameters 2. A-BCFterm send ModReq to BGW Local port Remote port Stream Mode: Send&Receive SDP offer ( audio, RTP/AVP 104, 102, 8, 105, 100) SDP answer ( audio, RTP/AVP 104,105) P-CSCF term UEb Access realm core realm 3. P-CSCFterm P-CSCForig 1. UEbP-CSCFterm

33. SIP:183 and SIP:PRACK

34. SDP offer & SDP answer in SIP:UPDATE & SIP:200OK (UPDATE) SIP:UPDATE SIP:200OK QCI=1 is ready in the calling party QCI=1 is ready in the called party Same codecs

35. SIP:200 (INVITE) & SIP:ACK

36. VoLTE Call Procedures Special Cases

37. Call I nitiation: Separate Invocation of SCC AS and MMTel Roles 1.The Open TAS receives the INVITE request over the ISC UNI containing the RegisteredRoles and InvokedRoles parameters. RegisteredRoles: SCC-AS, MMTel-AS, IP-SM_GW InvokedRoles: SCC-AS 2.The Open TAS validates the received InvokedRoles parameter against the authorized registered roles stored in the internal database. Validation is possible only when all the roles received in the InvokedRoles parameter are registered beforehand. Note : The call is rejected if the validation fails. 3.The Open TAS executes the SCC AS functionalities based on the existing licenses and configurations. 4.The MMTel services are suppressed and MMTel related internal database data is not used. 5.The call is routed back to the S-CSCF. 6.The 3rd party AS is triggered. 7.The Open TAS receives the INVITE request over the ISC UNI, again with the RegisteredRoles and InvokedRoles parameters. RegisteredRoles: SCC-AS, MMTel-AS, IP-SM_GW InvokedRoles: MMTEL-AS 8.Validation again(same as step2) 9.The Open TAS skips the SCC AS functionalities 10.The Open TAS executes the MMTel and IM-SSF functionalities based on the MMTel data stored in the internal database. 11.The call is routed back to the S-CSCF

38. Call Termination: Separate Invocation of SCC-AS and MMTEL roles 1.The Open TAS receives the INVITE request on the ISC NNI with the RegisteredRoles and InvokedRoles parameters . RegisteredRoles: SCC-AS, MMTel-AS, IP-SM_GW InvokedRoles: MMTEL-AS 2.Based on the InvokedRoles parameter, the call is routed to the Sh GW logic, or to MAP based GW logic 3.The Open TAS executes the MMTel and IM-SSF functionalities. 4.The Open TAS sends out a (late) OPTIONS request for getting the location for DP29 . Note: Based on the received TADSType (“external”): if the OPTIONS request fails, then call forwarding is not executed. However, the call is still delivered back to the S-CSCF because the external T-ADS will select a CS network if the UE is not available on the PS network. 5.InvokedRoles validation. . Note: The call is rejected if the validation fails. 6.The call is sent back to the S-CSCF. 7.The 3rd party AS is triggered. 8.The Open TAS receives the INVITE request on the ISC NNI (network-network interface) with the RegisteredRoles and InvokedRoles parameters. RegisteredRoles: SCC-AS, MMTel-AS, IP-SM_GW InvokedRoles: SCC-AS 9.The call is routed to Sh GW and visited terminating services based on one or the combinations of the following parameters: ServiceInfo InvokedRoles TADSType 10.MMTel services are suppressed in the GW and the visited terminating roles. MMTel related internal database data is not used . 11.The Open TAS executes the SCC AS functionalities based on the existing licenses and configurations. 12.Centralized T-ADS is executed. 13.OPTIONS sending is suppressed (considered as successful) based on the InvokedRoles . 14.InvokeRoles validation(same as step5). 15.The call is routed back to the S-CSCF.

39. TAS Modularity Example

40. Optimized MT Homing: Call from CS SIP-Invite(MSISDNb) I/S-CSCF GMSC/MGCF HSS TASb HLR SRI: MSISDN SRI ACK: IMSI, T-CSI IDP CON: IMRNmt SIP-Invite LIR LIA UDR UDA CUE UE is Registered in TAS? No Yes Check UE registration status from HSS? Forming IMRNmt UE is Registered in IMS? Yes Let the call continue normally in the CS Domain No SRI: MSISDN SRI ACK: MSRN MSS/ VLRb PRN: IMSI PRN ACK: MSRN IAM (MSRN) Start T-ADS logic IMS prefix is removed by GMSC/MGCF IMRNmt=MT homing IMS Prefix+MSISDNb

41. MO Homing: VoLTE UE Make a Call from CS Domain SIP-Invite(MSISDNb, orig mode) S-CSCFa HSSa TASa I-CSCFa IDP LIR(IMRNmo) LIA(TASa) UDR UDA May need restore UEa data from HSS Forming IMRNmo Remove IMS prefix, add orig to the outgoing INVITE ENUM query, start domain based routing or number based routing according to the ENUM query result MSS/ VLRa Check Uea’s MO service and mo routing logic CON(IMRNmo) SIP-Invite(IMRNmo) IMRNmo=MO homing IMS Prefix+ MSISDNb SIP-Invite(IMRNmo) SIP-Invite(MSISDNb, orig) SIP-Invite(MSISDNb, orig mode) LIR(MSISDNa) LIA(S-CSCFa or S-CSCF Capability) SIP-Invite(MSISDNb) SAR/SAA Ma interface SIP:INVITE ISC interface SIP:INVITE

42. VoLTE Originating Video Call , Terminated to CS

43. VoLTE Terminating Video Call: Downgrade to Audio to Connect a Setup Phase Announcement

44. VoLTE Terminating Video Call: Downgrade to Audio to Connect a Setup Phase Announcement and Upgrade Back to Video

45. Terminating Call , VoLTE Phone is Registered over LTE, Softphone is Registered Note: Additionally, there can be multiple softphones registered with a different instanceID and IMPI . In this sub use case, those devices are alerted in parallel as well.

46. Terminating Call , VoLTE Phone Attached to CS is NOT Registered to IMS, Softphone is Registered