R.3 Application usage of SIP

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

R.3.1 Procedures at the UE

R.3.1.0 Registration and authentication

Editor’s note: [WID: TURAN-CT, CR#4993]: Best usage of this FTT-IMS establishment is when the UE does not establish the IKEv2 security association which is an option not specified in subclause R.2.2.1. This requires further study.

In order to reach the IM CN subsystem in some untrusted access networks, the UE may support:

– address and/or port number conversions provided by a NA(P)T or NA(P)T-PT as described in annex F and annex K; or

– the IP UE requested FTT-IMS establishment procedure specified in 3GPP TS 24.322 [8Y], which is applicable to direct access to an external IP network and not applicable to access through a PLMN.

If a UE supports one or both of these capabilities then a UE may progressively try them to overcome failure to reach the IPM CN subsystem. Use of these capabilities shall have the following priority order:

1) UE does not use capability because reaching the IMS without an intervening NA(P)T, NA(P)T-PT, or tunnel is preferred.

2) UE may use address and/or port number conversions provided by a NA(P)T or NA(P)T-PT as described in either annex F or annex K.

3) UE may use the UE requested FTT-IMS establishment procedure specified in 3GPP TS 24.322 [8Y]. If the UE uses the UE-requested FTT-IMS establishment procedure specified in 3GPP TS 24.322 [8Y], the UE considers itself to:

– be configured to send keep-alives;

– be directly connected to an IP-CAN for which usage of NAT is defined; and

– be behind a NAT.

Optional procedures apply when the UE is supporting traversal of restrictive non-3GPP access network using STUN/TURN/ICE, as follows:

a) the protection of SIP messages is provided by utilizing TLS as defined in 3GPP TS 33.203 [19];

b) the mechanisms specified in this annex shall only be applicable when the IP traffic to the IMS core does not traverse through the Evolved Packet Core (EPC);

c) the UE shall establish the TLS connection to the P-CSCF on port 443 as defined in 3GPP TS 33.203 [19]. The UE shall use SIP digest with TLS for registration as specified in subclause 5.1. If the TLS connection is established successfully, the UE sends SIP signalling over the TLS connection to the P-CSCF;

d) the UE shall support the keep-alive procedures described in RFC 6223 [143];

NOTE 1: If the UE is configured to use an HTTP proxy, the UE use the HTTP CONNECT method specified in RFC 2817 [220] to request the HTTP proxy to establish the TCP connection with the P-CSCF. Once the UE has received a positive reply from the proxy that the TCP connection has been established, the UE initiates the TLS handshake with the P-CSCF and establishes the TLS connection.

e) the procedures described in subclause K.5.2 apply with the additional procedures described in the present subclause;

f) when using the ICE procedures for traversal of restrictive non-3GPP access network, the UE shall support the ICE TCP as specified in RFC 6544 [131] and TURN TCP as specified in RFC 6062 [221].

g) if the UE is configured to use TURN over TCP on port 80, the UE shall establish the TCP connection to TURN server on port 80. If the UE is configured to use TURN over TLS on port 443, the UE shall establish the TLS connection to the TURN server on port 443 as defined in 3GPP TS 33.203 [19]. If the UE is configured to use both, the UE should prefer to use TURN over TCP on port 80 to avoid TLS overhead;

h) if the connection is established successfully, the UE sends TURN control messages and media packets over the connection as defined in RFC 5766 [101].

NOTE 2: If the UE is configured to use an HTTP proxy, the UE use the HTTP CONNECT method specified in RFC 2817 [220] to request the HTTP proxy to establish the TCP connection with the TURN server. Then, if the UE is configured to use TURN over TLS on port 443 and the UE has received a positive reply from the proxy that the TCP connection has been established, the UE initiates the TLS handshake with the TURN server and establishes the TLS connection.

The UE shall perform reregistration of a previously registered public user identity bound to any one of its contact addresses when changing to an IP-CAN for which usage is specified in annex B, annex L or annex U. The reregistration is performed using the new IP-CAN.

NOTE 3: This document does not specify how the UE detects that the used IP-CAN has changed. The information that is forcing the reregistration is also used to generate the content for the P-Access-Network-Info header field.

NOTE 4: The UE will send the reregistration irrespective of whether it has a SIP dialog or not.

R.3.1.0a IMS_Registration_handling policy

Not applicable.

R.3.1.1 P-Access-Network-Info header field

The UE shall always include the P-Access-Network-Info header field where indicated in subclause 5.1.

R.3.1.1A Cellular-Network-Info header field

The UE:

1) using the Evolved Packet Core (EPC) via Untrusted Wireless Local Access Network (WLAN) as IP-CAN to access the IM CN subsystem; and

2) supporting one or more cellular radio access technology (e.g. E-UTRAN);

shall always include the Cellular-Network-Info header field specified in subclause 7.2.15, if the information is available, in every request or response in which the P-Access-Network-Info header field is present.

NOTE: If the Cellular-Network-Info header field includes radio cell identity, then the Cellular-Network-Info header field populated by the UE that supports Multi-RAT Dual Connectivity with the EPC as described in 3GPP TS 37.340 [264] will contain the information about the radio cell identity of the Master RAN node that is serving the UE.

R.3.1.2 Availability for calls

Not applicable.

R.3.1.2A Availability for SMS

Void.

R.3.1.3 Authorization header field

When using SIP digest or SIP digest without TLS, the UE need not include an Authorization header field on sending a REGISTER request, as defined in subclause 5.1.1.2.1.

