E.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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

E.3.1 Procedures at the UE

E.3.1.0 Registration and authentication

In order to reach IMS in some 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; and

– UE requested FTT-IMS establishment procedure specified in 3GPP TS 24.322 [8Y].

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

1) UE uses neither 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.

E.3.1.0a IMS_Registration_handling policy

Not applicable.

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

The UE may, but need not, include the P-Access-Network-Info header field where indicated in subclause 5.1.

E.3.1.1A Cellular-Network-Info header field

Not applicable.

E.3.1.2 Availability for calls

Not applicable.

E.3.1.2A Availability for SMS

Void.

E.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.

E.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.

E.3.1.5 3GPP PS data off

Not applicable.

E.3.1.6 Transport mechanisms

No additional requirements are defined.

E.3.1.7 RLOS

Not applicable.

E.3.2 Procedures at the P-CSCF

E.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.

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

In order to determine from which network the request was originated the P-CSCF shall check if the location information received in the network provided and/or UE provided "dsl-location", "eth-location" or "fiber-location" parameter in the P-Access-Network-Info header field(s) belongs to a location in the same country.

NOTE 1: If local policy does not require the insertion of P-Access-Network-Info header field in the P-CSCF even if it is missing in the received initial request, the P-CSCF can assume that the request is initiated by fixed broadband UE in the same country.

NOTE 2: If the location information in the network provided and UE provided "dsl-location", "eth-location" or "fiber-location" parameters (in a request that includes two P-Access-Network-Info header fields) is contradictory, or the two P-Access-Network-Info header fields indicate different access types the P-CSCF ignores either the network provided or the UE provided information according to operator policy.

E.3.2.2 Location information handling

Upon receipt of an initial request for a dialog or standalone transaction or an unknown method, the P-CSCF based on local policy may include a P-Access-Network-Info header field.The value of the "dsl-location", "eth-location" or "fiber-location" parameter shall be the value as received in the Location-Information header in the User-Data Answer command as specified in ETSI ES 283 035 [98].

NOTE: The way the P-CSCF deduce that the request comes from a UE connected through xDSL access is implementation dependent.