5.2 Procedures at the P-CSCF

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

5.2.1 General

Where the P CSCF provides emergency call support, the procedures of subclause 5.2.10 shall be applied first.

Subclause 5.2.2 through subclause 5.2.9 define P-CSCF procedures for SIP that do not relate to emergency. All SIP requests are first screened according to the procedures of subclause 5.2.10 to see if they do relate to an emergency.

For all SIP transactions identified:

– as relating to an emergency; or

– if priority is supported, as containing an authorised Resource-Priority header field or a temporarily authorised Resource-Priority header field, or, if such an option is supported, relating to a dialog which previously contained an authorised Resource-Priority header field;

the P-CSCF shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If the P-CSCF recognises the need for priority processing to a request or if the P-CSCF recognises the need to provide different priority processing than the one indicated by the originating UE, based on the information stored during registration, the P-CSCF may insert or modify Resource-Priority header in accordance with RFC 4412 [116].

NOTE 1: The special treatment can include filtering, higher priority processing, routeing, call gapping. The exact meaning of priority is not defined further in this document, but is left to national regulation and network configuration.

The P-CSCF shall support the Path and Service-Route header fields.

NOTE 2: The Path header field is only applicable to the REGISTER request and its 200 (OK) response. The Service-Route header field is only applicable to the 200 (OK) response of REGISTER request.

NOTE 3: In subsequent procedures, the P-CSCF can address the needs of individual users (e.g. in support of attached enterprise networks or in support of priority mechanisms, from information saved during registration. In this release of the specification, no information is specified in the registration procedures to perform this, and therefore this information has to either be associated with the user at time of registration from configured information, or by a mechanism outside the scope of this release of the specification.

When the P-CSCF sends any request or response to the UE, before sending the message the P-CSCF shall:

– remove the P-Charging-Function-Addresses and P-Charging-Vector header fields, if present.

When the P-CSCF receives any request or response from the UE, the P-CSCF:

1) shall remove the P-Charging-Function-Addresses and P-Charging-Vector header fields, if present. Also, the P-CSCF shall ignore any data received in the P-Charging-Function-Addresses and P-Charging-Vector header fields; and

2) may insert previously saved values into the P-Charging-Function-Addresses header field before forwarding the message;

NOTE 4: When the P-CSCF is located in the visited network, then it will not receive the P-Charging-Function-Addresses header field from the S-CSCF, IBCF, or I-CSCF. Instead, the P-CSCF discovers charging function addresses by other means not specified in this document.

3) shall remove the P-Access-Network-Info header field, if the request or the response include a P-Access-Network-Info header field with a "network-provided" parameter;

4) may insert a P-Access-Network-Info header field where:

a) if no mechanism exists to support the access technology for this UE, the "network-provided" parameter is included, and the access-type field is set to a preconfigured value;

b) if NASS is used to support the access technology for this UE, the "network-provided" parameter is included, and the access-type field is set:

– when xDSL is the IP-CAN, to one of "ADSL", "ADSL2", "ADSL2+", "RADSL", "SDSL", "HDSL", "HDSL2", "G.SHDSL", "VDSL", "IDSL", or "xDSL", and the "dsl-location" parameter is set with the value received in the Location-Information header field in the User-Data Answer command as specified in ETSI ES 283 035 [98];

NOTE 5: xDSL is a general abbreviation for all types of Digital Subscriber Lines, and "xDSL" is a possible access-type value of the P-Access-Network-Info header field.

– when Ethernet is the IP-CAN, to one of "IEEE-802.3", "IEEE-802.3a", "IEEE-802.3e", "IEEE-802.3i", "IEEE-802.3j", "IEEE-802.3u","IEEE-802.3ab"or "IEEE-802.3ae", "IEEE-802.3ak", "IEEE-802.3aq", "IEEE-802.3an", "IEEE-802.3y" or "IEEE-802.3z" and if NASS subsystem is used, and the "eth-location" parameter is set with the value received in the Location-Information header field in the User-Data Answer command as specified in ETSI ES 283 035 [98];

– when Fiber is the IP-CAN, to one of "G-PON", "XGPON1" or "IEEE-802.3ah" and if NASS subsystem is used, and the "fiber-location" parameter is set with the value received in the Location-Information header field in the User-Data Answer command as specified in ETSI ES 283 035 [98];

c) if the PCRF is used to support the access technology for this UE and 3GPP-User-Location-Info as specified in 3GPP TS 29.214 [13D] is not available:

– if the IP-CAN-Type value provided by the PCRF is not "DVB-RCS2", then:

I) the access-type field or the access-class field is set to a value consistent with that received from the PCRF in the IP-CAN-Type, RAT-Type and AN-Trusted parameters using the procedures specified in 3GPP TS 29.214 [13D].

If the IP-CAN-Type parameter is set "Non-3GPP-EPS (6)" as specified in 3GPP TS 29.212 [13B], the RAT-Type parameter is set to "VIRTUAL (1)" as specified in 3GPP TS 29.212 [13B] and the AN-Trusted parameter is set to "UNTRUSTED (1)" as specified in 3GPP TS 29.273 [12A], the P-CSCF shall include the access-class field set to "untrusted-non-3GPP-VIRTUAL-EPC".

II) if a 3GPP-MS-TimeZone parameter is available from the PCRF, then the "local-time-zone" parameter and the "daylight-saving-time" parameter may also be added using this information;

III) the "network-provided" parameter is added;

IV) if a TWAN-Identifier as specified in 3GPP TS 29.214 [13D] is received from the PCRF, the received TWAN-Identifier contains the Circuit-ID and the associated "Relay Identity", the received TWAN-Identifier does not contain the "Civic Address Information" and the P-CSCF is able to deduce a Geographical Identifier from the Circuit-ID and the associated "Relay Identity", then, if required by local operator policy, the P-CSCF shall include an operator-specific-GI field. The P-CSCF can obtain a Geographical Identifier from the CLF by using the e2 interface (see ETSI ES 283 035 [98]);

NOTE 6: ETSI ES 283 035 [98] Release 3 enables querying a CLF using the User-Data-Request command in which the Global-Access-Id AVP contains the Fixed-Access-ID AVP set using the Circuit-ID value as the Logical-Access-ID and the "Relay Identity" as the Relay-Agent to get a corresponding Geographical Identifier. If multiple CLFs are deployed, the P-CSCF can dertermine which CLF to query based on the CGI or the SAI values or can use a DIAMETER proxy if deployed.

V) if WLAN Location Information as specified in 3GPP TS 23.402 [7E] is received from the PCRF, the received WLAN Location Information contains the location identifier and the P-CSCF is able to deduce a Geographical Identifier from the WLAN Location Information, then, if required by local operator policy, the P-CSCF shall include an operator-specific-GI field; and

VI) if:

A) the access-class field of the P-Access-Network-Info header field is set to "untrusted-non-3GPP-VIRTUAL-EPC"; or

B) the access-class field of the P-Access-Network-Info header field is set to "3GPP-WLAN" and the AN-Trusted parameter specified in 3GPP TS 29.273 [12A] is received from PCRF and is set to "UNTRUSTED (1)";

then:

A) if a UE-Local-IP-Address parameter specified in 3GPP TS 29.212 [13B] is received from the PCRF and if required by local operator policy, P-CSCF shall also include in the P-Access-Network-Info header field a UE-local-IP-address parameter set to the UE local IP address in the UE-Local-IP-Address parameter received from PCRF;

B) if a UDP-Source-Port parameter specified in 3GPP TS 29.212 [13B] is received from the PCRF and if required by local operator policy, the P-CSCF shall also include in the P-Access-Network-Info header field a UDP-source-port parameter set to the UDP port in the UDP-Source-Port parameter received from PCRF;

C) if a TCP-Source-Port parameter specified in 3GPP TS 29.212 [13B] is received from the PCRF and if required by local operator policy, the P-CSCF shall also include in the P-Access-Network-Info header field a TCP-source-port parameter set to the TCP port in the TCP-Source-Port parameter received from PCRF; and

D) if an AN-GW-Address parameter specified in 3GPP TS 29.212 [13B] is received from the PCRF and if required by local operator policy, the P-CSCF shall also include in the P-Access-Network-Info header field an ePDG-IP-address parameter set to the ePDG IP address in the ePDG-IP-Address parameter received from PCRF; and

VII) if the P-CSCF supports reporting EPS fallback, then the "eps-fallback" parameter is included, if the information is available to the P-CSCF; and

– if the IP-CAN-Type value provided by the PCRF is "DVB-RCS2", then the "network-provided" parameter is included, the access-type field is set to "DVB-RCS2", and the "dvb-rcs2-node-id" parameter is set with the value provided by the IP-CAN provider;

d) if the PCRF is used to support the access technology for this UE and 3GPP-User-Location-Info as specified in 3GPP TS 29.214 [13D] is available;

I) the access-type field or the access-class field is set to a value consistent with that received from the PCRF in the IP-CAN-Type and RAT-Type parameters;

II) the access-info field is set to a value consistent with the information received from the PCRF in the 3GPP-User-Location-Info parameter;

III) if a 3GPP-MS-TimeZone parameter is available from the PCRF, then the "local-time-zone" parameter and the "daylight-saving-time" parameter may also be added using this information;

IV) the "network-provided" parameter is added;

V) if required by local operator policy and the P-CSCF is able to deduce a Geographical Identifier from the Cell Global Identity (CGI) or form the Service Area Identifier (SAI) received from the PCRF, the P-CSCF shall include an operator-specific-GI field. The P-CSCF can obtain a Geographical Identifier from the CLF by using the e2 interface (see ETSI ES 283 035 [98]); and

NOTE 7: ETSI ES 283 035 [98] Release 3 enables querying a CLF using the User-Data-Request command in which the Global-Access-Id AVP contains the 3GPP-User-Location-Info AVP with a CGI or a SAI value to get a corresponding Geographical Identifier. If multiple CLFs are deployed, the P-CSCF can determine which CLF to query based on the CGI or the SAI values or can use a DIAMETER proxy if deployed.

VI) if the P-CSCF supports reporting EPS fallback then the "eps-fallback" parameter is included, if the information is available to the P-CSCF; and

e) if DOCSIS is used, and proprietary means of obtaining a location are used, the access-type field is set to "DOCSIS" and the "network-provided" parameter is added; and

f) if none of NASS, PCRF and DOCSIS are used to support the access technology for the UE and the IP-CAN is not provided by the packet switched domain of the PLMN of the P-CSCF:

I) if the P-CSCF is unaware of the radio access technology used by the UE, the access-class field is set to "VIRTUAL-no-PS";

II) if the P-CSCF is aware that the radio access technology used by the UE is specified by IEEE Std 802.11 [248], the access-class field is set to "WLAN-no-PS"; and

III) the "network-provided" parameter is added;

5) shall remove all Feature-Caps header fields, if present, from a UE that is not considered as privileged sender;

6) may insert a P-Visited-Network-ID header field (except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO and UPDATE) according to RFC 7976 [52A] with the value:

I) of a pre-provisioned string that identifies the network of the P-CSCF at the home network; or

II) if the UE is roaming in deployments without IMS-level roaming interfaces according to 3GPP TS 23.228 [7], a string that identifies the visited network of the UE including an indication that the P-CSCF is located in the home network;

7) may insert a P-Visited-Network-ID header field in 200 (OK) response to INVITE request and in 200 (OK) response to MESSAGE request according to draft-jesske-update-p-visited-network [52B]; and

8) if a Geolocation header field is received from the UE, shall remove any present loc-src parameter from the Geolocation header field.

When the P-CSCF receives any request or response containing the P-Media-Authorization header field, the P-CSCF shall remove the header field.

NOTE 8: Depending on the security mechanism in use, the P-CSCF can integrity protect all SIP messages sent to the UE outside of the registration and authentication procedures by using a security association or TLS session. The P-CSCF will discard any SIP message that is not protected by using a security association or TLS session and is received outside of the registration and authentication procedures. The integrity and confidentiality protection and checking requirements on the P-CSCF within the registration and authentication procedures are defined in subclause 5.2.2.

With the exception of 305 (Use Proxy) responses, the P-CSCF shall not recurse on 3xx responses.

NOTE 9: If the P-CSCF is connected to a PDF the requirements for this interconnection is specified in the Release 6 version of this specification.

The P-CSCF may add, remove, or modify, the P-Early-Media header field within forwarded SIP requests and responses according to procedures in RFC 5009 [109].

NOTE 10: The P-CSCF can use the P-Early-Media header field for the gate control procedures, as described in 3GPP TS 29.214 [13D]. In the presence of early media for multiple dialogs due to forking, if the P-CSCF is able to identify the media associated with a dialog, (i.e., if symmetric RTP is used by the UE and the P-CSCF can use the remote SDP information to determine the source of the media) the P-CSCF can selectively open the gate corresponding to an authorized early media flow for the selected media.

When SIP digest without TLS is used, the P-CSCF shall discard any SIP messages received outside of the registration and authentication procedures that do not map to an existing IP association as defined in subclause 5.2.3.

In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT controlled by the P-CSCF, the P-CSCF may need to modify the SIP contents according to the procedures described in annex F. In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT not controlled by the P-CSCF, the P-CSCF may need to modify the SIP contents according to the procedures described in annex K if both a "reg-id" and "+sip.instance" header field parameters are present in the received Contact header field as described in RFC 5626 [92].

The P-CSCF shall support the provision of the user-related policies (e.g. consideration of the user as a privileged sender):

– from the S-CSCF during registration; and

– by local configuration.

For the same policy, the precedence between the locally configured policy and a policy received during registration shall be based on local operator policy.

For UE performing the functions of an external attached networks using static mode of operation, the P-CSCF will receive requests to establish a TLS session that are not accompanied by the associated procedures of subclause 5.2.2. The P-CSCF shall permit the establishment of such TLS sessions, but subsequent operations without the reception of a REGISTER request shall only be permitted if the P-CSCF is configured for such a UE performing the functions of an external attached network using static mode of operation. Where a REGISTER request is received from a UE, the P-CSCF shall process the REGISTER request as defined in subclause 5.2.2, and shall not provide special procedures for a UE performing the functions of an external attached network using static mode of operation for the duration of the registration.

NOTE 11: For requests other than REGISTER received from UEs that are not configured in this manner, then the procedures of subclause 5.2.6.3.2A apply.

NOTE 12: The P-CSCF does not subscribe to the reg event package for a UE performing the functions of an external attached network using static mode of operation.

When sending a failure response to any received request, depending on operator policy, the P-CSCF may insert a Response-Source header field with an "fe" header field parameter constructed with the URN namespace "urn:3gpp:fe", the fe-id part of the URN set to "p-cscf" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17. A P-CSCF when sending a failure response will add in the URN the "side" header field parameter set to:

– "orig" for a UE-originating case; and

– "term" for a UE-terminating case.

5.2.2 Registration

5.2.2.1 General

The P-CSCF shall be prepared to receive the unprotected REGISTER requests on the SIP default port values as specified in RFC 3261 [26]. The P-CSCF shall also be prepared to receive the unprotected REGISTER requests on the port advertised to the UE during the P-CSCF discovery procedure.

NOTE 1: The P-CSCF will only accept further registration and subsequent SIP messages on the same ports for security mechanisms that do not require to use negotiated ports for exchanging protected messages.

The P-CSCF shall distinguish between security mechanisms through the use of the Security-Client header field and Authorization header field as follows:

1) if a REGISTER request from the UE contains a Security-Client header field and the Require and Proxy-Require header fields contain "sec-agree", then for an initial registration, the P-CSCF shall select the sec-mechanism and mode (as described in Annex H of 3GPP TS 33.203 [19]) from the corresponding parameters offered in the Security-Client header field according to its priorities, as follows:

– if the P-CSCF selects the sec-mechanism "ipsec- 3gpp" then follow the procedures as described in subclause 5.2.2.2, in addition to the procedures described in this subclause;

– if the P-CSCF selects the sec-mechanism "tls" then follow the procedures as described in subclause 5.2.2.4, in addition to the procedures described in this subclause.

NOTE 2: If the Security-Client header field contains only media plane security mechanisms then Require and Proxy-Require header fields will not contain "sec-agree". The P-CSCF will then continue as per the procedure in bullet 2), not select a signalling plane security mechanism and then distinguish signalling plane security based upon the Authorization header field as described in the steps below.

2) if:

a) a REGISTER request from the UE does not contain a Security-Client header field;

b) a REGISTER request from the UE contains a Security-Client header field containing only media plane security mechanisms and the Require and Proxy-Require header fields do not contain "sec-agree"; or

c) the P-CSCF does not select any signalling plane security mechanism from the Security-Client header field;

then the P-CSCF shall behave as follows, in addition to the procedures described in the remainder of this subclause:

– if the REGISTER request does not contain an Authorization header field and was received over an access network defined in 3GPP specifications then follow the GPRS-IMS-Bundled authentication procedures as described in subclause 5.2.2.6; or

– if the REGISTER request does not contain an Authorization header field and was received over a TISPAN NASS and the P-CSCF supports both SIP digest and NASS-IMS bundled authentication, then the P-CSCF shall perform the steps required for NASS-IMS bundled authentication, in subclause 5.2.2.5, as well as the steps required for SIP digest without TLS, in subclause 5.2.2.3, unless it is configured to behave differently or the P-CSCF only supports either SIP digest without TLS or NASS-IMS bundled authentication. If the NASS-IMS bundled authentication related query from the P-CSCF to the TISPAN NASS fails, then the P-CSCF shall only continue with the SIP digest related steps; or

– if the REGISTER request does not contain an Authorization header field, and was received over an access other than defined in 3GPP specifications or TISPAN NASS, then follow the SIP digest without TLS procedures described in subclause 5.2.2.3; or

NOTE 3: How the P-CSCF recognizes over which access network a request was received is an implementation specific feature.

– if the REGISTER request contains an Authorization header field with an "algorithm" header field parameter set to "AKAv2-SHA-256" and the REGISTER request was received by eP-CSCF over TLS, then follow the IMS-AKA procedures for eP-CSCF defined in 3GPP TS 24.371 [8Z]; or

– if the REGISTER request contains an Authorization header field without an "algorithm" header field parameter set to "AKAv2-SHA-256" and was not received over a TISPAN NASS then follow the SIP digest without TLS procedures as described in subclause 5.2.2.3; or

– if the REGISTER request contains an Authorization header field and was received over a TISPAN NASS, and the P-CSCF supports both SIP digest and NASS-IMS bundled authentication, then the P-CSCF shall perform the steps required for NASS-IMS bundled authentication, in subclause 5.2.2.5, as well as the steps required for SIP digest without TLS, in subclause 5.2.2.3, unless it is configured to behave differently. If the NASS-IMS bundled authentication related query from the P-CSCF to the TISPAN NASS fails, then the P-CSCF shall only continue with the SIP digest related steps.

For subsequent registrations, the P-CSCF shall continue to use the selected mechanism.

NOTE 4: The steps required for SIP digest and for NASS-IMS bundled authentcation are not in contradiction. Rather, for NASS-IMS bundled authentication the P-CSCF needs to perform additional steps, namely an exchange with the TISPAN NASS and an inclusion of NASS location information in the REGISTER request, on top of the steps required for SIP digest.

NOTE 5: How the P-CSCF knows the access network type of a specific network interface is implementation-dependent (e.g. it can know the access network type from different UE IP address ranges or by using different network interfaces for different access network types).

When the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall:

1) insert a Path header field in the request including an entry containing:

– the SIP URI identifying the P-CSCF;

– an indication that requests routed in this direction of the path (i.e. from the S-CSCF towards the P-CSCF) are expected to be treated as for the UE-terminating case;

NOTE 6: This indication can e.g. be in a parameter in the URI, a character string in the user part of the URI or be a port number in the URI.

– an IMS flow token in the user portion of the P-CSCF’s SIP URI inserted into the Path header field, and the "ob" SIP URI parameter according to RFC 5626 [92]. The same SIP URI (user portion, hostport parameter and SIP URI parameters) shall be used for the initial registration, and the re-registrations, binding fetchings, and de-registration that refreshes of the respective registration;

