F.2 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

F.2.1 UE usage of SIP

F.2.1.1 General

This subclause describes the UE SIP procedures for supporting hosted NAT scenarios. The description enhances the procedures specified in subclause 5.1.

The UE shall support the symmetric response routeing mechanism according to RFC 3581 [56A].

F.2.1.2 Registration and authentication

F.2.1.2.1 General

The text in subclause 5.1.1.1 applies without changes

F.2.1.2.1A Parameters contained in the ISIM

The text in subclause 5.1.1.1A applies without changes

F.2.1.2.1B Parameters provisioned to a UE without ISIM or USIM

The text in subclause 5.1.1.1B applies without changes.

F.2.1.2.2 Initial registration

The procedures described in subclause 5.1.1.2.1 apply with the additional procedures described in the present subclause.

NOTE 1: In accordance with the definitions given in subclause 3.1 the IP address acquired initially by the UE in a hosted NAT scenario is the UE private IP address.

On sending a REGISTER request, the UE shall populate the header fields as indicated in subclause 5.1.1.2.1 with the exceptions of subitems c) and d) which are modified as follows

The UE shall populate:

c) a Contact header field according to the following rules: if the REGISTER request is sent without integrity protection, the Contact header field shall be set to include SIP URI(s) containing the private IP address of the UE in the hostport parameter or FQDN. If the UE supports GRUU, the UE shall include a "+sip.instance" header field parameter containing the instance ID. If the REGISTER request is integrity protected, the UE shall include the public IP address or FQDNin the hostport parameter. The UE shall only use a FQDN in a protected REGISTER request, if it is ensured that the FQDN resolves to the public IP address of the NAT. If the UE supports GRUU, the UE shall include a "+sip.instance" header field parameter containing the instance ID. The UE shall include all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3840 [62] for the IMS communication services it intends to use, and IARI values (coded as specified in subclause 7.2A.9.2), for the IMS applications it intends to use in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840 [62];

NOTE 2: The UE will learn its public IP address from the "received" header field parameter in the topmost Via header field in the 401 (Unauthorized) response to the unprotected REGISTER request.

d) a Via header field according to the following rules: if the REGISTER request is sent without integrity protection, the Via header field shall be set to include the private IP address or FQDN of the UE in the sent-by field. If the REGISTER request is integrity protected, the UE shall include the public IP address or FQDN in the sent-by field. The UE shall only use a FQDN in a protected REGISTER request, if it is ensured that the FQDN resolves to the public IP address of the NAT. Unless the UE has been configured to not send keep-alives, it shall include a "keep" header field parameter with no value in the Via header field, in order to indicate support of sending keep-alives associated with, the registration, as described in RFC 6223 [143];

NOTE 3: If the UE specifies a FQDN in the host parameter in the Contact header field and in the sent-by field in the Via header field of an unprotected REGISTER request, this FQDN will not be subject to any processing by the P-CSCF or other entities within the IM CN subsystem. The means to ensure that the FQDN resolves to the public IP address of the NAT are outside of the scope of this specification. One option for resolving this is local configuration.

If IMS AKA is used as a security mechanism, on sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields as defined in subclause 5.1.1.2.2, with the exceptions of subitems c), and d) which are modified as follows:

d) the Security-Client header field set to specify the security mechanisms the UE supports, the IPsec layer algorithms the UE supports and the parameters needed for the security association setup. The UE shall support the setup of two pairs of security associations as defined in 3GPP TS 33.203 [19]. The syntax of the parameters needed for the security association setup is specified in Annex H of 3GPP TS 33.203 [19]. The UE shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The UE shall support the IPSec layer algorithms for integrity protection and for encryption as defined in 3GPP TS 33.203 [19], and shall announce support for them according to the procedures defined in RFC 3329 [48]. In addition to transport mode the UE shall support UDP encapsulated tunnel mode as per RFC 3948 [63A] and shall announce support for both modes as described in TS 33.203 [19];

When a 401 (Unauthorized) response to a REGISTER is received and this response is received without integrity protection, the procedures described in subclause 5.1.1.2.1 apply with the following additions:

The UE shall compare the IP address in the "received" header field parameter with the corresponding value in the sent-by parameter in the topmost Via header field to detect if the UE is behind a NAT. If the comparison indicates that the respective values are the same, the UE concludes that it is not behind a NAT.

– If the UE is not behind a NAT, the UE shall proceed with the procedures described in subclause 5.1 of the main body of this specification;

– If the UE is behind a NAT, the UE shall verify using the Security-Server header field that mode "UDP-enc-tun" is selected. If the verification succeeds the UE shall store the IP address contained in the "received" header field parameter as the UE public IP address. If the verification does not succeed the UE shall abort the registration. When the UE detects that it is behind a NAT, the UE may include a transport=tcp URI parameter in the Contact header when it sends a protected REGISTER.

NOTE 4: The UE includes a transport=tcp parameter to ensure that P-CSCF uses TCP connection when it receives an initial request for a dialog or a request for a standalone transaction destined for the UE.

In addition, when a 401 (Unauthorized) response to a REGISTER is received (with or without integrity protection) the UE shall behave as described in subclause F.2.1.2.5.

When the UE, that is behind a NAT, receives a 400 (Bad Request) response with 301 Warning header field indicating "incompatible network address format" to the unprotected REGISTER request, the UE shall randomly select new values for the protected server port and the protected client port, and perform new initiate registration procedure by sending an unprotected REGISTER request containing the new values in the Security-Client header field.

Editor’s Note: [GINI CR#3968] The impact of bulk number registration procedures according to RFC 6140 [191] on the additional procedures in support for hosted NAT is FFS.

F.2.1.2.3 Initial subscription to the registration-state event package

The procedures described in subclause 5.1.1.3 apply with the additional procedures described in subclause F.2.1.4.1.

F.2.1.2.4 User-initiated re-registration

The procedures described in subclause 5.1.1.4.1 apply with the additional procedures described in the present subclause.

On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header fields as indicated in subclause 5.1.1.4.1 with the exception of subitems c) and d) which are modified as follows.

The UE shall populate:

c) a Contact header field set to include SIP URI(s) that contain(s) in the hostport parameter the public IP address of the UE or FQDN, and containing the instance ID of the UE in the "+sip.instance" header field parameter, if the UE supports GRUU. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT. The UE shall include all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3840 [62] for the IMS communication services it intends to use, and IARI values (coded as specified in subclause 7.2A.9.2), for the IMS applications it intends to use in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840 [62]. If the UE has detected it is behind a NAT, the UE may include a transport=tcp URI parameter in the Contact header;

d) a Via header field set to include the public IP address or FQDN of the UE in the sent-by field. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT. For the TCP, the response is received on the TCP connection on which the request was sent. If the UE previously has previously negotiated sending of keep-alives associated with the registration, it shall include a "keep" header field parameter with no value in the Via header field, in order to indicate continous support to send keep-alives, as described in RFC 6223 [143];

NOTE 1: The means to ensure that the FQDN resolves to the public IP address of the NAT are outside of the scope of this specification. One option for resolving this is local configuration.

When the UE, that is behind a NAT, receives a 400 (Bad Request) response with 301 Warning header field indicating "incompatible network address format" to the REGISTER request that does not contain a challenge response, the UE shall randomly select a new value for the protected client port, and send the REGISTER request containing the new values in the Security-Client header field.

NOTE 2: The protected server port stays fixed for a UE until all public user identities of the UE have been de-registered.

Editor’s Note: [GINI CR#3968] The impact of bulk number registration procedures according to RFC 6140 [191] on the additional procedures in support for hosted NAT is FFS.

F.2.1.2.5 Authentication

F.2.1.2.5.1 IMS AKA – general

The procedures of subclause 5.1.1.5.1 apply with with the additional procedures described in the present subclause.

On receiving a 401 (Unauthorized) response to the REGISTER request and the response is deemed to be valid, the UE shall behave as of subclause 5.1.1.5.1 with the exception of subitem 3) which is modified as follows.

The UE shall:

3) send another REGISTER request using the temporary set of security associations to protect the message. The header fields are populated as defined for the initial request (see subclause F.2.1.2.2), with the addition that the UE shall include an Authorization header field containing the private user identity and the authentication challenge response calculated by the UE using RES and other parameters, as described in RFC 3310 [49] when AKAv1 is used or as described in RFC 4169 [227] when AKAv2 is used. The UE shall also insert the Security-Client header field that is identical to the Security-Client header field that was included in the previous REGISTER request (i.e. the REGISTER request that was challenged with the received 401 (Unauthorized) response). The UE shall also insert the Security-Verify header field into the request, by mirroring in it the content of the Security-Server header field received in the 401 (Unauthorized) response. The UE shall set the Call-ID of the integrity protected REGISTER request which carries the authentication challenge response to the same value as the Call-ID of the 401 (Unauthorized) response which carried the challenge.

Whenever the 200 (OK) response is not received before the temporary SIP level lifetime of the temporary set of security associations expires or a 403 (Forbidden) response is received, the UE shall consider the registration to have failed. The UE shall delete the temporary set of security associations it was trying to establish, and use the old set of security associations. The UE should send an unprotected REGISTER request according to the procedure specified in subclause F.2.1.2.2 if the UE considers the old set of security associations to be no longer active at the P-CSCF.

F.2.1.2.5.2 Void

F.2.1.2.5.3 IMS AKA abnormal cases

The text in subclause 5.1.1.5.3 applies without changes.

F.2.1.2.5.4 SIP digest – general

Not applicable.

F.2.1.2.5.5 SIP digest – abnormal procedures

Not applicable.

F.2.1.2.5.6 SIP digest with TLS – general

Not applicable.

F.2.1.2.5.7 SIP digest with TLS – abnormal procedures

Not applicable.

F.2.1.2.5.8 Abnormal procedures for all security mechanisms

The text in subclause 5.1.1.5.8 applies without changes.

F.2.1.2.5A Network-initiated re-authentication

The text in subclause 5.1.1.5A applies without changes.

F.2.1.2.5B Change of IPv6 address due to privacy

The text in subclause 5.1.1.5B applies without changes.

F.2.1.2.6 User-initiated deregistration

The procedures of subclause 5.1.1.6.1 apply with with the additional procedures described in the present subclause.

On sending a REGISTER request, the UE shall populate the header fields as indicated in subclause 5.1.1.6 with the exception of subitems d) and e) which are modified as follows.

The UE shall populate:

c) a Contact header field set to either the value of "*" or SIP URI(s) that contain(s) in the hostport parameter the IP address of the UE or FQDN; and containing the instance ID of the UE in the "+sip.instance" header field parameter, if the UE supports GRUU. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT;

d) a Via header field set to include the IP address or FQDN of the UE in the sent-by field. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT;

NOTE 1: In case of hosted NAT traversal only the UE public IP addresses are bound to security associations.

NOTE 2: The means to ensure that the FQDN resolves to the public IP address of the NAT are outside of the scope of this specification. One option for resolving this is local configuration.

Editor’s Note: [GINI CR#3968] The impact of bulk number registration procedures according to RFC 6140 [191] on the additional procedures in support for hosted NAT is FFS.

F.2.1.2.7 Network-initiated deregistration

The procedures of subclause 5.1.1.7 apply with with the additional procedures described in the present subclause.

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package as described in subclause 5.1.1.3, including one or more <registration> element(s) which were registered by this UE with:

– the state attribute set to "terminated" and the event attribute set to "rejected" or "deactivated"; or

– the state attribute set to "active" and the state attribute within the <contact> element belonging to this UE set to "terminated", and associated event attribute element to "rejected" or "deactivated";

the UE shall remove all registration details relating to these public user identities. In case of a "deactivated" event attribute, the UE shall start the initial registration procedure as described in subclause F.2.1.2.2. In case of a "rejected" event attribute, the UE shall release all dialogs related to those public user identities.

F.2.1.3 Subscription and notification

The text in subclause 5.1.2 applies without changes.

F.2.1.4 Generic procedures applicable to all methods excluding the REGISTER method

F.2.1.4.1 UE originating case

The procedures described in subclause 5.1.2A.1 apply with the additional procedures described in the present subclause.

When the UE sends any request, the requirements in subclause 5.1.2A.1 are replaced by the following requirements. The UE shall include:

– a Via header field set to include the public IP address of the UE or FQDN and the protected server port in the sent-by field. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; and if this is a request for a new dialog, and the request includes a Contact header field, then the UE should populate the Contact header field as follows:

1) if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user identity to be used for this request, and the UE does not indicate privacy of the P-Asserted-Identity, then insert the public GRUU ("pub-gruu" header field parameter) value in the Contact header field as specified in RFC 5627 [93]; or

