F.4 P-CSCF usage of SIP in case UDP encapsulated IPsec is not employed

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.4.1 Introduction

The subclause F.4 describes the SIP procedures for supporting hosted NAT scenarios in case UDP encapsulated IPsec is not employed. In these scenarios the procedures for NAT traversal must take into account that all SIP requests and responses are not protected by an IPsec security association. This subclause also assumes that the UE transmits the SIP messages from the same IP address and port on which the UE expects to receive SIP messages.

F.4.2 Registration

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

When the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall add the "received" header field parameter to the Via header field set to the source IP address of the packet header in accordance with the procedure defined in RFC 3261 [26] and 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 request, in accordance with the procedure defined in RFC 3581 [56A].

When the P-CSCF detects that the UE is behind a NAT:

– if the UE has indicated in the received REGISTER request support of the keep-alive mechanism defined in SIP outbound (RFC 5626 [92]) according to RFC 6223 [143], the P-CSCF shall indicate to the UE that it supports the keep-alive mechanism; and

– if the UE has not indicated in the received REGISTER request support of the keep-alive mechanism defined in SIP outbound (RFC 5626 [92]) according to RFC 6223 [143]:

a) if a P-CSCF registration timer is running, the P-CSCF should not forward the REGISTER request if received half of the time before expiry of the S-CSCF registration timer, unless the request is intended to update the UE’s capabilities according to RFC 3840 [62] or to modify the ICSI values or IARI values that the UE intends to use in the g.ims.app-ref feature tag. If the P-CSCF decides to not forward the REGISTER request, the P-CSCF shall build a 200 (OK) response based on the contents of the 200 (OK) response to the previous REGISTER request and send this response to the UE. If the P-CSCF decides to forward the REGISTER request, the P-CSCF shall set the registration expiration interval to the registration expiration interval value indicated in the received 200 (OK) response to the previous REGISTER request; and

b) when the P-CSCF receives a 200 (OK) response to the REGISTER request, the P-CSCF shall modify the value of the Expires header field and/or Expires parameter in the Contact header according to the transport protocol. In order to minimize the number of REGISTER requests to the S-CSCF, the P-CSCF may also start a P-CSCF registration timer with a value of 600 seconds if the value received from the S-CSCF was for greater than 1200 seconds, or to half of the time otherwise.

If, upon receiving a REGISTER request from an unregistered user and the P-CSCF discovers that the UE is behind a NAT, the P-CSCF performs the following actions on the Contact header field depending on its content:

– if the Contact header field contains a contact address in the form of an IP address (NOTE), the P-CSCF shall save (for the duration of the registration) this IP address (i.e. the private IP address of the UE) and associated port number (i.e. the private port of the UE) and bind them to the source IP address (i.e. the public IP address of the NAT) and the source port number (i.e. the port number of the NAT) of the IP packet that contained the REGISTER request and forward the REGISTER request;

– if the Contact header field contains more than one contact addresses in the form of an IP address, the P-CSCF shall apply the above procedure to one of those contact addresses by choosing the one with the highest qvalue parameter) and delete any other contact addresses containing an IP address. If the P-CSCF was unable to choose a contact address based on the qvalue, the P-CSCF shall choose one based on local policy and delete any other contact addresses containing an IP address.

NOTE: When the host parameter in the Contact address is in the form of a FQDN, the P-CSCF will resolve the given FQDN (by DNS lookup) to the IP address of the UE. When including the FQDN in the Contact header field the UE insures that the FQDN resolves to the IP address that the UE uses to send the REGISTER request.

When the P-CSCF received a response to the above request, the P-CSCF shall forward the response to the UE using the mechanisms described in RFC 3581 [56A]. In case UDP is used, 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 in the response. If the REGISTER request received from the UE was received over a TCP connection, the P-CSCF shall send the response to the UE over the same TCP connection over which the request was received. The P-CSCF shall transmit the IP packet (containing the response) from the same IP address and port on which the REGISTER request was received.

F.4.3 General treatment for all dialogs and standalone transactions excluding the REGISTER method

F.4.3.1 Introduction

The procedures described in subclause 5.2.6 apply with the additional procedures described in subclause F.4.3.

F.4.3.2 Request initiated by the UE

When the P-CSCF receives, from the UE that is behind a NAT, an initial request for a dialog or a request for a standalone transaction, the P-CSCF shall:

a) if the "rport" header field parameter is included in the Via header field, set the value of the "rport" header field parameter in the Via header field to the source port of the received IP packet that contained the request;

aa) insert the "received" header field parameter in the Via header field containing the source IP address of the received IP packet (that contained the request), as defined in RFC-3581 [56A];