NOTE: In case the Authorization header field is absent, the mechanism only supports that one public user identity is associated with only one private user identity. The public user identity is set so that it is possible to derive the private user identity from the public user identity by removing SIP URI scheme and the following parts of the SIP URI if present: port number, URI parameters, and To header field parameters. Therefore, the public user identity used for registration in this case cannot be shared across multiple UEs. Deployment scenarios that require public user identities to be shared across multiple UEs that don’t include an private user identity in the initial REGISTER request can be supported as follows:

– Assign each sharing UE a unique public user identity to be used for registration,

– Assign the shared public user identitiess to the implicit registration set of the unique registering public user identities assigned to each sharing UE.

R.3.1.4 SIP handling at the terminating UE when precondition is not supported in the received INVITE request, the terminating UE does not have resources available and IP-CAN performs network-initiated resource reservation for the terminating UE

Not applicable.

R.3.1.5 3GPP PS data off

Not applicable.

R.3.1.6 Transport mechanisms

The transport mechansims as defined in subclause 4.2A are used with an additional requirement:

a) If the UE has attached to the EPC via untrusted non-3gpp access and uses IPSec tunnel mode, in order to reduce the risk of UDP fragmentation, the UE shall decrement the IPSec tunnel overhead from the path MTU between the UE and the ePDG prior applying the transport selection for SIP requests as defined in RFC 3261 [26] subclause 18.1.1.

NOTE: The method for discovering the maximum transmission unit for non-3GPP is implementation dependent and out of scope of 3GPP.

R.3.1.7 RLOS

Not applicable.

R.3.2 Procedures at the P-CSCF

R.3.2.0 Registration and authentication

The P-CSCF may support UEs connected via restrictive non-3GPP access network.

If the P-CSCF supports UEs connected via restrictive non-3GPP access network, when the P-CSCF receives a 200 (OK) response to a REGISTER request, if the contact address of REGISTER request contains an IP address assigned by the EFTF, and the UE’s Via header field contains a "keep" header field parameter, then the P-CSCF shall add a value to the "keep" header field parameter of the UE’s Via header field of the 200 (OK) response as defined in RFC 6223 [143].

Optional procedures apply when the P-CSCF is supporting traversal of restrictive non-3GPP access network using STUN/TURN/ICE, as follows:

NOTE: In this scenario, the restrictive non-3GPP access network coexists with NA(P)T device located in the customer premises domain:

a) the protection of SIP messages is provided by utilizing TLS as defined in 3GPP TS 33.203 [19];

b) the P-CSCF supporting these additional procedures should use SIP digest with TLS as defined in subclause 5 and the P-CSCF should inserts an IMS-ALG on the media plane;

c) the mechanisms specified in this annex shall only be applicable when the IP traffic to the IMS core does not traverse through the Evolved Packet Core (EPC);

d) the P-CSCF shall support the procedures defined in subclause 5.2, with the exception that the P-CSCF shall use SIP over TLS on port 443 as defined in 3GPP TS 33.203 [19];

e) when the UE has indicated support of the keep-alive mechanism defined in RFC 6223 [143], the P-CSCF shall indicate to the UE that it supports the keep-alive mechanism; and

f) the IMS-ALG in the P-CSCF shall support ICE procedures, as defined in subclause 6.7.2.7.

R.3.2.1 Determining network to which the originating user is attached

If the P-CSCF is configured to handle emergency requests, in order to determine from which network the request was originated the P-CSCF shall,

– if PCRF is used for this UE and 3GPP-User-Location-Info as specified in 3GPP TS 29.214 [13D] is available (see subclause 5.2.1), check the MCC and MNC received in 3GPP-User-Location-Info; and

– if PCRF is not used for this UE or 3GPP-User-Location-Info is not available, check the MCC and MNC fields received in the Cellular-Network-Info header field in the emergency request.

NOTE 1: The Cellular-Network-Info header field includes the MCC and the MNC of the cellular radio access network on which the UE most recently camped. The UE is not necessarily attached to a network via that cell or still camped on that cell.

NOTE 2: The above check can be against more than one MNC code stored in the P-CSCF.

R.3.2.2 Location information handling

Void.

R.3.2.3 Prohibited usage of PDN connection for emergency bearer services

If the P-CSCF detects that a UE uses a PDN connection for emergency bearer services for a non-emergency REGISTER request, the P-CSCF shall reject that request by a 403 (Forbidden) response.

NOTE: By assigning specific IP address ranges for a PDN connection for emergency bearer services and configuring those ranges in P-CSCF, the P-CSCF can detect based on the registered Contact address if UE uses an emergency PDN connection for initial registration.

R.3.2.4 Void

R.3.2.5 Void

R.3.2.6 Resource sharing

If PCC is supported for this access technology a P-CSCF supporting resource sharing shall apply the procedures in subclause L.3.2.6.

NOTE: Resource sharing has in this version of the specification no meaning in the WLAN IP CAN. However, since transfer to EPS IP CAN is seamless from P-CSCF point of view the resource sharing options used over the Rx interface when the UE is attached to the WLAN IP CAN could be used when the UE moves to EPS IP CAN and since Rx requires the resource sharing options to be included in the initial AAR the resource sharing options need to be included also when the UE attached to the WLAN IP CAN initiates or receives a INVITE request.

R.3.2.7 Priority sharing

If PCC is supported for this access technology a P-CSCF supporting priority sharing and if according to operator policy shall apply the procedures in subclause L.3.2.7.

R.3.2.8 RLOS

Not applicable.

R.3.3 Procedures at the S-CSCF

R.3.3.1 Notification of AS about registration status

Not applicable.

R.3.3.2 RLOS

Not applicable.