– the P-CSCF shall use a different IMS flow token for each registration. If the multiple registration mechanism is used, the P-CSCF shall also use a different IMS flow token for each registration flow associated with the registration;

NOTE 7: The form of the IMS flow token is of local significance to the P-CSCF only and can thus be chosen freely by a P-CSCF implementation.

NOTE 8: By inserting the "ob" SIP URI parameter in its SIP URI, the P-CSCF indicates that it supports multiple registrations as specified in RFC 5626 [92]. The presence of the "ob" SIP URI parameter is not an indication that the P-CSCF supports the keep-alive mechanism. When the P-CSCF detects that the UE is behind a NAT and the P-CSCF supports a keep-alive mechanism defined in RFC 5626 [92].

– if

a) the P-CSCF supports indicating the traffic leg associated with a URI as specified in RFC 7549 [225];

b) the UE is roaming;

c) the P-CSCF is not in the home network; and

d) required by local policy;

then the P-CSCF may append an "iotl" SIP URI parameter with a value set to "homeB-visitedB" to the SIP URI of the Path header field;

2) insert a Require header field containing the option-tag "path";

3) insert a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17] and a type 1 "orig-ioi" header field parameter. The P-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The P-CSCF shall not include the type 1 "term-ioi" header field parameter;

4) insert a P-Visited-Network-ID header field, with the value:

– of a pre-provisioned string that identifies the network of the P-CSCF at the home network; or

– if the UE is roaming in deployments without IMS-level roaming interfaces according to 3GPP°TS°23.228°[7], a string that identifies the visited network of the UE including an indication that the P-CSCF is located in the home network.

EXAMPLE: A UE is roaming using a deployment without an IMS-level roaming interface and the P-CSCF receives via Rx interface a MCC with the value "111" and a MNC with the value "22" identifying the visited network. The domain name of the home network where the P-CSCF is located has the value "networkoperator". In this case, the P-CSCF can set up the P-Visited Network-ID header with a string which can look like: "s8hr.mnc22.mcc111.networkoperator".

NOTE 9: The information of the visited network of the UE is taken from Rx interface as defined in 3GPP°TS°29.214°[13D].

NOTE 10: If required, the P-CSCF can determine that a UE is roaming using deployment without IMS-level roaming interfaces, if the via Rx interface received network information of the roaming UE points to a different network as the P-CSCF belongs to.

4A) store the announcement of the media plane security mechanisms the UE supports labelled with the "mediasec" header field parameter specified in subclause 7.2A.7 and received in the Security-Client header field, if any. Also, if the Security-Client header field contains only media plane security mechanisms, remove the header field;

NOTE 11: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

4B) if the REGISTER request contains an Authorization header field, remove the "integrity-protected" header field parameter, if present;

4C) 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" Via header field parameter in accordance with the procedure defined in RFC 3261 [26];

5) if the P-CSCF is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network:

a) if the request is not to be forwarded to an ATCF according to local policy select an exit point in visited network;

NOTE 12: The list of the exit points can be either obtained as specified in RFC 3263 [27A] or provisioned in the P-CSCF.

b) if the request is to be forwarded to an ATCF according to local policy:

i) insert a Route header field with the ATCF URI for originating requests; and

ii) forward the request; and

c) if the request is not to be forwarded to an ATCF according to local policy, then forward the request to the selected exit point.

If:

– no response is received to the REGISTER request and its retransmissions by the P-CSCF; or

– a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request is received;

the P-CSCF shall repeat the actions of this bullet with a different exit point or a different ATCF.

If the P-CSCF fails to forward the REGISTER request to any exit point or any ATCF, the P-CSCF shall send back a 504 (Server Time-Out) response to the user, in accordance with the procedures in RFC 3261 [26] unless local policy allows omitting the exit point;

NOTE 13: If the P-CSCF forwards the request to an IBCF in the visited network, the IBCF in the visited network can determine the entry point of the home network, as specified in RFC 3263 [27A] or the entry point of the home network can be provisioned in the IBCF in the visited network.

6) if the P-CSCF is located in the visited network and local policy does not require the application of IBCF capabilities in the visited network towards the home network:

a) if the request is not to be forwarded to an ATCF according to local policy select an entry point of the home network;

NOTE 14: The list of the entry points can be either obtained as specified in RFC 3263 [27A] or provisioned in the P-CSCF.

b) if the request is to be forwarded to an ATCF according to local policy:

i) insert a Route header field with the ATCF URI for originating requests; and

ii) forward the request; and

c) if the request is not to be forwarded to an ATCF according to local policy, then forward the request to the selected entry point.

If:

– no response is received to the REGISTER request and its retransmissions by the P-CSCF; or

– a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request is received;

the P-CSCF shall repeat the actions of this bullet with a different entry point or a different ATCF.

If the P-CSCF fails to forward the REGISTER request to any entry point or any ATCF, the P-CSCF shall send back a 504 (Server Time-Out) response to the user, in accordance with the procedures in RFC 3261 [26];

7) if the P-CSCF is located in the home network:

a) if the request is not to be forwarded to an ATCF according to local policy select the I-CSCF of the home network;

NOTE 15: The list of the I-CSCFs can be either obtained as specified in RFC 3263 [27A] or provisioned in the P-CSCF.

b) if the request is to be forwarded to an ATCF according to local policy:

i) insert a Route header field with the ATCF URI for originating requests; and

ii) forward the request; and

c) if the request is not to be forwarded to an ATCF according to local policy, then forward the request to the selected I-CSCF.

If:

– no response is received to the REGISTER request and its retransmissions by the P-CSCF; or

– a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request is received;

the P-CSCF shall repeat the actions of this bullet with a different I-CSCF or a different ATCF.

If the P-CSCF fails to forward the REGISTER request to any I-CSCF or any ATCF, the P-CSCF shall send back a 504 (Server Time-Out) response to the user, in accordance with the procedures in RFC 3261 [26]; and

8) void.

When the P-CSCF receives a 200 (OK) response to a REGISTER request, the P-CSCF shall check the value of the registration expiration interval value. When the registration expiration interval value is different than zero, then the P-CSCF shall:

1) save the list of service route values in the Service-Route header fields preserving the order, and bind the list either to the contact address or to the registration flow and the associated contact address (if the multiple registration mechanism is used) and the associated security association or TLS session over which the REGISTER request was received. The P-CSCF shall store this list during the entire registration period of the respective public user identity and bind it either to the associated contact address or to the registration flow and the associated contact address (if the multiple registration mechanism is used). The P-CSCF shall use this list to validate the routeing information in the requests originated by the UE using either the respective contact address or the registration flow and the associated contact address, and received over the respective security association or a TLS session. If the list of Service-Route header fields already exists either for this contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used), then the P-CSCF shall replace the already existing list of service route values with the list of Service-Route header fields received in the 200 (OK) response;

NOTE 16: When the UE registers multiple registration flows and the associated contact addresses, then the UE and the P-CSCF will have a list of Service-Route header fields for each registration flow and the associated contact address and the associated security association or TLS session. When sending a request using a given registration flow and the associated contact address and the associated security association or TLS session, the UE will use the corresponding list of Service-Route header fields, when building a list of Route header fields.

2) associate the list of service route values with the registered public user identity and either the associated contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used) and the associated security association or TLS session;

3) store the public user identities, found in the P-Associated-URI header field value, including any associated display names, and any parameters associated with either the user or the identities of the user, and associate them to the registered public user identity, i.e. the registered public user identity and its associated set of implicitly registered public user identities are bound to the contact address and security association or TLS session over which the REGISTER request was received;

3A) if the user-related policies statically provisioned to the P-CSCF (see subclause 5.2.1) indicate that the URIs contained in the P-Associated-URI header field shall not be forwarded towards the UE, and the P-CSCF is located in the home operator network of the UE, then the P-CSCF shall remove all but the first URI contained in the P-Associated-URI header field of the 200 (OK) response;

NOTE 17: The URIs in the P-Associated-URI header field might need to be removed in case of the UE performs the functions of an external attached network (e.g an enterprise network).

4) store the default public user identity, including its associated display name, if provided, for use with procedures for the P-Asserted-Identity header field for requests received from the UE over the respective security association or TLS session. The default public user identity is the first on the list of URIs present in the P-Associated-URI header field;

NOTE 18: There can be more than one default public user identity stored in the P-CSCF, as the result of the multiple registrations of public user identities.

NOTE 19: For each contact address and the associated security association or TLS session the P-CSCF will maintain a list of registered public user identities and the associated default public user identities, that it will use when populating the P-Asserted Identity header.

5) store the values received in the P-Charging-Function-Addresses header field;

6) if a "term-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "term-ioi" header field parameter;

NOTE 20: Any received "term-ioi" header field parameter will contain a type 1 IOI. The type 1 IOI identifies the home network of the registered user.

7) if the P-CSCF included an IMS flow token and the "ob" SIP URI parameter in the Path header field of the REGISTER request, check for presence of the option-tag "outbound" in the Require header field of the a 200 (OK) response:

– if the option-tag "outbound" is present, it indicates that the UE has successfully registered its public user identity with a new bidirectional flow as defined in RFC 5626 [92]. In this case the P-CSCF shall route the subsequent requests and responses destined for the UE as specified in RFC 5626 [92]; or

– if the option-tag "outbound" is not present, it indicates that the public user identity has not been registered as specified in RFC 5626 [92]. In this case the P-CSCF shall route the subsequent requests and responses destined for the UE as specified in RFC 3261 [26];

8) if the P-CSCF detects that the UE is behind a NAT, and the UE’s Via header field contains a "keep" header field parameter, the P-CSCF shall add a value to the parameter, to indicate that it is willing to receive keep-alives associated with the registration from the UE, as defined in RFC 6223 [143];

9) void; and

10) if the P-CSCF is located in the visited network, store the value of a "+g.3gpp.thig-path" Feature-Caps header field parameter, defined in subclause 7.9A.9, if included in the response. The P-CSCF shall remove the "+g.3gpp.thig-path" Feature-Caps header field parameter before forwarding the 200 (OK) response to the UE.

If the P-CSCF detects that the UE is behind a NAT, and the request was received over a TCP connection, the P-CSCF shall not close the TCP connection during the duration of the registration.

NOTE 21: The P-CSCF can conclude whether the UE is behind a NAT or not by comparing the IP address in the "received" header field parameter with the IP address in the sent-by parameter in the topmost Via header field. If the values do not match, the P-CSCF can conclude that the UE is behind a NAT.

5.2.2.2 IMS AKA as a security mechanism

When the P-CSCF receives a REGISTER request from the UE, as defined in subclause 5.2.2.1, the P-CSCF shall additionally:

1) insert the "integrity-protected" header field parameter (described in subclause 7.2A.2) with a value "yes" into the Authorization header field in case the REGISTER request was either received protected with the security association created during an ongoing authentication procedure and includes an authentication challenge response (i.e. RES parameter), or it was received on the security association created during the last successful authentication procedure, otherwise insert the parameter with the value "no";

1A) if the "reg-id" header field parameter was included in the Contact header field of the REGISTER request, insert in the Path header an IMS flow token and the "ob" URI parameter according to RFC 5626 [92]. The IMS flow token shall identify the flow from the P-CSCF toward the UE, as follows:

a) for UDP, the IMS flow token identifies the unidirectional flow from the P-CSCF’s protected client port and the P-CSCF’s IP address to the UE’s protected server port and the UE’s IP address. This flow is used by the P-CSCF to send requests and responses to the UE. The P-CSCF shall receive the requests and responses from the UE on its protected server port; or

b) for TCP, the IMS flow token identifies the existing TCP connection between the UE and the P-CSCF. This TCP connection is established by the P-CSCF, i.e. from the P-CSCF’s protected client port and the P-CSCF’s IP address to the UE’s protected server port and the UE’s IP address. This TCP connection is used to send SIP requests from the P-CSCF to the UE and receive SIP responses from the UE to the P-CSCF;

2) in case the REGISTER request was received without protection, on the default port or port advertised to UE for P-CSCF discovery:

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

b) 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 REGISTER request;

c) insert the "received" header field parameter in the Via header field containing the source IP address that the request came from, as defined in RFC 3581 [56A]; and

NOTE 1: As defined in RFC 3581 [56A], the P-CSCF will insert a "received" header field parameter containing the source IP address that the request came from, even if it is identical to the value of the "sent-by" component.

NOTE 2: Upon receiving the unprotected REGISTER request the P-CSCF detects if the UE is behind a NAT.

3) in case the REGISTER request was received protected, then towards the port that was notified to the UE in the previous response:

a) check the security association which protected the request. If the security association is a temporary one, then the request is expected to contain 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 request. 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;

– a Security-Client header field containing new parameter values is expected. If the Security-Client header field or any required parameter is missing, then the P-CSCF shall return a suitable 4xx response; and

– the P-CSCF shall remove and store the Security-Client header field before forwarding the request to the S-CSCF;

c) check if the private user identity conveyed in the Authorization header field of the protected REGISTER request is the same as the private user identity which was previously challenged or authenticated. If the private user identities are different, the P-CSCF shall reject the REGISTER request by returning a 403 (Forbidden) response; and

d) ignore the "rport" Via header field parameter, if included.

NOTE 3: Once the IPsec security associations between the UE and the P-CSCF have been created, in case of UDP the P-CSCF sends the responses to a different UE’s port then the one from which the request was received from the UE. For the TCP, the responses are sent on the TCP connection on which the request was received. Hence, the P-CSCF will ignore the "rport" Via header field parameter in all protected requests and responses, if received.

When the P-CSCF receives a 401 (Unauthorized) response to a REGISTER request, 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 static signalling plane security list and the parameters needed for this 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 and confidentiality protection as defined in 3GPP TS 33.203 [19] and shall announce support for them according to the procedures defined in RFC 3329 [48];

3A) insert a Security-Server header field to specify the media plane security mechanisms the P-CSCF (IMS-ALG) supports, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7;

NOTE 4 The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

4) set up the temporary set of security associations for this registration with a temporary SIP level lifetime between the UE and the P-CSCF for the user identified with the private user identity. 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 to the UE using the security association with which the associated REGISTER request was protected, or unprotected in case the REGISTER request was received unprotected. If the 401 (Unauthorized) response to the unprotected REGISTER request is sent using UDP, the P-CSCF shall send the response to the IP address listed in the "received" Via header field parameter and the port in the "rport" Via header field parameter. In case of TCP, the P-CSCF shall send the response over the same TCP connection over which the request was received from the UE.

NOTE 5: The challenge in the 401 (Unauthorized) response sent back by the S-CSCF to the UE as a response to the REGISTER request is piggybacked by the P-CSCF to insert the Security-Server header field in it. The S-CSCF authenticates the UE, while the P-CSCF negotiates and sets up two pairs of security associations with the UE during the same registration procedure. For further details see 3GPP TS 33.203 [19].

When the P-CSCF receives a 200 (OK) response to a REGISTER request as defined in subclause 5.2.2.1, the P-CSCF shall additionally:

1) if an existing set of security association is available, set the SIP level lifetime of the security association to the longest of either the previously existing security association lifetime, or the lifetime of the just completed registration plus 30 seconds;

2) if a temporary set of security associations exists, change the temporary set of security associations to a newly established set of security associations, i.e. set its SIP level lifetime to the longest of either the previously existing set of security associations SIP level lifetime, or the lifetime of the just completed registration plus 30 seconds; and

3) protect the 200 (OK) response to the REGISTER request within the same security association to that in which the REGISTER request was protected.

If the P-CSCF receives a SIP message (including REGISTER requests) from the UE over the newly established set of security associations that have not yet been taken into use, the P-CSCF shall:

1) reduce the SIP level lifetime of the old set of security associations towards the same UE to 64*T1 (if currently longer than 64*T1); and

2) use the newly established set of security associations for further messages sent towards the UE as appropriate (i.e. take the newly established set of security associations into use).

NOTE 6: If the UE has registered other contact addresses and established security associations for these contact addresses, it can use them when sending subsequent SIP messages rather than using the newly established set of security associations. In this case the P-CSCF will not receive any SIP message over the newly established set of security associations.

NOTE 7: In this case, the P-CSCF will send requests (that specify the associated contact address in the Request-URI) towards the UE over the newly established set of security associations. Responses towards the UE that are sent via UDP will be sent over the newly established set of security associations. Responses towards the UE that are sent via TCP will be sent over the same set of security associations that the related request was received on.

NOTE 8: When receiving a SIP message (including REGISTER requests) from the UE over a set of security associations that is different from the newly established set of security associations, the P-CSCF will not take any action on any set of security associations.

When the SIP level lifetime of an old set of security associations is about to expire, i.e. their SIP level lifetime is shorter than 64*T1 and a newly established set of security associations has not been taken into use, the P-CSCF shall use the newly established set of security associations for further messages towards the UE as appropriate (see NOTE 2).

When sending the 200 (OK) response for a REGISTER request that concludes a re-authentication, the P-CSCF shall:

1) keep the set of security associations that was used for the REGISTER request that initiated the re-authentication;

2) keep the newly established set of security associations created during this authentication; and

3) go on using for further requests sent towards the UE the set of security associations and associated contact address that was used to protect the REGISTER request that initiated the re-authentication as appropriate (see NOTE 6).

When sending the 200 (OK) respone for a REGISTER request that concludes an initial authentication of the user registering its public user identity with a given contact address the associated security association, i.e. the REGISTER request that initiated the authentication was received unprotected, the P-CSCF shall:

1) keep the newly established set of security associations created during this authentication; and

2) use the kept newly established set of security associations and associated contact address for further messages sent towards the UE as appropriate (see NOTE 6).

NOTE 9: For each contact address or for each registration flow and the associated contact address and bound to a set of security associations the P-CSCF will maintain two Route header field lists. The first Route header field list (constructed form the Service-Route header fields received during the last registration procedure of either the respective contact address or a registration flow and the associated contact address) is used only to validate the routeing information in the initial requests for a dialog and stand alone transactions originating from the UE using either the respective contact address or a registration flow and the associated contact address and are the respective security association. This list is valid as long as there is at least one public user identity registered either with the associated contact address or a registration flow and the associated contact address. The second list is the list of Route header fields (constructed from the Record Route header fields in the initial INVITE request and associated response) is used during the duration of the call. Once the call is terminated, this list of Route header fields is discarded.

The P-CSCF shall delete any security association from the IPsec database when their SIP level lifetime expires.

The handling of the security associations at the P-CSCF is summarized in table 5.2.2-1.

Table 5.2.2-1: Handling of security associations at the P-CSCF

	Temporary set of security associations	Newly established set of security associations	Old set of security associations
SIP message received over newly established set of security associations that have not yet been taken into use	No action	Take into use	Reduce SIP level lifetime to 64T1, if lifetime is larger than 64T1
SIP message received over old set of security associations	No action	No action	No action
Old set of security associations currently in use will expire in 64*T1	No action	Take into use	No action
Sending an authorization challenge within a 401 (Unauthorized) response for a REGISTER request	Create Remove any previously existing temporary set of security associations	No action	No action
Sending 200 (OK) response for REGISTER request that concludes re-authentication	Change to a newly established set of security associations	Convert to and treat as old set of security associations (see next column)	Continue using the old set of security associations over which the REGISTER request, that initiated the re-authentication was received. Delete all other old sets of security associations immediately
Sending 200 (OK) response for REGISTER request that concludes initial authentication	Change to a newly established set of security associations and take into use immediately	Convert to old set of security associations, i.e. delete	Delete

5.2.2.3 SIP digest without TLS as a security mechanism

When the P-CSCF receives a REGISTER request from the UE, as defined in subclause 5.2.2.1, the P-CSCF shall additionally:

1) if the REGISTER request includes an Authorization header field update the "integrity-protected" header field parameter as follows:

a) if the REGISTER request does not map to an existing IP association, and does not contain a challenge response, not include the "integrity-protected" header field parameter; or

b) if the REGISTER request does not map to an existing IP association, and does contain a challenge response, include an "integrity-protected" header field parameter with the value set to "ip-assoc-pending"; or

c) if the REGISTER request does map to an existing IP association, include an "integrity-protected" header field parameter with the value set to "ip-assoc-yes";