2) if a temporary GRUU value ("temp-gruu" header field parameter) has been saved associated with the public user identity to be used for this request, and the UE does indicate privacy of the P-Asserted-Identity, then insert the temporary GRUU ("temp-gruu" header field parameter) value in the Contact header field as specified in RFC 5627 [93].

If this is a request within an existing dialog, and the request includes a Contact header field, and the contact address previously used in the dialog was a GRUU, then the UE should insert the previously used GRUU value in the Contact header field as specified in RFC 5627 [93].

If the UE did not insert a GRUU in the Contact header field, then the UE shall include the public IP address of the UE or FQDN and the protected server port in the hostport parameter in any Contact header field that is otherwise included. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT.

NOTE: The means to ensure that the FQDN resolves to the public IP address of the NAT are outside of the scope of this specification. One option for resolving this is local configuration.

The UE shall discard any SIP response that is not integrity protected and is received from the P-CSCF outside of the registration and authentication procedures. The requirements on the UE within the registration and authentication procedures are defined in subclause F.2.1.2.4.

When a SIP transaction times out, i.e. timer B, timer F or timer H expires at the UE, the UE may behave as if timer F expired, as described in subclause F.2.1.2.3.

F.2.1.4.2 UE terminating case

The procedures described in subclause 5.1.2A.2 apply with the additional procedures described in the present subclause.

When the UE sends any response, the requirements in subclause 5.1.2A.1 are replaced by the following requirement.

If the response includes a Contact header field, and the response is not sent within an existing dialog, then the UE should populate the Contact header field as follows:

1) if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user identity from the P-Called-Party-ID header field, and the UE does not indicate privacy of the P-Asserted-Identity, then insert the public GRUU ("pub-gruu" header field parameter) value in the Contact header field as specified in RFC 5627 [93]; and

2) if a temporary GRUU value ("temp-gruu" header field parameter) has been saved associated with the public user identity from the P-Called-Party-ID header field, and the UE does indicate privacy of the P-Asserted-Identity, then the UE should insert the temporary GRUU ("temp-gruu" header field parameter) value in the Contact header field as specified in RFC 5627 [93].

If the UE did not insert a GRUU in the Contact header field, then the UE shall:

– include the public IP address of the UE or FQDN and the protected server port in the hostport parameter in any Contact header field that is otherwise included. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT.

NOTE: The means to ensure that the FQDN resolves to the public IP address of the NAT are outside of the scope of this specification. One option for resolving this is local configuration.

The UE shall discard any SIP request that is not integrity protected and is received from the P-CSCF outside of the registration and authentication procedures. The requirements on the UE within the registration and authentication procedures are defined in subclause F.2.1.2.

F.2.2 P-CSCF usage of SIP

F.2.2.1 Introduction

This subclause describes the SIP procedures for supporting hosted NAT scenarios.

The description enhances the procedures specified in subclause 5.2.

The P-CSCF shall support the symmetric response routeing mechanism according to RFC 3581 [56A].

NOTE: Symmetric response routeing is used to support hosted NAT and applicable only to initial, unprotected REGISTER requests and corresponding responses.

F.2.2.2 Registration

The procedures described in subclause 5.2.2 apply with the additional procedures described in the present subclause.

When the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall behave as of subclause 5.2.2.1.

If IMS AKA is the security mechanism, when the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall perform the procedures of subclause 5.2.2.2 with the following exception to items 2) and 3):

2) in case the REGISTER request was received without integrity protection, then:

a) check the existence of the Security-Client header field. If the Security-Client header field is not present, then the P-CSCF shall return a suitable 4xx response. If the Security-Client header field is present the P-CSCF shall:

– in case the UE indicated support for "UDP-enc-tun" then remove and store it.

– in case the UE does not indicate support for "UDP-enc-tun" then:

– if the host portion of the sent-by field in the topmost Via header field contains an IP address that differs from the source address of the IP packet, silently drop the REGISTER;

– otherwise continue with procedures as of subclause 5.2.2.

NOTE 1: If the UE does not indicate support for "UDP-enc-tun" and the P-CSCF detects that the UE is located behind a NAT device, then the P-CSCF can just drop the REGISTER to avoid unnecessary signalling traffic.

b) if the host portion of the sent-by field in the topmost Via header field contains a FQDN, or if it contains an IP address that differs from the source address of the IP packet, the P-CSCF shall:

– add a "received" header field parameter in accordance with the procedure defined in RFC 3581 [56A]. If the "rport" header field parameter is included in the Via header field, the P-CSCF shall also set the value of the "rport" header field parameter to the source port of the requestin accordance with the procedure defined in RFC 3581 [56A]; and

– check that no any previously registered UE has either the same public IP address (allocated by the NAT and indicated in the Via header field) and the protected server port (specified in the Security-Client header field) or the same public IP address and the protected client port (specified in the Security-Client header field). If there is such UE, the P-CSCF shall return a 400 (Bad Request) response with 301 Warning header field indicating "incompatible network address format" to the unprotected REGISTER request. Otherwise, the P-CSCF shall forward the REGISTER request.

NOTE 2: If two UEs are behind the same NAT, the NAT can assign to them the same public IP address (but different NAT’s port). Hence, the two respective UE will have different protected server port numbers, and different protected client port numbers.

3) in case the REGISTER request was received integrity protected, then the P-CSCF shall:

a) check the security association which protected the request. If the security association is a temporary one, the P-CSCF shall:

– in case the host parameter in the Contact address is in the form of a FQDN, ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP address bound to the security association;

– in case the P-CSCF has detected earlier that the UE is located behind a NAT, retrieve port_Uenc from the encapsulating UDP header of the packet received and complete configuration of the temporary set of security associations by configuring port_Uenc in each of the temporary security associations;

– check whether the request contains a Security-Verify header field in addition to a Security-Client header field. If there are no such header fields, then the P-CSCF shall return a suitable 4xx response. If there are such header fields, then the P-CSCF shall compare the content of the Security-Verify header field with the content of the Security-Server header field sent earlier and the content of the Security-Client header field with the content of the Security-Client header field received in the challenged REGISTER. If those do not match, then there is a potential man-in-the-middle attack. The request should be rejected by sending a suitable 4xx response. If the contents match, the P-CSCF shall remove the Security-Verify and the Security-Client header field;

b) if the security association the REGISTER request was received on, is an already established one, then the P-CSCF shall:

– remove the Security-Verify header field if it is present;

– check if the Security-Client header field containing new parameter values is present, and:

– if this header field or any required parameter is missing, then the P-CSCF shall return a suitable 4xx response.

– if this header field and the required parameters are present, then the P-CSCF shall check that no any previously registered UE has the same public IP address and the protected client port (specified in the Security-Client header field). If there is such UE, the P-CSCF shall return a 400 (Bad Request) response with 301 Warning header field indicating "incompatible network address format" to the REGISTER request. Otherwise, the P-CSCF shall remove and store the Security-Client header field before forwarding the request to the S-CSCF;

NOTE 3: When sending the protected REGISTER request to the P-CSCF, the UE will not modify the protected server port value, since the protected server port value stays fixed for a UE until all public user identities of the UE have been de-registered.

When the P-CSCF receives a 401 (Unauthorized) response to an unprotected REGISTER request:

1) if this response contains a "received" header field parameter in the Via header field associated with the UE;

2) if the request associated with the response was received:

A) using UDP and this response contains a "rport" header field parameter in the Via header field associated with the UE; or

B) using TCP; and

3) the UE indicated support for "UDP-enc-tun" IPsec mode;

