E2E VoLTE call setup(3/4) - Voice call setup

Once the IMS registration is successfully done between the UE and the IMS network, the user can make a VoLTE call. Upon request for voice call from the user, the VoLTE UE starts SIP signaling with the IMS core. The SIP messages are routed based on initial Filter Criteria (iFC) in the IMS Core and delivers SDP offer and answer to establish media session along with various SIP headers. As a consequence of the SIP signaling, a new dedicated EPS bearer is established between the UE and the SGW/PGW which is used to transfer voice media. The QoS of this new dedicated EPS bearer is defined by the PCC rules generated by the PCRF.

Introduction

While the SIP messages go through the default EPS bearer (QCI=5) towards the IMS core, the voice media path is established at the front-end NEs taking the role of IMS Application Level Gateway (IMS-ALG) and IM Access Gateway based on SDP negotiation. The following diagram shows the conceptual diagram of IMS-ALG and IMS Access Gateway model specified in 3GPP TS23.228. The IMS-ALG controls media resources and gating functions of the IM Access Gateway over Iq interface. It acts as a B2BUA and can modify the SDP and SIP headers of SIP messages if necessary. The IM Access Gateway executes the allocation and release of transport addresses, IP versioning and the media gating function under the control of the IMS-ALG.

Fig 1. IMS-ALG and IMS Access Gateway model

The following diagram shows how the media path is established. Upon request from the user for voice call setup, the UE sends VoLTE call setup request (i.e., SIP INVITE) to the IMS core with an SDP offer, which contains the allocated media information of the originating UE [A]. The IMS-ALG allocates media resource in the IM Access Gateway to which the originating VoLTE UE can access. The allocated media information at IM Access Gateway is sent back to the UE in the response as an SDP answer [a]. The IMS-ALG allocates additional media resource for the upstream, includes it in the SDP offer and sends it towards the remote IMS-ALG [B]. The IMS-ALG in the remote IMS network responds with the SDP answer containing the media access point of IM Access Gateway in the same network [b]. The IMS-ALG in the remote network also allocates another media resources and sends it to the UE as an SDP offer [C]. In turn, the UE will also send back the response including SDP answer of its own [c].

NOTE the gray arrow indicates the signaling path and the rest indicate the media path and its direction.

Fig 2. Media path establishment

NOTE The IM Access Gateway functionality is typically provided by Service Border Controller (SBC).

II. VoLTE call setup procedure

Upon request from the user for VoLTE call setup, the UE initiates SIP signaling with the IMS core. The P-CSCF address is informed to the UE when the UE attaches to the network. The signaling path beyond the P-CSCF is determined based on a routing mechanism of IMS core. The SDP negotiation is performed along with the SIP signaling and determines the media path for voice call setup.

Upon receiving call setup request (i.e., SIP INVITE), the P-CSCF informs the PCRF of the service data flow information. The PCRF triggers the Evolved Packet Core (EPC) to create a dedicated EPS bearer of QCI=1 for voice media by generating and provisioning PCC rules to the SGW/PGW. The PCC rules include QoS parameters and rules to be applied to service data flows based on which the SGW/PGW establishes mapping relations between service data flows and the EPS bearers.

NOTE Based on GSMA IR.92, the UE is strongly recommended to support the precondition framework for VoLTE. Please note that, in the following practice, the precondition procedure has been disabled before testing. Please refer to FCM.01, IR.92 and 3GPP TS 24.229 for the detail.

NOTE While the following procedure shows the only originating side, the same procedure and principles can also be applied to the terminating side. The signaling procedure handled within the IMS core has not been described to avoid complexities as it can vary based on the deployment architecture as per IMS vendor.

Fig 3. VoLTE setup call flow

[48] Upon request from the user to make a voice call, the originating UE sends the SIP INVITE towards the P-CSCF.