NOTE 1: The value of "ip-assoc-pending" for the "integrity-protected" header field parameter or the absence of an "integrity-protected" header field parameter in the Authorization header field is an indication to the I-CSCF and S-CSCF that this is an initial REGISTER request.

2) if the P-CSCF adds a "received" header field parameter and UDP is being used, also add an "rport" Via header field parameter with the IP source port of the received REGISTER request; and

3) if the REGISTER request does not contain an Authorization header field and the requests was received over a non 3GPP access network, insert a P-Access-Network-Info header field as described in subclause 5.2.1 step 4).

NOTE 2: How the P-CSCF recognizes over which access network a request was received is an implementation specific feature.

NOTE 3: Subclause 5.2.1 describes the encoding of the P-Access-Network-Info header field, the mandatory requirement is defined in the above bullet.

If the P-CSCF receives a 500 (Server Internal Error) or 504 (Server Time-Out) response to a REGISTER request, and if the REGISTER request is mapped to an existing IP association, then the P-CSCF shall delete the IP association.

NOTE 4: The P-CSCF deletes the IP association on receipt of 500 (Server Internal Error) or 504 (Server Time-Out) so that the next REGISTER request received from the UE will look like an initial REGISTER request.

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

1) insert a Security-Server header field to specify the media plane security mechanisms the P-CSCF (IMS-ALG) supports, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7; and

2) send the 401 (Unauthorized) response to the UE unprotected as defined in clause 4 of RFC 3581 [56A].

NOTE 5: The P-CSCF does not include signalling plane security mechanisms because the Require and Proxy-Require header fields in the REGISTER request do not contain "sec-agree".

When the P-CSCF receives a 200 (OK) response to a REGISTER request as defined in subclause 5.2.2.1, and the registration expiration interval value is different than zero, the P-CSCF shall additionally:

a) create an IP association by storing and associating the UE’s packet source IP address and port along with the "sent-by" parameter of the Via header field, cf. RFC 3261 [26], of the REGISTER request with the private user identity and all the successfully registered public user identities related to that private user identity;

b) overwrite any existing IP association which has the same pair of IP address and port, but a different private user identity; and

c) send the 200 (OK) response to the UE unprotected as defined in clause 4 of RFC 3581 [56A].

5.2.2.4 SIP digest with TLS as a security mechanism

TLS is optional to implement and is used only in combination with SIP digest authentication. If the P-CSCF supports TLS, then the P-CSCF shall support TLS as described in 3GPP TS 33.203 [19]. If the P-CSCF supports TLS, the P-CSCF shall support TLS ciphersuites as described in 3GPP TS 33.203 [19].

When the P-CSCF receives a REGISTER request from the UE, as defined in subclause 5.2.2.1, the P-CSCF shall additionally:

1) in case the REGISTER request was received without protection on the default port or port advertised to UE for P-CSCF discovery and with the Security-Client header field indicating "tls", then:

a) remove and store the Security-Client header field;

b) do not include the "integrity-protected" header field parameter in the Authorization header;

c) 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 to the source port of the received REGISTER request; and

d) insert the "received" header field parameter in the Via header containing the source IP address that the request came from, as defined in RFC 3581 [56A];

NOTE 1: The absence of an "integrity-protected" header field parameter in the Authorization header is an indication to the I-CSCF and S-CSCF that this is an initial REGISTER request.

NOTE 2: As defined in RFC 3581 [56A], the P-CSCF will insert a "received" header field parameter containing the source IP address that the request came from, even if it is identical to the value of the "sent-by" component.

NOTE 3: Upon receiving the unprotected REGISTER request the P-CSCF detects if the UE is behind a NAT.

2) if the REGISTER request was received protected with a TLS session, on the protected server port, created during an ongoing authentication procedure, where the Session ID for the TLS session is not yet bound to a private user identity, and contains an authentication challenge response (i.e. response parameter), then:

a) check if the private user identity conveyed in the Authorization header of the protected REGISTER request is the same as the private user identity which was previously challenged. If the private user identities are different, the P-CSCF shall reject the REGISTER request by returning a 403 (Forbidden) response;

b) check the existence of the Security-Verify header field and the Security-Client header field. If there are no such headers, then the P CSCF shall return a suitable 4xx response. If there are such headers, 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 request. If those do not match, then there is a potential man-in-the-middle attack. The P-CSCF should reject the request by sending a suitable 4xx response. If the contents match, the P-CSCF shall remove the Security-Verify and the Security-Client header fields;

c) include an "integrity-protected" header field parameter with the value set to "tls-pending"; and

d) if the hostport parameter in the Contact header field is in the form of a FQDN, the P-CSCF shall ensure that the given FQDN will resolve (e.g. by reverse DNS lookup) to the IP address bound to the TLS session; or

2A) if the REGISTER request was received, protected with a TLS session on the protected server port, created during an ongoing authentication procedure, where the Session ID for the TLS session is not yet bound to a private user identity, and does not contain an authentication challenge response (i.e. response parameter), reject the REGISTER request by returning a 403 (Forbidden) response;

3) if the REGISTER request was received on an existing TLS session created during a previous authentication procedure, then:

a) if the REGISTER request includes an Authorization header field, check if the private user identity conveyed in the Authorization header of the protected REGISTER request is the same as the private user identity which was previously authenticated, i.e. the private user identity previously associated with the Session ID for this TLS session. If the private user identities are different, the P-CSCF shall reject the REGISTER request by returning a 403 (Forbidden) response;

b) check the existence of the Security-Verify header field and 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 headers, 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 request. If those do not match, then there is a potential man-in-the-middle attack. The P-CSCF should reject the request by sending a suitable 4xx response;

c) the P-CSCF shall remove and store the Security-Client header field and remove the Security-Verify header field before forwarding the request to the S-CSCF; and

d) include an "integrity-protected" header field parameter with the value set to "tls-yes".

If the P-CSCF require security agreement, and the Security-Client header field is not present, then the P-CSCF shall return a suitable 4xx response.

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

1) insert a Security-Server header field in the response, containing the P-CSCF selected signalling plane mechanism name, as specified in Annex H of 3GPP TS 33.203 [19]. The P-CSCF shall support and indicate the "tls" security mechanism, as specified in RFC 3329 [48]. The P-CSCF shall support the TLS ciphersuites as described in 3GPP TS 33.203 [19] and shall announce support for them according to the procedures defined in RFC 3329 [48]; and

1A) insert a Security-Server header field in the response, containing the P-CSCF static media plane security list, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7;

2) send the 401 (Unauthorized) response to the UE using the TLS session with which the associated REGISTER request was protected, or unprotected in case the REGISTER request was received unprotected. If the 401 (Unauthorized) response to the unprotected REGISTER request is sent using UDP, the P-CSCF shall send the response to the IP address listed in the "received" header field parameter and the port in the "rport" header field parameter. In case of TCP, the P-CSCF shall send the response over the same TCP connection over which the request was received from the UE.

NOTE 4: The challenge in the 401 (Unauthorized) response sent back by the S-CSCF to the UE as a response to the REGISTER request is piggybacked by the P-CSCF to insert the Security-Server header field in it.

– create an association by storing and associating the UEs IP address and port of the TLS connection with the TLS Session ID, the private user identity and all the successfully registered public user identities related to that private user identity; and

– protect the 200 (OK) response to the REGISTER request within the same TLS session to that in which the request was protected.

5.2.2.5 NASS-IMS bundled authentication as a security mechanism

When the P-CSCF receives a REGISTER request from the UE, as defined in subclause 5.2.2.1, the P-CSCF shall additionally:

1) perform the NASS-IMS bundled authentication related query from the P-CSCF to the TISPAN NASS;

2) if the query in step 1) is successful, insert a P-Access-Network-Info header field as described in subclause 5.2.1 step 4); and

3) if the P-CSCF adds a "received" header field parameter and UDP is being used, the P-CSCF shall also add an "rport" Via header field parameter with the IP source port of the received REGISTER request.

When the P-CSCF receives a 200 (OK) response to a REGISTER request from the UE, as defined in subclause 5.2.2.1, the P-CSCF shall additionally:

1) store an association between the IP source address and port of the initial REGISTER request and the public user identities found in the P-Associated-URI header field value and associate them to the public user identity under registration;

2) store an association between the IP source address and port of the initial REGISTER request the default public user identity for use with procedures for the P-Asserted-Identity header field. The default public user identity is the first on the list of URIs present in the P-Associated-URI header field; and

3) insert a Security-Server header field to specify the media plane security mechanisms the P-CSCF (IMS-ALG) supports, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7.

NOTE 3: The P-CSCF does not include signalling plane security mechanisms because the Require and Proxy-Require header fields in the REGISTER request do not contain "sec-agree".

5.2.2.6 GPRS-IMS-Bundled authentication as a security mechanism

When the P-CSCF receives a SIP request from a GPRS-IMS-Bundled UE, the P-CSCF checks the IP address in the "sent-by" parameter of the Via header field provided by the UE as specified in RFC 3261 [6]. If the "sent-by" parameter contains a domain name, or if it contains an IP address that differs from the packet source IP address, the P-CSCF adds a "received" header field parameter to that Via header field value. This parameter contains the source IP address from which the packet was received.

When the P-CSCF receives a 200 (OK) response to a REGISTER request from the UE, as defined in subclause 5.2.2.1, the P-CSCF shall additionally:

4) insert a Security-Server header field to specify the media plane security mechanisms the P-CSCF (IMS-ALG) supports, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7.

NOTE: The P-CSCF does not include signalling plane security mechanisms because the Require and Proxy-Require header fields in the REGISTER request do not contain "sec-agree".

5.2.2.7 P-CSCF reconfigured to not accept registrations

If the P-CSCF has been reconfigured to not accept initial registrations and reregistrations and to redirect incoming registrations to another P-CSCF, on recepetion of a REGISTER request the P-CSCF shall return a 305 (Use Proxy) response.

NOTE 1: As an example, this situation can happen in case the P-CSCF has been administratively configured to force the UEs to attempt initial registration with another P-CSCF before shutdown.

NOTE 2: The UE does not use the Contact header field of 305 (Use Proxy) response to determine the IP address of the new P-CSCF through which the UE will attempt a new initial registration.

5.2.3 Subscription to the user’s registration-state event package

Upon receipt of a 200 (OK) response to the first initial REGISTER request (i.e. this was the first initial REGISTER request that the P-CSCF received from the user identified with its private user identity), the P-CSCF shall:

1) generate a SUBSCRIBE request in accordance with RFC 3680 [43] and RFC 6665 [28], with the following elements:

a) a Request-URI set to the resource to which the P-CSCF wants to be subscribed to, i.e. to the SIP URI that is the default public user identity of the user;

b) a From header field set to the P-CSCF’s SIP URI;

c) a To header field, set to the SIP URI that is the default public user identity of the user;

d) an Event header field set to the "reg" event package;

e) an Expires header field set to a value higher than the registration expiration interval value indicated in the 200 (OK) response to the REGISTER request;

f) a P-Asserted-Identity header field:

– if the received 200 (OK) response to the REGISTER request contained a "+g.3gpp.thig-path" Feature-Caps header field parameter, as defined in subclause 7.9A.9, and if the P-CSCF is located in the visited network, set to the value of the received "+g.3gpp.thig-path" Feature-Caps header field parameter; or

– set to the SIP URI of the P-CSCF, which was inserted into the Path header field during the registration of the user to whose registration state the P-CSCF subscribes to; and

g) a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17] and a type 1 "orig-ioi" header field parameter. The P-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The P-CSCF shall not include the type 1 "term-ioi" header field parameter;

1A) if

a) the P-CSCF supports indicating the traffic leg as specified in RFC 7549 [225];

b) the SIP URI used in the Request-URI of the SUBSCRIBE request belongs to a UE that is roaming;

c) the P-CSCF is not in the home network; and

d) if required by local policy;

then append the "iotl" SIP URI parameter set to "visitedA-homeA" to the Request-URI;

1B) if required by local policy, then insert a Route header field in the SUBSCRIBE request with the list of service route values saved from the Service-Route header field received in the 200 (OK) response to the last registration of the public user identity with associated contact address and skip steps 2 to 4;

2) if the P-CSCF is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, then the P-CSCF shall forward the request to an IBCF in the visited network;

3) if the P-CSCF is located in the visited network and local policy does not require the application of IBCF capabilities in the visited network towards the home network, determine the entry point of the home network (e.g., by using DNS services) and send the SUBSCRIBE request to that entry point, according to the procedures of RFC 3261 [26]; and

4) if the P-CSCF is located in the home network, then the P-CSCF shall forward the request to an I-CSCF in the home network.

NOTE: The subscription to reg event package is done once per private user identity.

Upon receipt of a dialog establishing NOTIFY request, as specified in RFC 6665 [28], associated with the SUBSCRIBE request, the P-CSCF shall:

1) store the information for the so established dialog;

2) store the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field, if present, of the received NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field of the 2xx response to SUBSCRIBE request;

3) follow the procedures specified in RFC 6665 [28]; and

4) store the "icid-value" header field parameter and the "orig-ioi" header field parameter if present in the received P-Charging-Vector header field.

When sending a response to the NOTIFY request, the P-CSCF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the NOTIFY request, a type 1 "term-ioi" header field parameter and the "icid-value" header field parameter. The P-CSCF shall set the type 1 "term-ioi" header field parameter to a value that identifies the sending network of the response, the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter and the "icid-value" header field parameter is set to the previously received value of "icid-value" header field parameter in the request.

If continued subscription is required the P-CSCF shall automatically refresh the subscription by the reg event package 600 seconds before the expiration time for a previously registered public user identity, either 600 seconds before the expiration time if the initial subscription was for greater than 1200 seconds, or when half of the time has expired if the initial subscription was for 1200 seconds or less. If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the P-CSCF shall still consider the original subscription valid for the duration of the most recently known "Expires" value according to RFC 6665 [28]. Otherwise, the P-CSCF shall consider the subscription invalid and start a new initial subscription according to RFC 6665 [28].

5.2.3A Void

5.2.3B SUBSCRIBE request

Upon receipt of a NOTIFY request with the Subscription-State header field set to "terminated", once the NOTIFY transaction is terminated, the P-CSCF can remove all the stored information related to the associated subscription.

5.2.4 Registration of multiple public user identities

Upon receipt of a NOTIFY request for the dialog associated with the subscription to the reg event package of the user, the P-CSCF shall:

– store the information for the established dialog;

– store the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field, if present, of the SIP NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field of the 2xx response to SIP SUBSCRIBE request;

– identify the public user identity as follows:

1) if no <wildcardedIdentity> subelement is included in the <registration> element, the public user identity is taken from the ‘aor’ attribute of the registration element; or

2) if a <wildcardedIdentity> sub element is included in the <registration> element, the wildcarded public user identity is taken from the <wildcardedIdentity> sub element. The wildcarded public user identity is treated as a public user identity in the procedures of this subclause;

3) for each public user identity whose state attribute in the <registration> element is set to "active", i.e. registered; and

i) the state attribute within the <contact> sub-element is set to "active";

ii) the value of the <uri> sub-element inside the <contact> sub-element is set to the contact address of the user’s UE; and

iii) the event attribute of that <contact> sub-element(s) is set to "registered" or "created";

the P-CSCF shall:

i) bind the indicated public user identity as registered to the contact address of the respective user, including any associated display names, and any parameters associated with either the user or the identities of the user;

ii) add the public user identity to the list of the public user identities that are registered for the user saved against the contact address;

iii) if the <actions> child element is included in the <registration> element, bind the policy received in the <actions> child element of the <registration> element to each contact address of the public user identity; and

iv) if the <actions> child element is not included in the <registration> element, remove the policy bound to each contact address of the public user identity;

4) for each public user identity whose state attribute in the <registration> element is set to "active", i.e. registered: and

i) the state attribute within the <contact> sub-element is set to "terminated";

ii) the value of the <uri> sub-element inside the <contact> sub-element is set to the contact address of the user’s UE; and

iii) the event attribute of that <contact> sub-element(s) is set to "deactivated", "expired", "probation", "unregistered", or "rejected";

the P-CSCF shall consider the binding between the indicated public user identity and the contact address and its related information as deregistered for this user, and shall release all stored information associated with the deregistered contact address and related information associated with this contact address; and

5) for each public user identity whose state attribute in the <registration> element is set to "terminated", i.e. deregistered; and for each <contact> sub-element, if

i) the value of the <uri> sub-element inside each <contact> sub-element is set to the respective contact address of the user’s UE; and

ii) the event attribute of each <contact> sub-element(s) is set to "deactivated", "expired", "probation", "unregistered", or "rejected";

the P-CSCF shall consider the indicated public user identity and all its contact addresses as deregistered for this UE, and shall release all stored information for these public user identity bound to the respective user and remove the public user identity from the list of the public user identities that are registered for the user;

– shall store the "orig-ioi" header field parameter if present in the received P-Charging-Vector header field; and

– follow the procedures specified in RFC 6665 [28].

When sending a response to the NOTIFY request, the P-CSCF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the NOTIFY request, a type 1 "term-ioi" header field parameter and the "icid-value" header field parameter. The P-CSCF shall set the type 1 "term-ioi" header field parameter to a value that identifies the sending network of the response, the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter and the "icid-value" header field parameter is set to the value populated in the initial request for the dialog.

If the P-CSCF is informed that all contact addresses that are registered with this P-CSCF and belonging to the user using its private user identity have been deregistered, i.e. the state attribute within each <contact> sub-element is set to "terminated", the P-CSCF shall either unsubscribe to the reg event package or let the subscription expire.

NOTE 1: Since there can be other active registrations of the user via other P-CSCFs, the S-CSCF will not terminate the by sending a NOTIFY request that includes the Subscription-State header set to "terminated".

If all public user identities, that were registered by the user using its private user identity, have been deregistered, the P-CSCF, will receive from the S-CSCF a NOTIFY request that may include the Subscription-State header field set to "terminated", as described in subclause 5.4.2.1.2. If the Subscription-State header field was not set to "terminated", the P-CSCF may either unsubscribe to the reg event package of the user or let the subscription expire.

NOTE 2: Upon receipt of a NOTIFY request with the Subscription-State header field set to "terminated", the P-CSCF considers the subscription to the reg event package terminated (i.e. as if the P-CSCF had sent a SUBSCRIBE request with an Expires header field containing a value of zero).

NOTE 3: There can be public user identities which are implicitly registered within the registrar (S-CSCF) of the user upon registration of one public user identity. The procedures in this subclause provide a mechanism to inform the P-CSCF about these implicitly registered public user identities.

5.2.5 Deregistration

5.2.5.1 User-initiated deregistration

When the P-CSCF receives a 200 (OK) response to a REGISTER request (sent according to subclause 5.2.2) sent by this UE, then the P-CSCF shall check each Contact header field included in the response. If there is a Contact header field that contains the contact address registered via this P-CSCF via the respective security associations or TLS sessions, and the value of the registration expiration interval value equals zero, then the P-CSCF shall:

1) if the "reg-id" header field parameter is not included in the Contact header field, remove the binding between the public user identity found in the To header field (together with the implicitly registered public user identities) and the contact address indicated in the Contact header field, from the registered public user identities list belonging to this UE and all related stored information;

1A) if the "reg-id" header field parameter is included in the Contact header field, remove the public user identity found in the To header field (together with the implicitly registered public user identities) and the flow identified by the "reg-id" header field parameter and all its related stored information belonging to this UE;

2) if multiple registrations is not used, check if the UE has left any other registered public user identity. When all of the public user identities that were registered by this UE are deregistered, the P-CSCF shall delete any security associations, TLS sessions or IP associations towards the UE, after the server transaction (as defined in RFC 3261 [26]) pertaining to this deregistration terminates; and

2A) if multiple registrations is used, check if the UE has left any other registered public user identity that is bound to this flow. When all of the public user identities that were registered and are bound to this flow are deregistered, the P-CSCF shall delete any security associations or TLS sessions associated with this flow, after the server transaction (as defined in RFC 3261 [26]) pertaining to this deregistration terminates.

NOTE 1: Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" (i.e. all public user identities are deregistered) and the Subscription-State header field set to "terminated", the P-CSCF considers the subscription to the reg event package terminated (i.e. as if the P-CSCF had sent a SUBSCRIBE request with an Expires header field containing a value of zero).