the P-CSCF shall:

1) delete any temporary set of security associations established towards the UE;

2) remove the "ck" and "ik" WWW-Authenticate header field parameters contained in the 401 (Unauthorized) response and bind the values to the proper private user identity and to the temporary set of security associations which will be setup as a result of this challenge. The P-CSCF shall forward the 401 (Unauthorized) response to the UE if and only if the "ck" and "ik" header field parameters have been removed;

3) insert a Security-Server header field in the response, containing the P-CSCF security list and the parameters needed for the security association setup, as specified in Annex H of 3GPP TS 33.203 [19]. The P-CSCF shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The P-CSCF shall support the IPSec layer algorithms for integrity protection and for encryption as defined in 3GPP TS 33.203 [19]. The P-CSCF shall indicate "UDP-enc-tun" as the only IPsec mode;

4) set up the temporary set of security associations with a temporary SIP level lifetime between the UE and the P-CSCF for the user identified with the private user identity. The P-CSCF shall select UDP encapsulated tunnel mode and shall leave the value for port-Uenc unspecified in each of the temporary security associations. For further details see 3GPP TS 33.203 [19] and RFC 3329 [48]. The P-CSCF shall set the temporary SIP level lifetime for the temporary set of security associations to the value of reg-await-auth timer; and

5) send the 401 (Unauthorized) response unprotected to the UE using the mechanisms described in RFC 3261 [26] and RFC 3581 [56A], i.e. in case UDP is used as transport protocol the P-CSCF shall send the response to the IP address indicated in the "received" header field parameter and to the port indicated in the "rport" header field parameter of the Via header field associated with the UE. In case UDP is used as transport protocol, the P-CSCF shall use the IP address and the port on which the REGISTER request was received as source IP address and the source port when sending the response back to the UE.

When the P-CSCF receives a 401 (Unauthorized) response to a protected REGISTER request and that REGISTER request was protected by an old set of security associations that use UDP encapsulated tunnel mode, the P-CSCF shall:

1) delete any temporary set of security associations established towards the UE;

3) insert a Security-Server header field in the response, containing the P-CSCF security list and the parameters needed for the security association setup, as specified in Annex H of 3GPP TS 33.203 [19]. The P-CSCF shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The P-CSCF shall support the IPsec layer algorithms for integrity protection and encryption as defined in 3GPP TS 33.203 [19]. The P-CSCF shall indicate "UDP-enc-tun" as the IPsec mode;

4) set up the temporary set of security associations with a temporary SIP level lifetime between the UE and the P-CSCF for the user identified with the private user identity. The P-CSCF shall select UDP encapsulated tunnel mode and shall specify the same port_Uenc that was used in the old set of security associations. The P-CSCF shall set the temporary SIP level lifetime for the temporary set of security associations to the value of reg-await-auth timer; and

5) send the 401 (Unauthorized) response to the UE using the old set of security associations.

Otherwise, when the P-CSCF receives a 401 (Unauthorized) response to an unprotected REGISTER request and:

– this response does not contain a "received" header field parameter in the Via header field associated with the UE;

– this response does not contain "rport" header field parameter in the Via header field associated with the UE and the request associated with the response was received using UDP; or

– when the P-CSCF receives a 401 (Unauthorized) response to a protected REGISTER request and that REGISTER request was protected by an old set of security associations that do not use UDP encapsulated tunnel mode;

the P-CSCF shall proceed as described in subclause 5.2.2.2.

F.2.3 S-CSCF usage of SIP

F.2.3.1 S-CSCF usage of SIP

F.2.3.1.1 Protected REGISTER with IMS AKA as a security mechanism

The procedures at the S-CSCF described in subclause 5.4.1.2.2 apply.

NOTE: When two UEs that are behind the same NAT register their contact addresses, the NAT can assign to them the same public IP address (but different NAT’s ports). If these two UEs select the same protected server port number, and register via different P-CSCFs, then they will have the same contact addresses (i.e. same IP address and protected server port). However, any request targeted to either UE will be sent to the respective P-CSCF, hence not causing any ambiguity at the P-CSCF when forwarding the request via NAT.