• Supported header: a list of option tags indicating supporting features. In this example, the "timer" and "100rel" indicate support of session timer and a reliable delivery of the provisional response (i.e., 183 Session In Progress), respectively.
• P-Early-Media header: indicator of whether the UE supports the early media mode.
• Allow header: a list of SIP methods that is supported by the UE.
• P-Preferred-Identity header: the originating user's identity that is preferred by the originating user to be used. This header is replaced with the P-Asserted-Identity header by the P-CSCF in the IMS network. If the SIP message is sent towards untrusted IMS core, the P-Asserted-Identity header shall be removed.
• User-Agent header: VoLTE client information
• Privacy header: preference of sending UE indicating that any sensitive information shall be hidden from any parties that do not need to know it.
• Accept-Contact header: a list of features of target UE preferred by the sending UE
• P-Access-Network-Info header: the radio access technology and cell identity.
• Session-Expires header: a valid period of time of this SIP INVITE session. The parameter “uac” indicates that the sending UE will refresh the session before the timer is expired.
• P-Preferred-Service header: service identification user wishes to be used. This header is replaced with the P-Asserted-Service header by the P-CSCF.
• Content-Type: media type of the message-body sent to the recipient.
• Route header: a list of IP addresses of intermediary nodes which the SIP request will go through. This would a copy of Service-Route header returned in 200 OK response to SIP REGISTER, which is inserted by the S-CSCF. The Service-Route header indicates the intermediary node associated with that S-CSCF.
• From header: sending user’s SIP URI or TEL URI
• To header: recipient’s SIP URI or TEL URI
• Call-ID header: a globally unique identifier of the SIP session. All the SIP messages of the same session must have the same Call-ID value.
• CSeq header: sequence of the same SIP method. The sequence number is incremented as the same SIP method is being sent.
• Max-Forwards header: maximum number of hops that the message can go through.
• Contact header: the contact address, device capabilities, feature-tags, etc. of the sending UE.
• Via header: a list of SIP addresses of intermediary nodes. The entry is inserted by each node that wants to stay in the signaling path for the SIP response. The response message for this request (e.g., 183 session in progress, 100 Trying, 200 OK, etc) will be transferred to the originating UE following the reverse path listed in this header.
• Content-Length: body length in bytes.

Fig 4. headers in SIP INVITE

The SIP INVITE contains an SDP offer. The SDP defines media information of the sending node which contains the contact ip address, port number and a list of supporting codec information. The following shows descriptions of each parameters used in SDP.

• ‘o’ (originator and session identifier): <username><session-id><network type><address type><ip address>
• ‘s’ (session name): any textual session name
• ‘c’ (connection data): <network type><address type><connection address>
• ‘t’ (timing): <start time><stop time>
• ‘m’ (media description): <media type><port><protocol><fmt: media format description>
• ‘b’ (bandwidth): AS (application specific) – maximum RTP session bandwidth (kbytes), RS – sending RTCP bandwidth (bytes), RR – receiving RTCP bandwidth (bytes)
• ‘a=rtpmap’ (attributes): <payload type><encoding name><clock rate><encoding parameters>
• ‘a=fmtp’(attributes): format specific parameters related with the corresponding media
• ‘a=ptime’(attributes): length of time represented by the media in a packet (ms)
• ‘a=maxptime’(attributes): maximum amount of media that can be encapsulated in each packet(ms)

The following is an SDP example included in the SIP INVITE captured on the Gm interface. The UE’s IP address is “100.64.63.41” and port number for audio is “1234”, which is depicted as [A] in Fig2.

Fig 5. Attributes in Session Description Protocol (SDP) offer

NOTE Upon receiving the SIP INVITE with an SDP offer, the P-CSCF may send service data information to the PCRF of which flow-status AVP set to ‘DISABLED’. In this case, the P-CSCF will send additional service data information when it receives the 183 Session In Progress with SDP answer. In the following example, the service data information is sent only once when the P-CSCF obtains SDP offer and answer all together at step #48.

The P-CSCF responds with a 100 Trying provisional response. The provisional response is a one-way response sent back to the originating side used as informative. It is not necessarily guaranteed for its safe arrival.

Fig 6. Parameters in 100 Trying

[49] 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 S-CSCF forwards it to the P-CSCF.

• Record-Route header: a list of IP addresses that is copied from the Route header by the terminating UE in the received SIP INVITE. The value of this header will be reused by the originating UE when it composes Route header upon sending subsequent SIP request.
• Require header: a list of option tags indicating features that needs to be supported by the recipient (i.e., the originating UE) of this message. In this case, the "100rel" indicates the originating UE shall support the reliable delivery of provisional response. 

NOTE the provisional response, 1xx, is an informative response therefore it does not usually require the reliable delivery. However, 183 Session In Progress would be an exception as it contains the SDP answer.

• RSeq header: the sequence number of this response. The value of this header is copied to the CSeq header in the following SIP PRACK sent by the originating UE.
• P-Asserted-Identity header : the authorized user's identity of the sending user of this message (i.e., the terminating user)
• P-Charging-Vector header: a collection of charging information, which consists of IMS Charging Identity (ICID) value, the address of the SIP proxy that creates the ICID value and the Inter Operator Identifiers (IOI). The ICID indicates a globally unique charging value that identifies a dialog, the IOI identifies both the originating and terminating networks involved in a SIP dialog. In the following example, the full text for the header is as follow:

icid-value=0.274.195-1418282284.647;term-ioi=32345;term-ioi=22345;icid-generated-at=10.75.0.5;term-ioi=Type3Term;orig-ioi=32345