NOTE 2: There is no requirement to distinguish a REGISTER request relating to a registration from that relating to a deregistration. For administration reasons the P-CSCF may distinguish such requests, however this has no impact on the SIP procedures.

NOTE 3: When the P-CSCF has sent the 200 (OK) response for the REGISTER request of the only public user identity currently registered with its associated set of implicitly registered public user identities using the respective security association or TLS session (i.e. no other public user identity belonging to the user is registered with this contact address the associated security association or TLS session), the P-CSCF removes the security association or TLS session established between the P-CSCF and the UE. Therefore further SIP signalling sent over this security association or TLS session (e.g. the NOTIFY request containing the deregistration event) will not reach the UE.

5.2.5.2 Network-initiated deregistration

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

– the state attribute within the <registration> element set to "terminated"; or

– the state attribute within the <registration> element set to "active" and the state attribute within the <contact> sub-element belonging to this UE and registered via this P-CSCF set to "terminated", and the event attribute within the <contact> sub-element belonging to this UE set either to "unregistered", or "rejected" or "deactivated";

the P-CSCF shall remove all stored information for these public user identities for this UE and remove these public user identities from the list of the public user identities that are registered for the user.

NOTE 1: If all public user identities have been removed from the list of the public user identities registered via this P-CSCF, and the NOTIFY request indicates that the UE is still registered (e.g. via another P-CSCF), the P-CSCF can unsubscribe from the reg event package of the UE.

Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" (i.e. all public user identities are deregistered) and the Subscription-State header field set to "terminated" or when all public user identities of the UE have been deregistered, the P-CSCF shall shorten any security associations or TLS sessions towards the UE.

NOTE 2: The security association between the P-CSCF and the UE is shortened to a value that will allow the NOTIFY request containing the deregistration event to reach the UE.

NOTE 3: When the P-CSCF receives the NOTIFY request with Subscription-State header field containing the value of "terminated", the P-CSCF considers the subscription to the reg event package terminated (i.e. as if the P-CSCF had sent a SUBSCRIBE request to the S-CSCF with an Expires header field containing a value of zero).

Upon receipt of a NOTIFY request for the dialog associated with the subscription to the reg event package of the user the P-CSCF shall store the "orig-ioi" header field parameter if present in the received P-Charging-Vector header field.

When sending a response to the NOTIFY request, the P-CSCF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the NOTIFY request, a type 1 "term-ioi" header field parameter and the "icid-value" header field parameter. The P-CSCF shall set the type 1 "term-ioi" header field parameter to a value that identifies the sending network of the response, the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter and the "icid-value" header field parameter is set to the value populated in the initial request for the dialog.

5.2.6 General treatment for all dialogs and standalone transactions excluding the REGISTER method

5.2.6.1 Introduction

The procedures of subclause 5.2.6 and its subclauses are general to all requests and responses, except those for the REGISTER method.

5.2.6.2 Determination of UE-originated or UE-terminated case

Upon receipt of an initial request or a target refresh request or a stand-alone transaction, the P-CSCF shall:

– perform the procedures for the UE-terminating case as described in subclause 5.2.6.4 if the request makes use of the information for UE-terminating calls, which was added to the Path header field entry of the P-CSCF during registration (see subclause 5.2.2), e.g. the message is received at a certain port or the topmost Route header field contains a specific user part or parameter;

– perform the procedures for the UE-originating case as described in subclause 5.2.6.3 if this information is not used by the request.

5.2.6.3 Requests initiated by the UE

5.2.6.3.1 General for all requests

When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction from a UE that is not considered as privileged sender, and:

– the request does not include any P-Preferred-Identity header field or none of the P-Preferred-Identity header fields included in the request matches any of the registered public user identities or any of the registered wildcarded public user identities, then the P-CSCF shall identify the originator and the served user of the request by the default public user identity;

– the request includes one or two P-Preferred-Identity header field(s) each of which matches one of the registered public user identity or a registered wildcarded public user identity, the P-CSCF shall identify the originator and the served user of the request by the public user identity from the first such P-Preferred-Identity header field; and

– the request includes two P-Preferred-Identity header fields, each of which matches a registered public user identity or a registered wildcarded public user identity, the P-CSCF shall identify the alternative identity of the originator of the request by the public user identity from the second such P-Preferred-Identity header field.

NOTE: When two identities are provided in the P-Preferred-Identity header fields, it is assumed that one is an alias of the other but P-CSCF does not have the information to verify this.

When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction from a UE that is considered as privileged sender, and the request:

a) does not include any P-Preferred-Identity header field, then the P‑CSCF shall identify the served user of the request by the default public user identity;

b) includes a P-Preferred-Identity header field that does not match one of the registered public user identities or wildcarded public user identities, then the P‑CSCF shall identify the served user of the request by the default public user identity; or

c) includes a P-Preferred-Identity header field that matches one of the registered public user identities or wildcarded public user identities, then the P‑CSCF shall identify the served user of the request by the public user identity from the P-Preferred-Identity header field.

If a P-Preferred-Identity header field value is a SIP URI with the user part starting with a "+", and a "user" SIP URI parameter with a "phone" value, then the P-CSCF shall translate the SIP URI to a tel URI with the user part of the SIP URI in the telephone-subscriber element in the tel URI when checking whether the header field value matches any of the registered public user identities. The P-CSCF shall not modify the header field value within the P-Preferred-Identity header field.

NOTE 1: The case above can occur when the UE receives a public user identity as a tel URI during registration, and then translates that into a SIP URI when sending an initial request for a dialog or a request for a standalone transaction.

In addition, if the request from a UE that is considered as privileged sender:

1) includes one or two P-Asserted-Identity header field(s) then the P‑CSCF shall identify the originator of that request by the public user identity from the first P-Asserted-Identity header field; or

2) does not include a P-Asserted-Identity header field then the P‑CSCF shall identify the originator of that request by the same identity that has been determined for the served user according to steps a), b), and c) above.

NOTE 2: If no security association was set-up during registration, the P-CSCF identifies the originator and served user of the request by using the IP association information stored during the registration for which it holds the list of registered public user identities.

NOTE 3: The contents of the From header field do not form any part of this decision process.

NOTE 4: The display-name portion of the P-Preferred-Identity header field and the registered public user identities is not included in the comparison to determine a match.

NOTE 5: The P-CSCF determines if the UE is considered as privileged sender using the user-related policies provisioned to the P-CSCF (see subclause 5.2.1).

When the P-CSCF receives from the UE an initial request for a dialog or a request for a standalone transaction, 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 3261 [26].

If the P-CSCF adds a "received" header field parameter and UDP is being used, the P-CSCF shall also add an "rport" header field parameter. If IMS AKA is used, the parameter value shall contain the UEs protected server port. Otherwise the parameter value shall contain the IP source of the request.

When the P-CSCF receives from the UE an initial request for a dialog or a request for a standalone transaction, and the request matches a trigger for starting logging of SIP signalling, as described in RFC 8497 [140] and configured in the trace management object defined in 3GPP TS 24.323 [8K], the P-CSCF shall treat the dialog as one for which logging of signalling is in progress and start to log SIP signalling for this dialog according to its trace configuration.

When the P-CSCF receives from the UE a request sent on a dialog for which logging of signalling is in progress, the P-CSCF shall check whether a trigger for stopping logging of SIP signalling has occurred, as described in RFC 8497 [140] and configured in the trace management object defined in 3GPP TS 24.323 [8K]. If a stop trigger event has occurred then the P-CSCF shall stop treating the dialog as one for which logging of signalling is in progress, else the P-CSCF shall append a "logme" header field parameter to the SIP Session-ID header field if the parameter is missing and determine, by checking its trace configuration, whether to log the request.

If:

– the P-CSCF supports indicating the traffic leg as specified in RFC 7459 [225];

– the UE is roaming;

– the P-CSCF is not in the home network; and

– required by local policy;

then the P-CSCF shall:

– if the bottommost Route header field does not contain the "tokenized-by" header field parameter and an "iotl" SIP URI parameter is not already included, append the "iotl" SIP URI parameter with a value set to "visitedA-homeA" to the URI of the bottommost Route header field; and

– if the bottommost Route header field contains the "tokenized-by" header field parameter and an "iotl" SIP URI parameter is not already included, append the "iotl" SIP URI parameter with a value set to "visitedA-homeA" to the URI of the second Route header field from the bottom.

NOTE 6: The bottommost Route header field contains the "iotl" SIP URI parameter if the S‑CSCF added the "iotl" SIP URI parameter in the Service-Route header field during registration and if the home network does not apply topology hiding. The second Route header field from the bottom contains the "iotl" SIP URI parameter if the S‑CSCF added the "iotl" SIP URI parameter in the Service-Route header field during registration and if the home network applies topology hiding.

If a P-CSCF supporting barring of premium numbers when roaming receives a request from a roaming UE and the Request-URI contains an E.164 number encoded as described in subclause 5.1.2A.1.2 which the P-CSCF is able to identify as a premium rate number in the country of the served network, the P-CSCF shall, based on local policy, add the "premium-rate" tel URI parameter specified in subclause 7.2A.17 set to a value "information" or "entertainment" as appropriate.

NOTE 7: The feature barring of premium numbers when roaming can be implemented in the P-CSCF or an IBCF of the visited network. Local policy ensures that the feature is only activiated in one of the two.

5.2.6.3.2 General for all responses

The P-CSCF shall log all SIP responses destined for the UE that contain a "logme" Session-ID header field parameter based on local policy.

5.2.6.3.2A Abnormal cases

When the P-CSCF is unable to forward the request to the next hop by the Route header fields, as determined by one of the following:

– there is no response to the service request and its retransmissions by the P-CSCF; or

– by unspecified means available to the P-CSCF;

and:

– the P-CSCF supports S-CSCF restoration procedures;

then the P-CSCF:

1) shall reject the request by returning a 504 (Server Time-out) response to the UE;

2) shall assume that the UE supports version 1 of the XML Schema for the 3GPP IM CN subsystem XML body if support for the 3GPP IM CN subsystem XML body as described in subclause 7.6 in the Accept header field is not indicated; and

3) shall include in the 504 (Server Time-out) response:

– a Content-Type header field with the value set to associated MIME type of the 3GPP IM CN subsystem XML body as described in subclause 7.6.1;

– a P-Asserted-Identity header field set to the value of the SIP URI of the P-CSCF included in the Path header field during the registration of the user whose UE sent the request causing this response (see subclause 5.2.2.1); and

– a 3GPP IM CN subsystem XML body containing:

a) an <ims-3gpp> element with the "version" attribute set to "1" and with an <alternative-service> child element, set to the parameters of the alternative service:

i) a <type> child element, set to "restoration" (see table 7.6.2) to indicate that S-CSCF restoration procedures are supported;

ii) a <reason> child element, set to an operator configurable reason; and

iii) an <action> child element, set to "initial-registration" (see table 7.6.3).

NOTE 1: These procedures do not prevent the usage of unspecified reliability or recovery techniques above and beyond those specified in this subclause.

If the P-CSCF receives a SIP request different from REGISTER that does not map to an existing IP association and unless the P-CSCF detects that the request is related to an emergency communication that is to be handled according to subclause 5.2.10.2 and if the request is not received from a UE performing the functions of an external attached network using static mode of operation, the P-CSCF shall discard this SIP request, i.e. it shall not send back a 100 Trying SIP response to the UE and shall not try to forward the request to the S-CSCF.

NOTE 2: Reception of SIP requests not corresponding to a stored registration context may happen if the P-CSCF has lost the registration context. If the UE does not receive any SIP response to the sent SIP request (i.e. the SIP transaction timer B or F expires), the UE will perform a new initial registration procedure.

NOTE 3: The P-CSCF can identify that a request is received from a UE performing the functions of an external attached network using static mode of operation by evaluating the TLS session or by other means. Such operation requires preconfiguration of the capability for this attached network in the P-CSCF.

5.2.6.3.3 Initial request for a dialog

When the P-CSCF receives from the UE an initial request for a dialog, and a service route value list exists for the served user of the request, the P-CSCF shall:

1) remove its own SIP URI from the top of the list of Route header fields;

2) if the UE is performing the functions of an external attached network using static mode of operation:

i) select an I-CSCF and insert a Route header field with the URI of the I-CSCF as the topmost Route header field; otherwise

NOTE 1: The list of the I-CSCFs can be either obtained as specified in RFC 3263 [27A] or be provisioned in the P-CSCF.

ii) verify that the resulting list of Route header fields matches the list of URIs received in the Service-Route header field (during the last successful registration or re-registration). This verification is done on a per URI basis, not as a whole string. If the verification fails, then the P-CSCF shall either:

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with the execution of steps 2 onwards; or

b) replace the preloaded Route header field value in the request with the value of the Service-Route header field received during the last 200 (OK) response for the last successful registration or reregistration;

NOTE 2: The P-CSCF can identify that a request is received from a UE performing the functions of an external attached network using static mode of operation by evaluating the TLS session or by other means.

3) if the 200 (OK) response to the last REGISTER request, which created or refreshed the binding of the contact address from which the request is received, has not contained a Feature-Caps header field, specified in RFC 6809 [190] with a "+g.3gpp.atcf" header field parameter, then:

a) if the P-CSCF is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, select an IBCF in the visited network and add the URI of the selected IBCF to the topmost Route header field;

NOTE 3: It is implementation dependent as to how the P-CSCF obtains the address of the IBCF exit point.

3A) if the 200 (OK) response to the last REGISTER request, which created or refreshed the binding of the contact address from which the request is received, contained a Feature-Caps header field with a "+g.3gpp.atcf" header field parameter, then:

a) add the ATCF URI for originating requests that the P-CSCF used to forward the last REGISTER request which created or refreshed the binding of the contact address from which the request is received, to the topmost Route header field;

4) add its own address to the Via header field. The P-CSCF Via header field entry is built in a format that contains the port number of the P-CSCF in accordance with the procedures of RFC 3261 [26], and either:

a) the P-CSCF FQDN that resolves to the IP address, or

b) the P-CSCF IP address;

5) when adding its own SIP URI to the Record-Route header field, build the P-CSCF SIP URI in a format that contains the port number of the P-CSCF where it awaits subsequent requests from the called party, and either:

a) the P-CSCF FQDN that resolves to the IP address; or

b) the P-CSCF IP address.

If the Contact header field in the request contains an "ob" SIP URI parameter, the P-CSCF shall add a flow token and the "ob" SIP URI parameter to its SIP URI;

NOTE 4: The inclusion of these values in the Record-Route header field will ensure that all subsequent mid dialog requests destined for the UE are sent over the same IMS flow over which the initial dialog-forming request was received.

5A) if a P-Private-Network-Indication header field is included in the request, check whether the information saved during registration or from configuration allows the receipt of private network traffic from this source. If private network traffic is allowed, the P-CSCF shall check whether the received domain name in any included P-Private-Network-Indication header field in the request is the same as the domain name associated with that saved information. If private network traffic is not allowed, or the received domain name does not match, then the P-CSCF shall remove the P-Private-Network-Indication header field;

5B) if the served user of the request is understood from information saved during registration or from configuration to always send and receive private network traffic from this source, insert a P-Private-Network-Indication header field containing the domain name associated with that saved information;

5C) if the request is originated from a UE which the P-CSCF considers as privileged sender (including one which is also a UE performing the functions of an external attached network using static mode of operation), keep the P-Asserted-Identity header field unchanged if one was received, or include the originator of the request in the P-Asserted-Identity header field if no P-Asserted-Identity header field was received. In addition remove any P-Preferred-Identity header field, include the served user of the request in the P-Served-User header field as specified in RFC 5502 [133] and skip step 6) below;

NOTE 5: The P-CSCF determines if the UE is considered as privileged sender using the user-related policies provisioned to the P-CSCF (see subclause 5.2.1).

NOTE 6: The P-CSCF can retrieve the identity of the UE performing the functions of an external attached network from the subjectCommonName (CN) if it is not present in the subjectAltName in the certificates during the TLS session setup in accordance with the procedures of RFC 5280 [213] or by other means.

5D) if the request is originated from a UE performing the functions of an external attached network using static mode of operation and which the P-CSCF considers as is not a privileged sender, include the served user of the request in the P-Served-User header field as specified in RFC 5502 [133] and skip step 6) below;

6) remove any P-Preferred-Identity header field or P-Asserted-Identity header field, if present, and insert a P-Asserted-Identity header field with the value identifying the originator of the request and the value of the alternative identity of the originator of the request, if identified (see subclause 5.2.6.3.1), including the display name if previously stored during registration representing the served user of the request;

6A) if the identity of the served user of the request was taken from P-Preferred-Identity header field by matching a registered wildcarded public user identity, and the identity of the served user is not a distinct identity within the range of the wildcarded public user identity, include the wildcarded public user identity value in the P-Profile-Key header field as defined in RFC 5002 [97];

NOTE 7: The matching of distinct public user identities takes precedence over the matching of wildcarded public user identities.

7) add a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17] and a type 1 "orig-ioi" header field parameter. The P-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The P-CSCF shall not include the type 1 "term-ioi" header field parameter. Based on local policy, the P-CSCF shall add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier;

7A) if the request comes from a UE performing the functions of an external attached network using static mode of operation add the "orig" parameter to the dialog request to indicate that this is an originating request; and

8) if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values received in the request such that the P-CSCF is able to release the session if needed. If the Contact header field in the INVITE request contains a GRUU, the P-CSCF shall save the GRUU received in the Contact header field of the request and associate that GRUU with the UE contact address used during registration or with the registration flow and the associated UE contact address used over which the INVITE request was received such that the P-CSCF is able to release the session if needed

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

NOTE 8: According to RFC 5626 [92], an approach such as having the Edge Proxy adds a Record-Route header field with a flow token is one way to ensure that mid-dialog requests are routed over the correct flow.

If the request comes from a UE performing the functions of an external attached network using static mode of operation:

– no response is received to the initial request for dialog and its retransmissions by the P-CSCF; or

– a 3xx response or 480 (Temporarily Unavailable) response is received,

the P-CSCF shall repeat the actions of the above bullets with a different I-CSCF.

If the P-CSCF fails to forward the initial request for dialog to any I-CSCF, the P-CSCF shall send back a 504 (Server Time-Out) response to the UE performing the functions of an external attached network, in accordance with the procedures in RFC 3261 [26].

5.2.6.3.4 Responses to an initial request for a dialog

When the P-CSCF receives any 1xx or 2xx response to the above request, the P-CSCF shall:

1) store the values received in the P-Charging-Function-Addresses header field;

2) store the list of Record-Route header fields from the received response;

3) store the dialog ID and associate it with the private user identity and public user identity involved in the session;

4) if a security association or TLS session exists, in the response rewrite its own Record Route entry to its own SIP URI that contains the protected server port number of the security association or TLS session established from the UE to the P-CSCF and either:

a) the P-CSCF FQDN that resolves to the IP address of the security association or TLS session established from the UE to the P-CSCF; or

b) the P-CSCF IP address of the security association or TLS session established from the UE to the P-CSCF;

NOTE 1: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of security associations. For details on the selection of the protected port values see 3GPP TS 33.203 [19].

5) if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is used, in the response rewrite its own Record-Route entry to its own SIP URI that contains an unprotected server port number where the P-CSCF expects subsequent requests from the UE; and

6) if the response corresponds to an INVITE request, save the Contact, From, To and Record-Route header field values received in the response such that the P-CSCF is able to release the session if needed;

before forwarding the response to the UE in accordance with the procedures of RFC 3261 [26].

NOTE 2: The P-CSCF can find the IMS communication service supported for the dialog, as determined by the originating home network, in the topmost occurance of the "+g.3gpp.icsi-ref" header field parameter of the Feature-Caps header field(s) of 18x or 2xx response. The information can be used for charging purpose or resource reservation purpose.

The P-CSCF shall forward the response to the UE using the mechanisms described in RFC 3261 [26] and RFC 3581 [56A], i.e. the P-CSCF shall send the response to the IP address indicated in the "received" header field parameter and, in case UDP is used, to the port indicated in the "rport" header field parameter (if present) of the Via header field associated with the UE. In case TCP is used, the P-CSCF shall use the TCP connection on which the REGISTER request was received for sending the response back to the UE.