b) if the request is a dialog-forming request that was received over UDP, bind the source IP address (i.e. the public IP address of the NAT) and associated source port number (i.e. the port number of the NAT) of the received IP packet (that contained the initial dialog-forming request) to:

– the IP address (i.e. the private IP address of the UE) and associated port number (i.e. the private port of the UE) contained in the Contact header field of the received dialog-forming request, if the Contact header field contained an IP address and associated port number, and save the binding; or

– the saved IP address (i.e. the private IP address of the UE) and associated port number (i.e. the private port of the UE) contained in the Contact header field of the REGISTER request, if the Contact header field of the received dialog-forming request contained a GRUU, and save the binding; and

c) if the dialog-forming request was received over TCP connection, keep this TCP connection up during the entire duration of the dialog;

before forwarding the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261 [26].

When the P-CSCF receives a response to the above request, the P-CSCF shall forward the response to the UE using the mechanisms described in RFC 3581 [56A]. In case UDP is used, 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 of the response. If the dialog-forming request received from the UE was received over the TCP connection, the P-CSCF shall send the response to the UE over the same TCP connection over which the dialog-forming request was received. The P-CSCF shall transmit the IP packet (containing the response) from the same IP address and port on which the initial dialog-forming request was received.

For all subsequent requests belonging to the dialog, received from the UE, the P-CSCF shall:

– insert the "received" header field parameter in the Via header field as described in RFC 3261 [26];

– if the "rport" header field parameter is included in the Via header field, set the value of the "rport" header field parameter in the Via header field as defined in RFC 3581 [56A]; and

– forward the request as described in RFC 3261 [26].

For all subsequent responses belonging to the dialog, destined for the UE, the P-CSCF shall forward the responses using the "received" header field parameter and if UDP is used, set the value of the "rport" header field parameter in the Via header field of the response as defined in RFC 3581 [56A].

For all subsequent requests belonging to the dialog and destined for the UE (that contains the private IP address and associated private port number in the Request-URI), the P-CSCF shall send the requests to the UE either:

– over the TCP connection that was established when the initial INVITE request was received; or

– use UDP. When sending the request using UDP, the P-CSCF shall insert the request in an IP packet, and send the IP packet to the saved IP address (i.e. the public IP address of the NAT) and associated port number (i.e. the port number of the NAT). The P-CSCF shall transmit the IP packet (containing the request) from the same IP address and port on which the REGISTER request was received.

NOTE: When inserting its SIP URI in the Record-Route header field of the dialog-forming request received from the UE, the P-CSCF can include a pointer in the user part of its SIP URI that points to the saved binding used to route the in-dialog requests to the UE. The Route header field of the in-dialog requests will contain the respective pointer in the user part of the P-CSCF’s SIP URI.

F.4.3.3 Request terminated by the UE

When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction destined for the UE (it contains the private IP address and associated private port number in the Request-URI), the P-CSCF shall send the requests to the UE either:

– over the TCP connection for the related registration or registration flow (if the multiple registrations mechanism is used), if available (e.g. TCP connection was established during the registration procedure); or

– use UDP. When sending the request using UDP, the P-CSCF shall send the request to the saved IP address (i.e. the public IP address of the NAT) and associated port number (i.e. the port number of the NAT) for the related registration or registration flow (if the multiple registrations mechanism is used) that is bound to the private IP address and associated private port number indicated in the Request-URI and saved during the registration procedure. The P-CSCF shall transmit the IP packet (containing the request) from the same IP address and port on which the REGISTER request was received.

NOTE 1: If the Contact bound to the terminating UE’s registration state includes a transport=tcp URI parameter, for the terminating requests, the P-CSCF follows the procedures specified in RFC 3261 [26] subclause 7 and RFC 3263 [27A] subclause 4.1 for selection of the transport, which recommend to use the TCP connection.

For all subsequent requests belonging to the dialog that are received from the UE, the P-CSCF shall:

– insert the "received" header field parameter in the Via header field as defined in RFC 3261 [26];

– if the "rport" header field parameter is included in the Via header field, set the value of the "rport" header field parameter in the Via header field as defined in RFC 3581 [56A]; and

– forward the request as described in RFC 3261 [26].

For all subsequent responses belonging to the dialog, destined or the UE, the P-CSCF shall forward the responses using the "received" header field parameter and if UDP is used, set the value of the "rport" header field parameter in the Via header field of the response as defined in RFC 3581 [56A].

– over the TCP connection, if available; or

NOTE 2: When inserting its SIP URI in the Record-Route header field in a response to the dialog-forming request received from the UE, the P-CSCF can include a pointer in the user part of its SIP URI that points to the saved binding used to route the in-dialog requests to the UE. The Route header field of the in-dialog requests will contain the respective pointer in the user part of the P-CSCF’s SIP URI.