Fig 7. Headers in 183 Session In Progress

[50] Upon receiving the 183 Session In Progress, the P-CSCF triggers the Authentication and Authorization Request (AAR) towards the PCRF to inform the fact that there is a new Application Focus (AF) session being created. The PCRF performs session binding between the AF session and the corresponding IP-CAN session.

NOTE AF indicates an element offering applications that require the Policy and Charging control of the user plane resources. In this context, it indicates the P-CSCF.

• Session-Id AVP: identifier of Rx session for this application. It lasts until this application (i.e., VoLTE session) does exist.
• AF-Application-Identifier AVP: identifier of the VoLTE call session assigned by the P-CSCF.
• Media-Component-Description AVP: media information of the service data flow
• Service-Info-Status AVP: the status of the service information that the P-CSCF is providing to the PCRF.
• FINAL SERVICE INFORMATION (0): the service has been fully negotiated between the two nodes and the provided service information is the result of the negotiation.
• PRELIMINARY SERVICE INFORMATION (1): the provided service information is a preliminary and further negotiation is to be needed between two nodes.

NOTE In this example, the value is set to be “FINAL SERVICE INFORMATION” as the P-CSCF has both SDP offer and answer.

• AF-Charging-Identifier AVP: identifier for charging correlation with bearer layer.
• Specific-Action AVP: a list of events that P-CSCF wants to be informed from the PCRF. The PCRF shall report to the P-CSCF when any of these events occurs.
• Subscription-Id AVP: identifier of the end user’s subscription. It holds subscription type and data. Multiple instances of the subscription-id indicates multiple type of identifiers of the same subscriber such as E164, SIP URI, IMSI, etc.
• Framed-IP-Address AVP: UE’s IP address which is allocated by the PGW during initial attach procedure.
• Required-Access-Info AVP: indicator of query by the P-CSCF for access network information.

Fig 8. AVPs in AAR

The Media-Component-Description AVP reflects the SDP offer and answer which includes the media type, direction and codec information.

• Media-Sub-Component AVP: descriptions for media flows. There are two sub components appears in this snapshot, one for RTP and the other one for RTCP.
• Flow-Description AVP: description for IP flow in each direction, of which IP addresses and port numbers are copied from the SDP offer and answer by the P-CSCF.
• Uplink IP flow: UE (“100.64.63,41”, “1234”) à SBC (“10.75.23.197”, “10570”)
• Downlink IP flow: SBC (“10.75.23.197”, “10570”) à UE (“100.64.63,41”, “1234”)
• Flow-Status AVP: permission status of each media flow.
• ENABLED-UPLINK (0): enable associated uplink IP flow(s) only.
• ENABLED-DOWNLINK (1): enable associated downlink IP flow(s) only.
• ENABLED (2): enable all associated IP flow(s)
• DISABLED (3): disable all associated IP flow(s)
• REMOVED (4): remove all associated IP flow(s)
• Media-Type AVP: the type of media stream e.g., audio, video, data, text, message.
• Max-Requested-Bandwidth-UL/DL AVP: the Maximum Bit Rate (MBR) of the IP flow in each direction. The bandwidth contains all the overhead coming from IP layer and the layer above e.g., IP, UDP, RTP, RTP payload.
• RS-Bandwidth AVP: maximum required bandwidth for RTCP sender reports.
• RR-Bandwidth AVP: maximum required bandwidth for RTCP receive reports.
• Codec-Data AVP: codec related information known at the P-CSCF.

Fig 9. Sub-AVPs of Media-Component-Description AVP

[51] Upon receiving the AAR, the PCRF generates PCC rules. PCC rules includes IP flow description for uplink and downlink (i.e., 5-tuple), QoS information, the flow status, etc. The SGW/PGW performs bearer binding between the received PCC rules and the corresponding IP-CAN bearer. The IP flow shall be mapped to a specific IP-CAN bearer based on these PCC rules by the SGW/PGW

• Charging-Rule-Definition AVP: A PCC rule. There are two PCC rules showing up for voice call, one for RTP and the other one for RTCP.
• Charging-Rule-Name AVP: A PCC rule name. It is uniquely defined within the same IP-CAN. If the PCC rule is pre-defined in PGW as is the case for default EPS bearer, it is uniquely defined within the PGW.
• Flow-Information AVP: a single IP flow packet filter. It includes the ip address and port number and the direction of the IP flow.
• Flow-Status AVP: permission status of each media flow. Refer to step#49 for the detail.
• QoS-Information AVP: QoS information to be applied to the IP flow, which includes QoS Class Identifier (QCI), GBR (Guaranteed Bit Rate), MBR (Maximum Bit Rate) and ARP (Allocation Retention Precedence).
• QoS-Class-Identifier AVP: QoS Class Identifier
• Guaranteed-Bitrate-UL/DL AVP: guaranteed for service data flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above e.g., IP, UDP, RTP and RTP payload.
• Max-Requested-Bandwidth-UL/DL AVP: the Maximum Bit Rate (MBR) of the IP flow in each direction. The bandwidth contains all the overhead coming from IP layer and the layer above e.g., IP, UDP, RTP, RTP payload.
• Allocation-Retention-Priority AVP: The priority of allocation and retention. When a new media resource is required to be allocated and all the resources are already occupied, the PGW can release the allocated media resource and re-allocate it for the new IP flow based on this value.
• Precedence AVP: the order of applying the service data flow template consisting of service data flow filters to the service data flow at PGW.
• Flows AVP: Indicator of the IP flow to which this PCC rule is to be applied.