5.2.6.3.5 Target refresh request for a dialog

When the P-CSCF receives from the UE a target refresh request for a dialog, the P-CSCF shall:

1) verify if the request relates to a dialog in which the originator of the request is involved:

a) if the request does not relates to an existing dialog in which the originator is involved, then the P-CSCF shall answer the request by sending a 403 (Forbidden) response back to the originator. The P-CSCF will not forward the request. No other actions are required; or

b) if the request relates to an existing dialog in which the originator is involved, then the P-CSCF shall continue with the following steps;

1A) remove its own SIP URI from the top of the list of Route header fields;

2) verify that the resulting list of Route header fields matches the list of Record-Route header fields constructed by inverting the order of the stored list of Record-Route header fields and removing its Record-Route header field value from the list. This verification is done on a per URI basis, not as a whole string. If the verification fails, then the P-CSCF shall either:

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with the execution of steps 3 onwards; or

b) replace the Route header field value in the request with the list of Record-Route header fields constructed by inverting the order of the stored list of Record-Route header fields and removing its Record-Route header value from the list;

3) add its own address to the Via header field. The P-CSCF Via header field entry is built in a format that contains the port number of the P-CSCF where it awaits the responses to come, and either:

a) the P-CSCF FQDN that resolves to the IP address, or

b) the P-CSCF IP address;

4) void

5) for INVITE dialogs (i.e. dialogs initiated by an INVITE request), replace the saved Contact and CSeq header field values received in the request such that the P-CSCF is able to release the session if needed. If the Contact header field in the INVITE request contains a GRUU, the P-CSCF shall save the GRUU received in the Contact header field of the request and associate that GRUU with the UE contact address used during session establishment or with the registration flow and the associated UE contact address used during session establishment such that the P-CSCF is able to release the session if needed;

NOTE: The replaced Contact header field value is valid only if a 1xx or 2xx response will be received for the request. In other cases the old value is still valid.

6) if the P-CSCF inserted the header field parameters into the Feature-Caps header field of the initial request for the dialog then when the target refresh request is forwarded in the same direction, the P-CSCF shall insert the header field parameters with the same parameter values in the Feature-Caps header field; and

7) add a P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog and a type 1 "orig-ioi" header field parameter. The P-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The P-CSCF shall not include the type 1 "term-ioi" header field parameter;

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

5.2.6.3.6 Responses to a target refresh request for a dialog

When the P-CSCF receives a 1xx or 2xx response to the above request, the P-CSCF shall:

1) if a security association or TLS session exists, rewrite the address and port number of its own Record Route entry to the same value as for the response to the initial request for the dialog; and

2) replace the saved Contact header field value received in the response such that the P-CSCF is able to release the session if needed;

before forwarding the response to the UE in accordance with the procedures of RFC 3261 [26].

5.2.6.3.7 Request for a standalone transaction

When the P-CSCF receives from the UE the request for a standalone transaction, and a service route value list exists for the served user of the request, the P-CSCF shall:

1) remove its own SIP URI from the top of the list of Route header fields;

2) if the UE is performing the functions of an external attached network using static mode of operation:

i) select an I-CSCF and insert a Route header field with the URI of the I-CSCF as the topmost Route header field; otherwise

NOTE 1: The list of the I-CSCFs can be either obtained as specified in RFC 3263 [27A] or be provisioned in the P-CSCF.

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with the execution of steps 3 onwards; or

b) replace the preloaded Route header field value in the request with the one received during the last registration in the Service-Route header field of the 200 (OK) response;

NOTE 3: It is implementation dependent as to how the P-CSCF obtains the address of the IBCF exit point.

a) add the ATCF URI for originating requests, that the P-CSCF used to forward the last REGISTER request which created or refreshed the binding of the contact address from which the request is received, to the topmost Route header field;

3B) if the request is originated from a UE which the P-CSCF considers as privileged sender (including one which is also a UE performing the functions of an external attached network using static mode of operation), keep the P-Asserted-Identity header field unchanged if one was received, or include the originator of the request in the P-Asserted-Identity header field if no P-Asserted-Identity header field was received. In addition remove any P-Preferred-Identity header field, include the served user of the request in the P-Served-User header field as specified in RFC 5502 [133] and skip step 4) below;

NOTE 4: The P-CSCF determines if the UE is considered as privileged sender using the user-related policies provisioned to the P-CSCF (see subclause 5.2.1).

NOTE 5: The P-CSCF can retrieve the identity of the UE performing the functions of an external attached network from the subjectCommonName (CN) if it is not present in the subjectAltName in the certificates during the TLS session setup in accordance with the procedures of RFC 5280 [213] or by other means.

3D) if the request is originated from a UE performing the functions of an external attached network using static mode of operation and which the P-CSCF considers as is not a privileged sender, include the served user of the request in the P-Served-User header field as specified in RFC 5502 [133] and skip step 4) below;

4) remove any P-Preferred-Identity header field or P-Asserted-Identity header field, if present, and insert P-Asserted-Identity header fields the value identifying the served user of the request and the value of the alternative identity of the originator of the request, if identified (see subclause 5.2.6.3.1), including the display name if previously stored during registration, representing the served user of the request;

4A) if the identity of the served user of the request was taken from P-Preferred-Identity header field by matching a registered wildcarded public user identity, and the identity of the served user is not a distinct identity within the range of the wildcarded public user identity, include the wildcarded public user identity value in the P-Profile-Key header field as defined in RFC 5002 [97];

NOTE 6: The matching of distinct public user identities takes precedence over the matching of wildcarded public user identities.

4B) if a P-Private-Network-Indication header field is included in the request, check whether the information saved during registration or from configuration allows the receipt of private network traffic from this source. If private network traffic is allowed, the P-CSCF shall check whether the received domain name in any included P-Private-Network-Indication header field in the request is the same as the domain name associated with that saved information. If private network traffic is not allowed, or the received domain name does not match, then the P-CSCF shall remove the P-Private-Network-Indication header field;

4C) if the served user of the request is understood from information saved during registration or from configuration to always send and receive private network traffic from this source, insert a P-Private-Network-Indication header field containing the domain name associated with that saved information; and

4D) if the request comes from a UE performing the functions of an external attached network using static mode of operation add the "orig" parameter to the dialog request to indicate that this is an originating request; and

5) add a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17] and a type 1 "orig-ioi" header field parameter. The P-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The P-CSCF shall not include the type 1 "term-ioi" header field parameter. Based on local policy, the P-CSCF shall add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier;

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

If the request comes from a UE performing the functions of an external attached network using static mode of operation:

– no response is received to the standalone SIP request and its retransmissions by the P-CSCF; or

– a 3xx response or 480 (Temporarily Unavailable) response is received,

the P-CSCF shall repeat the actions of the above bullets with a different I-CSCF.

If the P-CSCF fails to forward the standalone SIP request to any I-CSCF, the P-CSCF shall send back a 504 (Server Time-Out) response to the UE performing the functions of an external attached network, in accordance with the procedures in RFC 3261 [26].

5.2.6.3.8 Responses to a request for a standalone transaction

When the P-CSCF receives any response to the above request, the P-CSCF shall:

1) store the values received in the P-Charging-Function-Addresses header field;

before forwarding the response to the UE in accordance with the procedures of RFC 3261 [26].

NOTE: The P-CSCF can find the IMS communication service supported for the standalone transaction, as determined by the originating home network, in the topmost occurance of the "+g.3gpp.icsi-ref" header field parameter of the Feature-Caps header field(s) of 18x or 2xx response. The information can be used for charging purpose.

5.2.6.3.9 Subsequent request other than a target refresh request

When the P-CSCF receives from the UE a subsequent request other than a target refresh request (including requests relating to an existing dialog where the method is unknown), the P-CSCF shall:

1) verify if the request relates to a dialog in which the originator of the request is involved:

b) if the request relates to an existing dialog in which the originator is involved, then the P-CSCF shall continue with the following steps;

1A) remove its own SIP URI from the top of the list of Route header fields;

2) verify that the resulting list of Route header fields matches the list of Record-Route header fields constructed by inverting the order of the stored list of Record-Route header fields and removing its Record-Route header field from the list. This verification is done on a per URI basis, not as a whole string. If the verification fails, then the P-CSCF shall either:

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with the execution of steps 3 onwards; or

3) add a P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog and a type 1 "orig-ioi" header field parameter. The P-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The P-CSCF shall not include the type 1 "term-ioi" header field parameter; and

4) for INVITE dialogs, replace the saved CSeq header field value received in the request such that the P-CSCF is able to release the session if needed;

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

5.2.6.3.10 Responses to a subsequent request other than a target refresh request

Void

5.2.6.3.11 Request for an unknown method that does not relate to an existing dialog

When the P-CSCF receives from the UE the request for an unknown method (that does not relate to an existing dialog), and a service route value list exists for the served user of the request, the P-CSCF shall:

1) if the UE performing the functions of an external attached network using static mode of operation:

i) select an I-CSCF and insert a Route header field with the URI of the I-CSCF as the topmost Route header field; otherwise

NOTE 1: The list of the I-CSCFs can be either obtained as specified in RFC 3263 [27A] or be provisioned in the P-CSCF.

ii) verify that the list of URIs received in the Service-Route header field (during the last successful registration or re-registration) is included, preserving the same order, as a subset of the preloaded Route header fields in the received request. This verification is done on a per URI basis, not as a whole string. If the verification fails, then the P-CSCF shall either:

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with the execution of steps 2 onwards; or

b) replace the Route header field value in the request with the one received during the last registration in the Service-Route header field of the 200 (OK) response;

2) if the 200 (OK) response to the last REGISTER request, which created or refreshed the binding of the contact address from which the request is received, has not contained a Feature-Caps header field, specified in RFC 6809 [190] with a "+g.3gpp.atcf" header field parameter, then:

a) if the P-CSCF is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, then the P-CSCF shall select an IBCF in the visited network and add the URI of the selected IBCF to the topmost Route header field;

NOTE 3: It is implementation dependent as to how the P-CSCF obtains the address of the IBCF exit point.

2A) if the 200 (OK) response to the last REGISTER request, which created or refreshed the binding of the contact address from which the request is received, contained a Feature-Caps header field with a "+g.3gpp.atcf" header field parameter, then:

2B) if the request is originated from a UE which the P-CSCF considers as privileged sender (including one which is also a UE performing the functions of an external attached network using static mode of operation), keep the P-Asserted-Identity header field unchanged if one was received, or include the originator of the request in the P-Asserted-Identity header field if no P-Asserted-Identity header field was received. In addition remove any P-Preferred-Identity header field, include the served user of the request in the P-Served-User header field as specified in RFC 5502 [133] and skip step 3) below;

NOTE 4: The P-CSCF determines if the UE is considered privileged sender using based on the user-related policies provisioned to the P-CSCF (see subclause 5.2.1).

2C) if the request is originated from a UE performing the functions of an external attached network using static mode of operation and which the P-CSCF considers as is not a privileged sender, include the served user of the request in the P-Served-User header field as specified in RFC 5502 [133] and skip step 3) below;

3) remove any P-Preferred-Identity header field or P-Asserted-Identity header field, if present, and insert a P-Asserted-Identity header fields the value identifying the originator of the request and the value of the alternative identity of the originator of the request, if identified (see subclause 5.2.6.3.1), including the display name if previously stored during registration, representing the served user of the request;

3A) if the identity of the served user of the request was taken from P-Preferred-Identity header field by matching a registered wildcarded public user identity, and the identity of the served user is not a distinct identity within the range of the wildcarded public user identity, include the wildcarded public user identity value in the P-Profile-Key header field as defined in RFC 5002 [97]; and

3B) if the request comes from a UE performing the functions of an external attached network using static mode of operation add the "orig" parameter to the dialog request to indicate that this is an originating request; and

4) add a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17] and a type 1 "orig-ioi" header field parameter. The P-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The P-CSCF shall not include the type 1 "term-ioi" header field parameter. Based on local policy, the P-CSCF shall add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier;

NOTE 6: The matching of distinct public user identities takes precedence over the matching of wildcarded public user identities.

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

If the request comes from a UE performing the functions of an external attached network using static mode of operation:

– no response is received to the standalone SIP request and its retransmissions by the P-CSCF; or

– a 3xx response or 480 (Temporarily Unavailable) response is received,

the P-CSCF shall repeat the actions of the above bullets with a different I-CSCF.

If the P-CSCF fails to forward the unknown SIP request to any I-CSCF, the P-CSCF shall send back a 504 (Server Time-Out) response to the UE performing the functions of an external attached network using static mode of operation, in accordance with the procedures in RFC 3261 [26].

5.2.6.3.12 Responses to a request for an unknown method that does not relate to an existing dialog

NOTE: The P-CSCF can find the IMS communication service supported for the transaction, as determined by the originating home network, in the topmost occurance of the "+g.3gpp.icsi-ref" header field parameter of the Feature-Caps header field(s) of 18x or 2xx response. The information can be used for charging purpose.

5.2.6.4 Requests terminated by the UE

5.2.6.4.1 General for all requests

The P-CSCF shall log all SIP requests destined for the UE that contain a "logme" Session-ID header field parameter based on local policy.

If the serving network supports PCRF based P-CSCF restoration and the Restoration-Info header field is included in the incoming request, and the P-CSCF has no binding for the identity in the Request-URI, the P-CSCF shall:

– initiate the PCRF based P-CSCF restoration procedure as specified in 3GPP TS 23.380 [7D] using the IMSI value contained in the Restoration-Info header field; and

– reject the request with a 404 (Not Found) response.

If the P-CSCF supports PCRF based P-CSCF restoration procedures, the P-CSCF shall remove the Restoration-Info header field, if included in the incoming request.

If the serving network supports HSS based P-CSCF restoration procedures and the P-CSCF has no binding for the identity in the Request-URI, the P-CSCF shall reject the request with a 404 (Not Found) response.

Editor’s note: [WI: IMSProtoc7, CR#5264] P-CSCF procedures of the Service-Interact-Info header field are for further study.

If the user-related policies provisioned to the P-CSCF (see subclause 5.2.1) do not indicate that the served UE is authorized to send early media, the P-CSCF shall not allow media flows in forward and backward direction before the 200 (OK) response to the initial INVITE is received. Based on operator policy the P-CSCF shall either remove the P-Early-Media header field or replace the value of the P-Early-Media header field with "inactive", if received from the terminating UE.

If the user-related policies provisioned to the P-CSCF (see subclause 5.2.1) indicate that the served UE is authorized to send early media, the P-CSCF shall not remove or modify the P-Early-Media header field if received in an UPDATE request.

5.2.6.4.2 General for all responses

When the P-CSCF receives, destined for the UE, a response sent on a dialog for which logging of signalling is in progress, the P-CSCF shall check whether a trigger for stopping logging of SIP signalling has occurred, as described in RFC 8497 [140] and configured in the trace management object defined in 3GPP TS 24.323 [8K]. If a stop trigger event has occurred then the P-CSCF shall stop treating the dialog as one for which logging of signalling is in progress, else the P-CSCF shall append a "logme" header field parameter to the SIP Session-ID header field if the parameter is missing and determine, by checking its trace configuration, whether to log the request.

Editor’s note: [WI: IMSProtoc7, CR#5264] P-CSCF procedures of the Service-Interact-Info header field are for further study.

5.2.6.4.3 Initial request for a dialog

When the P-CSCF receives, destined for the UE, an initial request for a dialog, prior to forwarding the request, the P-CSCF shall:

1) if an indication has been received from the PCRF that the signalling bearer to the UE is lost, and has not recovered, reject the request by sending 500 (Server Internal Error) response;

NOTE 1: The signalling bearer can be considered as recovered by the P-CSCF when the registration timer expires in P-CSCF and the user is de-registered from the IM CN subsystem, a new REGISTER request from the UE is received providing an indication to the P-CSCF that the signalling bearer to that user has become available or a P-CSCF implementation dependent function which discovers that the signalling bearer is available to the UE.

NOTE 2: The Retry-After header field value is set based on operator policy.

2) convert the list of Record-Route header field values into a list of Route header field values and save this list of Route header fields;

3) if the request is an INVITE request, save a copy of the Contact, CSeq and Record-Route header field values received in the request such that the P-CSCF is able to release the session if needed;

4) if a security association or TLS session exists, when adding its own SIP URI to the top of the list of Record-Route header fields and save the list, build the P-CSCF SIP URI in a format that contains the protected server port number of the security association or TLS session established from the UE to the P-CSCF and either:

a) the P-CSCF FQDN that resolves to the IP address of the security association or TLS session established from the UE to the P-CSCF; or

b) the P-CSCF IP address of the security association or TLS session established from the UE to the P-CSCF;

5) if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is used, when adding its own SIP URI to the top of the list of Record-Route header fields and saving the list, build the P-CSCF URI in a format that contains an unprotected server port number where the P-CSCF expects subsequent requests from the UE;

6) if a security association or TLS session exists, when adding its own address to the top of the received list of Via header fields and save the list, build the P-CSCF Via header field entry in a format that contains the protected server port number of the security association or TLS session established from the UE to the P-CSCF and either:

a) the P-CSCF FQDN that resolves to the IP address of the security association or TLS session established from the UE to the P-CSCF; or

b) the P-CSCF IP address of the security association or TLS session established from the UE to the P-CSCF;

NOTE 3: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of security associations or TLS session. For details of the usage of the two ports see 3GPP TS 33.203 [19].

7) if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled athentication is used, when adding its own address to the top of the received list of Via header fields and saving the list, build the P-CSCF Via header field entry in a format that contains an unprotected server port number where the P-CSCF expects responses to the current request from the UE;

7A) if the recipient of the request is understood from information saved during registration or from configuration to always send and receive private network traffic from this source, remove the P-Private-Network-Indication header field containing the domain name associated with that saved information;

8) store the values received in the P-Charging-Function-Addresses header field;

9) store the "icid-value" header field parameter and if present, the "orig-ioi" header field parameter received in the P-Charging-Vector header field;

10) if the request contains an "fe-identifier" header field parameter, based on local policy, store the content of the "fe-identifier" header field parameter of the P-Charging-Vector header field; and

11) save a copy of the P-Called-Party-ID header field;

before forwarding the request to the UE either in accordance with the procedures of RFC 3261 [26] or as specified in RFC 5626 [92].

If no security association exists between the P-CSCF and the UE performing the functions of an external attached network operating in static mode, the P-CSCF shall initiate a TLS session towards the UE performing the functions of an external attached network operating in static mode before sending the initial request in accordance with 3GPP TS 33.310 [19D].

NOTE 4: The P-CSCF can identify that a call is directed to a UE performing the functions of an external attached network operating in static mode by evaluating the Route header field, the Request URI or other means.

Once the TLS session is set up (using the certificates) the P-CSCF shall send the initial request for dialog over the secure connection to the UE performing the functions of an external attached network operating in static mode.

5.2.6.4.4 Responses to an initial request for a dialog

When the P-CSCF receives any 1xx or 2xx response to the above request, the P-CSCF shall:

0A) if the response is originated from a UE which the P-CSCF considers as privileged sender, remove any P-Preferred-Identity header field, and skip step 1) below;

NOTE: The P-CSCF determines if the UE is considered privileged sender using based on the user-related policies provisioned to the P-CSCF (see subclause 5.2.1).

1) remove any P-Preferred-Identity header field or P-Asserted-Identity header field, if present, and insert a P-Asserted-Identity header field with the saved public user identity from the P-Called-Party-ID header field that was received in the request, plus the display name if previously stored during registration, representing the originator of the response;

2) verify that the list of Via header fields matches the saved list of Via header fields received in the request corresponding to the same dialog, including the P-CSCF Via header field value. This verification is done on a per Via header field value basis, not as a whole string. If the verification fails, then the P-CSCF shall either:

a) discard the response; or

b) replace the Via header field values with those received in the request;

3) verify that the list of URIs received in the Record-Route header field of the request corresponding to the same dialog is included, preserving the same order, as a subset of the Record-Route header field list of this response. This verification is done on a per URI basis, not as a whole string.

If the verification fails, then the P-CSCF shall either:

a) discard the response; or

b) replace the Record-Route header field values with those received in the request, and if a security association or TLS session exists, add its own Record-Route entry with its own SIP URI with the port number where it awaits subsequent requests from the calling party. The P-CSCF shall include in the Record-Route header field either:

– the P-CSCF FQDN that resolves to its IP address; or

– the P-CSCF IP address.

The P-CSCF shall remove the "comp" SIP URI parameter from the Record-Route header field.

If the verification is successful, the P-CSCF shall rewrite its own Record-Route entry to its SIP URI in a format that contains the port number where it awaits subsequent requests from the calling party. The P-CSCF shall include in the Record-Route header field either:

a) the P-CSCF FQDN that resolves to its IP address; or

b) the P-CSCF IP address.

The P-CSCF shall remove the "comp" SIP URI parameter from the Record-Route header field;

When adding its SIP URI to the Record-Route header field, the P-CSCF shall also copy the flow token and the "ob" SIP URI parameter from the Route header field of the initial dialog-forming request destined for the UE to its SIP URI, if the Route header field contained these values;

4) store the dialog ID and associate it with the private user identity and public user identity involved in the session;

5) if the response corresponds to an INVITE request, save the Contact, To, From and Record-Route header field value received in the response such that the P-CSCF is able to release the session if needed. If the Contact header field in the response to the INVITE request contains a GRUU, the P-CSCF shall save the GRUU received in the Contact header field of the response and associate that GRUU with the contact address which was used to send the INVITE request or with the registration flow and the associated UE contact address which was used to send on which the INVITE request such that the P-CSCF is able to release the session if needed; and

6) include in the P-Charging-Vector header field:

– an "icid-value" header field parameter set to the value received in the request;

– the "orig-ioi" header field parameter, if received in the request; and

– a type 1 "term-ioi" header field parameter that identifies the sending network;

– if the P-CSCF has stored an "fe-identifier" header field parameter of the P-Charging-Vector header field, based on local policy, the stored "fe-identifier" header field parameter and include its own address or identifier in the "fe-addr" element of the "fe-identifier" header field parameter of the P-Charging-Vector header field.

before forwarding the response in accordance with the procedures of RFC 3261 [26].

When the P-CSCF receives any other response to the above request, the P-CSCF shall:

1) verify that the list of Via header fields matches the saved list of Via header fields received in the request corresponding to the same dialog, including the P-CSCF Via header field value. This verification is done on a per Via header field value basis, not as a whole string. If these lists do not match, then the P-CSCF shall either:

a) discard the response; or

b) replace the Via header field values with those received in the request; and

2) include in the P-Charging-Vector header field:

a) an "icid-value" header field parameter set to the value received in the request;

b) the "orig-ioi" header field parameter, if received in the request; and

c) a type 1 "term-ioi" header field parameter that identifies the sending network;

before forwarding the response in accordance with the procedures of RFC 3261 [26].

5.2.6.4.5 Target refresh request for a dialog

When the P-CSCF receives, destined for the UE, a target refresh request for a dialog, prior to forwarding the request, the P-CSCF shall:

1) if a security association or TLS session exists, add its own address to the top of the received list of Via header fields and save the list. The P-CSCF Via header field entry is built in a format that contains the protected server port number of the security association or TLS session established from the UE to the P-CSCF and either:

a) the P-CSCF FQDN that resolves to the IP address of the security association or TLS session established from the UE to the P-CSCF; or

b) the P-CSCF IP address of the security association or TLS session established from the UE to the P-CSCF;

NOTE 1: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of security associations or TLS session. For details of the usage of the two ports see 3GPP TS 33.203 [19].

2) if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is used, when adding its own address to the top of the received list of Via header fields and saving the list, build the P-CSCF Via header field entry in a format that contains an unprotected server port number where the P-CSCF expects responses to the current request from the UE;

3) if a security association or TLS session exists, when adding its own SIP URI to the top of the list of Record-Route header fields and save the list, build the P-CSCF SIP URI in a format that contains the protected server port number of the security association or TLS session established from the UE to the P-CSCF and either:

a) the P-CSCF FQDN that resolves to the IP address of the security association or TLS session established from the UE to the P-CSCF; or

b) the P-CSCF IP address of the security association or TLS session established from the UE to the P-CSCF;

4) if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is used, when adding its own SIP URI to the top of the list of Record-Route header fields and saving the list, build the P-CSCF URI in a format that contains an unprotected server port number where the P-CSCF expects subsequent requests from the UE;

5) for INVITE dialogs, replace the saved Contact and CSeq header field values received in the request such that the P-CSCF is able to release the session if needed;

6) if the request is destined to a UE performing the functions of an external attached network operating in static mode, send the request using the already established TLS session as described in subclause 5.2.6.4.3; and

NOTE 2: The replaced Contact header field value is valid only if a 1xx or 2xx response will be received for the request. In other cases the old value is still valid.

7) store the "orig-ioi" header field parameter received in the P-Charging-Vector header field if present;

before forwarding the request to the UE in accordance with the procedures of either RFC 3261 [26] or RFC 5626 [92].

5.2.6.4.6 Responses to a target refresh request for a dialog

When the P-CSCF receives a 1xx or 2xx response to the above request, the P-CSCF shall:

a) discard the response; or

b) replace the Via header field values with those received in the request;

2) if a security association or TLS session exists, rewrite its own Record-Route entry to the same value as for the response to the initial request for the dialog and remove the "comp" SIP URI parameter;

3) replace the saved Contact header field value received in the response such that the P-CSCF is able to release the session if needed. If the Contact header field in the response to the target refresh request for a dialog contains a GRUU, the P-CSCF shall save the GRUU received in the Contact header field of the response and associate that GRUU with the contact address which was used to send the target refresh request or with the registration flow and the associated UE contact address which was used to send the target refresh request such that the P-CSCF is able to release the session if needed;

4) if the P-CSCF inserted the header field parameters into the Feature-Caps header field of the initial request for the dialog then when the response is forwarded in the same direction, the P-CSCF shall insert the header field parameters with the same parameter values in the Feature-Caps header field; and

5) include in the P-Charging-Vector header field:

– an "icid-value" header field parameter set to the value populated in the initial request for the dialog;

– the "orig-ioi" header field parameter, if received in the request; and

– a type 1 "term-ioi" header field parameter that identifies the sending network;

before forwarding the response in accordance with the procedures of RFC 3261 [26].

When the P-CSCF receives any other response to the above request, the P-CSCF shall:

a) discard the response; or

b) replace the Via header field values with those received in the request; and

2) if a security association or TLS session exists, rewrite the IP address and the port number of its own Record-Route entry to the IP address and the port number where it awaits subsequent requests from the calling party and remove the "comp" SIP URI parameter;

3) include in the P-Charging-Vector header field:

a) an "icid-value" header field parameter set to the value populated in the initial request for the dialog;

b) the "orig-ioi" header field parameter, if received in the request; and

c) a type 1 "term-ioi" header field parameter that identifies the sending network;

before forwarding the response in accordance with the procedures of RFC 3261 [26].

5.2.6.4.7 Request for a standalone transaction

When the P-CSCF receives, destined for the UE, a request for a standalone transaction, or a request for an unknown method (that does not relate to an existing dialog), prior to forwarding the request, the P-CSCF shall:

1) if an indication has been received from the PCRF that the signalling bearer to the UE is lost, and has not recovered, reject the request by sending 500 (Server Internal Error) response;

NOTE 2: The Retry-After header field value is set based on operator policy.

2) if a security association or TLS session exists, add its own address to the top of the received list of Via header fields and save the list. The P-CSCF Via header field entry is built in a format that contains the protected server port number of the security association or TLS session established from the UE to the P-CSCF and either:

a) the P-CSCF FQDN that resolves to the IP address of the security association or TLS session established from the UE to the P-CSCF; or

b) the P-CSCF IP address of the security association or TLS session established from the UE to the P-CSCF;

3) if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled authentication is used, when adding its own address to the top of the received list of Via header fields and saving the list, build the P-CSCF Via header field entry in a format that contains an unprotected server port number where the P-CSCF expects responses to the current request from the UE;

3A) if the recipient of the request is understood from information saved during registration or from configuration to always send and receive private network traffic from this source, remove the P-Private-Network-Indication header field containing the domain name associated with that saved information;

4) store the values received in the P-Charging-Function-Addresses header field;

5) store the "icid-value" header field parameter and if present, the "orig-ioi" header field parameter received in the P-Charging-Vector header field;

6) if the request contains an "fe-identifier" header field parameter, based on local policy, store the content of the "fe-identifier" header field parameter of the P-Charging-Vector header field; and

7) save a copy of the P-Called-Party-ID header field;

before forwarding the request to the UE either in accordance with the procedures of RFC 3261 [26] or as specified in RFC 5626 [92].

If no security association exists between the P-CSCF and the UE performing the functions of an external attached network operating in static mode, the P-CSCF shall initiate a TLS session towards the UE performing the functions of an external attached network operating in static mode before sending the standalone SIP request in accordance with 3GPP TS 33.310 [19D].

Once the TLS session is set up (using the certificates) the P-CSCF shall send the standalone SIP request over the secure connection to the UE performing the functions of an external attached network operating in static mode.

5.2.6.4.8 Responses to a request for a standalone transaction

When the P-CSCF receives any response to the above request, the P-CSCF shall:

a) discard the response; or

b) replace the Via header field values with those received in the request;

1A) if the response is originated from a UE which the P-CSCF considers as privileged sender, remove any P-Preferred-Identity header field, and skip step 2) below;

NOTE: The P-CSCF determines if the UE is considered privileged sender using based on the user-related policies provisioned to the P-CSCF (see subclause 5.2.1).

2) remove any P-Preferred-Identity header field or P-Asserted-Identity header field, if present, and insert an P-Asserted-Identity header field with the saved public user identity from the P-Called-Party-ID header field of the request, plus the display name if previously stored during registration, representing the originator of the response; and

3) include in the P-Charging-Vector header field:

– an "icid-value" header field parameter set to the value received in the request;

– the "orig-ioi" header field parameter, if received in the request;

– a type 1 "term-ioi" header field parameter that identifies the sending network; and

before forwarding the response in accordance with the procedures of RFC 3261 [26].

5.2.6.4.9 Subsequent request other than a target refresh request

1) if a security association or TLS session exists, add its own address to the top of the received list of Via header fields and save the list The P-CSCF Via header field entry is built in a format that contains the protected server port number of the security association or TLS session established from the UE to the P-CSCF and either:

a) the P-CSCF FQDN that resolves to the IP address of the security association or TLS session established from the UE to the P-CSCF; or

b) the P-CSCF IP address of the security association or TLS session established from the UE to the P-CSCF;

NOTE: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of security associations or TLS session. For details of the usage of the two ports see 3GPP TS 33.203 [19].

3) void;

4) for INVITE dialogs, replace the saved CSeq header field value received in the request such that the P-CSCF is able to release the session if needed;

5) if the request is destined to a UE performing the functions of an external attached network operating in static mode, send the request using the already established TLS session as described in subclause 5.2.6.4.3; and

6) store the "orig-ioi" header field parameter received in the P-Charging-Vector header field if present;

before forwarding the request to the UE either in accordance with the procedures of RFC 3261 [26] or as specified in RFC 5626 [92].

5.2.6.4.10 Responses to a subsequent request other than a target refresh request

When the P-CSCF receives any response to the above request, the P-CSCF shall:

a) discard the response; or

b) replace the Via header field values with those received in the request; and

2) include in the P-Charging-Vector header field:

a) an "icid-value" header field parameter set to the value received in the initial request for the dialog;

b) the "orig-ioi" header field parameter, if received in the request; and

c) a type 1 "term-ioi" header field parameter that identifies the sending network;

before forwarding the response in accordance with the procedures of RFC 3261 [26].

5.2.6.4.11 Request for an unknown method that does not relate to an existing dialog

Void.

5.2.6.4.12 Responses to a request for an unknown method that does not relate to an existing dialog

Void.

5.2.7 Initial INVITE

5.2.7.1 Introduction

In addition to following the procedures for initial requests defined in subclause 5.2.6, initial INVITE requests also follow the procedures of this subclause.

5.2.7.2 UE-originating case

When the P-CSCF receives from the UE an INVITE request for which resource authorization procedure is required, if it receives from the IP-CAN (e.g. via PCRF) an indication that the requested resources for the multimedia session being established cannot be granted and this indication does not provide an acceptable bandwidth information:

– if the P-CSCF is unable to handle further requests from the UE (i.e. P-CSCF is overloaded by SIP requests), the P-CSCF shall return a 503 (Service Unavailable) response to the received INVITE request. Depending on local operator policy, the 503 (Service Unavailable) response may include a Retry-After header field; and

– if the P-CSCF is able to handle further requests from the UE (i.e. P-CSCF is not overloaded by SIP requests), the P-CSCF shall return a 500 (Server Internal Error) response to the received INVITE request. Depending on local operator policy, the 500 (Server Internal Error) response may include a Retry-After header field.

When the P-CSCF receives from the UE an INVITE request, the P-CSCF may require the periodic refreshment of the session to avoid hung states in the P-CSCF. If the P-CSCF requires the session to be refreshed, then the P-CSCF shall apply the procedures described in RFC 4028 [58] clause 8.

NOTE 1: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality cannot automatically be granted, i.e. at least one of the involved UEs needs to support it.

The P-CSCF shall respond to all INVITE requests with a 100 (Trying) provisional response.

If received from the IP-CAN, the P-CSCF shall also include the access-network-charging-info parameter (e.g. received via the PCRF, over the Rx or Gx interfaces) in the P-Charging-Vector header field in the first request originated by the UE that traverses the P-CSCF, as soon as the charging information is available in the P-CSCF, e.g., after the local resource reservation is complete. Typically, this first request is an UPDATE request if the remote UA supports the "integration of resource management in SIP" extension or a re-INVITE request if the remote UA does not support the "integration of resource management in SIP" extension. See subclause 5.2.7.4 for further information on the access network charging information.

If:

– the UE is roaming;

– the P-CSCF is not in the home network; and

– an agreement exists with the home network operator (as identified by the bottom most URI in the list of URIs received in the Service-Route header field during the last successful registration or re-registration) to support Roaming Architecture for Voice over IMS with Local Breakout;

the P-CSCF may:

– insert into the request a Feature-Caps header field with the "+g.3gpp.trf" header field parameter as specified in RFC 6809 [190]. Based on local policy the P-CSCF shall insert the "+g.3gpp.trf" header field parameter with the parameter value set to the URI of the desired TRF; and

– if a TRF URI is included in the "+g.3gpp.trf" header field parameter and the P-CSCF supports indicating the traffic leg associated with a URI as specified in RFC 7549 [225] and if required by local policy, append an "iotl" SIP URI parameter with a value set to "homeA-visitedA" to the TRF URI.

If:

– the UE is roaming;

– the P-CSCF is not in the home network; and

– the visited network supports MRB functionality for the allocation of MRF resources and if an agreement exists with the home operator (identified by the bottom most URI in the list of URIs received in the Service-Route header field during the last successful registration or re-registration) to provide access to MRF resources from the visited network;

the P-CSCF may insert into the request a Feature-Caps header field with the "+g.3gpp.mrb" header field parameter, as specified in RFC 6809 [190]. Based on local policy the P-CSCF shall insert the "+g.3gpp.mrb" header field parameter with the parameter value set to the URI of the desired MRB.

The P-CSCF (IMS-ALG) shall transparently forward a received Contact header field towards the UE when the Contact header field contains a GRUU or a media feature tag indicating a capability for which the URI can be used.

NOTE 2: One example of such a media feature tag is the isfocus media feature tag where the URI in the Contact header field is used by conference services to transport the temporary conference identity that can be used when rejoining an ongoing conference.

NOTE 3: Various mechanisms can be applied to recognize the need for priority treatment (e.g., based on the dialled digits). The exact mechanisms are left to national regulation and network configuration.

Based on the alternative mechanism to recognize the need for priority treatment, the P-CSCF shall insert the temporarily authorised Resource-Priority header field with appropriate namespace and priority value in the INVITE request.

When the P-CSCF responds to the UE with a 500 (Server Internal Error) response after receiving an indication that radio/bearer resources are not available, then based on operator policy, the P-CSCF may include a Reason header field with a protocol value set to "FAILURE_CAUSE" and a "cause" header field parameter set to "1" as specified in subclause 7.2A.18.12.2 and a Response-Source header field with a "fe" header field parameter set to "<urn:3gpp:fe:p-cscf.orig>".

If the P-CSCF supports the in-call access update procedure and if a received a response to the INVITE request contains a Feature-Caps header field with a g.3gpp.in-call-access-update feature capability indicator, the P-CSCF shall store the value of this feature capability indicator.

5.2.7.3 UE-terminating case

When the P-CSCF receives an INVITE request destined for the UE the P-CSCF may require the periodic refreshment of the session to avoid hung states in the P-CSCF. If the P-CSCF requires the session to be refreshed, then the P-CSCF shall apply the procedures described in RFC 4028 [58] clause 8.

When the P-CSCF receives an initial INVITE request destined for the UE, it will have a list of Record-Route header fields. Prior to forwarding the initial INVITE request, the P-CSCF shall respond to all INVITE requests with a 100 (Trying) provisional response.

If received from the IP-CAN, the P-CSCF shall also include the access-network-charging-info parameter (e.g. received via the PCRF, over the Rx or Gx interfaces) in the P-Charging-Vector header field in the first request or reliable response originated by the UE that traverses the P-CSCF, as soon as the charging information is available in the P-CSCF e.g., after the local resource reservation is complete. When the P-CSCF sends the response including P-Charging-Vector header field, the P-CSCF shall set the "icid-value" header field parameter to the previously received value of "icid-value" header field parameter in the request. See subclause 5.2.7.4 for further information on the access network charging information.

If the P-CSCF supports the in-call access update procedure and if the received INVITE request contains a Feature-Caps header field with a g.3gpp.in-call-access-update feature capability indicator, the P-CSCF shall store the value of this feature capability indicator.

5.2.7.4 Access network charging information

The P-CSCF shall include the "access-network-charging-info" header field parameter within the P-Charging-Vector header field as described in subclause 7.2A.5.

5.2.8 Call release

5.2.8.1 P-CSCF-initiated call release

5.2.8.1.1 Cancellation of a session currently being established

Upon receipt of an indication that the signalling bearer is no longer available (e.g. an Rx interface message from PCRF), the P-CSCF shall cancel that dialog by applying the following steps:

1) if the P-CSCF serves the calling user of the session, send out a CANCEL request to cancel the INVITE request towards the terminating UE that includes:

a) if a cause or error code was received from the entity controlling radio/bearer resources, a Reason header field, with an appropriate protocol value in the protocol field, and the "cause" header field parameter set to the received cause or error code; and

b) if:

– no cause or error code was received from the entity controlling radio/bearer resources; or

– if the abort cause PS_TO_CS_HANDOVER was received over Rx from the entity controlling radio/bearer resources;

a Reason header field containing a 503 (Service Unavailable) status code according to the procedures described in RFC 3261 [26] and RFC 3326 [34A]; and

2) if the P-CSCF serves the called user of the session, send out a 500 (Server Internal Error) response to the received INVITE request. If a cause or error code was received from the entity controlling radio/bearer resources the P-CSCF shall include a Reason header field, with a protocol value set to "FAILURE_CAUSE" in the "protocol" header field parameter as described in subclause 7.2A.18.12.2, and the "cause" header field parameter set to "2" as described in subclause 7.2A.18.12.2.

Upon receipt of an indication that QoS or bearer resources are no longer available for a media negotiated in a multimedia session currently being established (e.g. an Rx interface message from PCRF) and if no SIP message removing the media for which resources are no longer available is received within an operator defined time after the reception of the indication, the P-CSCF shall:

1) cancel that dialog by responding to the original INVITE request with a 500 (Server Internal Error) response. If a cause or error code was received from the entity controlling radio/bearer resources the P-CSCF shall include a Reason header field, with a protocol value set to "FAILURE_CAUSE" in the "protocol" header field parameter as described in subclause 7.2A.18.12.2, and the "cause" header field parameter set to "1" as described in subclause 7.2A.18.12.2; and