Fig 10. AVPs of RAR

[52] The SGW/PGW initiates the EPS bearer creation procedure and responds with the Re-Auth-Answer (RAA) to the PCRF.

• Access-Network-Charging-Address AVP: IP address of the network entity within the access network performing charging.
• 3GPP-SGSN-MCC-MNC AVP: MCC and MNC of the access network.
• 3GPP-User-Location-Info AVP: UE’s current location. It is composed of Tracking Area Identity (TAI) and E-UTRAN Cell Global Identifier (ECGI).

Fig 11. AVPs of RAA

[53] The PCRF responds with the AAA to the P-CSCF.

Fig 12. AVPs of AAA

[54] Upon receiving the successful AAA from the PCRF, the P-CSCF continues the SIP signaling by forwarding the 183 Session In Progress towards the UE. The following snapshot shows headers of 183 Session In Progress captured on Gm interface.

• P-Early-Media header: indicator of whether the UE supports the early media mode. The early media option has been disabled in the practice.

Refer to step#47 and step#48 for the detailed description for SIP headers.

Fig 13. Headers of 183 Session In Progress

The following snapshot shows the SDP answer included in the 183 Session In Progress. The SBC is going to be a peer node from UE’s perspective. Given that, the IP address and port number represents the SBC to which the originating UE shall connect for media. The codec information represents the one supported by the SBC. Refer to step#47 for the detailed description for SDP attributes.

Fig 14. SDP answer in 183 Session In Progress

The SDP answer delivered to the originating UE shows the IP address is 10.75.23.197 and port number is 10570, which is depicted as [a] in Fig2.

[55] The UE confirms that the 183 Session In Progress with SDP answer has been received safely by sending SIP PRACK.

• RACK header: the sequence number the corresponding 183 Session In Progress and the SIP INVITE.

Refer to step#47 for the detailed description for other headers.

Fig 15. Headers in SIP PRACK

[56] The 200 OK response to the SIP PRACK is received by the UE.

Fig 16. Headers in 200 OK for PRACK

[57] The 180 Ringing provisional response is received by the UE. It indicates the voice call setup request is being notified to the recipient. Refer to step#47 and step#48 for the detailed description for headers.

NOTE If the option tag ‘100rel’ appears in the Require header, the UE shall acknowledge the provisional response by sending PRACK. If it appears in Supported header, it is just informative.

Fig 17. Headers in 180 Ringing

[58] The 200 OK response for the SIP INVITE is received by the UE. It indicates that the terminating user answered the phone. Upon receiving the response, the UE allocates the media resource. Refer to step#47 and step#48 for the detailed description for headers.

Fig 18. Headers in 200 OK for SIP INVITE

[59] The UE sends SIP ACK towards the terminating user. Refer to step#47 for the detailed description for headers.

Fig 19. Headers in SIP ACK

Red Mouse

REFERENCES

[1] 3GPP TS 23.228, "IP Multimedia System (IMS); Stage 2", v11.4.0, Mar 2012

[2] 3GPP TS 24.229, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); stage3", v11.3.0, Mar 2012

[3] 3GPP TS 24.628, "  ", v11.3.0, Mar 2012

[4] 3GPP TS 29.212, "Policy and Charging Control (PCC); Reference points", v12.6.0, Sep 2014

[5] 3GPP TS 29.214, "Policy and Charging Control over Rx reference point", v12.5.0, Sep 2014

[6] IETF RFC7315, "Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for 3GPP", July 2014

[7] IETF RFC4028, "Session Timer in the Session Initiation Protocol (SIP)", Apr 2005

[8] IETF RFC3264, "A offer and answer model with the Session Description Protocol (SDP)", Jun 2002

[9] IETF RFC3262, "Reliability of the Provisional Responses in Session Initiation Protocol (SIP)", Jun 2002

[10] IETF RFC3608, “Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration”, Oct, 2003

Last Updated: 26th Dec 2015