2) by sending out a CANCEL request to the INVITE request towards the terminating UE that includes a Reason header field containing a 503 (Service Unavailable) status code according to the procedures described in RFC 3261 [26] and RFC 3326 [34A].

5.2.8.1.2 Release of an existing session

Upon:

1) receipt of an indication that the radio/bearer resources are no longer available for a media negotiated in a session (e.g. an Rx interface message from PCRF) and if no SIP message removing the media for which resources are no longer available is received within an operator defined time after the reception of the indication;

2) receipt of an indication that the signalling bearer is no longer available (e.g. an Rx interface message from PCRF); or

3) detecting that the SDP offer conveyed in a SIP response contained parameters which are not allowed according to the local policy (as specified in the subclause 6.2);

the P-CSCF shall release the respective dialog by applying the following steps:

1) if the P-CSCF serves the calling user of the session, then the P-CSCF shall generate a BYE request destined for the called user based on the information saved for the related dialog, including:

– a Request-URI, set to the stored Contact header field provided by the called user;

– a To header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;

– a From header field, set to the From header field value as received in the initial INVITE request;

– a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;

– a CSeq header field, set to the current CSeq value stored for the direction from the calling to the called user, incremented by one;

– a Route header field, set to the routeing information towards the called user as stored for the dialog;

– a Reason header field or Reason header fields that contains:

a) if a cause or error code was received from the entity controlling radio/bearer resources, an appropriate protocol value in the protocol field, and the "cause" header field parameter set to the received cause or error code;

b) if no cause or error code was received from the entity controlling radio/bearer resources, and if radio/bearer interface resources are no longer available, a 503 (Service Unavailable) response code;

c) if no cause or error code was received from the entity controlling radio/bearer resources, and if the signalling bearer is no longer available, a 503 (Service Unavailable) response code;

d) if no cause or error code was received from the entity controlling radio/bearer resources, and if a SDP offer conveyed in a SIP response contained parameters which are not allowed according to the local policy, a 488 (Not Acceptable Here) response code; and

e) if the abort cause PS_TO_CS_HANDOVER was received over Rx from the entity controlling radio/bearer resources, a 503 (Service Unavailable) response code;

– further header fields, based on local policy; and

– send the generated BYE requests towards the called user;

2) if the P-CSCF serves the calling user of the session and upon detecting that the SDP offer conveyed in a SIP response contained parameters which are not allowed according to the local policy (as specified in the subclause 6.2), then the P-CSCF shall generate an additional BYE request destined for the calling user based on the information saved for the related dialog, including:

– a Request-URI, set to a contact address obtained from the stored Contact header field if provided by the calling user. If the stored Contact header field contains either a public or a temporary GRUU, the P-CSCF shall set the Request-URI either to:

a) the stored UE IP address and the UE port associated with the respective GRUU, if the stored Contact header field contains either a public or a temporary GRUU and the bidirectional flow as defined in RFC 5626 [92] is not used for this session; or

b) the UE IP address and UE port associated with the bidirectional flow that the P-CSCF uses to send the in-dialog requests toward the UE as defined in RFC 5626 [92];

– a To header field, set to the From header field value as received in the initial INVITE request;

– a From header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;

– a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;

– a CSeq header field, set to the current CSeq value stored for the direction from the called to the calling user, incremented by one;

– a Route header field, set to the routeing information towards the calling user as stored for the dialog;

– a Reason header field that contains a 488 (Not Acceptable Here) response code;

– further header fields, based on local policy; and

– send the BYE request either:

a) to the contact address indicated in the Request-URI, if the dialog being released did not use the bidirectional flow to send the requests to the UE as defined in RFC 5626 [92]; or

b) over the same flow that the P-CSCF uses to send the in-dialog requests toward the UE as defined in RFC 5626 [92];

3) If the P-CSCF serves the called user of the session, then the P-CSCF shall generate a BYE request destined for the calling user based on the information saved for the related dialog, including:

– a Request-URI, set to the stored Contact header field provided by the calling user;

– a To header field, set to the From header field value as received in the initial INVITE request;

– a From header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;

– a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;

– a CSeq header field, set to the current CSeq value stored for the direction from the called to the calling user, incremented by one;

– a Route header field, set to the routeing information towards the calling user as stored for the dialog;

– a Reason header field or Reason header fields that contains:

c) if no cause or error code was received from the entity controlling radio/bearer resources, and if a SDP offer conveyed in a SIP response contained parameters which are not allowed according to the local policy, a 488 (Not Acceptable Here) response code; and

d) if the abort cause PS_TO_CS_HANDOVER was received over Rx from the entity controlling radio/bearer resources, a 503 (Service Unavailable) response code;

– further header fields, based on local policy; and

– send the generated BYE requests towards the calling user;

4) if the P-CSCF serves the called user of the session and upon detecting that the SDP offer conveyed in a SIP response contained parameters which are not allowed according to the local policy (as specified in the subclause 6.2), then the P-CSCF shall generate an additional BYE request destined for the called user based on the information saved for the related dialog, including:

– a Request-URI, set to a contact address obtained from the stored Contact header field if provided by the called user. If the stored Contact header field contains either a public or a temporary GRUU, the P-CSCF shall set the Request-URI either to:

b) the UE IP address and the UE port associated with the bidirectional flow that the P-CSCF uses to send the in-dialog requests toward the UE as defined in RFC 5626 [92];

– a To header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;

– a From header field, set to the From header field value as received in the initial INVITE request;

– a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;

– a CSeq header field, set to the current CSeq value stored for the direction from the calling to the called user, incremented by one;

– a Route header field, set to the routeing information towards the called user as stored for the dialog;

– a Reason header field that contains a 488 (Not Acceptable Here) response code;

– further header fields, based on local policy; and

– send the BYE request either:

a) to the contact address indicated in the Request-URI, if the dialog being released did not use t the bidirectional flow to send the requests to the UE as defined in RFC 5626 [92]; or

b) over the same flow that the P-CSCF uses to send the in-dialog requests toward the UE as defined in RFC 5626 [92].

Upon receipt of the 2xx responses for the BYE requests, the P-CSCF shall delete all information related to the dialog and the related multimedia session.

5.2.8.1.3 Abnormal cases

Upon receipt of a request on a dialog for which the P-CSCF initiated session release, the P-CSCF shall terminate this received request and answer it with a 481 (Call/Transaction Does Not Exist) response.

5.2.8.1.4 Release of the existing dialogs due to registration expiration and deletion of the security association, IP association or TLS session

If there are still active dialogs associated with the user after the security associations, IP association or TLS sessions were deleted, the P-CSCF shall discard all information pertaining to these dialogs without performing any further SIP transactions with the peer entities of the P-CSCF.

NOTE: If the interface between the P-CSCF and the IP-CAN is supported, the P-CSCF will also indicate (e.g. via the Rx or Gx interface) that the session has been terminated.

5.2.8.2 Call release initiated by any other entity

When the P-CSCF receives a 2xx response for a BYE request matching an existing dialog, then the P-CSCF shall delete all the stored information related to the dialog.

5.2.8.3 Session expiration

If the P-CSCF requested the session to be refreshed periodically, and the P-CSCF got the indication that the session will be refreshed, when the session timer expires, the P-CSCF shall delete all the stored information related to the dialog.

NOTE: If the interface between the P-CSCF and the IP-CAN is supported, the P-CSCF will also indicate to the IP-CAN (e.g. via the Rx or Gx interface), that the session has terminated.

5.2.9 Subsequent requests

5.2.9.1 UE-originating case

The P-CSCF shall respond to all reINVITE requests with a 100 (Trying) provisional response.

For a reINVITE request or UPDATE request from the UE within the same dialog, the P-CSCF shall include the updated access-network-charging-info parameter from P-Charging-Vector header field when sending the SIP request to the S-CSCF. See subclause 5.2.7.4 for further information on the access network charging information.

For an ACK request from the UE sent on a dialog where a 200 (OK) has been received, the P-CSCF shall include the access-network-charging-info parameter from the P-Charging-Vector header field when updated access-network-charging-info is available when sending the ACK request to the S-CSCF. See subclause 5.2.7.4 for further information on the access network charging information.

If priority is supported, the P-CSCF shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field value.

NOTE: A UE-initiated priority upgrade request directly from the UE to the P-CSCF is not supported using a special dial string as described in clause 4.11.

5.2.9.2 UE-terminating case

The P-CSCF shall respond to all reINVITE requests with a 100 (Trying) provisional response.

For a reINVITE request or UPDATE request destined towards the UE within the same dialog, when the P-CSCF sends 200 (OK) response (to the INVITE request or UPDATE request) towards the S-CSCF, the P-CSCF shall include the updated access-network-charging-info parameter in the P-Charging-Vector header field. See subclause 5.2.7.4 for further information on the access network charging information.

If priority is supported, the P-CSCF shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field value and set the backwards indication accordingly.

5.2.10 Emergency service

5.2.10.1 General

If the P-CSCF belongs to a network where the registration is not required to obtain emergency service, the P‑CSCF shall accept any unprotected request on the IP address and port advertised to the UE during the P-CSCF discovery procedure. The P-CSCF shall also accept any unprotected request on the same IP address and the default port as specified in RFC 3261 [26].

When the P-CSCF sends unprotected responses to the UE, it shall use the same IP address and port where the corresponding request was received.

The P-CSCF can handle emergency session and other requests from both a registered user as well as an unregistered user. Certain networks only allow emergency session from registered users.

NOTE 1: If only emergency setup from registered users is allowed, a request from an unregistered user is ignored since it is received outside of the security association, TLS session or IP association.

The P-CSCF can handle emergency session establishment within a non-emergency registration, i.e. one that did not contain the "sos" SIP URI parameter in the Contact header field of the 200 (OK) response.

If the network uses the Resource-Priority header field to control the priority of emergency calls, and the P-CSCF receives a REGISTER request containing an "sos" SIP URI parameter in the Contact header field, the P-CSCF shall, in addition to the normal handling of the REGISTER request, add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135 [197] to the REGISTER request.

Upon receiving the 200 (OK) response to the REGISTER request that completes the emergency registration, as identified by the presence of the "sos" SIP URI parameter in the Contact header field of the 200 (OK) response, the P-CSCF shall not subscribe to the registration event package for any emergency public user identity specified in the REGISTER request.

Upon reception of a REGISTER request containing an "sos" SIP URI parameter in the Contact header field and not containing an Authorization header field, if:

1) the network supports IMS Services for roaming users in deployments without IMS-level roaming interfaces;

2) the UE is roaming; and

3) there is no II-NNI to the HPLMN of the served user;

NOTE 2: The P-CSCF can determine whether the UE is roaming by analysing the home network domain name of the user received in the Request-URI in the REGISTER request.

NOTE 3: The P-CSCF can know if II-NNI to the HPLMN of the served user is supported by analysing the home network domain name of the user received in the Request-URI in the REGISTER request.

or:

1) if required by operator policy; and

2) the UE is not roaming;

the P-CSCF:

1) shall not forward the REGISTER request; and

2) if the PCRF is used to retrieve the EPS-level identities (i.e., IMSI, IMEI(SV)) as specified in 3GPP TS 29.214 [13D] and IMSI is retrieved:

a) if the P-CSCF supports IMSI or IMEI verification upon reception of a REGISTER request without Authorization header;

i) if the IMSI derived from public user identity conveyed in To header is different from the IMSI received from PCRF, shall reject the REGISTER request by returning a 403 (Forbidden) response and shall not perform the rest of steps; and

NOTE 4: The P-CSCF can also derive IMSI from derived private user identity. The private user identity can be derived from the public user identity being registered by removing URI scheme and the following parts of the URI if present: port number, URI parameters, and To header field parameters.

ii) if the IMEI(SV) is retrieved from the PCRF and the TAC and SNR portions of the IMEI obtained from instance ID conveyed in Contact header field are different from the TAC and SNR portions of IMEI(SV) received from PCRF, reject the REGISTER request by returning a 403 (Forbidden) response and shall not perform the rest of steps;

b) if MSISDN is retrieved:

i) shall generate:

– a SIP URI with user=phone for the retrieved MSISDN; and

– a tel URI for the retrieved MSISDN;

and shall include the URIs in the associated set of implicitly registered public user identities bound to the contact address from which the REGISTER request was received; and

ii) shall treat the SIP URI with user=phone for the retrieved MSISDN as the default public user identity for requests received from the contact address from which the REGISTER request was received;

c) if MSISDN is not retrieved:

i) shall generate a temporary public user identity for the IMSI retrieved from the PCRF as specified in 3GPP TS 29.214 [13D] and shall include the temporary public user identity in the associated set of implicitly registered public user identities bound to the contact address from which the REGISTER request was received; and

ii) shall treat the temporary public user identity for the retrieved IMSI as the default public user identity for requests received from the contact address from which the REGISTER request was received; and

NOTE 5: In the case when MSISDN is not retrieved, if the temporary public user identity is not provisioned in the HSS or is provisioned in the HSS, but barred, then a PSAP callback is not possible.

d) shall send a 200 (OK) response for the REGISTER request. In the 200 (OK) response, the P-CSCF shall include a P-Associated-URI header field containing the list of the implicitly registered public user identities bound to the contact address from which the REGISTER request was received. The first URI in the list of public user identities will indicate the default public user identity.

The P-CSCF shall store a configurable list of local emergency service identifiers, i.e. emergency numbers (the emergency numbers that can be resolved in the network to which the P-CSCF belongs) and emergency service URNs (i.e. emergency service URNs identifying emergency services that can be resolved in the network to which the P-CSCF belongs). In addition to the configurable list of local emergency service identifiers, the P-CSCF shall store a configurable list of roaming partners’ emergency service identifiers (i.e. the emergency service numbers or the emergency service URNs identifying emergency services, which can be resolved in the roaming partners’ network). Each emergency number in a configurable list is mapped to an emergency service URN if the network is configured, for the emergency number, to:

– accept a received request including the emergency number; or

– reject, using a 380 (Alternative Service) response, a received request including the emergency number, and include in the response a Contact header field with the emergency service URN.

NOTE 6: The emergency service URN is common to all networks, although subtypes might either not necessarily be in use, or a different set of subtypes is in use in different networks.

Access technology specific procedures are described in each access technology specific annex to determine the originating network of the requests.

NOTE 7: Depending on local operator policy, the P-CSCF has the capability to reject requests relating to specific methods in accordance with RFC 3261 [26], as an alternative to the functionality described above.

5.2.10.2 General treatment for all dialogs and standalone transactions excluding the REGISTER method – requests from an unregistered user

If the P-CSCF receives an initial request for a dialog or standalone transaction, or an unknown method from an unregistered user on the IP address and the unprotected port advertised to the UE during the P-CSCF discovery or the SIP default port, the P-CSCF shall inspect the Request-URI independent of values of possible entries in the received Route header fields for emergency service identifiers. The P-CSCF shall consider the Request URI of the initial request as an emergency service identifier, if it is an emergency number or an emergency service URN in the list of local emergency service identifiers or in the list of roaming partners emergency service identifiers.

If the Request-URI is a service URN with a top-level service type of "sos" as specified in RFC 5031 [69] and the P-CSCF does not consider the Request URI of the initial request as an emergency service identifier, the P-CSCF may:

– remove the right most service identifier and re-inspect the Request-URI for emergency service identifiers; or

– set the Request-URI to an operator defined emergency service URN that matches one of the emergency service identifiers.

If the P-CSCF detects that the Request-URI of the initial request for a dialog or a standalone transaction, or an unknown method matches one of the emergency service identifiers, the P-CSCF:

1) shall include in the Request-URI an emergency service URN, i.e. a service URN with a top-level service type of "sos" in accordance with RFC 5031 [69]:

a) if the received Request-URI matches an emergency service URN, as received in the Request-URI from the UE; and

b) if the received Request-URI does not match an emergency service URN, as deduced from the Request-URI received from the UE;

NOTE 1: Bullet b) can happen if a request is received from a UE not following the procedures in the present document.

2) shall include a topmost Route header field set to the URI associated with an E-CSCF;

NOTE 2: How the list of E-CSCF is obtained by the P-CSCF is implementation dependent.

3) shall execute the procedure described in subclause 5.2.6.3.3, subclause 5.2.6.3.7, subclause 5.2.6.3.11 and subclause 5.2.7.2, as appropriate except for:

– verifying the preloaded route against the received Service-Route header field;

– routing to IBCF;

– removing the P-Preferred-Identity header field;

– inserting a P-Asserted-Identity header field; and

– inserting a type 1 "orig-ioi" header field parameter in the P-Charging-Vector header field;

3A) void;

3B) where the network uses the Resource-Priority header field to control the priority of emergency calls, shall add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135 [197];

4) if the P-CSCF detects that the UE is behind a NAT, and the UE’s Via header field contains a "keep" header field parameter, shall add a value to the parameter, to indicate that it is willing to receive keep-alives associated with the dialog from the UE, as defined in RFC 6223 [143]; and

5) if required by operator policy (e.g. when the network supports IMS services for roaming users in deployments without IMS-level roaming interfaces), and the P-CSCF supports including EPS-level identities (i.e. IMSI, IMEI(SV)) and MSISDN in a request from an unregistered user:

a) shall attempt to retrieve from PCRF the EPS-level identities and MSISDN available for the IP-CAN session of the request:

b) if a Subscription-Id AVP(s) as specified in 3GPP TS 29.214 [13D] with an MSISDN, an IMSI or both is(are) retrieved:

i) shall remove from the request any P-Preferred-Identity header field;

ii) if an MSISDN is retrieved, shall insert in the request a P-Asserted-Identity header field set to a tel URI carrying the MSISDN; and

iii) if an IMSI is retrieved, shall insert in the request a P-Asserted-Identity header field set to a temporary public user identity derived from the IMSI, as defined in 3GPP TS 23.003 [3]; and

c) if a User-Equipment-Info-Type AVP or a User-Equipment-Info-Extension AVP as specified in 3GPP TS 29.214 [13D] with an IMEI(SV) is retrieved where the TAC and SNR portions are different from the TAC and SNR portions of the IMEI received in the "+sip.instance" header field parameter of the Contact header field of the request and if according to operator policy, shall reject the request with 403 (Forbidden) response.

When the P-CSCF receives any 1xx or 2xx response to the above requests, the P-CSCF shall execute the appropriate procedure for the type of request described in subclause 5.2.6.3.4, subclause 5.2.6.3.8, and subclause 5.2.6.3.12, except that the P-CSCF may rewrite the port number of its own Record-Route entry to an unprotected port where the P-CSCF wants to receive the subsequent incoming requests from the UE belonging to this dialog.

If the P-CSCF does not receive any response to the initial request for a dialog or standalone transaction or unknown method (including its retransmissions); or receives a 3xx response or 480 (Temporarily Unavailable) response to an initial request for a dialog or standalone transaction or an unknown method, the P-CSCF shall include a URI associated with a different E-CSCF in the topmost Route header field and forward the request.

When the P-CSCF received a subsequent request in the dialog from the UE, and the network uses the Resource-Priority header field to control the priority of emergency calls, the P-CSCF shall add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135 [197].

When the P-CSCF receives a target refresh request from the UE for a dialog, the P-CSCF shall execute the procedure described in subclause 5.2.6.3.5, except for inserting a type 1 "orig-ioi" header field parameter in the P-Charging-Vector header field.

When the P-CSCF receives from the UE subsequent requests other than a target refresh request (including requests relating to an existing dialog where the method is unknown), the P-CSCF shall execute the procedure described in subclause 5.2.6.3.9, except for inserting a type 1 "orig-ioi" header field parameter in the P-Charging-Vector header field.

5.2.10.2A General treatment for all dialogs and standalone transactions excluding the REGISTER method – requests to an unregistered user

When the P-CSCF receives, destined for the UE, a target refresh request for a dialog, prior to forwarding the request, the P-CSCF shall execute the procedure described in step 5, the paragraph of subclause 5.2.6.4.5.

When the P-CSCF receives a 1xx or 2xx response to the above request the P-CSCF shall execute the procedure described in subclause 5.2.6.4.6, except for inserting type 1 "orig-ioi" and "term-ioi" header field parameters in the P-Charging-Vector header field.

When the P-CSCF receives any other response to the above request the P-CSCF shall execute the procedure described in steps in the paragraph of subclause 5.2.6.4.6 describing when the P-CSCF receives any other response to a target request, except for inserting type 1 "orig-ioi" and "term-ioi" header field parameters in the P-Charging-Vector header field.

When the P-CSCF receives, destined for the UE, a subsequent request for a dialog that is not a target refresh request (including requests relating to an existing dialog where the method is unknown), prior to forwarding the request, the P-CSCF shall execute the procedure described in steps 3 and 4 of subclause 5.2.6.4.9 describing when a P-CSCF receives a subsequent request.

When the P-CSCF receives any other response to the above request the P-CSCF shall execute the procedure described in steps in the paragraph of subclause 5.2.6.4.10 describing when the P-CSCF receives any other response to a subsequent request, except for inserting type 1 "orig-ioi" and "term-ioi" header field parameters in the P-Charging-Vector header field.

5.2.10.3 General treatment for all dialogs and standalone transactions excluding the REGISTER method after emergency registration

If the P-CSCF receives an initial request for a dialog, or a standalone transaction, or an unknown method, for a registered user over the security association, TLS session, or IP association that was created during the emergency registration, as identified by the presence of the "sos" SIP URI parameter in the Contact header field of the 200 (OK) response, the P-CSCF shall inspect the Request-URI independent of values of possible entries in the received Route header fields for emergency service identifiers. The P-CSCF shall consider the Request URI of the initial request as an emergency service identifier, if it is an emergency number or an emergency service URN from the configurable lists that are associated with:

– the country of the operator to which the P-CSCF belongs to; and

– for inbound roamers, the country from which the UE is roaming from. The P-CSCF determines the country to which the UE is belonging to based on the content of the P-Assserted-Identity header field which contains the home network domain name in a SIP URI belonging to the user.

If the P-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone transaction, or an unknown method does not match any one of the emergency service identifiers in the associated lists, the P-CSCF shall either:

– reject the request by returning a 403 (Forbidden) response to the UE; or

– if the Request-URI is a service URN with a top-level service type of "sos" as specified in RFC 5031 [69]:

1) the P-CSCF sets the Request-URI to an operator defined emergency service URN that matches one of the emergency service identifiers; or

2) remove the right most service identifier and re-inspect the Request-URI for emergency service identifiers.

If the P-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone transaction, or an unknown method matches one of the emergency service identifiers in the associated lists, the P-CSCF shall:

1) include in the Request-URI an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031 [69]:

a) if the received Request-URI matches an emergency service URN, as received from the UE in the Request-URI; and

b) if the received Request-URI does not match an emergency service URN, as deduced from the Request-URI received from the UE.

NOTE 1: Bullet b) can happen if a request is received from a UE not following the procedures in the present document.

1A) if the operator policy requires that emergency service requests are forwarded to the S-CSCF and the P-CSCF determines that the network to which the originating user is attached (see the IP-CAN specific annexes for the detailed procedure) is the network the P-CSCF is in and if the user is not roaming, then:

NOTE 2: The P-CSCF can know if the user is roaming by comparing the home network domain name of the user received in the Request-URI in the REGISTER request with its own domain name. If they are different the user is a roaming user.

a) execute the procedure described in subclause 5.2.6.3.3, subclause 5.2.6.3.7, subclause 5.2.6.3.11 and subclause 5.2.7.2, as appropriate except for routing to IBCF;

b) before the request is forwarded in the referenced procedures, include a bottom most Route header field set to the URI associated with an E-CSCF;

NOTE 3: It is implementation dependent as to how the P-CSCF obtains the list of E-CSCFs.

c) afterwards upon receipt of a target refresh request or a subsequent request other than a target refresh request (including requests relating to an existing dialog where the method is unknown) for a dialog from the UE, execute the procedure described in subclause 5.2.6.3.5 and subclause 5.2.6.3.9; and

d) afterwards upon receipt of any response from the UE to a target refresh request or a subsequent request other than a target refresh request (including requests relating to an existing dialog where the method is unknown) for a dialog, execute the procedure described in subclause 5.2.6.4.6 and subclause 5.2.6.4.10;

1B) if the condition for 1A) is not fulfilled then:

a) execute the procedure described in subclause 5.2.6.3.3, subclause 5.2.6.3.7, subclause 5.2.6.3.11 and subclause 5.2.7.2, as appropriate except for:

– verifying the preloaded route against the received Service-Route header field;

– routing to IBCF; and

– inserting a type 1 "orig-ioi" header field parameter in the P-Charging-Vector header field;

b) before the request is forwarded in the referenced procedures, remove all Route header fields and include a Route header field set to the URI associated with an E-CSCF;

NOTE 4: It is implementation dependent as to how the P-CSCF obtains the list of E-CSCFs.

1C) if the request is from a UE that is not considered as privileged sender and if the alternative identity of the originator of the request was not identified (see subclause 5.2.6.3.1):

i) if the P-Asserted-Identity header field in the request to be sent contains a SIP URI and if a tel URI belongs to the set of implicitly registered public user identities that contains the SIP URI, add a second P-Asserted-Identity header field that contains the first tel URI of the implicitly registered public user identities; and

ii) if the P-Asserted-Identity header field in the request to be sent contains a tel URI, add a second P-Asserted-Identity header field that contains the first SIP URI of the implicitly registered public user identities that contains the tel URI;

2) if the request contains a Contact header field containing a GRUU the P-CSCF shall save the GRUU received in the Contact header field of the request and associate it with the UE IP address and UE port such that the P-CSCF is able to route target refresh request containing that GRUU in the Request-URI. The UE port used for the association is determined as follows:

– if IMS AKA or SIP digest with TLS is being used as a security mechanism, the UE protected server port for the security association on which the request was received; or

– if SIP digest without TLS, NASS-IMS bundled authentication or GPRS-IMS-Bundled Authentication is being used as a security mechanism, the UE unprotected port on which the request was received;

3) where the network uses the Resource-Priority header field to control the priority of emergency calls, add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135 [197]; and

4) if the P-CSCF supports calling number verification using signature verification and attestation information as specified in subclause 3.1 and if required by operator policy, the P-CSCF shall perform attestation of the user identity by inserting:

– a "verstat" tel URI parameter, specified in subclause 7.2A.20, to the tel URI or SIP URI with a user=phone parameter in the From header field or the P-Asserted-Identity header field;

– an Attestation-Info header field specified in subclause 7.2.18; and

– an Origination-Id header field, specified in subclause 7.2.19, set to a UUID identifying the P-CSCF which is configured based on local policy;

If the P-CSCF does not receive any response to an initial request for a dialog or standalone transaction or an unknown method sent to an E-CSCF (including its retransmissions); or receives a 480 (Temporarily Unavailable) response to an initial request for a dialog or standalone transaction or an unknown method sent to an E-CSCF, the P-CSCF shall include a URI, associated with a different E-CSCF, in the topmost Route header field and forward the request.

If the P-CSCF does not receive any response to an initial request for a dialog or standalone transaction or an unknown method sent to a S-CSCF (including its retransmissions); or receives a 480 (Temporarily Unavailable) response to an initial request for a dialog or standalone transaction or an unknown method sent to a S-CSCF, the P-CSCF shall include a URI, associated with a different E-CSCF, in the topmost Route header field of the initial request for a dialog or standalone transaction or an unknown method, and forward the request.

When the P-CSCF receives a target refresh request for a dialog with the Request-URI containing a GRUU the P-CSCF shall:

– obtain the UE IP address and UE port associated to the GRUU contained in the Request-URI and rewrite the Request-URI with that UE IP address and UE port; and

– perform the steps in subclause 5.2.6.4.5 for when the P-CSCF receives, destined for the UE, a target refresh request for a dialog.

5.2.10.4 General treatment for all dialogs and standalone transactions excluding the REGISTER method – non-emergency registration

If the P-CSCF receives an initial request for a dialog, or a standalone transaction, or an unknown method, for a registered user, and the request is:

a) understood from saved or included information to relate to private network traffic (see subclause 5.2.6.3), and operator policy requires the P-CSCF to detect an emergency session request relating to private network traffic; or

b) not understood from saved or included information to relate to private network traffic (see subclause 5.2.6.3);

then the P-CSCF shall inspect the Request-URI independent of values of possible entries in the received Route header fields for emergency service identifiers. The P-CSCF shall consider the Request URI of the initial request as an emergency service identifier, if it is an emergency numbers or an emergency service URN from the configurable lists that are associated with:

– the country of the operator to which the P-CSCF belongs to;

– the country of roaming partners, if the request originates from a different country then the country of the network to which the P-CSCF belongs to. Access technology specific procedures are described in each access technology specific annex to determine from which country and roaming partner the request was originated. If the country from which the request originates can not be determined all lists are associated.

0A) determine the geographical location of the UE. Access technology specific procedures are described in each access technology specific annex:

a) if the UE is roaming and the P-CSCF is in the home operator’s network, or the SDP of the request describes CS media (see 3GPP TS 24.292 [8O]), then the P-CSCF:

I) shall reject the request as specified in subclause 5.2.10.5;

b) if the UE is roaming and the P-CSCF is in the same network where the UE is roaming, or the UE is not roaming, then the P-CSCF, depending on operator policies:

I) may reject the request as specified in subclause 5.2.10.5; or

II) may continue with the next steps;

NOTE 1: Roaming is when a UE is in a geographic area that is outside the serving geographic area of the home IM CN subsystem.

NOTE 2: Emergency service URN in the request-URI indicates for the network that the emergency call attempt is recognized by the UE.

1) include in the Request-URI an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031 [69], if necessary. If information on the type of emergency service is known include a sub-service type. The entry in the Request-URI that the P-CSCF includes shall be:

– if the received Request-URI matches an emergency service URN, as received from the UE in the Request-URI; and

– if the received Request-URI does not match an emergency service URN, as deduced from the Request-URI received from the UE;

1A) if operator policy requires that emergency service requests are forwarded to the S-CSCF and the P-CSCF determines that the network to which the originating user is attached (see the IP-CAN specific annexes for the detailed procedure) is the network the P-CSCF is in then:

a) execute the procedure described in subclause 5.2.6.3.3, subclause 5.2.6.3.7, subclause 5.2.6.3.11 and subclause 5.2.7.2, as appropriate except for routing to IBCF;

b) before the request is forwarded in the referenced procedures, include a bottom most Route header field set to the URI associated with an E-CSCF;

NOTE 3: It is implementation dependent as to how the P-CSCF obtains the list of E-CSCFs.

1B) if the condition for 1A) is not fulfilled then:

a) execute the procedure described in subclause 5.2.6.3.3, subclause 5.2.6.3.7, subclause 5.2.6.3.11 and subclause 5.2.7.2, as appropriate except for:

– verifying the preloaded route against the received Service-Route header field;

– routing to IBCF; and

– inserting a type 1 "orig-ioi" header field parameter in the P-Charging-Vector header field;

b) before the request is forwarded in the referenced procedures, remove all Route header fields and include a Route header field set to the URI associated with an E-CSCF;

NOTE 4: It is implementation dependent as to how the P-CSCF obtains the list of E-CSCFs.

1C) if the request is from a UE that is not considered as privileged sender and if the alternative identity of the originator of the request was not identified (see subclause 5.2.6.3.1):

– if IMS AKA or SIP digest with TLS is being used as a security mechanism, the UE protected server port for the security association on which the request was received; or

– if SIP digest without TLS is being used as a security mechanism, the UE unprotected port on which the request was received; and

If the P-CSCF does not receive any response to the initial request for a dialog or standalone transaction or an unknown method sent to an E-CSCF (including its retransmissions); or receives a 480 (Temporarily Unavailable) response to an initial request for a dialog or standalone transaction or an unknown method sent to an E-CSCF, the P-CSCF shall include a URI, associated with a different E-CSCF that has not been tried before for this initial request for the dialog or standalone transaction (including its retransmissions), in the topmost Route header field and forward the request.

If the P-CSCF does not receive any response to the initial request for a dialog or standalone transaction or an unknown method sent to a S-CSCF (including its retransmissions); or receives a 480 (Temporarily Unavailable) response to an initial request for a dialog or standalone transaction or an unknown method sent to a S-CSCF, the P-CSCF shall include a URI, associated with a different E-CSCF that has not been tried before for this initial request for the dialog or standalone transaction (including its retransmissions), in the topmost Route header field of the initial request for a dialog or standalone transaction or an unknown method, and forward the request.

If the P-CSCF:

– does not receive any response to this initial request for a dialog or standalone transaction or an unknown method (including its retransmissions); or receives a 3xx response or 480 (Temporarily Unavailable) response to an initial request for a dialog or standalone transaction or an unknown method, and if all E-CSCFs have been tried before for this initial request for the dialog or standalone transaction (including its retransmissions), the P-CSCF shall reject this request as specified in subclause 5.2.10.5;

– receives:

1) any 4xx response other than a 480 (Temporarily Unavailable) response;

2) any 5xx response;

3) any 6xx response,

and the entry in the Request-URI as received from the UE is not in accordance with RFC 5031 [69], then the P-CSCF shall reject this request as specified in subclause 5.2.10.5.

If the P-CSCF receives from the IP-CAN (e.g. via PCRF) an indication that the requested resources for the multimedia session being established cannot be granted and the entry in the Request-URI as received from the UE is not in accordance with RFC 5031 [69], then the P-CSCF shall:

– send a CANCEL request to cancel the request forwarded to the selected E-CSCF; and

– reject this request as specified in subclause 5.2.10.5.

When the P-CSCF receives a target refresh request for a dialog with the Request-URI containing a GRUU the P-CSCF shall:

– obtain the UE IP address and UE port associated to the GRUU contained in the Request-URI and rewrite the Request-URI with that UE IP address and UE port; and

– perform the steps in subclause 5.2.6.4 for when the P-CSCF receives, destined for the UE, a target refresh request for a dialog.

5.2.10.5 Abnormal and rejection cases

If the IM CN subsystem to where the P-CSCF belongs to is not capable to handle emergency sessions or due to local policy does not handle emergency sessions or only handles certain type of emergency session request or does not support emergency sessions for either the geographical location of the UE is located or the IP-CAN to which the UE is attached, or the SDP of the request describes CS media (see 3GPP TS 24.292 [8O]), or for reasons described in subclause 5.2.10.4, the P-CSCF shall not forward the initial request for a dialog or standalone transaction or an unknown method. The P-CSCF:

I) shall reject the request by returning a 380 (Alternative Service) response;

II) if:

– support for the 3GPP IM CN subsystem XML body as described in subclause 7.6 in the Accept header field is not indicated, the P-CSCF shall assume that the UE supports version 1 of the 3GPP XML Schema for the IM CN subsystem XML; or

– if both the "sv" and "schemaversion" parameters are present, then the P-CSCF shall ignore the value of the "schemaversion" parameter;

III) shall include in the 380 (Alternative Service) response:

a) a Content-Type header field with the value set to associated MIME type of the 3GPP IM CN subsystem XML body as described in subclause 7.6.1;

b) a P-Asserted-Identity header field set to the value of the SIP URI of the P-CSCF included in the Path header field during the registration of the user whose UE sent the request causing this response (see subclause 5.2.2.1); and

c) if required by operator policy implementing national regulatory requirements, a Contact header field with an emergency service URN (i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031 [69]). If a type of emergency service can be deduced from the Request-URI received from the UE and if required by operator policy implementing national regulatory requirements, the P-CSCF shall include in the emergency service URN a sub-service type deduced from the Request-URI received from the UE; and

NOTE 1: If the Request-URI identifies an emergency service with a type of emergency service, and the 380 (Alternative Service) response does not contain a Contact header field with an emergency service URN or contains a Contact header field with an emergency service URN which does not include a sub-service type, and if, upon reception of the response, the UE performs the emergency call attempt in the IM CN subsystem, then the emergency call attempt in the IM CN subsystem can be misrouted.

IV) shall include an IM CN subsystem XML body with the following elements:

a) an <ims-3gpp> element with the "version" attribute set to "1" and with an <alternative-service> child element, set to the parameters of the alternative service;

i) a <type> child element, set to "emergency" (see table 7.6.2) to indicate that it was an emergency call;

ii) a <reason> child element, set to an operator configurable reason; and

iii) an <action> child element, set to "emergency-registration" (see table 7.6.3) if the P-CSCF is accordingly configured by the operator.

NOTE 2: Emergency service URN in the request-URI indicates for the network that the emergency call attempt is recognized by the UE.

NOTE 3: Some networks only allow session requests with a Request-URI containing an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031 [69].

Upon reception of a REGISTER request containing an "sos" SIP URI parameter in the Contact header field and containing an Authorization header field, if:

1) the network supports IMS Services for roaming users in deployments without IMS-level roaming interfaces;

2) required by operator policy;

3) the UE is roaming; and

4) there is no II-NNI to the HPLMN of the served user;

NOTE 4: The P-CSCF can determine whether the UE is roaming by analysing the home network domain name of the user received in the Request-URI in the REGISTER request.

NOTE 5: The P-CSCF can know if II-NNI to the HPLMN of the served user is supported by analysing the home network domain name of the user received in the Request-URI in the REGISTER request.

or:

1) if required by operator policy; and

2) the UE is not roaming;

the P-CSCF:

1) if the P-CSCF supports GPRS-IMS-Bundled authentication, shall reject the request by returning a 420 (Bad Extension) response in which the Unsupported header field contains the value "sec-agree"; and

2) if the P-CSCF does not support GPRS-IMS-Bundled authentication, shall reject the request by returning a 403 (Forbidden) response.

When the P-CSCF responds 420 (Bad Extension) or 403 (Forbidden) response, if required by operator policy implementing national regulatory requirements (i.e., the network support an emergency session for an unregistered user as described in subclause 5.2.10.2), the P-CSCF shall include:

1) a Content-Type header field with the value set to associated MIME type of the 3GPP IM CN subsystem XML body as described in subclause 7.6.1;

2) a Content-Disposition header field with a disposition type "render" value and a "handling" header field parameter with an "optional" value, as described in RFC 3261 [26];

3) a P-Asserted-Identity header field set to the value of the SIP URI of the P-CSCF; and

4) a 3GPP IM CN subsystem XML body containing:

a) an <ims-3gpp> element with the "version" attribute set to "1" and with an <alternative-service> child element, set to the parameters of the alternative service:

i) a <type> child element, set to "emergency" (see table 7.6.2) to indicate that it was an emergency call;

ii) a <reason> child element, set to an operator configurable reason; and

iii) an <action> child element, set to "anonymous-emergencycall" (see table 7.6.3) if the P-CSCF is accordingly configured by the operator.

5.2.11 Void

5.2.12 Resource sharing

The P-CSCF supporting resource sharing shall perform the actions defined in access technology specific annexes.

5.2.13 Priority sharing

The P-CSCF supporting priority sharing shall perform the actions defined in access technology specific annexes.

5.2.14 In-call access update

If the P-CSCF supports the in-call access update procedure, has received the g.3gpp.in-call-access-update feature-capability indicator during session set-up, and determines that the UE has changed location, then the P-CSCF shall generate a MESSAGE request populated as follows:

NOTE: This procedure can be used for both reporting change of IP-CAN and reporting change of PLMN.

1) the Request URI set to the stored value of the g.3gpp.in-call-access-update feature-capability indicator;

2) a From header field set to the FQDN of the P-CSCF sending the request;

3) a To header field, set to the same value as the Request-URI;

4) a P-Asserted-Identity header field set to the default public user identity of the served user;

5) a P-Charging-Vector header field with the "icid-value" header field parameter populated with the ICID value used for the dialog related to the access change and a type 1 "orig-ioi" header field parameter. The P-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The P-CSCF shall not include the type 1 "term-ioi" header field parameter;

6) a P-Access-Network-Info header field including network-provided location information;

7) a P-Visited-Network-ID header field; and

8) if the MESSAGE request is to be sent via the S-CSCF, a Route header field with the S-CSCF address as received in the Service-Route header field during registration.