[TS 24.229]Procedures at the S-CSCF

2017. 1. 25. 17:23

5 Application usage of SIP

5.4 Procedures at the S-CSCF

5.4.0 General

Where the S-CSCF provides emergency call support, the procedures of subclause 5.4.8 shall be applied first.

Upon

1) a third-party registration due to initial registration on behalf of a served public user identity; or

2) a trigger to an AS for unregistered public user identity and there is no IP address of that AS associated with that public user identity stored

the S-CSCF shall store the IP address of the AS and associate the IP address with the public user identity and the AS SIP URI along with all URI parameters.

Editor's Note: [WI:IMSProtoc7, CR#5303] The analysis on error cases is FFS.

5.4.1 Registration and authentication

5.4.1.1 Introduction

The S-CSCF shall determine which authentication mechanism applies based on the contents of the REGISTER request and the authentication mechanism assigned in the HSS:

1) if the REGISTER request contains an Authorization header field with the "integrity-protected" header field parameter set to "no", the S-CSCF shall perform the initial registration procedures with IMS-AKA authentication described in subclauses 5.4.1.2.1 and 5.4.1.2.1A;

2) if the REGISTER request contains an Authorization header field with the "integrity-protected" header field parameter set to "yes", the S-CSCF shall perform the protected registration procedures with IMS-AKA as a security mechanism as described in subclause 5.4.1.2.2;

2A) if the REGISTER request contains an Authorization header field with the "integrity-protected" header field parameter set to "tls-connected" and with the "algorithm" header field parameter set to "AKAv2-SHA-256", and if the S-CSCF supports the IMS AKA using HTTP Digest AKAv2 without IPSec security association, the S-CSCF shall perform:

a) if the REGISTER request does not contain an authentication challenge response, the initial registration procedures for IMS-AKA authentication described in subclauses 5.4.1.2.1 and 5.4.1.2.1A; or

b) if the REGISTER request contains an authentication challenge response, the protected registration procedures with IMS-AKA as a security mechanism as described in subclause 5.4.1.2.2;

NOTE 1: 3GPP TS 33.203 [19] defines support of IMS AKA using http Digest AKAv2 without IPSec security association only for WebRTC.

3) if the REGISTER request does not contain an Authorization header field, then the S-CSCF shall identify the user by the public user identity as received in the To header field of the REGISTER request. The S-CSCF shall derive the private user identity from the public user identity being registered. The S-CSCF shall derive the private user identity by removing SIP URI scheme and the following parts of the SIP URI if present: port number, URI parameters, and To header field parameters or by alternative mechanisms to derive the private user identity if operator policy requires to do so. These alternative mechanisms are not defined in this version of the specification;

4) if the REGISTER request does not contain an Authorization header field and the access-type field in the P-Access-Network-Info header field indicated xDSL, Ethernet, or Fiber access, and containing the "network provided" header field parameter and the S-CSCF supports NASS-IMS-bundled authentication but does not support SIP digest, then the S-CSCF shall perform the initial registration procedures with NASS-IMS bundled authentication as a security mechanism as described in subclause 5.4.1.2.1D;

5) if the REGISTER request does not contain an Authorization header field and the access-type field in the P-Access-Network-Info header field indicates it is received from an IP-CAN different from 3GPP and containing the "network provided" header field parameter and the S-CSCF supports SIP digest but does not support NASS-IMS-bundled authentication, then the S-CSCF shall perform the initial registration procedures with SIP digest as a security mechanism as described in subclauses 5.4.1.2.1 and 5.4.1.2.1B;

6) if the REGISTER request does not contain an Authorization header field and there is no P-Access-Network-Info header field containing the "network provided" field or there is a P-Access-Network-Info header field indicating a 3GPP access network containing the "network provided”, and the S-CSCF supports GPRS-IMS-Bundled authentication, the S-CSCF shall perform the initial registration procedures with GPRS-IMS-Bundled authentication described in subclause 5.4.1.2.1E;

7) if the REGISTER request does not contain an Authorization header field, and the P-Access-Network-Info header field indicates it is received from an access network other than 3GPP, xDSL, Ethernet or Fiber and containing the "network provided" header field parameter, and the S-CSCF supports SIP digest and NASS-IMS bundled authentication, the S-CSCF shall perform the initial registration procedures with SIP digest as a security mechanism as described in subclauses 5.4.1.2.1 and 5.4.1.2.1B:

8) if the REGISTER request does not contain an Authorization header field, and the P-Access-Network-Info header field indicates it is received from a xDSL, Ethernet or Fiber access network, and containing the "network provided" header field parameter, and the S-CSCF supports SIP digest and NASS-IMS bundled authentication, the S-CSCF sends an authentication request for the user to the HSS indicating that the authentication scheme is unknown as described in 3GPP TS 29.228 [14]:

- if the HSS responds with an authentication scheme of SIP digest, then the S-CSCF shall perform the initial registration procedures with SIP digest as a security mechanism as described in subclauses 5.4.1.2.1 and 5.4.1.2.1B; or

- if the HSS responds with an authentication scheme of NASS-IMS bundled authentication and the request was received from a P-CSCF in the home network and the P-CSCF is "TISPAN-enabled", then the S-CSCF shall perform the initial registration procedures with NASS-IMS bundled authentication as a security mechanism as described in subclause 5.4.1.2.1D;

9) if the REGISTER request contains an Authorization header field without an "integrity-protected" header field parameter, the S-CSCF shall send an authentication request for the user to the HSS indicating that the authentication scheme is unknown as described in 3GPP TS 29.228 [14]:

- if the HSS responds with an authentication scheme of NASS-IMS bundled authentication and the request was received from a P-CSCF is in the home network and the P-CSCF is "TISPAN-enabled", then the S-CSCF shall perform the initial registration procedures with NASS-IMS bundled authentication as a security mechanism as described in subclause 5.4.1.2.1D; or

10) if the REGISTER request contains an Authorization header field with the "integrity-protected" header field parameter set to "tls-pending", "tls-yes", "ip-assoc-pending" or "ip-assoc-yes", the S-CSCF shall perform the protected registration procedures for SIP digest described in subclause 5.4.1.2.2A;

11) if the REGISTER request contains an Authorization header field with the "integrity-protected" header field parameter set to "auth-done", the S-CSCF shall perform the protected registration procedures described in subclause 5.4.1.2.2E; and

12) if the REGISTER request contains a JSON Web Token with the "3gpp-waf" JSON Web Token claim or with the "3gpp-wwsf" JSON Web Token claim, as defined in RFC 7519 [235], and if the S-CSCF supports WebRTC, and if the S-CSCF has received authorization information about WAF or WWSF entities from the HSS, or per configuration, then the S-CSCF shall check whether the WAF or WWSF is not barred, as specified in 3GPP TS 33.203 [9] annex X. If the WAF or the WWSF is barred, the S-CSCF shall send a 403 (Forbidden) response to the REGISTER request.

NOTE 2: The S-CSCF needs to be configured to know which P-CSCFs are "TISPAN-enabled" and uses the Via header field to determine which P-CSCF forwarded the registration request.

The S-CSCF shall act as the SIP registrar for all UEs belonging to the IM CN subsystem and with public user identities.

Subclause 5.4.1.2 through subclause 5.4.1.7 define S-CSCF procedures for SIP registration that do not relate to emergency. All registration requests are first screened according to the procedures of subclause 5.4.8.2 to see if they do relate to an emergency registration.

For all SIP registrations identified:

- as relating to an emergency; or

- if priority is supported, as containing an authorised Resource-Priority header field;

the S-CSCF shall give priority over other registrations. This allows special treatment of such registrations.

NOTE 3: 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 S-CSCF shall support the use of the Path and Service-Route header field. The S-CSCF shall also support the Require and Supported header fields. 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. The S-CSCF shall not act as a redirect server for REGISTER requests.

The network operator defines minimum and maximum times for each registration. These values are provided within the S-CSCF.

The procedures for notification concerning automatically registered public user identities of a user are described in subclause 5.4.2.1.2.

If the S-CSCF supports HSS based P-CSCF restoration procedures, and receives a REGISTER request from a P-CSCF that the S-CSCF considers is in a non-working state, the S-CSCF shall consider this P-CSCF as being in a working state.

If the S-CSCF supports PCRF based P-CSCF restoration procedures, and receives a REGISTER request from a P-CSCF that the S-CSCF considers is in a non-working state, the S-CSCF shall consider this P-CSCF as being in a working state.

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

5.4.1.2 Initial registration and user-initiated reregistration

5.4.1.2.1 Unprotected REGISTER

Any REGISTER request received unprotected by the S-CSCF without an Authorization header field, or with an Authorization header field having the "integrity-protected" header field parameter in the Authorization header field set to "no", or without an "integrity-protected" header field parameter is considered to be an initial registration. If such an initial registration contains a private user identity specifically reserved for IM CN subsystem registrations from an MSC Server enhanced for ICS as defined in 3GPP TS 23.003 [3], the S-CSCF shall respond with a 403 (Forbidden) response. The S‑CSCF shall consider this registration attempt as failed..

NOTE 1: For NASS-IMS bundled authentication and GPRS-IMS-Bundled Authentication there is no distinction between a protected and an unprotected REGISTER. There is only an unprotected REGISTER to consider.

NOTE 2: If IMS AKA or SIP digest with TLS are used as a security mechanism, a 200 (OK) final response to an initial registration will only be sent back after the S-CSCF receives a correct authentication challenge response in a REGISTER request that is sent integrity protected.

NOTE 3: A REGISTER with the registration expiration interval value equal to zero will always be received protected. However, it is possible that in error conditions a REGISTER with the registration expiration interval value equal to zero can be received unprotected. In that instance the procedures below will be applied.

Upon receipt of a REGISTER request that is part of an initial registration as outlined above, for a public user identity for which the maximum number of allowed simultaneously registration flows for the used UE (i.e. linked to the same private user identity and instance ID) is reached, if the REGISTER is adding a new registration flow, then the S-CSCF shall reject the REGISTER by generating a 403 (Forbidden) response. If not, the S-CSCF shall continue with the rest of the procedures of this subclause.

Upon receipt of a REGISTER request that is part of an initial registration as outlined above, for a user identity linked to a private user identity and instance ID/reg-id if available, that has previously registered one or more public user identities, the S-CSCF shall:

1) perform the procedure below in this subclause for receipt of a REGISTER request for a public user identity which is not already registered, for the received public user identity;

2) if the multiple registrations is not used and if the authentication that in step 1) has been successful, and there are public user identities (including the public user identity being registered, if previously registered) that belong to this user that have been previously registered with the same private user identity, and with an old contact address different from the one received in the REGISTER request, and the previous registrations have not expired, perform the network initiated deregistration procedure (as described in subclause 5.4.1.5) for the previously registered public user identities belonging to this user including the public user identity being registered, if previously registered; and

3) if the multiple registrations is used (i.e., the "reg-id" header field parameter is included in the REGISTER request), and if the authentication that concludes the initial registration has been successful, and if the public user identity being registered has been previously registered with the same private user identity and the same "+sip.instance" and "reg-id" header field parameter values, and the previous registration has not expired:

a) identify the registration flow being replaced;

b) terminate any dialog, as specified in subclause 5.4.5.1.2, with a status code 480 (Temporarily Unavailable) in the Reason header field of the BYE request, associated with the registration flow being replaced; and

c) send a NOTIFY request to the subscribers to the registration event package for the public user identity indicated in the REGISTER request, as described in subclause 5.4.2.1.2.

NOTE 4: The way the S-CSCF identifies the dialogs associated with the registration flow being replaced is implementation specific.

NOTE 5: The S-CSCF will inform the HSS that the previously registered public user identities, excluding the public user identity being registered, have been deregistered.

NOTE 6: Contact related to emergency registration is not affected. S-CSCF is not able deregister contact related to emergency registration and will not delete that.

When S-CSCF receives a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "no" and a non-empty "response" Authorization header field parameter, the S-CSCF shall ignore the value of the "response" header field parameter.

Upon receipt of a REGISTER request that is part of an initial registration as outlined above, for a public user identity which is not already registered linked to the same private user identity and the "+sip.instance" and "reg-id" header field parameters, if available, the S-CSCF shall:

1) identify the user by the public user identity as received in the To header field and if the REGISTER request includes an Authorization header field, identify the private user identity as received in the "username" Authorization header field parameter of the REGISTER request;

2) check if the P-Visited-Network-ID header field is included in the REGISTER request, and if it is included identify the visited network by the value of this header field;

3) select an authentication vector for the user. If no authentication vector for this user is available, after the S-CSCF has performed the Authentication procedure with the HSS, as described in 3GPP TS 29.228 [14], the S-CSCF shall select an authentication vector as described in 3GPP TS 33.203 [19].

Prior to performing Authentication procedure with the HSS, the S-CSCF decides which HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 3GPP TS 29.228 [14] or use the value as received in the P-User-Database header field in the REGISTER request as defined in RFC 4457 [82];

NOTE 7: The HSS address received in the response to SLF query or as a value of P-User-Database header field can be used to address the HSS of the public user identity in further queries.

NOTE 8: At this point the S-CSCF informs the HSS, that the user currently registering will be served by the S-CSCF by passing its SIP URI to the HSS. This will be used by the HSS to direct all subsequent incoming initial requests for a dialog or standalone transactions destined for this user to this S-CSCF.

NOTE 9: When passing its SIP URI to the HSS, the S-CSCF may include in its SIP URI the transport protocol and the port number where it wants to be contacted.

4) store the "icid-value" header field parameter received in the P-Charging-Vector header field;

5) challenge the user by generating a 401 (Unauthorized) response for the received REGISTER request appropriate to the security mechanism in use;

6) send the so generated 401 (Unauthorized) response towards the UE, and if the URI in the first Path header field has an "ob" SIP URI parameter, include a Require header field with the option-tag "outbound" as described in RFC 5626 [92]; and

7) start timer reg-await-auth which guards the receipt of the next REGISTER request.

If the received REGISTER request indicates that the challenge sent previously by the S-CSCF to the UE was deemed to be invalid by the UE, the S-CSCF shall stop the timer reg-await-auth and proceed as described in the subclause 5.4.1.2.3.

5.4.1.2.1A Challenge with IMS AKA as security mechanism

On sending a 401 (Unauthorized) response to an unprotected REGISTER request, the S-CSCF shall populate the header fields as follows:

1) a WWW-Authenticate header field which transports:

a) a globally unique name of the S-CSCF in the "realm" header field parameter;

b) the RAND and AUTN parameters and optional server specific data for the UE in the "nonce" header field parameter;

c) if the REGISTER request does not contain an Authorization header field with the "algorithm" header field parameter set to "AKAv2-SHA-256":

- the security mechanism, which is "AKAv1-MD5", in the "algorithm" header field parameter;

- the IK (Integrity Key) parameter for the P-CSCF in the "ik" header field parameter (see subclause 7.2A.1); and

- the CK (Cipher Key) parameter for the P-CSCF in the "ck" header field parameter (see subclause 7.2A.1); and

d) if the REGISTER request does contain an Authorization header field with the "algorithm" header field parameter set to "AKAv2-SHA-256", and if the S-CSCF supports the IMS AKA using HTTP Digest AKAv2 without IPSec security association:

- the security mechanism, which is "AKAv2-SHA-256" in the "algorithm" header field parameter.

The S-CSCF shall store the RAND parameter used in the 401 (Unathorized) response for future use in case of a resynchronisation. If a stored RAND already exists in the S-CSCF, the S-CSCF shall overwrite the stored RAND with the RAND used in the most recent 401 (Unauthorized) response.

5.4.1.2.1B Challenge with SIP digest as security mechanism

On sending a 401 (Unauthorized) response to an unprotected REGISTER request, the S-CSCF shall populate the header fields as follows:

1) a WWW-Authenticate header field as defined in RFC 2617 [21], which transports:

- a protection domain in the "realm" header field parameter;

- a "nonce" header field parameter (generated by the S-CSCF);

- an "algorithm" header field parameter; if the algorithm value is not provided in the authentication vector, it shall have the value "MD5"; and

- a "qop" header field parameter; if the qop value is not provided in the authentication vector, it shall contain the value "auth".

5.4.1.2.1C Challenge with SIP digest with TLS as security mechanism

The procedures for subclause 5.4.1.2.1B apply.

NOTE: The S-CSCF is not able to distinguish between SIP Digest with TLS and SIP Digest without TLS for the case of an unprotected REGISTER request, therefore the procedures are the same for both.

5.4.1.2.1D Initial registration and user-initiated reregistration for NASS-IMS bundled authentication

Upon receipt of a REGISTER request that is determined to be NASS-IMS bundled authentication, for a user identity linked to a private user identity that has a registered public user identity but with a new contact address, the S-CSCF shall:

1) perform the procedure for receipt of a REGISTER request without the "integrity-protected" header field parameter in the Authorization header field or without the Authorization header field, for the received public user identity; and

2) if the Contact header field of the REGISTER request does not contain a "reg-id" header field parameter (i.e., the multiple registrations mechanism is not used), and the authentication has been successful, and there are public user identities (including the public user identity being registered, if previously registered) belonging to this user that have been previously registered with the same private user identity and with an old contact address different from the one received in the REGISTER request and if the previous registration have not expired:

a) terminate all dialogs, if any, associated with the previously registered public user identities (including the public user identity being registered, if previously registered), with a status code 480 (Temporarily Unavailable) in the Reason header field of the BYE request, as specified in subclause 5.4.5.1.2;

b) send a NOTIFY request, to the subscribers to the registration event package of the previously registered public user identities, that indicates that all previously registered public user identities (excluding the public user identity being registered) belonging to this user identified with its private user identity, have been deregistered, as described in subclause 5.4.2.1.2. For the public user identity being registered, the NOTIFY request contains the new contact information; and

NOTE 1: The last dialog to be terminated will be the dialog established by the UE subscribing to the reg event package. When sending the NOTIFY request to the UE over this dialog, the S-CSCF will terminate this dialog by setting in the NOTIFY request the Subscription-State header field to the value of "terminated".

c) delete all information associated with the previously registered public user identities.

NOTE 2: Contact related to emergency registration is not affected. The S-CSCF is not able to deregister contact related to emergency registration and will not delete it.

Upon receipt of a REGISTER request that is determined to be NASS-IMS bundled authentication, for a public user identity for which the maximum number of allowed simultaneously registration flows is for the used UE (i.e. linked to the same private user identity and instance ID) is reached, if the REGISTER is adding a new registration flow, then the S-CSCF shall reject the REGISTER by generating a 403 (Forbidden) response. If not, the S-CSCF shall continue with the rest of the procedures of this subclause;

Upon receipt of a REGISTER request without the "integrity-protected" header field parameter in the Authorization header field or without an Authorization header field, which is not for an already registered public user identity linked to the same private user identity, the S-CSCF shall:

1) identify the user by the public user identity as received in the To header field of the REGISTER request and if the Authorization header field is present, the private user identity as received in the Authorization header field of the REGISTER request. If the Authorization header field is not present, the S-CSCF shall derive the private user identity from the public user identity being registered by removing SIP URI scheme and the following parts of the SIP URI if present: port number, URI parameters, and To header field parameters;

2) check whether one or more Line-Identifiers previously received over the Cx interface, and stored as a result of a Authentication procedure with the HSS, are available for the user. If not, the S-CSCF performs the Authentication procedure with the HSS, as described in 3GPP TS 29.228 [14], in order to obtain these Line-Identifiers;

3) in the particular case where the S-CSCF received via the Cx interface one or more Line-Identifiers, compare each of Line-Identifiers with the "dsl-location", "eth-location" or "fiber-location" parameter of the P-Access-Network-Info header field (if present and if it includes the "network-provided" parameter):

- if one of these match, the user is considered authenticated, behave as described in step 5) to 11) of subclause 5.4.1.2.2;

- otherwise i.e. if these do not match, return a 403 (Forbidden) response to the REGISTER request; and

4) if no Line-Identifier is received over the Cx interface, send a 500 (Server Internal Error) response to the REGISTER request.

Upon receipt of a REGISTER request without the "integrity-protected" header field parameter in the Authorization header field or without an Authorization header field, for an already registered public user identity linked to the same private user identity, and for existing contact information, the S-CSCF shall behave as described in subclause 5.4.1.2.2F.

5.4.1.2.1E Initial registration and user-initiated reregistration for GPRS-IMS-Bundled authentication

Upon receipt of a REGISTER request without an Authorization header field, the S-CSCF shall:

1) identify the user by the public user identity as received in the To header field of the REGISTER request. The S-CSCF shall derive the private user identity 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;

1A) if the maximum number of simultaneously registration flows allowed for the related public user identity for the used UE (i.e. linked to the same private user identity and instance ID) is reached, then the S-CSCF shall reject the REGISTER by generating a 403 (Forbidden) response. If not, the S-CSCF shall continue with the rest of the steps;

2) check if the P-Visited-Network-ID header field is included in the REGISTER request, and if it is included identify the visited network by the value of this header field;

3) check whether an IP address is stored for this UE. If no IP address (or prefix) is stored for the UE, query the HSS as described in 3GPP TS 29.228 [14] with the derived private user identity and the public user identity as input and store the received IP address (or prefix) of the UE; if the S-CSCF receives a prefix from the HSS, it will only check against prefixes otherwise it will check against the full IP address;

NOTE 1: At this point the S-CSCF informs the HSS, that the user currently registering will be served by the S‑CSCF by passing its SIP URI to the HSS. This will be indicated by the HSS for all further incoming requests to this user, in order to direct all these requests directly to this S-CSCF.

4) check whether a "received" header field parameter exists in the Via header field provided by the UE. If a "received" header field parameter exists, the S-CSCF shall compare the IP address recorded in the "received" header field parameter against the UE's IP address stored during registration. In case of IPv6 stateless autoconfiguration, the S-CSCF shall compare the prefix of the IP address recorded in the "received" header field parameter against the UE's IP address prefix stored during registration. If no "received" header field parameter exists in the Via header field provided by the UE, then the S-CSCF shall compare IP address recorded in the "sent-by" parameter against the stored UE IP address. In case of IPv6 stateless autoconfiguration, S-CSCF shall compare the prefix of the IP address recorded in the "sent-by" parameter against the UE's IP address prefix stored during registration. In any case, if the stored IP address (or prefix) and the (prefix of the) IP address recorded in the Via header field provided by the UE do not match, the S‑CSCF shall query the HSS as described in 3GPP TS 29.228 [14] with the derived private user identity and the public user identity as input and store the received IP address (or prefix) of the UE. If the stored IP address (or prefix) and the (prefix of the) IP address recorded in the Via header field provided by the UE still do not match the S-CSCF shall reject the registration with a 403 (Forbidden) response and skip the following steps;

5) after performing the S-CSCF Registration/deregistration notification procedure with the HSS, as described in 3GPP TS 29.228 [14], store the following information in the local data:

a) the list of public user identities, including the registered own public user identity and its associated set of implicitly registered public user identities and wildcarded public user identities due to the received REGISTER request. Each public user identity is identified as either barred or non-barred;

b) all the service profile(s) corresponding to the public user identities being registered (explicitly or implicitly), including initial Filter Criteria (the initial Filter Criteria for the Registered and common parts is stored and the unregisterd part is retained for possible use later - in the case the S-CSCF is retained if the user becomes unregistered);

c) if S-CSCF restoration procedures are supported, the restoration information if received as specified in 3GPP TS 29.228 [14]; and

d) if PCRF based P-CSCF restoration procedures are supported, all the user profile(s) corresponding to the public user identities being registered (explicitly or implicitly), including the IMSI, if available;

NOTE 2: There might be more than one set of initial Filter Criteria received because some implicitly registered public user identities that are part of the same implicit registration set belong to different service profiles.

6) update registration bindings as follows:

a) bind to each non-barred registered public user identity all registered contact information including all header field parameters contained in the Contact header field and all associated URI parameters with the exception of the "pub-gruu" and "temp-gruu" header field parameters as specified in RFC 5627 [93], and store information for future use; and

b) if the Contact URI in the Contact header field does not contain a "bnc" URI parameter, then for each binding that contains a "+sip.instance" Contact header field parameter, assign a new temporary GRUU, as specified in subclause 5.4.7A.3;

NOTE 3: There might be more than one contact information available for one public user identity.

NOTE 4: The barred public user identities are not bound to the contact information.

7) check whether a Path header field was included in the REGISTER request and construct a list of preloaded Route header fields from the list of entries in the received Path header field. The S-CSCF shall preserve the order of the preloaded Route header fields and bind them either to the contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used) and the contact information that was received in the REGISTER request;

NOTE 5: If this registration is a reregistration or an initial registration (i.e., there are previously registered public user identities belonging to the user that have not been deregistered or expired), then a list of pre-loaded Route header fields will already exist. If multiple registration mechanism was not used, then the existing list of pre-loaded Route header fields is bound to a respective contact address of the UE. However, if multiple registration mechanism was used, then the existing list of pre-loaded Route header fields is bound to a registration flow and the associated contact address that was used to send the REGISTER request. In either case, the new list replaces the old list.

8) determine the duration of the registration by checking the registration expiration interval value in the received REGISTER request and bind it either to the respective contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used). Based on local policy, the S-CSCF may reduce the duration of the registration or send back a 423 (Interval Too Brief) response specifying the minimum allowed time for registration. The local policy can take into account specific criteria such as the used authentication mechanism to determine the allowed registration duration;

9) store the "icid-value" header field parameter received in the P-Charging-Vector header field;

9A) if an "orig-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "orig-ioi" header field parameter; and

NOTE 6: Any received "orig-ioi" header field parameter will be a type 1 IOI. The type 1 IOI identifies the network from which the request was sent.

10) create and send a 200 (OK) response for the REGISTER request as specified in subclause 5.4.1.2.2F.

When a user de-registers, or is de-registered by the HSS, the S-CSCF shall delete the IP address stored for the UE.

5.4.1.2.2 Protected REGISTER with IMS AKA as a security mechanism

Upon receipt of a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "yes" or to "tls-connected", the S-CSCF shall identify the user by the public user identity as received in the To header field and the private user identity as received in the Authorization header field of the REGISTER request, and:

If the maximum number of simultaneously registration flows allowed for the related public user identity for the used UE (i.e. linked to the same private user identity and instance ID) is reached, then the S-CSCF shall reject the REGISTER by generating a 403 (Forbidden) response. If not, the S-CSCF shall continue with rest of the procedures of this subclause;

In the case that there is no authentication currently ongoing for this user (i.e. no timer reg-await-auth is running):

1) check if the user needs to be reauthenticated.

The S-CSCF may require authentication of the user for any REGISTER request, and shall always require authentication for REGISTER requests received without the "integrity-protected" header field parameter in the Authorization header field set to "yes" or "tls-connected".

If the user needs to be reauthenticated, the S-CSCF shall proceed with the procedures as described for the unprotected REGISTER in subclause 5.4.1.2.1, beginning with step 3). If the user does not need to be reauthenticated, the S-CSCF shall proceed with the following steps in this paragraph; and

2) check whether a registration expiration interval value is included in the REGISTER request and its value. If the registration expiration interval value indicates a zero value, the S-CSCF shall perform the deregistration procedures as described in subclause 5.4.1.4. If the registration expiration interval value does not indicate zero, the S-CSCF:

- if the REGISTER request does not contain a "reg-id" header field parameter and the contact address indicated in the Contact header field was not previously registered, send a 403 (Forbidden) response to the UE; and

NOTE 1: New contact address is always registered via an initial registration.

3) check whether the public user identity received in the To header field is already registered. If it is not registered, the S-CSCF shall proceed beginning with step 4B below. Otherwise, the S-CSCF shall:

- send a 439 (First Hop Lacks Outbound Support) response to the UE, if the REGISTER request contains the "reg-id" Contact header field parameter and the "outbound" option tag in a Supported header field, but the first URI in the Path header field does not have an "ob" URI parameter; or

- otherwise proceed beginning with step 6 below.

In the case that a timer reg-await-auth is running for this user the S-CSCF shall:

1) check if the Call-ID of the request matches with the Call-ID of the 401 (Unauthorized) response which carried the last challenge. The S-CSCF shall only proceed further if the Call-IDs match;

2) stop timer reg-await-auth;

3) check whether an Authorization header field is included, containing:

a) the private user identity of the user in the "username" header field parameter;

b) if the "integrity-protected" header field parameter is set to "yes", the "algorithm" header field parameter set to "AKAv1-MD5"

c) if the "integrity-protected" header field parameter is set to "tls-connected", the "algorithm" header field parameter set to "AKAv2-SHA-256" if the S-CSCF supports the IMS AKA using HTTP Digest AKAv2 without IPSec security association; and

d) the authentication challenge response needed for the authentication procedure in the "response" header field parameter.

The S-CSCF shall only proceed with the following steps in this paragraph if the authentication challenge response was included;

4) check whether the received authentication challenge response and the expected authentication challenge response (calculated by the S-CSCF using XRES and other parameters as described in RFC 3310 [49] when AKAv1 is used or as described in RFC 4169 [227] when AKAv2 is used) match. The XRES parameter was received from the HSS as part of the Authentication Vector. The S-CSCF shall only proceed with the following steps if the challenge response received from the UE and the expected response calculated by the S-CSCF match;

4A) if the Contact header field of the REGISTER request does not contain a "reg-id" header field parameter (i.e., the multiple registrations mechanism is not used), and there are public user identities (including the public user identity being registered, if previously registered) that belong to this user that have been previously registered with the same private user identity, and with an old contact address different from the one received in the REGISTER request and if the previous registrations have not expired:

a) terminate all dialogs, associated with the previously registered public user identities (including the public user identity being registered, if previously registered), with a status code 480 (Temporarily Unavailable) in the Reason header field of the BYE request, as specified in subclause 5.4.5.1.2;

NOTE 2: The last dialog to be terminated will be the dialog established by the UE subscribing to the reg event package. When sending the NOTIFY request to the UE over this dialog, the S-CSCF will terminate this dialog by setting in the NOTIFY request the Subscription-State header field to the value of "terminated".

c) delete all information associated with the previously registered public user identities;

NOTE 3: Contact related to emergency registration is not affected. The S-CSCF is not able to deregister contact related to emergency registration and will not delete it.

4B) if the REGISTER request contains the "reg-id" Contact header field parameter and the "outbound" option tag in a Supported header field, but the first URI in the Path header field does not have an "ob" URI parameter, send a 439 (First Hop Lacks Outbound Support) response to the UE;

5) after performing the S-CSCF Registration/deregistration notification procedure with the HSS, as described in 3GPP TS 29.228 [14], store the following information in the local data:

b) all the service profile(s) corresponding to the public user identities being registered (explicitly or implicitly), including initial Filter Criteria(the initial Filter Criteria for the Registered and common parts is stored and the unregistered part is retained for possible use later - in the case of the S-CSCF is retained if the user becomes unregistered);

c) if S-CSCF restoration procedures are supported, the restoration information if received as specified in 3GPP TS 29.228 [14]; and

NOTE 4: There might be more than one set of initial Filter Criteria received because some implicitly registered public user identities that are part of the same implicit registration set belong to different service profiles.

6) update registration bindings:

a) if the Contact URI in the Contact header field does not contains a "bnc" URI parameter, then bind to each non-barred registered public user identity all registered contact information including all header field parameters contained in the Contact header field and all associated SIP URI parameters, with the exception of the "pub-gruu" and "temp-gruu" header field parameters as specified in RFC 5627 [93], and store information for future use;

b) if the Contact URI in the Contact header field contains a "bnc" URI parameter, as a network option bind each non-barred registered public user identity to a contact address generated according to the procedures of RFC 6140 [191].

NOTE 5: It is assumed that when the Contact header field contains a "bnc" parameter, the associated public user identities obtained from the HSS are all of a form compatible with registration procedures as specified in RFC 6140 [191]; i.e. the set consists only of distinct public user identities contain global numbers in the international format or wildcarded public user identities representing multiple global numbers in the international format. The S-CSCF procedures for handling the error case where an associated public user identity is incompatible with RFC 6140 [191] is out of scope of this specification.

c) if the Contact URI in the Contact header field does not contain a "bnc" URI parameter, then for each binding that contains a "+sip.instance" Contact header field parameter, assign a new temporary GRUU, as specified in subclause 5.4.7A.3;

d) if the Contact header field of the REGISTER request contained a "+sip.instance" and a "reg-id" header field parameter, and the SIP URI in the Path header field inserted by the P-CSCF contained an "ob" SIP URI parameter header field, and:

- if the public user identity has not previously been registered with the same "+sip.instance" and "reg-id" Contact header field parameter values, then create the registration flow in addition to any existing registration flow; or

- if the public user identity has previously been registered with the same "+sip.instance" and "reg-id" header field parameter values, then determine whether the request refreshes or replaces an existing registration flow. If the request:

i) refreshes an existing registration flow, then the S-CSCF shall leave the flow intact; or

ii) replaces the existing registration flow with a new flow, then the S-CSCF shall:

a) terminate any dialog, as specified in subclause 5.4.5.1.2, with a status code 480 (Temporarily Unavailable) in the Reason header field of the BYE request, associated with the registration flow being replaced; and

b) send a NOTIFY request to the subscribers to the registration event package for the public user identity indicated in the REGISTER request, as described in subclause 5.4.2.1.2;

NOTE 6: The S-CSCF determines whether this REGISTER request replaces or refreshes an existing registration flow by examining the SIP URI in the Path header field inserted into the request by the P-CSCF (see subclause 5.2.2.1).

NOTE 7: The way the S-CSCF identifies the dialogs associated with the registration flow being replaced is implementation specific.

NOTE 8: There might be more than one contact information available for one public user identity.

NOTE 9: The barred public user identities are not bound to the contact information.

NOTE 10: Contact related to emergency registration is not affected. S-CSCF is not able deregister contact related to emergency registration and will not delete that.

7) check whether a Path header field was included in the REGISTER request and construct a list of preloaded Route header fields from the list of entries in the received Path header field. The S-CSCF shall preserve the order of the preloaded Route header fields and bind them either to the contact address of the UE or the registration flow and the associated contact address (if the multiple registration mechanism is used) and the contact information that was received in the REGISTER request;

NOTE 11: If this registration is a reregistration or an initial registration (i.e., there are previously registered public user identities belonging to the user that have not been deregistered or expired), then a list of pre-loaded Route header fields will already exist. If multiple registration mechanism was not used, then the existing list of pre-loaded Route header fields is bound to a respective contact address of the UE. However, if multiple registration mechanism was used, then the existing list of pre-loaded Route header fields is bound to a registration flow and the associated contact address that was used to send the REGISTER request. In either case, the new list replaces the old list.

8) determine the duration of the registration by checking the value of the registration expiration interval value in the received REGISTER request and bind it either to the respective contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used). Based on local policy, the S-CSCF may reduce the duration of the registration or send back a 423 (Interval Too Brief) response specifying the minimum allowed time for registration. The local policy can take into account specific criteria such as the used authentication mechanism to determine the allowed registration duration;

9) store the "icid-value" header field parameter received in the P-Charging-Vector header field;

10) if an "orig-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "orig-ioi" header field parameter; and

NOTE 12: Any received "orig-ioi" header field parameter will be a type 1 IOI. The type 1 IOI identifies the network from which the request was sent.

11) create and send a 200 (OK) response for the REGISTER request as specified in subclause 5.4.1.2.2F.

5.4.1.2.2A Protected REGISTER with SIP digest as a security mechanism

Upon receipt of a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "tls-pending", "tls-yes", "ip-assoc-pending", or "ip-assoc-yes", the S-CSCF shall identify the user by the public user identity as received in the To header field and the private user identity as received in the Authorization header field of the REGISTER request, and:

NOTE: Although the REGISTER request with the "integrity-protected" header field parameter set to "ip-assoc-pending" or "ip-assoc-yes" is handled as protected REGISTER request, the integrity of the request is actually not protected by SIP digest.

In the case that there is no authentication currently ongoing for this user (i.e. no timer reg-await-auth is running):

1) check if the user needs to be reauthenticated. The S-CSCF may require authentication of the user for any REGISTER request, and shall always require authentication for REGISTER requests received without the "integrity-protected" header field parameter in the Authorization header field set to "tls-yes".

If the user needs to be reauthenticated and the REGISTER did not include an Authorization header field with a digest response, the S-CSCF shall proceed with the authentication procedures as described for the initial REGISTER in subclause 5.4.1.2.1 and subclause 5.4.1.2.1B.

If the user needs to be reauthenticated and the REGISTER included an Authorization header field with a digest response, the S-CSCF shall proceed with the authentication procedures as described for the initial REGISTER in subclause 5.4.1.2.1 and subclause 5.4.1.2.1B and include the "stale" header field parameter with value "true" in the WWW-Authenticate header field.

In the case that a timer reg-await-auth is running for this user the S-CSCF shall:

1) check if the Call-ID of the request matches with the Call-ID of the 401 (Unauthorized) response which carried the last challenge. The S-CSCF shall only proceed further if the Call-IDs match;

2) stop timer reg-await-auth;

3) in the case the algorithm is "MD5", check the following additional fields:

- a "realm" header field parameter matching the "realm" header field parameter in the authentication challenge;

- an "algorithm" header field parameter which matches the "algorithm" header field parameter sent in the authentication challenge;

- "nonce" header field parameter matching the "nonce" header field parameter in the authentication challenge;

- a "cnonce" header field parameter; and

- a nonce-count field.

The S-CSCF shall only proceed with the following steps in this paragraph if the authentication challenge response was included;

4) check whether the received authentication challenge response and the expected authentication challenge response match. The expected response is calculated by the S-CSCF as described in RFC 2617 [21] using the H(A1) value provided by the HSS. If the received authentication challenge response and the expected authentication challenge response match, then the UE is considered authenticated. If the UE is considered authenticated, and if the "integrity-protected" header field parameter in the Authorization header field is set to the value "tls-pending" or "tls-yes", then the S-CSCF shall associate the registration with the local state of "tls-protected";

NOTE 1: The S-CSCF can have a local security policy to treat messages other than initial REGISTER requests, messages relating to emergency services, and error messages, differently depending on whether the registration is associated with the state "tls-protected".

4A) if the REGISTER request contains the "reg-id" Contact header field parameter and the "outbound" option tag in a Supported header field, but the first URI in the Path header does not have an "ob" URI parameter, send a 439 (First Hop Lacks Outbound Support) response to the UE;

5) after performing the S-CSCF Registration/deregistration notification procedure with the HSS, as described in 3GPP TS 29.228 [14], store the following information in the local data:

b) all the service profile(s) corresponding to the public user identities being registered (explicitly or implicitly), including initial Filter Criteria(the initial Filter Criteria for the Registered and common parts is stored and the unregistered part is retained for possible use later - in the case of the S-CSCF is retained if the user becomes unregistered);

c) if S-CSCF restoration procedures are supported, the restoration information, if received, as specified in 3GPP TS 29.228 [14]; and

6) update registration bindings:

a) if the Contact URI in the Contact header field does not contains a "bnc" URI parameter, then bind to each non-barred registered public user identity all registered contact information including all header field parameters contained in the Contact header field and all associated URI parameters, with the exception of the "pub-gruu" and "temp-gruu" header field parameters as specified in RFC 5627 [93], and store information for future use;

b) if the Contact URI in the Contact header field contains a "bnc" URI parameter, as a network option bind each non-barred registered public user identity to a contact address as specified in RFC 6140 [191].

NOTE 3: It is assumed that when the Contact header field contains a "bnc" parameter, the associated public user identities obtained from the HSS are all of a form compatible with registration procedures as specified in RFC 6140 [191]; i.e. the set consists only of distinct public user identities contain global numbers in the international format or wildcarded public user identities representing multiple global numbers in the international format. The S-CSCF procedures for handling the error case where an associated public user identity is incompatible with RFC 6140 [191] is out of scope of this specification.

d) if the Contact header field of the REGISTER request does not contain a "reg-id" header field parameter (i.e., the multiple registrations mechanism is not used), and there are public user identities (including the public user identity being registered, if previously registered) that belong to this user that have been previously registered with the same private user identity, and with an old contact address different from the one received in the REGISTER request and if the previous registrations have not expired:

- terminate all dialogs, associated with the previously registered public user identities (including the public user identity being registered, if previously registered), with a status code 480 (Temporarily Unavailable) in the Reason header field of the BYE request, as specified in subclause 5.4.5.1.2;

- send a NOTIFY request, to the subscribers to the registration event package of the previously registered public user identities, that indicates that all previously registered public user identities (excluding the public user identity being registered) belonging to this user identified with its private user identity, have been deregistered, as described in subclause 5.4.2.1.2. For the public user identity being registered, the NOTIFY request contains the new contact information; and

NOTE 4: The last dialog to be terminated will be the dialog established by the UE subscribing to the reg event package. When sending the NOTIFY request to the UE over this dialog, the S-CSCF will terminate this dialog by setting in the NOTIFY request the Subscription-State header field to the value of "terminated".

- delete all information associated with the previously registered public user identities;

NOTE 5: Contact related to emergency registration is not affected. The S-CSCF is not able to deregister contact related to emergency registration and will not delete it.

e) if the Contact header field of the REGISTER request contained a "+sip.instance" and a "reg-id" header field parameter, and the SIP URI in the Path header field inserted by the P-CSCF contained an "ob" SIP URI parameter header field, and:

i) refreshes an existing registration flow, then the S-CSCF shall leave the flow intact; or

ii) replaces the existing registration flow with a new flow, then the S-CSCF shall:

b) send a NOTIFY request to the subscribers to the registration event package for the public user identity indicated in the REGISTER request, as described in subclause 5.4.2.1.2; and

f) store the used nonce as a valid nonce for this registration or registration flow (if multiple registration mechanism is used) for an operator configured duration.

NOTE 7: The way the S-CSCF identifies the dialogs associated with the registration flow being replaced is implementation specific.

NOTE 8: There might be more than one contact information available for one public user identity.

NOTE 9: The barred public user identities are not bound to the contact information.

NOTE 10: Contact related to emergency registration is not affected. S-CSCF is not able deregister contact related to emergency registration and will not delete that.

7) check whether a Path header field was included in the REGISTER request and construct a list of preloaded Route header fields from the list of entries in the received Path header field. The S-CSCF shall preserve the order of the preloaded Route header fields and bind them to either the contact address of the UE or the registration flow and the associated contact address (if the multiple registration mechanism is used) and contact information that was received in the REGISTER request;

9) store the "icid-value" header field parameter received in the P-Charging-Vector header field;

10) if an "orig-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "orig-ioi" header field parameter; and

NOTE 12: Any received "orig-ioi" header field parameter will be a type 1 IOI. The type 1 IOI identifies the network from which the request was sent.

11) create and send a 200 (OK) response for the REGISTER request as specified in subclause 5.4.1.2.2F. The S-CSCF shall also store the nonce-count value in the received REGISTER request and include an Authentication-Info header field containing the fields described in RFC 2617 [21] as follows:

- a "nextnonce" header field parameter if the S-CSCF requires a new nonce for subsequent authentication responses from the UE. In that case, the S-CSCF shall consider this nonce as a valid nonce for this registration or registration flow (if multiple registration mechanism is used) for an operator configured duration;

- a "qop" header field parameter matching the "qop" Authorization header field parameter sent by the UE;

- a "rspauth" header field parameter with a response-digest calculated as described in RFC 2617 [21];

- a "cnonce" header field parameter value matching the cnonce in the Authorization header field sent by the UE; and

- a "nonce-count" header field parameter matching the "nonce-count" Authorization header field parameter sent by the UE.

5.4.1.2.2B Protected REGISTER with SIP digest with TLS as a security mechanism

The procedures for subclause 5.4.1.2.2A apply.

5.4.1.2.2C NASS-IMS bundled authentication as a security mechanism

There is no protected REGISTER when NASS-IMS bundled authentication is used as a security mechanism. The procedures of subclause 5.4.1.2.1D apply to all REGISTER requests.

5.4.1.2.2D GPRS-IMS-Bundled authentication as a security mechanism

There is no protected REGISTER when GPRS-IMS-Bundled authentication is used as a security mechanism. The procedures of subclause 5.4.1.2.1E apply to all REGISTER requests.

5.4.1.2.2E Protected REGISTER – Authentication already performed

The S-CSCF shall not perform authentication of the user for any REGISTER request with the "integrity-protected" header field parameter in the Authorization header set to "auth-done".

In this release of this document, when the registration procedure as specified in this subclause is performed, i.e., the REGISTER request contains the "integrity-protected" header field parameter in the Authorization header set to "auth-done", the S-CSCF shall not employ outbound registration as described in RFC 5626 [92].

Upon receipt of a REGISTER request with the "integrity-protected" header field parameter in the Authorization header set to "auth-done", the S-CSCF shall identify the user by the public user identity as received in the To header field and the private user identity as received in the Authorization header field of the REGISTER request.

In addition the S-CSCF shall check whether a registration expiration interval value is included in the REGISTER request and its value. If the registration expiration interval value indicates a zero value, the S-CSCF shall perform the deregistration procedures as described in subclause 5.4.1.4. If the registration expiration interval value does not indicate zero, the S-CSCF shall:

1) if the REGISTER request contains the "reg-id" header field parameter in the Contact header field, respond with a 403 (Forbidden) response to the REGISTER request; and

2) if there are public user identities (including the public user identity being registered, if previously registered) that belong to this user that have been previously registered with the same private user identity, and with an old contact address different from the one received in the REGISTER request and if the previous registrations have not expired:

NOTE 1: The last dialog to be terminated will be the dialog established by the user (identified with its private user identity) subscribing to its own reg event package using the old contact address. When sending the NOTIFY request over this dialog, the S-CSCF will terminate this dialog by setting in the NOTIFY request the Subscription-State header field to the value of "terminated".

c) delete all information associated with the previously registered public user identities;

Subsequently, the S-CSCF shall check whether the public user identity received in the To header field is already registered. If it is not registered, the S-CSCF shall proceed beginning with step 1 below. Otherwise, the S-CSCF shall proceed beginning with step 2 below.

1) after performing the S-CSCF Registration/deregistration notification procedure with the HSS, as described in 3GPP TS 29.228 [14], store the following information in the local data:

b) all the service profile(s) corresponding to the public user identities being registered (explicitly or implicitly), including initial Filter Criteria(the initial Filter Criteria for the Registered and common parts is stored and the unregistered part is retained for possible use later - in the case of the S-CSCF is retained if the user becomes unregistered); and

c) if PCRF based P-CSCF restoration procedures are supported, all the user profile(s) corresponding to the public user identities being registered (explicitly or implicitly), including the IMSI, if available;

2) update registration bindings:

a) if the Contact URI in the Contact header field does not contains a "bnc" URI parameter, then bind to each non-barred registered public user identity all registered contact information including all header parameters contained in the Contact header and all associated URI parameters, with the exception of the URI "pub-gruu" and "temp-gruu" parameters as specified in RFC 5627 [93], and store information for future use;

c) if the Contact URI in the Contact header field does not contain a "bnc" URI parameter, then for each binding that contains a "+sip.instance" header field parameter, assign a new temporary GRUU, as specified in subclause 5.4.7A.3.

NOTE 4: There might be more than one contact information available for one public user identity.

NOTE 5: The barred public user identities are not bound to the contact information.

3) check whether a Path header was included in the REGISTER request and construct a list of preloaded Route headers from the list of entries in the received Path header field. The S-CSCF shall preserve the order of the preloaded Route header fields and bind them to the contact information that was received in the REGISTER request;

NOTE 6: If this registration is a reregistration or an initial registration (i.e., there are previously registered public user identities belonging to the user that have not been deregistered or expired), then a list of pre-loaded Route headers will already exist. The new list replaces the old list.

4) determine the duration of the registration by checking the value of the registration expiration interval value in the received REGISTER request. Based on local policy, the S-CSCF may reduce the duration of the registration or send back a 423 (Interval Too Brief) response specifying the minimum allowed time for registration. The local policy can take into account specific criteria such as the used authentication mechanism to determine the allowed registration duration;

5) store the "icid-value" header field parameter received in the P-Charging-Vector header;

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

NOTE 7: Any received "orig-ioi" header field parameter will be a type 1 IOI. The type 1 IOI identifies the network from which the request was sent.

7) create and send a 200 (OK) response for the REGISTER request as specified in subclause 5.4.1.2.2F.

5.4.1.2.2F Successful registration

If a 200 (OK) response is to be sent for a REGISTER request, the S-CSCF shall, in addition to any contents identified elsewhere in subclause 5.4.1.2, include:

a) the list of received Path header fields;

b) a P-Associated-URI header field containing the list of the registered distinct public user identity and its associated set of implicitly registered distinct public user identities. The first URI in the list of public user identities supplied by the HSS to the S-CSCF will indicate the default public user identity to be used by the S-CSCF. The public user identity indicated as the default public user identity must be a registered public user identity. The S-CSCF shall place the default public user identity as the first entry in the list of URIs present in the P-Associated-URI header field. The default public user identity will be used by the P-CSCF in conjunction with the procedures for the P-Asserted-Identity header field, as described in subclause 5.2.6.3. If the S-CSCF received a display name from the HSS for a public user identity, then the S-CSCF shall populate the P-Associated-URI header field entry for that public identity with the associated display name. The S-CSCF shall not add a barred public user identity to the list of URIs in the P-Associated-URI header field;

NOTE 1: The P-Associated-URI header field lists only the public user identity and its associated set of implicitly registered public user identities that have been registered, rather than the list of user's URIs that may be either registered or unregistered as specified in RFC 7315 [52]. If the registered public user identity which is not barred does not have any other associated public user identities or wildcarded public user identities, the P-Associated-URI header field lists only the registered public user identity itself, rather than an empty P-Associated-URI header field as specified in RFC 7315 [52]. The P-Associated-URI header field does not list wildcarded public user identities.

c) a Service-Route header field containing:

A) the SIP URI identifying the S-CSCF containing an indication that subsequent requests routed via this service route (i.e. from the P-CSCF to the S-CSCF) was sent by the UE using either the contact address of the UE or the registration flow and the associated contact address (if the multiple registration mechanism is used) that has been registered and are treated as for the UE-originating case.

NOTE 2: 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.

The S-CSCF shall use a different SIP URI for each registration. If the multiple registration mechanism is used, the S-CSCF shall also use a different SIP URI for each registration flow associated with the registration;

B) if network topology hiding is required a SIP URI identifying an IBCF as the topmost entry; and

NOTE 3: In accordance with the procedures described in RFC 3608 [38], an IBCF does not insert its own routable SIP URI to the Service-Route header field.

C) if

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

2) the UE is roaming;

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

4) required by local policy

then the S-CSCF may append an "iotl" SIP URI parameter with a value set to "visitedA-homeA" to the S-CSCF SIP URI in the Service-Route header field;

d) if the P-CSCF is in the same network as the S-CSCF a P-Charging-Function-Addresses header field containing the values received from the HSS. It can be determined if the P-CSCF is in the same network as the S-CSCF by the contents of the P-Visited-Network-ID header field included in the REGISTER request;

NOTE 4: The P-CSCF does not check the P-Charging-Function-Addresses header field, providing this header field to the visiting network could cause undefined charging behaviour.

e) a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the REGISTER request, a type 1 "term-ioi" header field parameter and the "icid-value" header field parameter. The S-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;

f) a Contact header field listing all contact addresses for this public user identity, including all saved header field parameters and URI parameters (including all ICSI values and IARI values) received in the Contact header field of the REGISTER request,

g) GRUUs in the Contact header field. If the REGISTER request contained a Required or Supported header field containing the value "gruu" then for each contact address in the Contact header field that has a "+sip.instance" header field parameter:

i) add "pub-gruu" header field parameter containing the public GRUU representing (as specified in subclause 5.4.7A.2) the association between the public user identity from the To header field in the REGISTER request and the instance ID contained in the "+sip.instance" header field parameter;

ii) if the Contact URI in the Contact header field does not contain a "bnc" URI parameter, then add a "temp-gruu" header field parameters. containing the most recently assigned temporary GRUU representing (as specified in subclause 5.4.7A) the association between the public user identity from the To header field in the REGISTER request and the instance ID contained in the "+sip.instance" header field parameter; and

iii) if the S-CSCF supports RFC 6140 [191] and the Contact URI in the Contact header field contains a "bnc" URI parameter, then add a "temp-gruu-cookie" header field parameter containing a value generated as specified in RFC 6140 [191];

h) if the received REGISTER request contained both a "reg-id" and "+sip.instance" header field parameters in the Contact header field, and the first URI within the Path header field contains the "ob" SIP URI parameter a Require header field with the "outbound" option-tag as described in RFC 5626 [92];

NOTE 5: There might be other contact addresses available, that this UE or other UEs have registered for the same public user identity.

i) if debugging configuration data exists for the address of record in the To header field, an empty P-Debug-ID header field;

j) optionally, a Feature-Caps header field, as specified in RFC 6809 [190], including the "+g.3gpp.icsi-ref" header field parameter set to the ICSI values contained in the service profile of the served user except the ones that require explicit support indication by the P-CSCF of one or more specific media capabilities. The specific media capabilities are indicated as supported by the presence of one or more feature capability indicators as listed in subclause 7.9A.7 in the a Feature-Caps header field received in the REGISTER request, according to RFC 6809 [190] for the corresponding registration or registration flow (if multiple registration mechanism is used). The absence of feature capability indicators as listed in subclause 7.9A.7 in the a Feature-Caps header field received in the REGISTER request means that the P-CSCF is not supporting indication of media capabilities and the S-CSCF should assume that all media capabilities required are supported. The associated media capabilities that need to be explicitly indicated as supported by the IMS-AGW controlled by the P-CSCF (IMS-ALG) are locally configured in the S-CSCF; and

k) if the home network supports calling number verification, as described in draft-ietf-stir-rfc4474bis [252], a Feature-Caps header field, as specified in RFC 6809 [190], including the "+g.3gpp.verstat" header field parameter;

NOTE 6: If the network has indicated support for the calling number verification to a UE during registration, the network needs to perform calling number verification for all calls delivered to the registered contact address.

and send the so created 200 (OK) response to the UE.

For all service profiles in the implicit registration set, the S-CSCF shall send a third-party REGISTER request, as described in subclause 5.4.1.7, to each AS that matches the Filter Criteria of the service profile from the HSS for the REGISTER event; and,

NOTE 7: If this registration is a reregistration, the Filter Criteria already exists in the local data.

NOTE 8: If the same AS matches the Filter Criteria of several service profiles for the event of REGISTER request, then the AS will receive several third-party REGISTER requests. Each of these requests will include a public user identity from the corresponding service profile.

The S-CSCF shall consider the public user identity being registered to be bound either to the contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used), as specified in the Contact header field, for the duration indicated in the registration expiration interval value.

5.4.1.2.3 Abnormal cases - general

In the case that the expiration timer from the UE is too short to be accepted by the S-CSCF, the S-CSCF shall:

- reject the REGISTER request with a 423 (Interval Too Brief) response, containing a Min-Expires header field with the minimum registration time the S-CSCF will accept.

On receiving a failure response to one of the third-party REGISTER requests, based on the information in the Filter Criteria the S-CSCF may:

- abort sending third-party REGISTER requests; and

- initiate network-initiated deregistration procedure.

If the Filter Criteria does not contain instruction to the S-CSCF regarding the failure of the contact to the AS, the S-CSCF shall not initiate network-initiated deregistration procedure.

In the case that the REGISTER request from the UE contains multiple SIP URIs which are different addresses as Contact header field entries, the S-CSCF shall store:

- the entry in the Contact header field with the highest value of the "q" header field parameter; or

- an entry decided by the S-CSCF based on local policy;

and include the stored entry in the 200 (OK) response.

In the case that the REGISTER request from the UE contains multiple SIP URIs which are the same addresses with the same value of the "q" Contact header field parameter, the S-CSCF shall not store multiple entries with the same "q" value but store one of the entries with the same "q" value based on local policy along with any entries that have different "q" values and include only the stored entries in the 200 (OK) response.

NOTE 1: The UE can register multiple SIP URIs in the Contact header field simultanously, provided they all contain the same IP address and port number. In this case the S-CSCF behaviour is as defined RFC 3261 [26] (i.e multiple Contact header field entries are bound to the public user identity in the To header field and are returned in the 200 (OK) response).

NOTE 2: If the timer reg-await-auth expires, the S-CSCF will consider the authentication to have failed. If the public user identity was already registered, the S-CSCF will leave it registered, as described in 3GPP TS 33.203 [19].

If the S-CSCF receives a new initial REGISTER request before the reg-await-auth timer expires, the S-CSCF shall:

1) stop the reg-await-auth timer; and

2) initiate the authentication procedures for initial registration as if there is no authentication currently ongoing for this user and send a 401 (Unauthorized) response containing a new challenge as described in subclause 5.4.1.

For any error response, the S-CSCF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the REGISTER request, a type 1 "term-ioi" header field parameter and the "icid-value" header field parameter. The S-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 and the "icid-value" header field parameter is set to the previously received value of "icid-value" header field parameter in the request.

NOTE 3: Any previously received "orig-ioi" header field parameter will be a type 1 IOI. The type 1 IOI identifies the visited network of the registered user.

If the Contact header field in the REGISTER request from the UE contains an invalid Contact URI as defined in RFC 6140 [191] (e.g., the Contact URI contains both a "bnc" and "user" URI parameter) then the S-CSCF shall reject the REGISTER request with a 400 (Bad Request) response.

5.4.1.2.3A Abnormal cases – IMS AKA as security mechanism

In the case that the REGISTER request, that contains the authentication challenge response from the UE does not match with the expected REGISTER request (e.g. wrong Call-Id or authentication challenge response) and the request has the "integrity-protected" header field parameter in the Authorization header field set to "yes", the S-CSCF shall:

- send a 403 (Forbidden) response to the UE. The S‑CSCF shall consider this authentication attempt as failed. The S-CSCF shall not update the registration state of the subscriber.

NOTE 1: If the UE was registered before, it stays registered until the registration expiration time expires.

In the case that the REGISTER request from the UE containing an "auts" Authorization header field parameter, indicating that the SQN was deemed to be out of range by the UE), the S-CSCF will fetch new authentication vectors from the HSS. In order to indicate a resynchronisation, the S-CSCF shall include the value of the "auts" header field parameter received from the UE and the stored RAND, when fetching the new authentication vectors. On receipt of the new authentication vectors from the HSS, the S-CSCF shall either:

- send a 401 (Unauthorized) response to initiate a further authentication attempt, using these new vectors; or

- respond with a 403 (Forbidden) response if the authentication attempt is to be abandoned. The S-CSCF shall not update the registration state of the subscriber.

NOTE 2: If the UE was registered before, it stays registered until the registration expiration time expires.

NOTE 3: Since the UE responds only to two consecutive invalid challenges, the S-CSCF will send a 401 (Unauthorized) response that contains a new challenge only twice.

NOTE 4: In the case of an "auts" Authorization header field parameter being present in the REGISTER request, the "response" Authorization header field parameter in the same REGISTER request will not be taken into account by the S-CSCF.

In the case that the S-CSCF receives a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "yes", for which the public user identity received in the To header field and the private user identity received in the "username" Authorization header field parameter of the REGISTER request do not match to any registered user at this S-CSCF, if the S-CSCF supports S-CSCF restoration procedures, the S-CSCF shall behave as described in subclause 5.4.1.2.2, otherwise the S-CSCF shall:

- respond with a 500 (Server Internal Error) response to the UE.

NOTE 5: This error is not raised if there is a match on the private user identity, but no match on the public user identity.

5.4.1.2.3B Abnormal cases – SIP digest as security mechanism

- send a 403 (Forbidden) response to the UE. The S CSCF shall consider this authentication attempt as failed. The S-CSCF shall not update the registration state of the subscriber; or

- rechallenge the user by issuing a 401 (Unauthorized) response including a challenge as per the authentication procedures described in subclause 5.4.1.2.1B.

NOTE 1: If the UE was registered before, it stays registered until the registration expiration time expires.

In the case that the REGISTER request from the UE contains an invalid "nonce" Authorization header field parameter with a valid challenge response for that nonce (indicating that the client knows the correct username/password), or when the nonce-count value sent by the UE is not the expected value, the S-CSCF shall:

- send a 401 (Unauthorized) response to initiate a further authentication attempt with a fresh nonce and the "stale" header field parameter set to "true" in the WWW-Authenticate header field.

In the case that the S-CSCF receives a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "tls-pending", "tls-yes", "ip-assoc-pending", or "ip-assoc-yes", for which the public user identity received in the To header field and the private user identity received in the Authorization header field of the REGISTER request do not match to any registered or initial registration pending user at this S-CSCF, if the S-CSCF supports S-CSCF restoration procedures, the S-CSCF shall behave as described in subclause 5.4.1.2.2A, otherwise the S-CSCF shall:

- respond with a 500 (Server Internal Error) response to the UE.

NOTE 2: This error is not raised if there is a match on the private user identity, but no match on the public user identity.

5.4.1.2.3C Abnormal cases – SIP digest with TLS as security mechanism

The procedures for subclause 5.4.1.2.3B apply.

5.4.1.2.3D Abnormal cases – NASS-IMS bundled authentication as security mechanism

There are no abnormal cases for NASS-IMS bundled authentication.

5.4.1.2.3E Abnormal cases – GPRS-IMS-Bundled authentication as security mechanism

There are no abnormal cases for GPRS-IMS-Bundled authentication.

5.4.1.3 Authentication and reauthentication

Authentication and reauthentication is performed by the registration procedures as described in subclause 5.4.1.2.

5.4.1.4 User-initiated deregistration

5.4.1.4.1 Normal cases

When S-CSCF receives a REGISTER request with the registration expiration interval value containing the value zero, the S-CSCF shall:

1) verify that the REGISTER request is associated with an existing registered contact or an existing flow or, if the S-CSCF restoration procedures are supported by this S-CSCF, attempt to restore a contact or flow from HSS associated with the REGISTER request. If no associated contact or flow exists then the S-CSCF shall send a 481 (Call Leg/Transaction Does Not Exist) response to the UE and skip the remaining procedures in this subclause;

2) if IMS AKA is in use as the security mechanism, check whether the "integrity-protected" header field parameter in the Authorization header field set to "yes", indicating that the REGISTER request was received integrity protected. The S-CSCF shall only proceed with the following steps if the "integrity-protected" header field parameter is set to "yes";

3) if SIP digest without TLS or SIP digest with TLS is in use as a security mechanism, check whether the "integrity-protected" header field parameter in the Authorization header field set to "tls-yes" or "ip-assoc-yes", indicating that the REGISTER request was received from a previously registered user. If the "integrity-protected" header field parameter is set to "tls-pending", "ip-assoc-pending" or is not present the S-CSCF shall ensure authentication is performed as described in subclause 5.4.1.2.1 (and consequently subclause 5.4.1.2.1B or 5.4.1.2.1C) if local policy requires. The S-CSCF shall only proceed with the following steps if the "integrity-protected" header field parameter is set to "tls-yes", "ip-assoc-yes", or the required authentication is successfully performed if required by local policy;

4) if NASS-IMS bundled authentication is in use as a security mechanism, only proceed with the following steps if the "integrity-protected" header field parameter in the Authorization header field does not exist or without an Authorization header field, and one or more Line-Identifiers previously received over the Cx interface, stored as a result of an Authentication procedure with the HSS, as described in 3GPP TS 29.228 [14], are available for the user;

4A) if the security mechanism as described in subclause 5.4.1.2.2E is in use, check whether the "integrity-protected" header field parameter in the Authorization header field set to "auth-done". The S-CSCF shall only proceed with the following steps if the "integrity-protected" header field parameter is set to "auth-done";

5) release all INVITE dialogs that include this user's contact addresses or the flows that are being deregistered, and where these dialogs were initiated by or terminated towards these contact addresses and the same public user identity found that was To header field that was received REGISTER request or with one of the implicitly registered public user identities by applying the steps listed in subclause 5.4.5.1.2;

6) examine the Contact header field in the REGISTER request, and:

a) if the value "*" is not included in the Contact header field and:

i) if the "reg-id" header field parameter is not included in the Contact header field, then:

- remove the binding (i.e. deregister) between the public user identity found in the To header field together with the implicitly registered public user identities and the contact addresses specified in the REGISTER request. The S-CSCF shall only remove the contact addresses that were registered by this UE;

ii) if the "reg-id" header field parameter and "+sip.instance" header field parameter are included in the Contact header field, and the UE supports multiple registrations (i.e. the "outbound" option tag is included in the Supported header field), then:

- remove the binding (i.e. deregister) between the public user identity indicated in the To header field (together with the associated implicitly registered public user identities) and the flow identified by the "reg-id" header field parameter;

7) if the S-CSCF receives a REGISTER request with the value "*" in the Contact header field and the value zero in the Expires header field, remove all contact addresses that were bound to the public user identity found in the To header field and have been registered by this UE identified with its private user identity;

8) for all service profiles in the implicit registration set send a third-party REGISTER request, as described in subclause 5.4.1.7, to each AS that matches the Filter Criteria of the service profile from the HSS for the REGISTER event;

9) if this is a deregistration request for the only public user identity currently registered with its associated set of implicitly registered public user identities (i.e. no other is registered) and there are still active multimedia sessions that includes this user's registered contact address, where the session was initiated by or terminated towards the contact with the registered contact address for that public user identity which is currently registered or with one of the implicitly registered public user identities, release only each of these multimedia sessions associated with the registered contact address by applying the steps listed in subclause 5.4.5.1.2. The S-CSCF shall only release dialogs associated to the multimedia sessions originated or terminated towards the registered user's contact address; and

10) send a 200 (OK) response to a REGISTER request that contains a list of Contact header fields enumerating all contacts and flows that are currently registered, and all contacts that have been deregistered. For each contact address and the flow that has been deregistered, the Contact header field shall contain the contact address and the "reg-id" header field parameter that identifies the flow, if a flow was deregistered, and the associated information, and the registration expiration interval value shall be set to zero.

If all public user identities of the UE are deregistered, then the S-CSCF may consider the UE and P-CSCF subscriptions to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header field containing a value of zero).

If the Authorization header field of the REGISTER request contained an "integrity-protected" header field parameter set to the value "no", the S-CSCF shall apply the procedures described in subclause 5.4.1.2.1.

On completion of the above procedures in this subclause and of the S-CSCF Registration/deregistration notification procedure with the HSS, as described in 3GPP TS 29.228 [14], for one or more public user identities, the S-CSCF shall:

1) update or remove those public user identities, their registration state and the associated service profiles from the local data; and

2) if all the contacts bound to the public user identities have been deregistered and there is no ongoing session due to the public user identities, then remove all the stored AS IP addresses which are associated with those public user identities.

Based on operators' policy the S-CSCF can request the HSS to either be kept or cleared as the S-CSCF allocated to this subscriber. If emergency contacts are still registered for this subscriber, the S-CSCF requests the HSS to be kept as the S-CSCF allocated to this subscriber.

5.4.1.4.2 Abnormal cases - IMS AKA as security mechanism

If case that the S-CSCF receives a REGISTER request with the "integrity-protected" header field parameter in the Authorization header set to "yes" or to "tls-connected", for which the public user identity received in the To header and the private user identity received in the Authorization header of the REGISTER request do not match to any registered user at this S-CSCF, if the S-CSCF supports S-CSCF restoration procedures as specified in 3GPP TS 23.380 [7D], the S-CSCF shall behave as described in subclause 5.4.1.4.1, otherwise the S-CSCF shall:

- respond with a 500 (Server Internal Error) response to the UE.

NOTE: This error is not raised if there is a match on the private user identity, but no match on the public user identity.

5.4.1.4.4 Abnormal cases – SIP digest with TLS as security mechanism

The procedures for subclause 5.4.1.4.2 apply.

5.4.1.4.5 Abnormal cases – NASS-IMS bundled authentication as security mechanism

There are no abnormal cases for NASS-IMS bundled authentication.

5.4.1.4.6 Abnormal cases – GPRS-IMS-Bundled authentication as security mechanism

There are no abnormal cases for GPRS-IMS-Bundled authentication.

5.4.1.5 Network-initiated deregistration

NOTE 1: A network-initiated deregistration event that occurs at the S-CSCF can be received from the HSS or can be an internal event in the S-CSCF.

For any registered public user identity, the S-CSCF can deregister:

- all contact addresses bound to the indicated public user identity (i.e. deregister the respective public user identity);

- some contact addresses bound to the indicated public user identity;

- a particular contact address bound to the indicated public user identity; or

- one or more registration flows and the associated contact address bound to the indicated public user identity, when the UE supports multiple registration procedure;

by sending a single NOTIFY request.

Prior to initiating the network-initiated deregistration for the only currently registered public user identity and its associated set of implicitly registered public user identities and wildcarded public user identities that have been registered either with the same contact address of the UE or the same registration flow and the associated contact address (if the multiple registration mechanism is used), i.e. there are no other public user identities registered either with this contact address or with this registration flow and the associated contact address (if the multiple registration mechanism is used), and there are still active multimedia sessions belonging either to this contact address or to this registration flow and the associated contact address (if the multiple registration mechanism is used), the S-CSCF shall release only multimedia sessions belonging to this contact address or to this registration flow and the associated contact address (if the multiple registration mechanism is used) as described in the following paragraph. The multimedia sessions for the same public user identity, if registered either with another contact address or another registration flow and the associated contact address (if the multiple registration mechanism is used) remain unchanged.

Prior to initiating the network-initiated deregistration while there are still active multimedia sessions that are associated with this user and contact, the S-CSCF shall release none, some or all of these multimedia sessions by applying the steps listed in subclause 5.4.5.1.2 under the following conditions:

- when the S-CSCF does not expect the UE to reregister a given public user identity and its associated set of implicitly registered public user identities that have been registered with respective contact address (i.e. S-CSCF will set the event attribute within the respective <contact> element to "rejected" for the NOTIFY request, as described below), the S-CSCF shall release all sessions that are associated with the registered contact address for the public user identities using the contact address that is being deregistered, which includes the implicitly registered public user identities.

- when the S-CSCF expects the UE to reregister a given public user identity and its associated set of implicitly registered public user identities that have been registered with respective contact address (i.e. S-CSCF will set the event attribute within the respective <contact> element to "deactivated" for the NOTIFY request, as described below), the S-CSCF shall only release sessions that currently include the user's contact address, where the session was initiated by or terminated towards the user with the contact address registered to one of the public user identities using the contact address that is being deregistered, which includes the implicitly registered public user identities.

When a network-initiated deregistration event occurs for one or more public user identities that are bound either to one or more contact addresses or registration flows and the associated contact addresses (if the multiple registration mechanism is used), the S-CSCF shall send a NOTIFY request to all subscribers that have subscribed to the respective reg event package. For each NOTIFY request, the S-CSCF shall:

1) set the Request-URI and Route header field to the saved route information during subscription;

2) set the Event header field to the "reg" value;

3) in the body of the NOTIFY request, include as many <registration> elements as many public user identities the S-CSCF is aware of the user owns;

4) set the aor attribute within each <registration> element to one public user identity:

a) set the <uri> sub-element inside each <contact> sub-element of each <registration> element to the respective contact address provided by the UE;

b) if the public user identity:

i) has been deregistered (i.e. all contact addresses and all registration flows and associated contact addresses bound to the indicated public user identity are removed) then:

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

- set the state attribute within each <contact> element belonging to this UE to "terminated"; and

- set the event attribute within each <contact> element belonging to this UE to either "unregistered", or "deactivated" if the S-CSCF expects the UE to reregister or "rejected" if the S-CSCF does not expect the UE to reregister; or

NOTE 2: If the multiple registration mechanism is used, then the reg-id header field parameter will be included as an <unknown-param> element within each respective <contact> element.

NOTE 3: The UE will consider its public user identity as deregistered when the binding between the respective public user identity and all contact addresses and all registration flows and associated contact addresses (if the multiple registration mechanism is used) belonging to the UE have been removed.

ii) has been kept registered then:

I) set the state attribute within the <registration> element to "active";

II) set the state attribute within each <contact> element to:

- for the binding between the public user identity and either the contact address or a registration flow and associated contact addresses (if the multiple registration mechanism is used) to be removed set the state attribute within the <contact> element to "terminated", and event attribute element to either "unregistered", or "deactivated" if the S-CSCF expects the UE to reregister or "rejected" if the S-CSCF does not expect the UE to reregister; or

- for the binding between the public user identity and either the contact address or the registration flow and associated contact addresses (if the multiple registration mechanism is used) which remain unchanged, if any, leave the <contact> element unmodified, and if the contact has been assigned GRUUs and the Contact URI did not contain a "bnc" SIP URI parameter then set the <pub-gruu> and <temp-gruu> sub-elements of the <contact> element as specified in RFC 5628 [94] and include the <unknown-param> sub-element within each <contact> to any additional header field parameters contained in the Contact header field of the REGISTER request according to RFC 3680 [43]; and

NOTE 4: There might be more than one contact information available for one public user identity. When deregistering this UE, the S-CSCF will only modify the <contact> elements that were originally registered by this UE using its private user identity. The <contact> elements of the same public user identity, if registered by another UE using different private user identities remain unchanged.

5) 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 S-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The S-CSCF shall not include the type 1 "term-ioi" header field parameter.

The S-CSCF shall only include the non-barred public user identities in the NOTIFY request.

When sending a final NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" (i.e. all public user identities have been deregistered or expired), the S-CSCF shall also terminate the subscription to the registration event package by setting the Subscription-State header field to the value of "terminated".

Also, for all service profiles in the implicit registration set the S-CSCF shall send a third-party REGISTER request, as described in subclause 5.4.1.7, to each AS that matches the Filter Criteria of the service profile from the HSS as if a equivalent REGISTER request had been received from the user deregistering that public user identity, or combination of public user identities.

On completion of the above procedures for one or more public user identities linked to the same private user identity, the S-CSCF shall consider those public user identities and the associated implicitly registered public user identities which have no contact address or a registration flow and associated contact addresses (if the multiple registration mechanism is used) bound to them as deregistered. On completion of the S-CSCF Registration/deregistration notification procedure with the HSS, as described in 3GPP TS 29.228 [14], the S-CSCF shall:

1) update or remove those public user identities linked to the same private user identity, their registration state and the associated service profiles from the local data (based on operators' policy the S-CSCF can request of the HSS to either be kept or cleared as the S-CSCF allocated to this subscriber); and

On the completion of the Network initiated de-registration by the HSS procedure, as described in 3GPP TS 29.228 [14], the S-CSCF shall remove:

1) those public user identities, their registration state and the associated service profiles from the local data; and

5.4.1.6 Network-initiated reauthentication

The S-CSCF may request a subscriber to reauthenticate at any time, based on a number of possible operator settable triggers.

NOTE 1: Triggers for re-authentication include e.g. a current registration of the UE is set to expire at a predetermined time; one or more error conditions in the S-CSCF; the S-CSCF mistrusts the UE.

If the S-CSCF is informed that a private user identity needs to be re-authenticated, the S-CSCF shall generate a NOTIFY request on all dialogs which have been established due to subscription to the reg event package of that user. For each NOTIFY request the S-CSCF shall:

1) set the Request-URI and Route header field to the saved route information during subscription;

2) set the Event header field to the "reg" value;

3) in the body of the NOTIFY request, include as many <registration> elements as many public user identities the S-CSCF is aware of the user owns:

a) set the <uri> sub-element inside the <contact> sub-element of each <registration> element to the contact address provided by the UE;

b) set the aor attribute within each <registration> element to one public user identity;

c) set the state attribute within each <registration> element to "active";

d) set the state attribute within each <contact> element to "active";

e) set the event attribute within each <contact> element that was registered by this UE to "shortened";

f) set the expiry attribute within each <contact> element that was registered by this UE to an operator defined value; and

g) if the Contact URI did not contain a "bnc" SIP URI parameter then set the <pub-gruu> and <temp-gruu> sub-elements within each <contact> element as specified in subclause 5.4.2.1.2; and

NOTE 2: There might be more than one contact information available for one public user identity. The S-CSCF will only modify the <contact> elements that were originally registered by this UE using its private user identity. The S-CSCF will not modify the <contact> elements for the same public user identitity, if registered by another UE using different private user identity.

4) set 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 S-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The S-CSCF shall not include the type 1 "term-ioi" header field parameter.

Afterwards the S-CSCF shall wait for the user to reauthenticate (see subclause 5.4.1.2).

NOTE 3: Network initiated re-authentication can occur due to internal processing within the S-CSCF.

The S-CSCF shall only include the non-barred public user identities in the NOTIFY request.

When generating the NOTIFY request, the S-CSCF shall shorten the validity of all registration lifetimes associated with this private user identity to an operator defined value that will allow the user to be re-authenticated.

5.4.1.7 Notification of Application Servers about registration status

During registration, the S-CSCF shall include the P-Access-Network-Info header fields (as received in the REGISTER request from the UE and the P-CSCF) and a P-Visited-Network-ID header field (as received in the REGISTER request from the UE) in the third-party REGISTER request sent towards the ASs, if the AS is part of the trust domain. If the AS is not part of the trust domain, the S-CSCF shall not include any P-Access-Network-Info header field or P-Visited-Network-ID header field. The S-CSCF shall not include a P-Access-Network-Info header field in any responses to the REGISTER request.

If the registration procedure described in subclauses 5.4.1.2, 5.4.1.4 or 5.4.1.5 (as appropriate) was successful, the S-CSCF shall send a third-party REGISTER request to each AS with the following information:

a) the Request-URI, which shall contain the AS's SIP URI;

b) the From header field, which shall contain the S-CSCF's SIP URI;

c) the To header field, which shall contain a non-barred public user identity belonging to the service profile of the processed Filter Criteria. It may be either a public user identity as contained in the REGISTER request received from the UE or one of the implicitly registered public user identities in the service profile, as configured by the operator;

NOTE 1: For the whole implicit registration set only one public user identity per service profile appears in the third-party REGISTER requests. Thus, based on third-party REGISTER requests only, the ASs will not have complete information on the registration state of each public user identity in the implicit registration set. The only way to have a complete and continuously updated information (even upon administrative change in subscriber's profile) is to subscribe to the reg event package.

d) the Contact header field, which shall contain the S-CSCF's SIP URI;

e) for initial registration and user-initiated reregistration (subclause 5.4.1.2), the registration expiration interval value, which shall contain the same value that the S-CSCF returned in the 200 (OK) response for the REGISTER request received from the UE;

f) for user-initiated deregistration (subclause 5.4.1.4) and network-initiated deregistration (subclause 5.4.1.5), the registration expiration interval value, which shall contain the value zero;

NOTE 2: The user can have one or more contacts registered after a third-party deregister. If an AS needs more detailed knowledge of the user registration status, the AS can subscribe to the reg event package.

g) for initial registration and user-initiated reregistration (subclause 5.4.1.2), a message body, if there is Filter Criteria indicating the need to include HSS provided data for the REGISTER event (e.g. HSS may provide AS specific data to be included in the third-party REGISTER) or if there is Filter Criteria indicating the need to include the contents of the incoming REGISTER request or the contents of the 200 (OK) response to the incoming REGISTER request in the body of the third-party REGISTER. The S-CSCF shall format the MIME body and set the value of the Content-Type header field to include the MIME type specified in subclause 5.4.1.7A;

NOTE 3: When the AS is outside the trust domain for any header field that is permitted in the REGISTER request received from the UE or final response to the REGISTER request received from the UE, including an Include Register Request or Include Register Response indication in the initial Filter Criteria would cause the incoming REGISTER request or 200 (OK) response to the incoming REGISTER request contents to be delivered to the AS revealing information that AS is not trusted to obtain. Include Register Request and Include Register Response indication is therefore not included in the initial Filter Criteria for an AS that exists outside the trust domain for any such header field.

h) for initial registration and user-initiated reregistration, the P-Charging-Vector header field, which shall contain the same "icid-value" header field parameter that the S-CSCF received in the REGISTER request from the UE. The S-CSCF shall insert a type 3 orig-ioi parameter in place of any received "orig-ioi" header field parameter and shall set the type 3 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The S-CSCF shall not include the type 3 "term-ioi" header field parameter;

i) for initial registration and user-initiated reregistration, a P-Charging-Function-Addresses header field, which shall contain the values received from the HSS if the message is forwarded within the S-CSCF home network;

j) in case the received REGISTER request contained a P-User-Database header field and the AS belongs to the same operator as the S-CSCF, optionally a P-User-Database header field which shall contain the received value;

k) if debugging configuration data exists for the address of record in the To header field, an empty P-Debug-ID header field; and

l) if the S-CSCF supports using a token to identify the registration for initial registration and user initiated reregistration, a "+g.3gpp.registration-token" Contact header field parameter, as defined in subclause 7.9.7, set to a value identifying this registration. The value shall be the same until the UE is deregistered.

For third-party REGISTER upon user-initiated reregistration, user-initiated deregistration or network-initiated deregistration, the S-CSCF shall send SIP REGISTER request towards the IP address associated with the corresponding registered public user identity stored as described in subclause 5.4.0.

When the S-CSCF receives any response to a third-party REGISTER request, the S-CSCF shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field, if present.

NOTE 4: Any received "term-ioi" header field parameter will be a type 3 IOI. The type 3 IOI identifies the service provider from which the response was sent.

If the S-CSCF fails to receive a SIP response or receives a 408 (Request Timeout) response or a 5xx response to a third-party REGISTER, the S-CSCF shall:

- if the default handling defined in the filter criteria indicates the value "SESSION_CONTINUED" as specified in 3GPP TS 29.228 [14] or no default handling is indicated, no further action is needed; and

- if the default handling defined in the filter criteria indicates the value "SESSION_TERMINATED" as specified in 3GPP TS 29.228 [14], initiate the network-initiated deregistration as described in subclause 5.4.1.5 for the currently registered public user identity and its associated set of implicitly registered non-barred public user identities bound to the contact(s) registered in the REGISTER request causing the third-party REGISTER request.

5.4.1.7A Including contents in the body of the third-party REGISTER request

If there is a service information XML element provided in the HSS Filter Criteria for an AS (see 3GPP TS 29.228 [14]), then in the third-party REGISTER request the S-CSCF shall:

- include in the message body the service information within the <service-info> XML which is a child XML element of an <ims-3gpp> element with the "version" attribute set to "1" element as described in subclause 7.6; and

- set the value of the content type to the MIME type specified in subclause 7.6.

If there is an Include Register Request XML element provided in the HSS Filter Criteria for an AS (see 3GPP TS 29.228 [14]), then in the third-party REGISTER request the S-CSCF shall:

- include in the message body the incoming SIP REGISTER request within a "message/sip" MIME body as defined in RFC 3261 [26]; and

- set the value of the content type to "message/sip".

If there is an Include Register Response XML element provided in the HSS Filter Criteria for an AS (see 3GPP TS 29.228 [14]), then in the third-party REGISTER request, the S-CSCF shall:

- include in the message body the 200 (OK) response to the incoming SIP REGISTER request within a "message/sip" MIME body as defined in RFC 3261 [26]; and

- set the value of the content type to "message/sip".

If there is more than one message body to be included in the third-party REGISTER request then in the third-party REGISTER request the S-CSCF shall:

- include a multipart message body and set the value of the Content-Type header field to "multipart/mixed" as specified in RFC 2046 [149] and RFC 5621 [150]; and

- set the Content-Type of the elements of the MIME body to the content type specified for the body.

If there is only one message body to be included in the third-party REGISTER request then the S-CSCF sets the Content-Type header field to the content type specified for the body.

5.4.1.8 Service profile updates

NOTE 1: The S-CSCF can receive an update of subscriber data notification on the Cx interface, from the HSS, which can affect the stored information about served public user identities. According to 3GPP TS 29.228 [14], the changes are guaranteed not to affect the default public user identity within the registration implicit set.

When receiving a Push-Profile-Request (PPR) from the HSS (as described in 3GPP TS 29.228 [14]), modifying the service profile of served public user identities, the S-CSCF shall:

1) if the modification consists in the addition of a new non-barred public user identity to an implicit set, or in the change of status from barred to non-barred for a public user identity already in the implicit set, add the public user identity to the list of registered, non-barred public user identities;

2) if the modification consists in the deletion of a public user identity while there are no active multimedia session belonging to this public user identity, or in the change of status from non-barred to barred of a public user identity in an implicit set, remove the public user identity from the list of registered, non-barred public user identities;

NOTE 2: As the S-CSCF checks the barring status of the public user identity on receipt of a initial request for a dialog, or a standalone transaction, the above procedures have no impact on transactions or dialogs already in progress and are effective only for new transactions and dialogs.

3) if the modification consists of deletion of a public user identity from an implicit registration set while there are active multimedia session belonging to this public user identity and contact, release these multimedia sessions as described in subclause 5.4.5.1.2 and after all multimedia sessions are released, remove the public user identity from the list of registered, non-barred public user identities; and

4) synchronize with the UE and IM CN entities, by either:

- performing the procedures for notification of the reg-event subscribers about registration state, as described in subclause 5.4.2.1.2; or

- triggering the UE to re-register, by:

a) depending on operator configuration, rejecting a request from the UE using a 504 (Server Time-out) response and indicating in the response that S-CSCF restoration procedures are supported, in accordance with subclause 5.4.3.2; or

b) shortening the life time of the current registration, as described in subclause 5.4.1.6, e.g. when a new trigger point of Register method is added in the iFCs.

NOTE 3: The UE procedure in response to receiving a rejection as described in item a) (see subclause 5.1.2A.1.6) is specified for UEs since 3GPP Rel-8.

5.4.2 Subscription and notification

5.4.2.1 Subscriptions to S-CSCF events

5.4.2.1.1 Subscription to the event providing registration state

When an incoming SUBSCRIBE request addressed to S-CSCF arrives containing the Event header field with the reg event package, the S-CSCF shall:

0) if the Request-URI of the SUBSCRIBE request contains a URI for which currently no binding exists, then send a 480 (Temporarily Unavailable) response indicating that the subscription was not successful and skip the remainder of the steps;

1) check if, based on the local policy, the request was generated by a subscriber who is authorised to subscribe to the registration state of this particular user. The authorized subscribers include:

- all public user identities this particular user owns, that the S-CSCF is aware of, and which are not-barred;

- all the entities identified by the Path header field (i.e. the P-CSCF to which this user is attached to or the IBCF which encrypted the Path header field); and

- all the ASs listed in the initial filter criteria that are part of the trust domain;

if the request is received from a subscriber which is not auhorized to subscribe to the registration state of this particular user, then send a 403 (Forbidden) response indicating that the subscription was not successful and skip the remainder of the steps;

NOTE 1: The S-CSCF finds the identity for authentication of the subscription in the P-Asserted-Identity header field received in the SUBSCRIBE request.

1A) if the Request-URI of the SUBSCRIBE request identifies a public user identity that was implicitly registered using the registration procedures defined in RFC 6140 [191] and performs the functions of an external attached network, and the registration is currently active, then skip the remainder of the procedure in this subclause and route the SUBSCRIBE request to the UE performing the functions of an externally attached network using the procedures defined in subclause 5.4.3.3;

1B) store the "icid-value" header field parameter received in the P-Charging-Vector header field;

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

NOTE 2: Any received "orig-ioi" header field parameter will be either a type 1 IOI or a type 3 IOI. The type 1 IOI identifies the sending network and the type 3 IOI identifies the service provider from which the request was sent.

3) generate a 200 (OK) response acknowledging the SUBSCRIBE request and indicating that the authorised subscription was successful as described in RFC 3680 [43] and RFC 6665 [28]. The S-CSCF shall populate the header fields as follows:

- an Expires header field, set to either the same or a decreased value as the Expires header field in SUBSCRIBE request;

- if the request originated from an ASs listed in the initial filter criteria, a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the SUBSCRIBE request, a type 3 "term-ioi" header field parameter and the "icid-value" header field parameter. The S-CSCF shall set the type 3 "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; and

- if the request originated from a public user identity this particular user owns, or any of the entities identified by the Path header field, a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the SUBSCRIBE request, a type 1 "term-ioi" header field parameter, and the "icid-value" header field parameter. The S-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.

The S-CSCF may set the Contact header field to an identifier uniquely associated to the SUBSCRIBE request and generated within the S-CSCF, that may help the S-CSCF to correlate refreshes for the SUBSCRIBE dialog; and

NOTE 3: The S-CSCF could use such unique identifiers to distinguish between UEs, when two or more users, holding a shared subscription, register under the same public user identity.

4) determine the applicable private user identity as the private user identity included in a REGISTER request:

- which created (implicitly or explictly) a binding of the public user identity in the Request-URI of the SUBSCRIBE request to an contact address; and

- for which one of the following is true:

a) the 200 (OK) response to the REGISTER request contained the Service-Route header field with the S-CSCF URI matching the URI in the top Route header field of the SUBSCRIBE request (i.e. the SUBSCRIBE request originated by a served UE); or

b) the 200 (OK) response to the REGISTER request contained a Path header field with a URI matching the URI in the P-Asserted-Identity header field of the SUBSCRIBE request (i.e. the SUBSCRIBE request originated by a P-CSCF serving a UE).

NOTE 4: If the URI in the P-Asserted-Identity header field of the initial SUBSCRIBE request matches URIs of several Path header fields (e.g. the SUBSCRIBE request is originated by Rel-7 P-CSCF), the applicable private user identity is not determined.

Afterwards the S-CSCF shall perform the procedures for notification about registration state as described in subclause 5.4.2.1.2.

If the SUBSCRIBE request originated from an AS listed in the initial filter criteria, for any response that is not a 2xx response, the S-CSCF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the SUBSCRIBE request, a type 3 "term-ioi" header field parameter and the "icid-value" header field parameter. The S-CSCF shall set the type 3 "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 the SUBSCRIBE request originated from a public user identity this particular user owns, or any of the entities identified by the Path header field, for any response that is not a 2xx response, the S-CSCF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the SUBSCRIBE request, a type 1 "term-ioi" header field parameter and the "icid-value" header field parameter. The S-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.

When the S-CSCF receives a subscription refresh request for a dialog that was established by the UE subscribing to the reg event package, the S-CSCF shall accept the request irrespective if the user's public user identity specified in the SUBSCRIBE request is either registered or has been deregistered.

5.4.2.1.2 Notification about registration state

The UE can bind any one of its public user identities either to its contact address or to a registration flow and the associated contact address (if the multiple registration mechanism is used) via a single registration procedure. When multiple registrations mechanism is used to register a public user identity and bind it to a registration flow and the associated contact address, the S-CSCF shall generate a NOTIFY request that includes one <contact> element for each binding between a public user identity and a registration flow and the associated contact address.

NOTE 1: If the UE binds a given public user identity to the same contact address but several registration flows and the associated contact address (via several registrations), then the NOTIFY request will contain one <contact> element for each registration flow and the associated contact address. Each respective <contact> elements will contain the same contact address in the <uri> sub-element, but different value in the "id" attribute and different "reg-id" value included in the respective <unknown-param> element.

For every successful registration that creates a new binding between a public user identity and either its contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used, the NOTIFY request shall always include a new <contact> element containing new value in the "id" sub-element, the state attribute set to "active", and event attribute set to either "registered" or "created".

Any successful registration (that creates a new binding between a public user identity and either its contact address or a registration flow and associated contact address) may additionally replace or remove one or more existing bindings. In the NOTIFY request, for each replaced or removed binding, the <contact> element shall have the state attribute set to "terminated" and the event attribute set to "unregistered", "deactivated", or "rejected".

NOTE 2: When multiple registrations mechanism is not used, if the UE registers new contact address then all registrations, if any, using an old contact address are deregistered, i.e. the new registration replaces the old registrations. Hence, for each deregistered public user identity, the NOTIFY request will have the state attribute within the <registration> element set to "terminated" and the state attribute in the <contact> element set to "terminated" and the event attribute set to "unregistered", "deactivated", or "rejected".

NOTE 3: If the UE uses a multiple registrations mechanism to bind a public user identity to a new registration flow the registration flow and the associated contact address, and if the new registration flow replaces an existing registration flow, then for the registration flow and the associated contact address being replaced, the respective <contact> element in the NOTIFY request will have the state attribute set to "terminated" and the event attribute set to "unregistered", "deactivated", or "rejected".

The S-CSCF shall send a NOTIFY request:

- when an event pertaining to the user occurs. In this case the NOTIFY request is sent on all dialogs which have been established due to subscription to the reg event package of that user; and

- as specified in RFC 6665 [28].

When sending a NOTIFY request, the S-CSCF shall not use the default filtering policy as specified in RFC 3680 [43], i.e. the S-CSCF shall always include in every NOTIFY request the state information of all registered public user identities of the user (i.e. the full state information).

NOTE 4: Contact information related to emergency registration is not included.

When generating NOTIFY requests, the S-CSCF shall not preclude any valid reg event package parameters in accordance with RFC 3680 [43].

For each NOTIFY request triggered by an event and on all dialogs which have been established due to subscription to the reg event package of that user, the S-CSCF shall:

1) set the Request-URI and Route header field to the saved route information during subscription;

2) set the Event header field to the "reg" value;

3) in the body of the NOTIFY request, include one <registration> elements for each public user identity that the S-CSCF is aware the user owns.

If the user shares one or more public user identities with other users, the S-CSCF shall include any contact addresses registered by other users of the shared public user identity in the NOTIFY request;

4) for each <registration> element:

a) set the aor attribute to one public user identity or if the public user identity of this <registration> element is a wildcarded public user identity, then choose arbitrarily a public user identity that matches the wildcarded public user identity and the service profile of the wildcarded public user identity and set the aor attribute to this public user identity;

NOTE 5: If the public user identity of this <registration> element is a wildcarded public user identity, the value of the aor attribute will not be used by the receiver of the NOTIFY.

b) set the <uri> sub-element inside each <contact> sub-element of the <registration> element to the contact address provided by the respective UE as follows:

I) if the aor attribute of the <registration> element contains a SIP URI and if the Contact URI did not contain a "bnc" SIP URI parameter, then for each contact address that contains a "+sip.instance" Contact header field parameter, include <pub-gruu> and <temp-gruu> sub-elements within the corresponding <contact> element. The S-CSCF shall set the contents of these elements as specified in RFC 5628 [94]; or

II) if the aor attribute of the <registration> element contains a tel-URI, determine its alias SIP URI and if the Contact URI did not contain a "bnc" SIP URI parameter then include a copy of the <pub-gruu> and <temp-gruu> sub-elements from that equivalent element;

c) if the respective UE has provided a display-name in a Contact header field, set the <display-name> sub-element inside the respective <contact> sub-element of the <registration> element to the value provided by the UE according to RFC3680 [43];

d) if the user owns a wildcarded public user identity then include a <wildcardedIdentity> sub-element as described in subclause 7.10.2;

e) if the public user identity set in step a):

I) has been deregistered either by the UE or the S-CSCF (i.e. upon the deregistration, there are no binding left between this public user identity and either a contact address or a registration flows and associated contact addresses that belong to this user) then:

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

- set the state attribute within each <contact> element belonging to this user to "terminated"; and

- set the event attribute within each <contact> element to "deactivated", "expired", "unregistered", "rejected" or "probation" according to RFC 3680 [43].

If the public user identity has been deregistered for this user and this deregistration has already been indicated in the NOTIFY request, and no new registration for this user has occurred, its <registration> element shall not be included in the subsequent NOTIFY requests;

II) has been registered by the UE (i.e. the public user identity has not been previously bound either to a contact address or to a registration flow and the associated contact address (if the multiple registration mechanism is used)) then:

- set the <unknown-param> element to any additional header field parameters contained in the Contact header field of the REGISTER request according to RFC 3680 [43];

NOTE 6: If the multiple registration mechanism is used, then the reg-id header field parameter will be included as an <unknown-param> element.

- if the subscription contains, for the applicable private user identity (determined as described in subclause 5.4.2.1.1) and the public user identity, any of the policies described in subclause 7.10.3, then include the policy associated with the applicable private user identity and the public user identity using coding described in subclause 7.10.3;

- set the state attribute within the <registration> element to "active"; and:

- set the state attribute within the <contact> element belonging to this user to "active", include new value for the "id" attribute within the <contact> sub-element, and set the event attribute within this <contact> element to "registered";

NOTE 7: If this registration, that created new binding, additionally replaces or removes one or more existing registrations, then for the replaced or removed registrations the respective <registration> elements and <contact> elements will be modified accordingly.

III) has been re-registered (i.e. it has been previously registered) then:

- set the state attribute within the <registration> element to "active";

- set the <unknown-param> element to any additional header field parameters contained in the Contact header field of the REGISTER request according to RFC 3680 [43];

- for contact addresses to be registered: set the state attribute within the <contact> element to "active"; and set the event attribute within the <contact> element to "registered";

- for contact addresses to be re-registered, set the state attribute within the <contact> element to "active"; and set the event attribute within the <contact> element to "refreshed" or "shortened" according to RFC 3680 [43]; and

- for contact addresses that remain unchanged, if any, leave the <contact> element unmodified (i.e. the event attribute within the <contact> element includes the last event that caused the transition to the respective state);

IV) has been automatically registered or registered by the S-CSCF, and has not been previously automatically registered:

- set the <unknown-param> element to any additional header field parameters contained in the Contact header field of the REGISTER request according to RFC 3680 [43];

- set the state attribute within the <registration> element to "active";

- set the state attribute within the <contact> element to "active"; and

- set the event attribute within the <contact> element to "created"; or

V) is hosted (unregistered case) at the S-CSCF:

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

- set the state attribute within each <contact> element to "terminated"; and

- set the event attribute within each <contact> element to "unregistered".

The S-CSCF shall also terminate the subscription to the registration event package by setting the Subscription-State header field to the value of "terminated"; and

NOTE 8: The value of "init" for the state attribute within the <registration> element is not used.

f) set the callid and cseq attributes for the <contact> as specified in RFC 3680 [43], and the first-cseq attribute as specified in RFC 5628 [94]; and

NOTE 9: Errata of RFC 5628 clarifies the usage of the first-cseq attribute of the <temp-gruu> element.

5) set the 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

- if the NOTIFY request is sent towards an AS listed in the initial filter criteria a type 3 "orig-ioi" header field parameter. The S-CSCF shall set the type 3 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The S-CSCF shall not include the type 3 "term-ioi" header field parameter; and

- if the NOTIFY request is sent towards a public user identity this particular user owns, or any of the entities identified by the Path header field, a type 1 "orig-ioi" header field parameter. The S-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The S-CSCF shall not include the type 1 "term-ioi" header field parameter.

NOTE 10: When sending a NOTIFY request to a subscriber subscribing or unsubscribing to the reg event package, or when the S-CSCF terminates the subscription, the event attribute within the <contact> element includes the last event that caused the transition to the respective state.

The S-CSCF shall only include the non-barred public user identities in the NOTIFY request.

EXAMPLE 1: If sip:user1_public1@home1.net is registered, the public user identity sip:user1_public2@home1.net can automatically be registered. Therefore the entries in the body of the NOTIFY request look like:

<?xml version="1.0"?>

<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"

xmlns:cp="urn:ietf:params:xml:ns:common-policy"

xmlns:eri="urn:3gpp:ns:extRegInfo:1.0"

version="0" state="full">

<registration aor="sip:user1_public1@home1.net" id="as9"

state="active">

<unknown-param name="audio"/>

</contact>

</registration>

<registration aor="sip:user1_public2@home1.net" id="as10"

state="active">

<unknown-param name="audio"/>

</contact>

<cp:actions>

<eri:rph ns="wps" val="1"/>

<eri:privSender/>

</cp:actions>

</registration>

</reginfo>

EXAMPLE 2: If sip:user1_public1@home1.net is registered, the public user identity sip:ep_user1@home1.net can automatically be registered. sip:ep_user1@home1.net is a dedicated identity out of the related range indicated in the <wildcardedIdentity> element. Therefore the entries in the body of the NOTIFY request look like:

<?xml version="1.0"?>

<reginfo xmlns="urn:ietf:params:xmlns:reginfo"

xmlns:ere="urn:3gpp:ns:extRegExp:1.0"

version="0" state="full">

<registration aor="sip:user1_public1@home1.net" id="as10"

state="active">

</contact>

</registration>

<registration aor="sip:ep_user1@home1.net" id="as11"

state="active">

</contact>

<ere:wildcardedIdentity>sip:ep_user!.*!@home1.net

</ere:wildcardedIdentity>

</registration>

</reginfo>

When sending a final NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" (i.e. all public user identities have been deregistered, expired or are hosted (unregistered case) at the S-CSCF), the S-CSCF shall also terminate the subscription to the registration event package by setting the Subscription-State header field to the value of "terminated".

When all of a UE's contact addresses have been deregistered (i.e. there is no <contact> element set to "active" for this UE), the S-CSCF shall consider subscription to the reg event package belonging to the UE cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header field containing a value of zero).

The S-CSCF shall only include the non-barred public user identities in the NOTIFY request.

When the S-CSCF receives any response to the NOTIFY request, the S-CSCF shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field, if present.

NOTE 11: Any received "term-ioi" header field parameter will be a type 3 IOI if received from an AS or a type 1 IOI if received from a public user identity this particular user owns, or any of the entities identified by the Path header field. The type 3 IOI identifies the service provider from which the response was sent and the type 1 IOI identifies the network from which the response was sent.

5.4.2.1.3 Subscription to the event providing debug state

When an incoming SUBSCRIBE request addressed to S-CSCF arrives containing the Event header field with the debug event package, the S-CSCF shall:

1) check if, based on the local policy, the request was generated by a subscriber who is authorised to subscribe to the registration state of this particular user. The authorized subscribers include:

- all public user identities this particular user owns, that the S-CSCF is aware of, and which are not-barred;

- all the entities identified by the Path header field (i.e. the P-CSCF to which this user is attached to or the IBCF which encrypted the Path header field); and

- all the ASs listed in the initial filter criteria that are part of the trust domain;

NOTE 1: An AS acting as a proxy copies the P-Debug-ID header from an incoming to an outgoing request, and an AS acting as a B2BUA retrieves debugging configuration via the Sh interface, if Sh is available. Therefore, only an AS in a different network from the S-CSCF and acting as a B2BUA needs to subscribe to debug event.

NOTE 2: The S-CSCF finds the identity for authentication of the subscription in the P-Asserted-Identity header field received in the SUBSCRIBE request.

1A) store the "icid-value" header field parameter received in the P-Charging-Vector header field;

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

NOTE 3: Any received "orig-ioi" header field parameter will be either a type 1 or a type 3 IOI. The type 1 IOI identifies the sending network and the type 3 IOI identifies the service provider from which the request was sent.

3) generate a 200 (OK) response acknowledging the SUBSCRIBE request and indicating that the authorised subscription was successful as described in draft-dawes-sipping-debug [140]. The S-CSCF shall populate the header fields as follows:

- an Expires header field, set to either the same or a decreased value as the Expires header field in SUBSCRIBE request;

- if the request originated from an ASs listed in the initial filter criteria, a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the SUBSCRIBE request, a type 3 "term‑ioi" header field parameter and the "icid-value" header field parameter. The S-CSCF shall set the type 3 "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; and

- if the request originated from a public user identity this particular user owns, or any of the entities identified by the Path header field, a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the SUBSCRIBE request, a type 1 "term-ioi" header field parameter and the "icid-value" header field parameter. The S-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.

NOTE 4: The S-CSCF could use such unique identifiers to distinguish between UEs, when two or more users, holding a shared subscription, register under the same public user identity.

Afterwards the S-CSCF shall perform the procedures for notification about debug configuration state as described in subclause 5.4.2.1.4.

For any response that is not a 2xx response, the S-CSCF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the SUBSCRIBE request, a type 3 "term-ioi" header field parameter and the "icid-value" header field parameter. The S-CSCF shall set the type 3 "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.

When the S-CSCF receives a subscription refresh request for a dialog that was established by the UE subscribing to the debug event package, the S-CSCF shall accept the request irrespective if the user's public user identity specified in the SUBSCRIBE request is either registered or has been deregistered.

5.4.2.1.4 Notification about debug configuration

The S-CSCF shall send a NOTIFY request:

- when an event that changes the debugging configuration of the user occurs. In this case the NOTIFY request is sent on all dialogs which have been established due to subscription to the debug event package of that user; and

- as specified in RFC 6665 [28].

The S-CSCF shall set the 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:

The S-CSCF shall generate the body of the NOTIFY request as specified in draft-dawes-sipping-debug [140].

EXAMPLE: For user alice@atlanta.com subscribed to her debug configuration, the entries in the body of the NOTIFY request look like:

<?xml version="1.0"?>

<debuginfo xmlns="urn:ietf:params:xml:ns:debuginfo"

version="0" state="full">

<debugconfig aor="alice@atlanta.com" id="r01" state="active"

expires="43200">

<start-trigger>

<method>INVITE</method>

<from>alice@atlanta.com</from>

</start-trigger>

<stop-trigger>

<time-period>P7M30S</time-period>

</stop-trigger>

<trace-depth>minimum</trace-depth>

<debug-id>1A346D</debug-id>

</control>

</session>

</debugconfig>

</debuginfo>

NOTE 1: If multiple sessions are to be debugged, then multiple <session></session> elements are included in the XML, each one with a different debug-id attribute.

When all of a UE's debug configurations have expired (i.e. there is no <debugconfig> element set to "active" for this UE), the S-CSCF shall consider subscription to the debug event package belonging to the UE cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header field containing a value of zero).

When the S-CSCF receives any response to the NOTIFY request, the S-CSCF shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field, if present.

NOTE 2: Any received "term-ioi" header field parameter will be a type 3 IOI if received from an AS or a type 1 IOI if received from a public user identity this particular user owns, or any of the entities identified by the Path header field. The type 3 IOI identifies the service provider from which the response was sent and the type 1 IOI identifies the network from which the response was sent.

5.4.2.1A Outgoing subscriptions to load-control event

Based on operator policy, the S-CSCF may subscribe to the load-control event package with one or more target SIP entities. The list of target SIP entities is provisioned.

Subscription to the load-control event package is triggered by internal events (e.g. the physical device hosting the SIP entity is power-cycled) or through a management interface.

The S-CSCF shall perform subscriptions to the load-control event package to a target entity in accordance with RFC 6665 [28] and with RFC 7200 [201]. When subscribing to the load-control event, the S-CSCF shall:

1) Send a SUBSCRIBE request in accordance with RFC 6665 [28] and with RFC 7200 [201] to the target entity, with the following elements:

- an Expires header field set to a network specific value;

2) If the target entity is located in a different network and local policy requires the application of IBCF capabilities, forward the request to an IBCF acting as an exit point.

The S-CSCF shall automatically refresh ongoing subscription to the load-control event package 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.

The S-CSCF can terminate a subscription according to RFC 6665 [28].

5.4.2.2 Other subscriptions

Upon receipt of a NOTIFY request with the Subscription-State header field set to "terminated" and the S-CSCF has retained the SIP dialog state information for the associated subscription, once the NOTIFY transaction is terminated, the S-CSCF can remove all the stored information related to the associated subscription.

5.4.3 General treatment for all dialogs and standalone transactions excluding requests terminated by the S-CSCF

5.4.3.1 Determination of UE-originated or UE-terminated case

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

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

- perform the procedures for the UE-originating case as described in subclause 5.4.3.2 if the topmost Route header field of the request contains the "orig" parameter. The S-CSCF shall remove the "orig" parameter from the topmost Route header field; or,

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

5.4.3.2 Requests initiated by the served user

For all SIP transactions identified:

- 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 S-CSCF shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs.

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.

When the S-CSCF receives from the UE an initial request for a dialog, which contains a GRUU and an "ob" SIP URI parameter in the Contact header field, and multiple contact addresses have been registered for the specific GRUU, then for all subsequent in-dialog requests sent toward the UE's, the S-CSCF shall populate the Request-URI with the registered contact address from which the UE sent the initial request for the dialog.

NOTE 2: When a given contact address is registered, the S-CSCF can use a dedicated value in its Service-Route header field entry to identify the given contact address. When the S-CSCF receives an initial request for a dialog, the S-CSCF can find out from which contact address the initial request was sent by looking at the preloaded Route header field (constructed from the Service-Route header field returned in the response for the REGISTER request) which contains the entry of the S-CSCF.

When performing SIP digest without TLS, when the S-CSCF receives from the served user an initial request for a dialog or a request for a standalone transaction, the S-CSCF may perform the steps in subclause 5.4.3.6 to challenge the request based on local policy.

NOTE 3: If the user registration is associated with the state "tls-protected", then the execution of Proxy-Authorization as described in subclause 5.4.3.6 is still possible, although it is unlikely this would add additional security provided the P-CSCF is trusted. Thus, in most cases the state "tls-protected" will be reason for the S-CSCF to not desire Proxy-Authentication for this user.

NOTE 4: The option for the S-CSCF to challenge the request does not apply to a request from an AS acting as an originating UA.

When performing GPRS-IMS-Bundled authentication, when the S-CSCF receives from the served user an initial request for a dialog or a request for a standalone transaction, the S-CSCF shall check whether a "received" header field parameter exists in the Via header field provided by the UE. If a "received" header field parameter exists, S-CSCF shall compare the (prefix of the) IP address received in the "received" header field parameter against the UE's IP address (or prefix) stored during registration. If no "received" header field parameter exists in the Via header field provided by the UE, then S-CSCF shall compare the (prefix of the) IP address received in the "sent-by" parameter against the IP address (or prefix) stored during registration. If the stored IP address (or prefix) and the (prefix of the) IP address in the "received" Via header field parameter provided by the UE do not match, the S-CSCF shall reject the request with a 403 (Forbidden) response. In case the stored IP address (or prefix) and the (prefix of the) IP address in the "received" Via header field parameter provided by the UE do match, the S-CSCF shall proceed as described in the remainder of this subclause.

If the S-CSCF supports HSS based P-CSCF restoration, and receives a request from a P-CSCF that the S-CSCF considers is not reachable, the S-CSCF shall consider this P-CSCF as being reachable.

If the S-CSCF supports PCRF based P-CSCF restoration, and receives a request from a P-CSCF that the S-CSCF considers is in a not reachable, the S-CSCF shall consider this P-CSCF as being reachable.

When the S-CSCF receives from the served user or from a PSI an initial request for a dialog or a request for a standalone transaction, and the request is received either from a functional entity within the same trust domain or contains a valid original dialog identifier (see step 3) or the dialog identifier (From, To and Call-ID header fields) relates to an existing request processed by the S-CSCF, then prior to forwarding the request, the S-CSCF shall:

0) if the request is received from a P-CSCF that does not support the trust domain handling of the P-Served-User header field then remove any P-Served-User header fields;

1) determine the served user as follows:

a) if the request contains a P-Served-User header field then

i) determine the served user by taking the identity contained in a P-Served-User header field as defined in RFC 5502 [133]. Then check whether the determined served user is a barred public user identity. In case the said header field contains the served user identity is a barred public user identity for the user, then the S-CSCF shall reject the request by generating a 403 (Forbidden) response. Otherwise, the S-CSCF shall save the public user identity of the served user and continue with the rest of the steps;

NOTE 5: If the P-Served-User header field contains a barred public user identity, then the message has been received, either directly or indirectly, from a non-compliant entity which should have had generated the content with a non-barred public user identity.

b) if the request does not contain a P-Served-User header field then

i) determine the served user by taking the identity contained in one of the URI(s) of the P-Asserted-Identity header field. In case the determined served user is a barred public user identity, then the S-CSCF shall reject the request by generating a 403 (Forbidden) response. Otherwise, the S-CSCF shall save the public user identity of the served user and continue with the rest of the steps; and

ii) if the P-Asserted-Identity header field contains two URIs and the URI other than the determined served user is not an alias of the determined served user or is barred then act based on local policy, e.g. reject the request by generating a 403 (Forbidden) response or remove the URI not identifying the determined served user from the P-Asserted-Identity header field;

NOTE 6: If the P-Asserted-Identity header field contains a barred public user identity, then the message has been received, either directly or indirectly, from a non-compliant entity which should have had generated the content with a non-barred public user identity.

1A) if the Contact is a GRUU, but is not valid as defined in subclause 5.4.7A.4, then return a 4xx response as specified in RFC 5627 [93];

2) store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field if present, and remove it from any forwarded request;

NOTE 7: Any received "orig-ioi" header field parameter will be either a type 1 IOI or a type 3 IOI. The type 1 IOI identifies the network from which the request was sent and the type 3 IOI identifies the service provider from which the request was sent (AS initiating a session on behalf of a user or a PSI);

3) check if an original dialog identifier that the S-CSCF previously placed in a Route header field is present in the topmost Route header field of the incoming request.

- If not present, the S-CSCF shall build an ordered list of initial filter criteria based on the public user identity of the served user (as determined in step 1) of the received request as described in 3GPP TS 23.218 [5].

- If present, the request has been sent from an AS in response to a previously sent request, an ordered list of initial filter criteria already exists and the S-CSCF shall not change the ordered list of initial filter criteria even if the AS has changed the P-Served-User header field or the P-Asserted-Identity header field;

NOTE 8: An original dialog identifier is sent to each AS invoked due to iFC evaluation such that the S-CSCF can associate requests as part of the same sequence that trigger iFC evaluation in priority order (and not rely on SIP dialog information that can change due to B2BUA AS). If the same original dialog identifier is included in more than one request from a particular AS (based on service logic in the AS), then the S-CSCF will continue the iFC evaluation sequence rather than build a new ordered list of iFC;

4) remove its own SIP URI from the topmost Route header field;

4A) if a reference location was received from the HSS at registration as part of the user profile and the request does not contain a message body with the content type application/pidf+xml in accordance with RFC 6442 [89] and does not contain a P-Access-Network-Info header field containing the "network-provided" parameter, the S-CSCF shall insert a P-Access-Network-Info header field constructed according to the reference location received from the HSS and containing the "network-provided" parameter. The access type information received from the HSS shall be mapped into the corresponding access-type parameter of the P-Access-Network-Info header field and the location information shall be mapped into the location parameter corresponding to the access-type parameter, i.e. into "dsl-location" parameter, "fiber-location" parameter or "eth-location" parameter;

4B) if there was an original dialog identifier present in the topmost Route header field of the incoming request and the request is received from a functional entity within the same trust domain and contains a P-Asserted-Service header field, continue the procedure with step 5;

4C) if the request contains a P-Preferred-Service header field, check whether the ICSI value contained in the P-Preferred-Service header field is part of the set of the subscribed services for the served user and determine, using operator-configured data, whether the contents of the request match the ICSI for the subscribed service. The operator-configured data used to determine if there is a matching between the request and the ICSI value may be based on any information in the request (e.g. SDP media capabilities, Content-Type header field, request method). Then:

a) if there is no match between the request and the ICSI value, as an operator option, the S-CSCF may reject the request by generating a 403 (Forbidden) response. Otherwise remove the P-Preferred-Service header field and continue with the rest of the steps; and

b) if there is a match between the request and the ICSI value, then include a P-Asserted-Service header field in the request containing the ICSI value contained in the P-Preferred-Service header field, remove the P-Preferred-Service header field, and continue the procedure with step 5;

4D) if the request does not contain a P-Preferred-Service header field, check, using operator-configured data, whether the contents of the request match a subscribed service for each and any of the subscribed services for the served user:

a) if not, as an operator option, the S-CSCF may reject the request by generating a 403 (Forbidden) response; and

b) if so, and if the request is related to an IMS communication service and the IMS communication service requires the use of an ICSI value then select an ICSI value for the related IMS communication service and include a P-Asserted-Service header field in the request containing the selected ICSI value; and

NOTE 9: If more than one ICSI values match the contents of the request, the S-CSCF selects an ICSI value based on local policy.

c) if so, and if the request is related to an IMS communication service and the IMS communication service does not require the use of an ICSI value then continue without including an ICSI value; and

d) if so, and if the request does not relate to an IMS communication service (or if the S-CSCF is unable to unambiguously determine the service being requested but decides to allow the session to continue) then continue without including an ICSI value;

5) check whether the initial request matches any unexecuted initial filter criteria. If there is a match, then the S-CSCF shall select the first matching unexecuted initial filter criteria from the ordered list of initial filter criteria and the S-CSCF shall:

a) insert the AS URI to be contacted into the Route header field as the topmost entry followed by its own URI populated as specified in the subclause 5.4.3.4;

NOTE 10: If the AS is accessed via an ISC gateway function, then the URI will be the address of the ISC gateway function.

b) if the S-CSCF supports the P-Served-User extension as specified in RFC 5502 [133] and draft-mohali-dispatch-originating-cdiv-parameter [239] insert P-Served-User header field populated with the served user identity as determined in step 1. If required by operator policy, the S-CSCF shall:

- if the associated session case is "Originating" as specified in 3GPP TS 29.228 [14], include the sescase header field parameter set to "orig" and the regstate header field parameter set to "reg";

- if the associated session case is "Originating_Unregistered" as specified in 3GPP TS 29.228 [14], include the sescase header field parameter set to "orig" and the regstate header field parameter set to "unreg";

- if the associated session case is "Originating_CDIV" as specified in 3GPP TS 29.228 [14], include the "orig-cdiv" header field parameter, defined in draft-mohali-dispatch-originating-cdiv-parameter [239]; and

c) if the AS is located outside the trust domain then the S-CSCF shall remove the access-network-charging-info parameter in the P-Charging-Vector header field from the request that is forwarded to the AS; if the AS is located within the trust domain, then the S-CSCF shall retain the access-network-charging-info parameter in the P-Charging-Vector header field in the request that is forwarded to the AS;

d) insert a type 3 "orig-ioi" header field parameter in place of any received "orig-ioi" header field parameters in the P-Charging-Vector header field. The S-CSCF shall set the type 3 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The S-CSCF shall not include the type 3 "term-ioi" header field parameter;

e) remove the "transit-ioi" header field parameter, if received;

f) based on operator policy insert in a Relayed-Charge header field the value of the received "transit-ioi" header field parameter in the P-Charging-Vector header field;

g) if the S-CSCF supports using a token to identify the registration and if a registration exists, insert a "+g.3gpp.registration-token" Feature-Caps header field parameter, as defined in subclause 7.9A.8, set to the same value as included in the "+g.3gpp.registration-token" Contact header field parameter of the third party REGISTER request sent to the AS when the UE registered; and

h) if an IP address associated with the served user and the AS SIP URI is stored as described in subclause 5.4.0 exists, then the S-CSCF forwards the SIP message to the IP address associated with the served user and the AS SIP URI;

NOTE 11: Depending on the result of processing the filter criteria the S-CSCF might contact one or more AS(s) before processing the outgoing Request-URI.

NOTE 12: An AS can activate or deactivate its own filter criteria via the Sh interface. As the S-CSCF checks initial filter criteria only on receipt of an initial request for a dialog, or a standalone transaction, a modified service profile will have no impact on transactions or dialogs already in progress and the modified profile will be effective only for new transactions and dialogs. If the S-CSCF receives a modification of the iFC during their execution, then it should not update the stored initial Filter Criteria until the iFC related to the initial request have been completely executed.

6) if there was no original dialog identifier present in the topmost Route header field of the incoming request store the value of the "icid-value" header field parameter received in the P-Charging-Vector header field and retain the "icid-value" header field parameter in the P-Charging-Vector header field. Optionally, the S-CSCF may generate a new, globally unique ICID and insert the new value in the "icid-value" header field parameter of the P-Charging-Vector header field when forwarding the message. If the S-CSCF creates a new ICID, then it is responsible for maintaining the two ICID values in the subsequent messaging;

7) in step 5, if the initial request did not match any unexecuted initial filter criteria (i.e. the request is not forwarded to an AS):

a) remove the received "transit-ioi" from the P-Charging-Vector header field, if present;

b) insert a type 2 "orig-ioi" header field parameter into the P-Charging-Vector header field. The S-CSCF shall set the type 2 "orig-ioi" header field parameter to a value that identifies the sending network. The S-CSCF shall not include the type 2 "term-ioi" header field parameter; and

c) remove the Relayed-Charge header field, if present;

8) insert a P-Charging-Function-Addresses header field populated with values received from the HSS if the request does not contain a P-Charging-Function-Addresses header field and the message is forwarded within the S-CSCF home network, including towards AS;

9) if there was no original dialog identifier present in the topmost Route header field of the incoming request and if the served user is not considered a privileged sender then:

a) if the P-Asserted-Identity header field contains only a SIP URI and if the S-CSCF has knowledge that the SIP URI contained in the received P-Asserted-Identity header field is an alias SIP URI for a tel URI, add a second P-Asserted-Identity header field containing this tel-URI, including the display name associated with the tel URI, if available; and

b) if the P-Asserted-Identity header field contains only a tel URI, the S-CSCF shall add a second P-Asserted-Identity header field containing a SIP URI. The added SIP URI shall contain in the user part a "+" followed by the international public telecommunication number contained in tel URI, and user's home domain name in the hostport part. The added SIP URI shall contain the same value in the display name as contained in the tel URI. The S-CSCF shall also add a "user" SIP URI parameter equals "phone" to the SIP URI;

NOTE 13: If tel URI is shared URI so is the alias SIP URI.

10) if the request is not forwarded to an AS and if the outgoing Request-URI is:

- a SIP URI with the user part starting with a + and the "user" SIP URI parameter equals "phone", and if configured per local operator policy, the S-CSCF shall perform the procedure described here. Local policy can dictate whether this procedure is performed for all domains of the SIP URI, only if the domain belongs to the home network, or not at all. If local policy indicates that the procedure is to be performed, then the S-CSCF shall translate the international public telecommunications number contained in the user part of the SIP URI (see RFC 3966 [22]) to a globally routeable SIP URI using either an ENUM/DNS translation mechanism with the format specified in RFC 6116 [24], or any other available database. Database aspects of ENUM are outside the scope of the present document. An S-CSCF that implements the additional routeing functionality described in annex I may forward the request without attempting translation. If an agreement exists between the home network and the visited network to support roaming architecture for voice over IMS with local breakout, the S-CSCF does not enable NP capabilities, and the S-CSCF decides to loopback the call to the visited network, the S-CSCF may forward the request without attempting translation. If a translation is in fact performed and it succeeds, the S-CSCF shall update the Request-URI with the globally routeable SIP URI either returned by ENUM/DNS or obtained from any other available database. If this translation fails, the request may be forwarded to a BGCF or any other appropriate entity (e.g. a MRFC to play an announcement) in the originator's home network or the S-CSCF may send an appropriate SIP response to the originator. When forwarding the request to a BGCF or any other appropriate entity, the S-CSCF shall leave the original Request-URI containing the SIP URI with "user" SIP URI parameter equals phone unmodified. If the request is forwarded, the S-CSCF shall remove the access-network-charging-info parameter from the P-Charging-Vector header field prior to forwarding the message;

- a SIP URI with a "user" SIP URI parameter equals "dialstring" and the domain name of the SIP URI belongs to the home network (i.e. the local number analysis and handling is either failed in the appropriate AS or the request has not been forwarded to AS for local number analysis and handling at all), either forward the request to any appropriate entity (e.g a MRFC to play an announcement) in the originator's home network or send an appropriate SIP response to the originator;

- a SIP URI with a local number (see RFC 3966 [22]) in the user part and a "user" SIP URI parameter equals "phone" and the domain name of the SIP URI belongs to the home network (i.e. the local number analysis and handling is either failed in the appropriate AS or the request has not been forwarded to AS for local number analysis and handling at all), either forward the request to to a BGCFor any appropriate entity (e.g a MRFC to play an announcement) in the originator's home network or send an appropriate SIP response to the originator;

- a tel URI containing a global number (see RFC 3966 [22]) in the international format, the S-CSCF shall translate the E.164 address to a globally routeable SIP URI using either an ENUM/DNS translation mechanism with the format specified in RFC 6116 [24], or any other available database. Database aspects of ENUM are outside the scope of the present document. An S-CSCF that implements the additional routeing functionality described in annex I may forward the request without attempting translation. If an agreement exists between the home network and the visited network to support roaming architecture for voice over IMS with local breakout, the S-CSCF does not enable NP capabilities, and the S-CSCF decides to loopback the call to the visited network, the S-CSCF may forward the request without attempting translation. If this translation is in fact performed and it succeeds, the S-CSCF shall update the Request-URI with the globally routeable SIP URI returned by ENUM/DNS or any other available database. If this translation fails, the request may be forwarded to a BGCF or any other appropriate entity (e.g a MRFC to play an announcement) in the originator's home network or the S-CSCF may send an appropriate SIP response to the originator. When forwarding the request to a BGCF or any other appropriate entity, the S-CSCF shall leave the original Request-URI containing the tel URI unmodified. If the request is forwarded, the S-CSCF shall remove the access-network-charging-info parameter from the P-Charging-Vector header field prior to forwarding the message;

- a tel URI containing a local number (see RFC 3966 [22]) (i.e. the local number analysis and handling is either failed in the appropriate AS or the request has not been forwarded to AS for local number analysis and handling at all), either forward the request to a BGCF or any other appropriate entity (e.g. a MRFC to play an announcement) in the originator's home network or send an appropriate SIP response to the originator;

- a pres URI or an im URI, the S-CSCF shall forward the request as specified in RFC 3861 [63]. In this case, the S-CSCF shall not modify the received Request-URI: and

- a service URN, e.g. a service URN with a top-level service type of "sos" as specified in RFC 5031 [69]. In this case the S-CSCF shall not modify the received Request-URI.

NOTE 14: If there is no SIP-based transport found after applying the procedure specified in RFC 3861 [63], the S-CSCF can forward the request to a translating gateway.

Additional procedures apply if the S-CSCF supports NP capabilities and these capabilities are enabled by local policy, and the database used for translation from an international public telecommunications number to a SIP URI also provides NP data (for example, based on the PSTN Enumservice as defined by RFC 4769 [114] or other appropriate data bases). If the above translation from an international public telecommunications number to a SIP URI failed, but NP data was obtained from the database and there is no "npdi" parameter in the received request, then the S-CSCF shall, based on operator policy, replace the URI in the Request-URI with the obtained NP data, prior to forwarding the request to the BGCF or other appropriate entity. If the received request already contains a tel-URI "npdi" parameter, then the S-CSCF may update the URI with the obtained NP data. The URI is updated by the S-CSCF by adding NP parameters defined by RFC 4694 [112]. If the Request-URI is a tel-URI, then an "npdi" tel-URI parameter is added to indicate that NP data retrieval has been performed, and if the number is ported, an "rn" tel-URI parameter is added to identify the ported-to routeing number. If the Request-URI is in the form of a SIP URI user=phone, the "npdi" and "rn" tel-URI parameters are added as described above to the userinfo part of the SIP URI;

NOTE 15: When the S-CSCF replaces the tel-URI in the Request-URI with the obtained NP data, all tel URI parameters in the received Request-URI will be replaced by the obtained NP data.

10A) if the request is not forwarded to an AS and if local policy requires the application of additional routeing capabilities, as defined in annex I, the S-CSCF shall apply the additional routeing capabilities if they are locally available or forward the request to an entity that implements the additional routeing capabilities;

10B) if an agreement exists between the home network and the visited network to support Roaming Architecture for Voice over IMS with Local Breakout then continue with the following steps. Otherwise continue with step 11. If:

- the top most Route header contains an indication that this is the UE-originating case;

NOTE 16: This indication can e.g. be in a URI parameter, a character string in the user part of the URI or can be a port number in the URI added by the S-CSCF during the registration in the Service-Route header field.

- the UE is roaming (as identified by the P-Visited-Network-ID header field value in the original REGISTER request); and

- the request is an INVITE request;

determine if loopback routeing is applicable for this request using local policy, and save this decision for subsequent processing along with the following information:

a) any URI representing the TRF address preference received from the visited network; and

b) the ICID received in the request.

In addition, the S-CSCF shall also include in the request a Feature-Caps header field with the "+g.3gpp.home-visited" header field parameter according to RFC 6809 [190] with the "+g.3gpp.home-visited" header field parameter set to the identifier of the visited network received in the P-Visited-Network-ID header field in the original registration request;

10C) if the request is an INVITE request, then determine whether loopback is applied for this request. The information saved in step 10B, and the presence or absence of the Feature-Caps header field with the "+g.3gpp.home-visited" header field parameter in the received INVITE request are taken into account in making this decision:

a) if loopback routeing is not to be performed for this request remove any "+g.3gpp.trf" header field parameter or "+g.3gpp.home-visited" header field parameter from the Feature-Caps header field of the outgoing request;

b) if loopback routeing is applied for this request;

i) remove all entries in the Route header field;

ii) if a "+g.3gpp.trf" header field parameter with a parameter value containing a valid URI, is included in the Feature-Caps header field of the request, insert the URI in a Route header field;

iii) if a "+g.3gpp.trf" header field parameter, with a parameter value containing a valid URI is not included in the Feature-Caps header field of the request, insert a locally configured TRF address, associated with the visited network for this call, in the Route header field;

iv) remove any "+g.3gpp.home-visited" header field parameter from the Feature-Caps header field of the outgoing request;

v) insert the "+g.3gpp.loopback" header field parameter as specified in subclause 7.9A.4 in the Feature-Caps header field of the request, in accordance with the RFC 6809 [190]. If providing the identifier of the home network is supported by the S-CSCF and the visited network, the S‑CSCF may based on operator agreement insert the "+g.3gpp.loopback" header field parameter set to the identifier of the home network;

vi) if included in the incoming request, remove the "+g.3gpp.trf" header field parameter from the Feature-Caps header field from the outgoing request;

vii) remove a type 2 "orig-ioi" header field parameter that was added in step 7 from the P-Charging-Vector header field and insert a type 1 "orig-ioi" header field parameter into the P-Charging-Vector header field. The S-CSCF shall set the type 1 "orig-ioi" header field parameter to a value that identifies the network in which the S-CSCF resides. The S-CSCF shall not include the "term-ioi" header field parameter; and

viii) if the S-CSCF supports indicating the traffic leg associated with a URI as specified in RFC 7549 [225] and if an "iotl" SIP URI parameter is not included in the TRF URI in the Route header field and if required by local policy, append an "iotl" URI parameter with a value set to "homeA-visitedA" to the URI in the Route header field; and

c) if the final decision on loopback routeing is deferred to a subsequent entity in the home network, the BGCF, then the S-CSCF includes, if absent, in the request a Feature-Caps header field with the "+g.3gpp.home-visited" header field parameter, with the parameter value set to the identifier of the visited network received in the P-Visited-Network-ID header field in the original registration request. The S-CSCF is expected to know by means of network configuration that such a subsequent entity exists; and

NOTE 17: The subsequent entity in the home network, the BGCF, will remove the "+g.3gpp.home-visited" header field parameter from the Feature-Caps header field when a final routeing decision is taken.

11) determine the destination address (e.g. DNS access) using the URI placed in the topmost Route header field if present, otherwise based on the Request-URI. If the destination requires interconnect functionalities (e.g. the destination address is of an IP address type other than the IP address type used in the IM CN subsystem), the S-CSCF shall forward the request to the destination address via an IBCF in the same network;

12) if network hiding is needed due to local policy, put the address of the IBCF to the topmost Route header field;

13) in case of an initial request for a dialog:

a) determine the need for GRUU processing. GRUU processing is required if:

- an original dialog identifier that the S-CSCF previously placed in a Route header field is not present in the topmost Route header field of the incoming request (this means the request is not returning after having been sent to an AS), and

- the contact address contains a GRUU that was either assigned by the S-CSCF that is valid as specified in subclause 5.4.7A.4 or a temporary GRUU self assigned by the UE based on the "temp-gruu-cookie" header parameter provided to the UE;

NOTE 18: The procedures for determining that a URI is a temporary GRUU assigned by the UE are specified in subclause 7.1.2.3 of RFC 6140 [191].

b) if GRUU processing is not required and the initial request originated from a served user, then determine the need to record-route for other reasons:

- if the request is routed to an AS which is part of the trust domain, the S-CSCF shall decide, based on operator policy, whether to record-route or not. The decision is configured in the S-CSCF using any information in the received request that may otherwise be used for the initial filter criteria. If the request is record-routed the S-CSCF shall create a Record-Route header field containing its own SIP URI;

- if the request is a SUBSCRIBE request and routed elsewhere, the S-CSCF shall decide, based on operator policy, whether to record-route or not. The decision is configured in the S-CSCF using any information in the received request (e.g. event package name). If the request is record-routed the S-CSCF shall create a Record-Route header field containing its own SIP URI; or

NOTE 19: Some subscriptions to event packages (e.g. presence) can result in virtually persistent subscriptions and if the S-CSCF Record-Routes this can prevent reassignment of the S-CSCF.

NOTE 20: If the S-CSCF does not Record-Route the initial SUBSCRIBE request, it will not be possible to perform SIP digest authentication of SIP requests sent inside the SIP dialog related to the associated subscription.

- if the request not a SUBSCRIBE request and is routed elsewhere, create a Record-Route header field containing its own SIP URI;

NOTE 21: For requests originated from a PSI the S-CSCF can decide whether to record-route or not based on operator policy.

c) if GRUU processing is required, the S-CSCF shall create a Record-Route header field containing its own SIP URI;

d) if GRUU processing is required, the S-CSCF shall save an indication that GRUU-routeing is to be performed for in-dialog requests that reach the S-CSCF because of the Record-route header field added in step c);

NOTE 22: The manner of representing the GRUU-routeing indication is a private matter for the S-CSCF. The indication is used during termination processing of in-dialog requests to cause the S-CSCF to replace a Request-URI containing a GRUU with the corresponding registered contact address. It can be saved using values in the Record-Route header field, or in dialog state.

14) based on the destination user (Request-URI), remove any P-Access-Network-Info header field and the access-network-charging-info parameter in the P-Charging-Vector header field prior to forwarding the message;

14A) if the request is not routed to an AS, to a BGCF or to an entity that implements the additional routeing functionality, remove the P-Served-User header field prior to forwarding the request;

14B) if the S-CSCF supports indicating the traffic leg as specified in RFC 7549 [225], the request is not routed to an AS, to a BGCF or to an entity that implements the additional routeing functionality, loopback routeing is not to be performed for this request, required by local policy and the Request-URI contains a SIP URI, append the "iotl" SIP URI parameter set to "homeA-homeB" to the Request-URI;

15) route the request based on SIP routeing procedures;

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

17) if the request matches a trigger for starting logging of SIP signalling, as described in draft-dawes-sipping-debug [140], start to log SIP signalling for this dialog according to its debug configuration; and

18) if the S-CSCF supports using a token to identify the registration and if the request is not forwarded to an AS, remove the "+g.3gpp.registration-token" Feature-Caps header field parameter, defined in subclause 7.9A.8, if received in the request.

When the S-CSCF receives, an initial request for a dialog or a request for a standalone transaction, from an AS acting on behalf of an unregistered user, the S-CSCF shall:

1) execute the procedures described in the steps 1, 2, 3, 4, 4B, 4C, 4D, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 and 16 in the above paragraph (when the S-CSCF receives, from a registered served user, an initial request for a dialog or a request for a standalone transaction).

NOTE 23: When the S-CSCF does not have the user profile, before executing the actions as listed above, it initiates the S-CSCF Registration/deregistration notification procedure, as described in 3GPP TS 29.228 [14]; with the purpose of downloading the relevant user profile (i.e. for unregistered user) and informs the HSS that the user is unregistered. The S-CSCF will assess triggering of services for the unregistered user, as described in 3GPP TS 29.228 [14]. When requesting the user profile, and the request received by the S-CSCF contains a P-Profile-Key header field, the S-CSCF can include the header field value in S-CSCF Registration/deregistration notification. If the response from the HSS includes a Wildcarded Public Identity AVP, and if the request received by the S-CSCF did not include a P-Profile-Key header field, the S-CSCF uses the AVP value to set the P-Profile-Key header field before forwarding the request to an AS.

When the S-CSCF receives a request initiated by the served user for which the S-CSCF does not have the user profile or does not trust the data that it has (e.g. due to restart), the S-CSCF shall attempt to retrieve the user profile from the HSS. If the S-CSCF receives a Diameter result code of DIAMETER_UNABLE_TO_COMPLY as defined in 3GPP TS 29.228 [14], the S-CSCF supports S-CSCF restoration procedures, and the Request-URI of the request does not match an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031 [69], then the S-CSCF shall:

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

II) 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

III) 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 S-CSCF included in the Service-Route header field (see subclause 5.4.1.2.2F) during the registration of the user whose UE sent the request causing this response; and

- a 3GPP IM CN subsystem XML body:

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 24: These procedures do not prevent the usage of unspecified reliability or recovery techniques above and beyond those specified in this subclause.

Depending on operator configuration (see subclause 5.4.1.8), when the S-CSCF receives a request with a Request-URI that does not match an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031 [69], the request initiated by the served user for which the S-CSCF has modified but not synchronized the service profile for the served user and the S-CSCF supports S-CSCF restoration procedures, then the S-CSCF shall reject the request as described in items I), II) and III).

If the S-CSCF:

a) fails to receive a SIP response within a configurable time; or

b) receives a 408 (Request Timeout) response or a 5xx response from the AS without previously receiving a 1xx response to the original SIP request, and without previously receiving a SIP request from the AS that contained the same original dialog identifier as the original request;

the S-CSCF shall:

- if the default handling defined in the filter criteria indicates the value "SESSION_TERMINATED" as specified in 3GPP TS 29.228 [14], either forward the received response or, if the request is an initial INVITE request, send a 408 (Request Timeout) response or a 5xx response towards the served UE as appropriate (without verifying the matching of filter criteria of lower priority and without proceeding for further steps).

If the S-CSCF receives any final response from the AS, the S-CSCF shall forward the response towards the served UE (without verifying the matching of filter criteria of lower priority and without proceeding for further steps).

When the S-CSCF receives any response to the above request containing a Relayed-Charge header field, and the next hop is not an AS, the S-CSCF shall remove the Relayed-Charge header field from the forwarded response.

When the S-CSCF receives any response to the above request, the S-CSCF may:

1) apply any privacy required by RFC 3323 [33] and RFC 3325 [34] to the P-Asserted-Identity header field.

NOTE 25: The P-Asserted-Identity header field would normally only be expected in 1xx or 2xx responses.

NOTE 26: The optional procedure above is in addition to any procedure for the application of privacy at the edge of the trust domain specified by RFC 3325 [34].

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

1) If logging is in progress for this dialog, check whether a trigger for stopping logging of SIP signalling has occurred, as described in draft-dawes-sipping-debug [140]. If a stop trigger event has occurred then stop logging of signalling, else determine, by checking its debug configuration, whether to log the response.

When the S-CSCF receives any response to the above request containing a "term-ioi" header field parameter in the P-Charging-Vector header field, the S-CSCF shall:

1) store the value of the received "term-ioi" header field parameter if present;

2) remove all received "orig-ioi", "term-ioi" and "transit-ioi" header field parameters from the forwarded response;

3) include the stored "orig-ioi" header field parameter if received in the request;

4) include a type 1 "term-ioi" header field parameter if next hop is not an AS, or a type 3 "term-ioi" header field parameter. The "term-ioi" header field parameter is set to a value that identifies the sending network of the response

NOTE 27: Any received "term-ioi" header field parameter will be a type 2 IOI, if received from an S-CSCF, or type 3 IOI, if received from an AS, or type 1 IOI if the S-CSCF performed loopback routeing for this request. A type 2 IOI identifies the sending network of the response, a type 3 IOI identifies the sending service provider of the response, and a type 1 IOI identifies the visited network of the served user.

5) include any received "transit-ioi" header field parameter, from the P-Charging-Vector header field, in a Relayed-Charge header field, if the next hop is an AS.

When the S-CSCF receives any 1xx or 2xx response to the initial request for a dialog, if the response corresponds to an INVITE request, the S-CSCF shall save the Contact and Record-Route header field values in the response in order to be able to release the session if needed.

When the S-CSCF receives any 1xx or 2xx response to an initial request for a dialog or a request for a standalone transaction, if the response is forwarded within the S-CSCF home network and not to an AS, the S-CSCF shall insert a P-Charging-Function-Addresses header field populated with values received from the HSS.

When the S-CSCF, upon sending an initial INVITE request that includes an IP address in the SDP offer (in "c=" parameter), receives an error response indicating that the IP address type is not supported, (e.g., the S-CSCF receives the 488 (Not Acceptable Here) with 301 Warning header field indicating "incompatible network address format"), the S-CSCF shall either:

- fork the initial INVITE request to the IBCF; or

- process the error response and forward it using the Via header field.

NOTE 28: If the S-CSCF knows that the originating UE supports both IPv6 and IPv4 addresses simultaneously, the S-CSCF will forward the error response to the UE using the Via header field.

Editor's Note: How the S-CSCF determines whether the UE supports both IPv6 and IPv4 addressing simultaneously is for further study.

When the S-CSCF receives from the served user a target refresh request for a dialog, prior to forwarding the request the S-CSCF shall:

0A) if the dialog is related to an IMS communication service determine whether the contents of the request (e.g. SDP media capabilities, Content-Type header field) match the IMS communication service as received as the ICSI value in the P-Asserted-Service header field in the initial request. As an operator option, if the contents of the request do not match the IMS communication service the S-CSCF may reject the request by generating a status code reflecting which added contents are not matching. Otherwise, continue with the rest of the steps;

1) remove its own URI from the topmost Route header field;

2) create a Record-Route header field containing its own SIP URI;

3) for INVITE dialogs (i.e. dialogs initiated by an INVITE request), save the Contact and CSeq header field values received in the request such that the S-CSCF is able to release the session if needed;

4) in case the request is routed towards the destination user (Request-URI) or in case the request is routed to an AS located outside the trust domain, remove the access-network-charging-info parameter in the P-Charging-Vector header field;

5) route the request based on the topmost Route header field; and

6) if the request was sent on a dialog for which logging of signalling is in progress, check whether a trigger for stopping logging of SIP signalling has occurred, as described in draft-dawes-sipping-debug [140]. If a stop trigger event has occurred then stop logging of signalling, else determine, by checking its debug configuration, whether to log the response.

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

When the S-CSCF receives any 1xx or 2xx response to the target refresh request for an INVITE dialog, the S-CSCF shall replace the saved Contact header field values in the response such that the S-CSCF is able to release the session if needed.

If the S-CSCF inserted in the initial request for the dialog the header field parameters into the Feature-Caps header field then the S-CSCF shall include the header field parameters with the same parameter values into the Feature-Caps header field in any target refresh request for the dialog, and in each 1xx or 2xx response to target refresh request sent in the same direction.

When the S-CSCF receives from the served user a subsequent request other than a target refresh request for a dialog, prior to forwarding the request the S-CSCF shall:

1) remove its own URI from the topmost Route header field;

2) in case the request is routed towards the destination user (Request-URI) or in case the request is routed to an AS located outside the trust domain, remove the access-network-charging-info parameter in the P-Charging-Vector header field; and

3) route the request based on the topmost Route header field; and

4) if the request was sent on a dialog for which logging of signalling is in progress, check whether a trigger for stopping logging of SIP signalling has occurred, as described in draft-dawes-sipping-debug [140]. If a stop trigger event has occurred, stop logging of signalling, else determine, by checking its debug configuration, whether to log the request.

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

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

5.4.3.3 Requests terminated at the served user

For all SIP transactions identified:

the S-CSCF shall give priority over other transactions or dialogs. This allows special treatment for such transactions or dialogs.

When the S-CSCF receives, destined for a registered served user, an initial request for a dialog or a request for a standalone transaction, and the request is received either from a functional entity within the same trust domain or contains a valid original dialog identifier or the dialog identifier (From, To and Call-ID header fields) relates to an existing request processed by the S-CSCF, then prior to forwarding the request, the S-CSCF shall:

1) check if an original dialog identifier that the S-CSCF previously placed in a Route header field is present in the topmost Route header field of the incoming request.

- If present, the request has been sent from an AS in response to a previously sent request.

- If not present, it indicates that the request is visiting the S-CSCF for the first time and in this case the S-CSCF shall determine the served user by taking the identity contained in the Request-URI. If the Request-URI is a temporary GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.3, then take the public user identity that is associated with the temporary GRUU to be the served user identity. Then check whether the determined served user identity is a barred public user identity. In case the served user identity is a barred public user identity for the user, then the S-CSCF shall reject the request by generating a 404 (Not Found) response. Otherwise, the S-CSCF shall save the Request-URI from the request, the served user identity and the public user identity of the served user and continue with the rest of the steps;

NOTE 2: An original dialog identifier is sent to each AS invoked due to iFC evaluation such that the S-CSCF can associate requests as part of the same sequence that trigger iFC evaluation in priority order (and not rely on SIP dialog information that can change due to B2BUA AS). If the same original dialog identifier is included in more than one request from a particular AS (based on service logic in the AS), then the S-CSCF will continue the iFC evaluation sequence rather than build a new ordered list of iFC;

2) remove its own URI from the topmost Route header field;

2A) if there was no original dialog identifier present in the topmost Route header field of the incoming request build an ordered list of initial filter criteria based on the public user identity in the Request-URI of the received request as described in 3GPP TS 23.218 [5].

3) if there was an original dialog identifier present in the topmost Route header field of the incoming request then check whether the Request-URI matches the saved Request-URI. The Request-URI and saved Request-URI are considered a match:

a) if the canonical forms of the two Request-URI are equal to the saved value of the Request-URI;

b) if the Request-URI is a GRUU (public or temporary) and the saved value of the Request-URI is a GRUU (public or temporary) and both GRUUs represent the same public user identity or represent public user identities that are alias SIP URIs of each other; or

c) if the Request-URI is an alias SIP URI of the saved value of the Request-URI.

NOTE 3: The canonical form of the Request-URI is obtained by removing all URI parameters (including the user-param), and by converting any escaped characters into unescaped form. The alias SIP URI is defined in subclause 3.1.

If there is no match, then the S-CSCF shall decide whether to trigger the originating services to be executed after retargeting. The decision is configured in the S-CSCF and may use any information in the received request that is used for the initial filter criteria or an operator policy. The S-CSCF shall decide either to:

a) stop evaluating current iFC. In that case, if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values received in the request such that the S-CSCF is able to release the session if needed, forward the request based on the topmost Route header field or if not available forward the request based on the Request-URI (routeing based on Request-URI is specified in steps 7 and 10 through 14a from subclause 5.4.3.2) and skip the following steps; or

b) stop evaluating current iFC and build an ordered list of iFC with the originating services to be executed after retargeting as described in 3GPP TS 23.218 [5] criteria based on the public user identity of the served user and start the evaluation of that iFC as described in subclause 5.4.3.2 starting at step 4B of subclause 5.4.3.2;

NOTE 4: The S-CSCF assesses triggering of services for the originating services after retargeting means it evaluates IFCs with a SessionCase set to ORIGINATING_CDIV, as defined in 3GPP TS 29.228 [14]. If the P-Served-User extension specified in RFC 5502 [133] is supported, the S-CSCF uses the "orig-cdiv" header field parameter defined in draft-mohali-dispatch-originating-cdiv-parameter [239].

NOTE 5: The identity of the served user can be obtained from the History-Info header field (see RFC 7044 [66]) or the P-Served User header field as specified in RFC 5502 [133]. The served user can be a public user identity, a public GRUU, or a temporary GRUU. It needs to be ensure, that all ASs in the iFC can determine the served user correctly.

NOTE 6: The S-CSCF determines whether to apply a) or b) based on information in the initial Filter Criteria.

3A) if the Request-URI is a GRUU, but is not valid as defined in subclause 5.4.7A.4, then return a 4xx response as specified in RFC 5627 [93];

3B) if the Request-URI contains a public GRUU and the saved value of the Request-URI is a temporary GRUU, then replace the Request-URI with the saved value of the Request-URI;

3C) if the request contains a P-Asserted-Service header field check whether the IMS communication service identified by the ICSI value contained in the P-Asserted-Service header field is allowed by the subscribed services for the served user:

a) if so, continue from step 4; and

b) if not, as an operator option, the S-CSCF may reject the request by generating a 403 (Forbidden) response. Otherwise, remove the P-Asserted-Service header field and continue with the rest of the steps;

3D) if the request does not contain a P-Asserted-Service header field check if the contents of the request matches a subscribed service (e.g. SDP media capabilities, Content-Type header field) for each and any of the subscribed services for the served user:

a) if not, as an operator option, the S-CSCF may reject the request by generating a 403 (Forbidden) response. Otherwise, continue with the rest of the steps; and

b) if so, and if the request is related to an IMS communication service and the IMS communication service requires the use of an ICSI value then include a P-Asserted-Service header field in the request containing the ICSI value for the related IMS communication service, and use it as a header field in the initial request when matching initial filter criteria in step 4; and

c) if so, and if the request is related to an IMS communication service and the IMS communication service does not require the use of an ICSI value then continue without including an ICSI value; and

4) check whether the initial request matches any unexecuted initial filter criteria based on the public user identity of the served user in the priority order and apply the filter criteria on the SIP method as described in 3GPP TS 23.218 [5] subclause 6.5. If there is a match, then the S-CSCF shall select the first matching unexecuted initial filter criteria and:

a) if the Request-URI is a temporary GRUU as defined in subclause 5.4.7A.3, then replace the Request-URI with the public GRUU that is associated with the temporary GRUU (i.e. the public GRUU representing the same public user identity and instance ID as the temporary GRUU);

b) insert the AS URI to be contacted into the Route header field as the topmost entry followed by its own URI populated as specified in the subclause 5.4.3.4;

c) if the S-CSCF supports the P-Served-User extension as specified in RFC 5502 [133], insert the P-Served-User header field populated with the served user identity as determined in step 1. If required by operator policy, the S-CSCF shall:

- if the associated session case is "Terminating" as specified in 3GPP TS 29.228 [14], include the sescase header field parameter set to "term" and the regstate header field parameter set to "reg";

- if the associated session case is "Terminating_Unregistered" as specified in 3GPP TS 29.228 [14], include the sescase header field parameter set to "term" and the regstate header field parameter set to "unreg";

d) insert a type 3 "orig-ioi" header field parameter replacing any received "orig-ioi" header field parameter in the P-Charging-Vector header field. The type 3 "orig-ioi" header field parameter identifies the sending network of the request message. The S-CSCF shall not include the type 3 "term-ioi" header field parameter;

e) remove the "transit-ioi" header field parameter, if received;

f) based on operator policy insert a Relayed-Charge header field containing the value of the received "transit-ioi" header field parameter in the P-Charging-Vector header field; and

g) if an IP address associated with the served user and the AS SIP URI is stored as described in subclause 5.4.0 exists, then the S-CSCF forwards the SIP message to the IP address associated with the served user and the AS SIP URI;

NOTE 7: Depending on the result of the previous process, the S-CSCF can contact one or more AS(s) before processing the outgoing Request-URI.

NOTE 8: If the Request-URI of the received terminating request contains a temporary GRUU, then step 4 replaces the Request-URI with the associated public GRUU before invoking the AS, and step 3B restores the original temporary GRUU when the request is returned from the AS.

NOTE 9: An AS can activate or deactivate its own filter criteria via the Sh interface. As the S-CSCF checks initial filter criteria only on receipt of an initial request for a dialog, or a standalone transaction, a modified service profile will have no impact on transactions or dialogs already in progress and the modified profile will be effective only for new transactions and dialogs. If the S-CSCF receives a modification of the iFC during their execution, then it should not update the stored initial Filter Criteria until the iFC related to the initial request have been completely executed.

5) if there was no original dialog identifier present in the topmost Route header field of the incoming request insert a P-Charging-Function-Addresses header field, if not present, populated with values received from the HSS if the message is forwarded within the S-CSCF home network, including towards AS;

7) if there was no original dialog identifier present in the topmost Route header field of the incoming request:

- store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field, if present;

- remove received "orig-ioi", "term-ioi" and "transit-ioi" header field parameters from the forwarded request if next hop is not an AS;

- include a type 1 "orig-ioi" header field parameter if next hop is not an AS; and

- remove any received Relayed-Charge header field;

NOTE 10: Any received "orig-ioi" header field parameter will be a type 2 IOI. or type 3 IOI. A type 2 IOI identifies the sending network of the request message, a type 3 IOI identifies the sending service provider of the request message.

7A) if there was an original dialog identifier present in the topmost Route header field of the incoming request:

- store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field, if present;

- remove the received "orig-ioi" header field parameter if next hop is not an AS; and

- include a type 1 "orig-ioi" header field parameter if next hop is not an AS;

NOTE 11: Any received "orig-ioi" header field parameter will be a type 3 IOI. A type 3 IOI identifies the sending service provider of the request message.

8) in the case:

i) there are no Route header fields in the request; and

ii) there are bindings saved during registration or re-registration as described in subclause 5.4.1.2 which are not marked as created by an emergency registration as described in subclause 5.4.8.2;

then, create a target set of potential routes from the list of preloaded routes associated with the bindings in item 8) ii), as follows:

a) if the Request-URI contains a valid GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.4 that does not contain a "bnc" URI parameter, then the target set is determined by following the procedures for Request Targeting specified in RFC 5627 [93], using the public user identity and instance ID derived from the GRUU using the procedures of subclause 5.4.7A;

b) if the Request-URI contains a valid public GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.4 that contains a "bnc" URI parameter then the target set is determined by following the procedures for routeing of public GRUUs specified in RFC 6140 [191].

NOTE 12: The procedures for Request Targeting for public GRUUs in subclause 7.1.1 of RFC 6140 [191] involve copying the "sg" SIP URI parameter from the Public GRUU into the Request-URI along with the bound registered Contact Address.

NOTE 13: In this release of the specification, use of preloaded routes saved during registration or re-registration which created or refreshed bindings marked as created by an emergency registration is out of scope.

c) if the Request-URI contains a temporary GRUU not assigned by the S-CSCF but that contains "temp-gruu-cookie" information provided by the S-CSCF to the UE in a "temp-gruu-cookie" header field parameter as specified in RFC 6140 [191] then the target set is determined by following the procedures for Request Targeting for temporary GRUUs specified in RFC 6140 [191]; or

NOTE 14: The procedures for obtaining the "temp-gruu-cookie" information from the temporary GRUU and for routeing of temporary GRUUs are specified in subclause 7.1.2.3 of RFC 6140 [191].

d) if the Request-URI contains a public user identity or a GRUU not assigned by the S-CSCF, then the target set is all the registered contacts saved for the destination public user identity;

9) if necessary perform the caller preferences to callee capabilities matching according to RFC 3841 [56B] to the target set;

NOTE 15: This might eliminate entries and reorder the target set.

NOTE 16: The S-CSCF performs caller preferences to callee capabilities matching also to select among multiple targets set to a single instance-id, when the UE has registered multiple registration flows.

10) in case there are no Route header fields in the request:

a) if there is more than one route in the target set determined in steps 8) and 9) above:

- if the fork directive in the Request-Disposition header field was set to "no-fork", use the contact with the highest qvalue parameter to build the target URI. In case no qvalue parameters were provided, the S-CSCF shall decide locally what contact address to be used to build the target URI;

- if the fork directive in the Request-Disposition header field was not set to "no-fork", fork the request or perform sequential search based on the relative preference indicated by the qvalue parameter of the Contact header field in the REGISTER request, as described in RFC 3261 [26]. In case no qvalue parameters were provided, then the S-CSCF determine the contact address to be used to build the target URI as directed by the Request-Disposition header field as described in RFC 3841 [56B]. If the Request-Disposition header field is not present, the S-CSCF shall decide locally whether to fork or perform sequential search among the contact addresses;

- in case that no route is chosen, return a 480 (Temporarily unavailable) response or another appropriate unsuccessful SIP response and terminate these procedures; and

- per the rules defined in RFC 5626 [92], the S-SCSF shall not populate the target set with more than one contact with the same public user identity and instance-id at a time. If a request for a particular public user identity and instance-id fails with a 430 response, the S-CSCF shall replace the failed branch with another target with the same public user identity and instance-id, but a different reg-id;

b) If no "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in 3GPP TS 29.228 [14] has been received, in the service profile of the served public user identity, from the HSS during registration, build the Request-URI with the contents of the target URI determined in the previous step, otherwise the Request-URI is retained as received;

c) insert a P-Called-Party-ID SIP header field containing the contents of the Request-URI (if no "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in 3GPP TS 29.228 [14] has been received, in the service profile of the served public user identity, from the HSS during registration, then exclude "rn" tel-URI parameter and "npdi" tel-URI parameter as defined in RFC 4694 [112]) received in the request unless the Request-URI contains a temporary GRUU in which case insert the public GRUU in the P-Called-Party-ID;

d) build the Route header field with the Path values from the chosen route and if "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in 3GPP TS 29.228 [14] has been received, in the service profile of the served user identity, from the HSS during registration and the selected contact address was not registered as described in RFC 5626 [92], add the content of the target URI determined in step a), as last URI of the route. If the selected contact address was registered as described in RFC 5626 [92], the target URI determined in step a) is not added to the Route header field; and

e) save the Request-URI and the total number of Record-Route header fields as part of the dialog request state.

NOTE 17: For each initial dialog request terminated at a served user two pieces of state are maintained to assist in processing GRUUs: the chosen contact address to which the request is routed; and the position of an entry for the S-CSCF in the Record-Route header field that will be responsible for GRUU translation, if needed (the position is the number of entries in the list before the entry was added). The entry will be added in step 5) of the below procedures for handling S-CSCF receipt any 1xx or 2xx response to the initial request for a dialog. The S-CSCF can record-route multiple times, but only one of those (the last) will be responsible for gruu translation at the terminating end.

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

12) optionally, apply any privacy required by RFC 3323 [33] and RFC 3325 [34] to the P-Asserted-Identity header field and privacy required by RFC 7044 [66]. The S-CSCF shall not remove any priv-value from the Privacy header field;

NOTE 18: keeping the priv-value in the Privacy header field is necessary to indicate to the UE that the public user identity was not sent because of restriction. Although RFC 3323 [33] states that when a privacy service performs one of the functions corresponding to a privacy level listed in the Privacy header field, it SHOULD remove the corresponding priv-value from the Privacy header field, there is no harm that the S-CSCF does not remove the priv-values as there will be no other entity that would perform the privacy service after the S-CSCF.

NOTE 19: The optional procedure above is in addition to any procedure for the application of privacy at the edge of the trust domain specified by RFC 3325 [34].

13) in case of an initial request for a dialog, either:

- if the request is routed elsewhere, create a Record-Route header field containing its own SIP URI;

13A) if the request is routed towards the UE remove the P-User-Database header field and P-Served-User header field if present;

13B) if the request is sent on a dialog for which logging of signalling is not in progress, and the request contains a P-Debug-ID header field, remove the P-Debug-ID header field before forwarding the request;

13C) if the request was sent on a dialog for which logging of signalling is in progress, check whether a trigger for stopping logging of SIP signalling has occurred, as described in draft-dawes-sipping-debug [140]. If a stop trigger event has occurred, stop logging of signalling, else determine, by checking its debug configuration, whether to log the request;

13D) if the request is routed towards the UE,

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

- the UE is roaming; and

- required by local policy;

then:

- 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 an "iotl" SIP URI parameter set to "homeB-visitedB" 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 an "iotl" SIP URI parameter set to "homeB-visitedB" to the URI of the second Route header field from the bottom;

NOTE 20: The bottommost Route header field contains an "iotl" SIP URI parameter if the P‑CSCF added the "iotl" SIP URI parameter in the Path header field during registration and if the visited network does not apply topology hiding. The second Route header field from the bottom contains an "iotl" SIP URI parameter if the P‑CSCF added the "iotl" SIP URI parameter in the Path header field during registration and if the visited network applied topology hiding.

13E) if the S-CSCF supports HSS based P-CSCF restoration and the S-CSCF considers the P-CSCF, identified by the bottommost Route header field, is not reachable:

- reject the request with a 480 (Temporarily Unavailable) response; and

- initiate the HSS based P-CSCF restoration procedure towards the served user as specified in 3GPP TS 23.380 [7D];

13F) if the S-CSCF supports PCRF based P-CSCF restoration procedures, insert a Restoration-Info header field including the IMSI value contained in the user profile of the registered served user as a quoted string defined in 3GPP TS 29.228 [14];

NOTE 21: If PCRF based P-CSCF restoration procedure is operated between the home network and the visited network, the operator policy depends on an agreement with the visited network operator.

13G) if the S-CSCF supports PCRF based P-CSCF restoration procedures,

- the request contains a topmost Route header field pointing to a P-CSCF, and

- the S-CSCF considers the P-CSCF is in a non-working state,

remove all entries in the Route header field and add a Route header field set to the URI associated with an alternative P-CSCF; and

NOTE 22: How the SIP URI of the alternative P-CSCF is obtained by the S-CSCF is implementation dependent. The S-CSCF can make sure that selected P-CSCF support the PCRF based P-CSCF restoration procedures based on local configuration.

NOTE 23: It is implementation dependent as to how the S-CSCF determines the P-CSCF is in non-working state.

14) forward the request based on the topmost Route header field.

If the S-CSCF receives any response to the above request, the S-CSCF shall:

If the S-CSCF supports HSS based P-CSCF restoration and

a) receives a 404 (Not Found) response;

b) fails to receive any SIP response from a P-CSCF serving a non-roaming user within a configurable time; or

NOTE 24: The configurable time needs to be less than timer B and timer F.

c) receives a 408 (Request Timeout) response or a 504 (Server Time-out) response:

- including a Restoration-Info header field defined in subclause 7.2.11 set to "noresponse"; and

- the "+g.3gpp.ics" Contact header field parameter with a value set to "server" was not included in the REGISTER request when the UE registered;

NOTE 25: If this Contact header field parameter is not included the S-CSCF can deduce that the P-CSCF did not respond to the request.

the S-CSCF shall:

- send a 480 (Temporarily Unavailable) response;

- initiate the HSS based P-CSCF restoration procedure towards the served user as specified in 3GPP TS 23.380 [7D]; and

- if b) or c) above applied consider the P-CSCF as not reachable.

If the S-CSCF supports PCRF based P-CSCF restoration and receives a 404 (Not Found) response, the S-CSCF shall consider the P-CSCF to be in a non-working state and shall initiate the PCRF based P-CSCF restoration procedure towards the served user as specified in 3GPP TS 23.380 [7D].

If the S-CSCF:

a) fails to receive a SIP response within a configurable time; or

the S-CSCF shall:

- if the default handling defined in the filter criteria indicates the value "SESSION_TERMINATED" as specified in 3GPP TS 29.228 [14], either forward the received response or, if the request is an initial INVITE request, send a 408 (Request Timeout) response or a 5xx response towards the originating UE as appropriate (without verifying the matching of filter criteria of lower priority and without proceeding for further steps).

If the S-CSCF receives any final response from the AS, the S-CSCF shall forward the response towards the originating UE (without verifying the matching of filter criteria of lower priority and without proceeding for further steps).

When the S-CSCF receives any response to the above request and forwards it to an AS, the S-CSCF shall remove any "orig-ioi", "term-ioi" and "transit-ioi" header field parameter if received in a P-Charging-Vector header field, insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the request, a type 3 "term-ioi" header field parameter, and based on operator option insert a Relayed-Charge header field in the response. The S-CSCF shall set the type 3 "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 include in the Relayed-Charge header field the received "transit-ioi" header field parameter from the P-Charging-Vector header field.

NOTE 26: Any received "term-ioi" header field parameter will be a type 1 IOI or a type 3 IOI. The type 1 IOI identifies the network from which the response was sent and the type 3 IOI identifies the service provider from which the response was sent.

When the S-CSCF receives, destined for an unregistered served user or a statically pre-configured PSI, an initial request for a dialog or a request for a standalone transaction, the S-CSCF shall:

1) Void.

2) execute the procedures described in 1, 2, 3, 3C, 3D, 4, 5, 6, 7, 11, 13, 13B, 13C and 14 in the above paragraph (when the S-CSCF receives, destined for the registered served user, an initial request for a dialog or a request for a standalone transaction).

3) In case that no more AS needs to be contacted, then S-CSCF shall return an appropriate unsuccessful SIP response. This response may be a 480 (Temporarily unavailable) and terminate these procedures.

NOTE 27: When the S-CSCF does not have the user profile, before executing the actions as listed above, it initiates the S-CSCF Registration/deregistration notification procedure, as described in 3GPP TS 29.228 [14]; with the purpose of downloading the relevant user profile (i.e. for unregistered user) and informs the HSS that the user is unregistered. The S-CSCF will assess triggering of services for the unregistered user, as described in 3GPP TS 29.228 [14]. When requesting the user profile the S-CSCF can include the information in the P-Profile-Key header field in S-CSCF Registration/deregistration notification. When requesting the user profile, and the request received by the S-CSCF contains a P-Profile-Key header field, the S-CSCF can include the header field value in S-CSCF Registration/deregistration notification. If the response from the HSS includes a Wildcarded Public Identity AVP, and if the request received by the S-CSCF did not include a P-Profile-Key header field, the S-CSCF uses the AVP value to set the P-Profile-Key header field before forwarding the request to an AS.

Prior to performing S-CSCF Registration/Deregistration procedure with the HSS, the S-CSCF decides which HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 3GPP TS 29.228 [14] or use the value as received in the P-User-Database header field in the initial request for a dialog or a request for a standalone transaction as defined in RFC 4457 [82]. The HSS address received in the response to SLF query can be used to address the HSS of the public user identity with further queries.

If the HSS indicates to the S-CSCF that there is already another S-CSCF assigned for the user, the S-CSCF shall return a 305 (Use Proxy) response containing the SIP URI of the assigned S-CSCF received from the HSS in the Contact header field.

When the S-CSCF receives any response to the above request containing a Relayed-Charge header field, and the next hop is not an AS, the S-CSCF shall remove the Relayed-Charge header field.

When the S-CSCF receives any 1xx or 2xx response to the initial request for a dialog (whether the user is registered or not), the S-CSCF shall:

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

2) if the response is not forwarded to an AS (i.e. the response is related to a request that was matched to the first executed initial filter criteria):

a) remove the received "transit-ioi" header field parameter if present and insert a type 2 "term-ioi" header field parameter in the P-Charging-Vector header field of the outgoing response. The type 2 "term-ioi" header field is set to a value that identifies the sending network of the response and the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter. Values of "orig-ioi" and "term-ioi" header field parameters in the received response are removed; and

b) if the S-CSCF supports using a token to identify the registration, remove the "+g.3gpp.registration-token" Feature-Caps header field parameter, defined in subclause 7.9A.8, if received in the response;

3) in case the served user is not considered a privileged sender then:

a) if the P-Asserted-Identity header field contains only a SIP URI and in the case where the S-CSCF has knowledge that the SIP URI contained in the received P-Asserted-Identity header field is an alias SIP URI for a tel URI, the S-CSCF shall add a second P-Asserted-Identity header field containing this tel URI, including the display name associated with the tel URI, if available; and

4) in case the response is sent towards the originating user, the S-CSCF may retain the P-Access-Network-Info header field based on local policy rules and the destination user (Request-URI);

5) save an indication that GRUU routeing is to be performed for subsequent requests sent within this same dialog if:

a) there is a record-route position saved as part of the initial dialog request state; and

b) the contact address in the response is a valid GRUU assigned by the S-CSCF as specified in subclause 5.4.7A.4 or a temporary GRUU self assigned by the UE based on the "temp-gruu-cookie" header field parameter provided to the UE;

6) if the S-CSCF supports using a token to identify the registration and if a registration exists, add a "+g.3gpp.registration-token" Feature-Caps header field parameter, as defined in subclause 7.9A.8, set to the same value as included in the "+g.3gpp.registration-token" Contact header field parameter of the third party REGISTER request sent to the AS when the UE registered; and

NOTE 28: There could be several responses returned for a single request, and the decision to insert or modify the Record-Route needs to be applied to each. But a response might also return to the S-CSCF multiple times as it is routed back through AS. The S-CSCF will take this into account when carrying out step 5) to ensure that the information is stored only once.

7) if the response is forwarded within the S-CSCF home network and not to an AS, insert a P-Charging-Function-Addresses header field populated with values received from the HSS.

When the S-CSCF receives a response to a request for a standalone transaction (whether the user is registered or not), then:

1) in case the served user is not considered a privileged sender then:

2) in case the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the access-network-charging-info parameter in the P-Charging-Vector header field; otherwise, the S-CSCF shall remove the access-network-charging-info parameter in the P-Charging-Vector header field.

When the S-CSCF receives the 200 (OK) response for a standalone transaction request, the S-CSCF shall:

1) insert a P-Charging-Function-Addresses header field populated with values received from the HSS if the message is forwarded within the S-CSCF home network, including towards an AS;

1A) if the S-CSCF supports using a token to identify the registration and if a registration exists, add a "+g.3gpp.registration-token" Feature-Caps header field parameter, as defined in subclause 7.9A.8, set to the same value as included in the "+g.3gpp.registration-token" Contact header field parameter of the third party REGISTER request sent to the AS when the UE registered;

1B) if the S-CSCF supports using a token to identify the registration in case the response is not forwarded to an AS the S-CSCF shall remove the "+g.3gpp.registration-token" Feature-Caps header field parameter, defined in subclause 7.9A.8, if received in the response; and

2) if the response is not forwarded to an AS (i.e. the response is related to a request that was matched to the first executed initial filter criteria), remove the received "orig-ioi", "term-ioi" and "transit-ioi" header field parameter if present and insert a type 2 "term-ioi" header field parameter in the P-Charging-Vector header field of the outgoing response. The type 2 "term-ioi" header field parameter is set to a value that identifies the sending network of the response and the type 2 "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter.

NOTE 29: If the S-CSCF forked the request of a stand alone transaction to multiple UEs and receives multiple 200 (OK) responses, the S-CSCF will select and return only one 200 (OK) response. The criteria that the S-CSCF employs when selecting the 200 (OK) response is based on the operator's policy (e.g. return the first 200 (OK) response that was received).

When the S-CSCF receives, destined for a served user, a target refresh request for a dialog, prior to forwarding the request, the S-CSCF shall:

0) if the dialog is related to an IMS communication service determine whether the contents of the request (e.g. SDP media capabilities, Content-Type header field) match the IMS communication service as received as the ICSI value in the P-Asserted-Service header field in the initial request. As an operator option, if the contents of the request do not match the IMS communication service the S-CSCF may reject the request by generating a status code reflecting which added contents are not matching. Otherwise, continue with the rest of the steps;

1) if the incoming request is received on a dialog for which GRUU routeing is to be performed and the Request-URI is not the GRUU for this dialog, then return a response of 400 (Bad Request).

2) if the incoming request is received on a dialog for which GRUU routeing is to be performed and the Request-URI contains the GRUU for this dialog then:

i) if the Request-URI contains a valid GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.4 that does not contain a "bnc" URI parameter, then perform the procedures for Request Targeting specified in RFC 5627 [93], using the public user identity and instance ID derived from the Request-URI, as specified in subclause 5.4.7A;

ii) if the Request-URI contains a valid public GRUU assigned by the S-CSCF as defined in subclause 5.4.7A.4 that contains a "bnc" URI parameter then the target set is determined by following the procedures for routeing of public GRUUs specified in RFC 6140 [191]. or

NOTE 30: The procedures for Request Targeting for public GRUUs in subclause 7.1.1 of RFC 6140 [191] involve copying the "sg" SIP URI parameter from the Public GRUU into the Request-URI along with the bound registered Contact Address.

iii) if the Request-URI contains a temporary GRUU not assigned by the S-CSCF but that contains "temp-gruu-cookie" information provided by the S-CSCF to the UE in a "temp-gruu-cookie" header field parameter as specified in RFC 6140 [191] then the target set is determined by following the procedures for routeing of temporary GRUUs specified in RFC 6140 [191];

NOTE 31: The procedures for obtaining the "temp-gruu-cookie" information from the temporary GRUU and for routeing of temporary GRUUs are specified in subclause 7.1.2.3 of RFC 6140 [191].

iv) if no contact can be selected, return a response of 480 (Temporarily Unavailable);

3) remove its own URI from the topmost Route header field;

4) for INVITE dialogs (i.e. dialogs initiated by an INVITE request), save the Contact and CSeq header field values received in the request such that the S-CSCF is able to release the session if needed;

5) create a Record-Route header field containing its own SIP URI;

5A) if the request is sent on a dialog for which logging of signalling is not in progress, and the request contains a P-Debug-ID header field, remove the P-Debug-ID header field before forwarding the request;

5B) if the request was sent on a dialog for which logging of signalling is in progress, check whether a trigger for stopping logging of SIP signalling has occurred, as described in draft-dawes-sipping-debug [140]. If a stop trigger event has occurred, stop logging of signalling, else determine, by checking its debug configuration, whether to log the request; and

6) forward the request based on the topmost Route header field.

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

When the S-CSCF receives any 1xx or 2xx response to the target refresh request for a dialog (whether the user is registered or not), the S-CSCF shall:

1) for INVITE dialogs, replace the saved Contact header field values in the response such that the S-CSCF is able to release the session if needed; and

When the S-CSCF receives, destined for the served user, a subsequent request other than target refresh request for a dialog, prior to forwarding the request, the S-CSCF shall:

1) if the incoming request is received on a dialog for which GRUU routeing is to be performed and the Request-URI is not the GRUU for this dialog, then return a response of 400 (Bad Request).

2) if the incoming request is received on a dialog for which GRUU routeing is to be performed and the Request-URI contains the GRUU for this dialog then:

NOTE 32: The procedures for Request Targeting for public GRUUs in subclause 7.1.1 of RFC 6140 [191] involve copying the "sg" SIP URI parameter from the Public GRUU into the Request-URI along with the bound registered Contact Address.

NOTE 33: The procedures for obtaining the "temp-gruu-cookie" information from the temporary GRUU and for routeing of temporary GRUUs are specified in subclause 7.1.2.3 of RFC 6140 [191].

iv) if no contact can be selected, return a response of 480 (Temporarily Unavailable).

3) remove its own URI from the topmost Route header field;

3A) if the request is sent on a dialog for which logging of signalling is not in progress, and the request contains a P-Debug-ID header field, remove the P-Debug-ID header field before forwarding the request;

3B) if the request was sent on a dialog for which logging of signalling is in progress, check whether a trigger for stopping logging of SIP signalling has occurred, as described in draft-dawes-sipping-debug [140]. If a stop trigger event has occurred, stop logging of signalling, else determine, by checking its debug configuration, whether to log the request; and

4) forward the request based on the topmost Route header field.

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

When the S-CSCF receives a response to a a subsequent request other than target refresh request for a dialog, in case the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the access-network-charging-info parameter from the P-Charging-Vector header field; otherwise, the S-CSCF shall remove the access-network-charging-info parameter from the P-Charging-Vector header field.

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

5.4.3.4 Original dialog identifier

The original dialog identifier is an implementation specific token that the S-CSCF encodes into the own S-CSCF URI in a Route header field, prior to forwarding the request to an AS. This is possible because the S-CSCF is the only entity that creates and consumes the value.

The token may identify the original dialog of the request, so in case an AS acting as a B2BUA changes the dialog, the S-CSCF is able to identify the original dialog when the request returns to the S-CSCF. In a case of a standalone transaction, the token indicates that the request has been sent to the S-CSCF from an AS in response to a previously sent request. The token can be encoded in different ways, such as e.g., a character string in the user-part of the S-CSCF URI, a parameter in the S‑CSCF URI or port number in the S-CSCF URI.

The S-CSCF shall ensure that the value chosen is unique so that the S-CSCF may recognize the value when received in a subsequent message of one or more dialogs and make the proper association between related dialogs that pass through an AS.

An original dialog identifier is sent to each AS invoked due to iFC evaluation such that the S-CSCF can associate requests as part of the same sequence that trigger iFC evaluation in priority order (and not rely on SIP dialog information that may change due to B2BUA AS).

NOTE: If the same original dialog identifier is included in more than one request from a particular AS (based on service logic in the AS), then the S-CSCF will continue the iFC evaluation sequence. If the AS wants iFC evaluation to start from the beginning for a request, then AS should not include an original dialog identifier;

5.4.3.5 Void

5.4.3.6 SIP digest authentication procedures for all SIP request methods initiated by the UE excluding REGISTER

5.4.3.6.1 General

When the S-CSCF receives from the UE a request (excluding REGISTER), and SIP digest without TLS or SIP digest with TLS is supported and in use for this UE, the S-CSCF may perform the following steps if authentication of SIP request methods initiated by the UE excluding REGISTER is desired:

1) The S-CSCF shall identify the user by the public user identity as received in the P-Asserted-Identity header field;

2) If the public user identity does not match one of the registered public user identities, and the public user identity does not match one of the registered wildcarded public user identities, the S-CSCF may reject the request with a 400 (Bad Request) response or silently discard the request;

3) If the request does not contain a Proxy-Authorization header field or the Proxy-Authorization header field does not contain a digest response, the S-CSCF shall:

a) challenge the user by generating a 407 (Proxy Authentication Required) response for the received request, including a Proxy-Authenticate header field as defined in RFC 2617 [21], which includes:

- a "realm" header field parameter;

- a "nonce" header field parameter, with a newly generated value by the S-CSCF;

- an "algorithm" header field parameter; if the algorithm value is not provided in the authentication vector, it shall have the value "MD5"; and

- a "qop" header field parameter; if the qop value is not provided in the authentication vector, it shall have the value "auth".

The challenge parameters, with the exception of the "nonce" header field parameter, shall be the same as the ones used for the last successfull registration.

NOTE 1: The usage of the same parameters for authentication of non-registration SIP requests requires the storage of these parameters during authentication of REGISTER requests, as retrieval of authentication vectors is only specified for REGISTER requests.

b) send the so generated 407 (Proxy Authentication Required) response towards the UE;

c) retain the nonce and initialize the corresponding nonce count to a value of 1; and

d) start timer request-await-auth.

4) If the request contains a Proxy-Authorization header field, the S-CSCF shall:

a) check whether the Proxy-Authorization header field contains:

- the private user identity of the user in the "username" header field parameter;

- an "algorithm" header field parameter value which matches the "algorithm" header field parameter in the authentication challenge (i.e. "MD5");

- a "response" header field parameter with the authentication challenge response;

- a "realm" header field parameter matching the "realm" header field parameter in the authentication challenge;

- "nonce" header field parameter matching a nonce that is deemed valid by the S-CSCF for the related registration or registration flow (i.e. a nonce that was set in a a Proxy-Authenticate header field of a 407 (Proxy Authentication Required) response to a non-REGISTER request for which the associated validity duration has not expired or in a WWW-Authenticate header field of a 401 (Unauthorized) response to a REGISTER request for which the associated validity duration has not expired, a nonce sent in a "nextnonce" header field parameter sent in a Authentication-Info header field of a 200 OK (OK) to REGISTER request ) or if an authentication is ongoing for this request (i.e. a associated "req-await-auth" is running) matching the nonce that was sent in a Proxy-Authenticate header field of the 407 (Proxy Authentication Required) response to this request;

NOTE 2: The related registration flow or registration is identified by the couple instance-id and reg-id if the multiple registration mechanism is used or by contact address if not.

- a "uri" header field parameter matching the SIP Request-URI;

- a "cnonce" header field parameter; and

- a "nonce-count" header field parameter with a value that equals the nonce-count expected by the S-CSCF. The S-CSCF may choose to accept a nonce-count which is greater than the expected nonce-count. If the S-CSCF uses this nonce-count and authentication is successful and the S-CSCF increments it for any subsequent authentication responses.

If any of the above checks do not succeed, the S-CSCF shall proceed as described in subclause 5.4.3.6.2, and skip the remainder of this procedure; and

b) check whether the received authentication challenge response and the expected authentication challenge response match. The S-CSCF shall compute the expected digest response as described in RFC 2617 [21] using the H(A1) value contained within the authentication vector, and other digest parameters (i.e. nonce, cnonce, nonce-count, qop).

In the case where the digest response does not match the expected digest response calculated by the S-CSCF, the S-CSCF shall consider the authentication attempt as failed and do one of the following:

1) rechallenge the user by issuing a 407 (Proxy Authentication Required) response including a challenge as per procedures described in this subclause; or

2) reject the request by issuing a 403 (Forbidden) response; or

3) reject the request without sending a response.

In the case where the digest response matches the expected digest response calculated by the S-CSCF, the S-CSCF shall:

1) consider the identity of the user verified and the request authenticated and continue with the procedures as described in subclause 5.4.3;

2) if the used nonce was not considered valid before the authentication succed (i.e a "req-await-auth" was running), add this nonce to the list of the valid nonces for the related registration or registration flow (if multiple registration mechanism is used) for an operator configured duration; and

3) stop the related "request-await-auth" running if any.

If the timer request-await-auth expires, the S-CSCF shall consider the authentication to have failed.

5.4.3.6.2 Abnormal cases

In the case that SIP digest is used and the request from the UE contains an invalid "nonce" Authorization header field parameter with a valid challenge response for that nonce (indicating that the client knows the correct username/password), or when the "nonce-count" Authorization header field parameter value sent by the UE is not the expected value, or when the Proxy-Authorization header field does not include the correct parameters, the S-CSCF shall:

- send a 407 (Proxy Authentication Required) response to initiate a further authentication attempt with a fresh nonce and the "stale" header field parameter set to "true" in the Proxy-Authenticate header field.

When the S-CSCF cannot forward an initial incoming request to an Application Server due to overload control mechanism, it shall either

- if the default handling defined in the filter criteria indicates the value "SESSION_CONTINUED" as specified in 3GPP TS 29.228 [14] or no default handling is indicated, execute the procedure from step 5 in subclause 5.4.3.2 or from step 4 in subclause 5.4.3.3 depending on the type of request; and

- if the default handling defined in the filter criteria indicates the value "SESSION_TERMINATED" as specified in 3GPP TS 29.228 [14], reject the request as specified in RFC 7339 [199] and RFC 7200 [201] (without verifying the matching of filter criteria of lower priority and without proceeding for further steps).

5.4.4 Call initiation

5.4.4.1 Initial INVITE

When the S-CSCF receives an INVITE request, either from the served user or destined to the served user, the S-CSCF may require the periodic refreshment of the session to avoid hung states in the S-CSCF. If the S-CSCF requires the session to be refreshed, the S-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.

For interworking with a visiting network, where the P-CSCF of the visiting network does not support priority but it is intended or required to give users of that P-CSCF priority in the home network, the S-CSCF in the home network shall recognize the need for priority treatment if such detection is not alternately provided via an IBCF in the home network.

NOTE 2: 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.

When an S-CSCF interworks with a visiting network that does not support priority, and the S-CSCF recognizes the need for priority treatment, the S-CSCF shall insert the temporarily authorised Resource-Priority header field with appropriate namespace and priority value in the INVITE request.

When the S-CSCF receives an initial INVITE request destined for the served user, the S-CSCF shall either:

a) examine the SDP offer (the "c=" parameter) to detect if it contains an IP address type that is not supported by the IM CN subsystem; or

NOTE 3: The S-CSCF can, based on local policy, assume that a UE supports the IP address type of the SDP offer for media if it is identical to the address type of a contact that the UE has registered.

b) process the initial INVITE request without examining the SDP.

NOTE 4: If the S-CSCF knows that the terminating UE supports both IPv6 and IPv4 addressing simultaneously, the S-CSCF will forward the initial INVITE request to the UE without examining the SDP.

Editor's Note: How the S-CSCF determines whether the UE supports both IPv6 and IPv4 addressing simultaneously is for further study.

NOTE 5: If the SDP offer contained an IP address type that is not supported by the IM CN subsystem, the S-CSCF will receive the 488 (Not Acceptable Here) response with 301 Warning header field indicating "incompatible network address format".

Subsequently, when the S-CSCF detects that the SDP offer contained an IP address type that is not supported by the IM CN subsystem (i.e., either case a) or b)), the S-CSCF shall either:

- return a 305 (Use Proxy) response to the I-CSCF with the Contact field containing the SIP URI of the IBCF, or

- forward the initial INVITE request to the IBCF. When forwarding the initial INVITE request, the S-CSCF shall not insert its SIP URI into the Record-Route header field.

If overlap signalling using the multiple-INVITE method is supported as a network option, several INVITE requests with the same Call ID and the same From header field (including "tag" header field parameter) can be received outside of an existing dialog. Such INVITE requests relate to the same call. If the S-CSCF receives an INVITE request from the served user outside an existing dialog with the same Call ID and From header field as a previous INVITE request during a certain period of time, it shall route the new INVITE request to the same next hop as the previous INVITE request.

Editor’s note [CR 4476, WI EMC_PC]: It is FFS how the S-CSCF processes a terminating request towards a Public User Identity that was only registered with IMS using an emergency bearer, even if the request includes a Priority header field with the "psap-callback" header field value.

5.4.4.2 Subsequent requests

5.4.4.2.1 UE-originating case

When the S-CSCF receives the request containing the access-network-charging-info parameter in the P-Charging-Vector, the S-CSCF shall store the access-network-charging-info parameter from the P-Charging-Vector header field. The S-CSCF shall retain access-network-charging-info parameter in the P-Charging-Vector header field when the request is forwarded to an AS. However, the S-CSCF shall not include the access-network-charging-info parameter in the P-Charging-Vector header field when the request is forwarded outside the home network of the S-CSCF.

When the S-CSCF receives any request or response (excluding CANCEL requests and responses) related to a UE-originated dialog or standalone transaction, the S-CSCF shall insert previously saved values into the P-Charging-Vector header field before forwarding the message within the S-CSCF home network, including towards AS.

When the S-CSCF receives any request or response (excluding ACK requests and CANCEL requests and responses) related to a UE-originated dialog or standalone transaction, the S-CSCF may insert previously saved values into the P-Charging-Function-Addresses header field before forwarding the message within the S-CSCF home network, including towards AS.

5.4.4.2.2 UE-terminating case

When the S-CSCF receives 180 (Ringing) or 200 (OK) (to INVITE) responses containing the access-network-charging-info parameter in the P-Charging-Vector, the S-CSCF shall store the access-network-charging-info parameter from the P-Charging-Vector header field. The S-CSCF shall retain the access-network-charging-info parameter in the P-Charging-Vector header field when the response is forwarded to an AS. However, the S-CSCF shall not include the access-network-charging-info parameter in the P-Charging-Vector header field when the response is forwarded outside the home network of the S-CSCF.

When the S-CSCF receives any request or response (excluding CANCEL requests and responses) related to a UE-terminated dialog or standalone transaction, the S-CSCF shall insert previously saved values into the P-Charging-Vector header field before forwarding the message within the S-CSCF home network, including towards AS.

When the S-CSCF receives any request or response (excluding ACK requests and CANCEL requests and responses) related to a UE-terminated dialog or standalone transaction, the S-CSCF may insert previously saved values into the P-Charging-Function-Addresses header field before forwarding the message within the S-CSCF home network, including towards AS.

When the S-CSCF receives an error response (to INVITE) for an existing early dialog, and if the S-CSCF does not forward the response immediately (if the S-CSCF forked the INVITE request it may wait for additional final responses), the S-CSCF does not have knowledge of having received an 199 (Early Dialog Terminated) provisional response on the same early dialog, and the associated INVITE request included the "199" option-tag in the Supported header field, and the INVITE request did not include the "100rel" option tag in the Require header field, the S-CSCF shall trigger and send an unreliable 199 (Early Dialog Terminated) provisional response, using the same "tag" To header field parameter value as the error response, as specified in RFC 6228 [142].

When the S-CSCF has forked an initial INVITE request, and it has received:

- a 2xx response associated with one of the early dialogs, the S-CSCF shall in each CANCEL request it generates as specified in RFC 3261 [26] insert a Reason header field with a "SIP" protocol header field parameter value, a "200" cause header field parameter value, and a "Call completed elsewhere" text header field parameter value, as specified in RFC 3326 [34A]; or

- a 6xx response associated with one of the early dialogs, the S-CSCF shall, in each CANCEL request it generates as specified in RFC 3261 [26] insert a Reason header field with "SIP" protocol header field parameter value, a cause header field parameter value representing the response code (e.g. "603") in the received response, and a text header field parameter with a value associated with the response code (e.g. a "Declined" value in the case of a "603" response code), as specified in RFC 3326 [34A].

5.4.5 Call release

5.4.5.1 S-CSCF-initiated session release

5.4.5.1.1 Cancellation of a session currently being established

Upon receipt of a network internal indication to release a session which is currently being established, the S-CSCF shall:

1) cancel the related dialogs by sending the CANCEL request according to the procedures described in RFC 3261 [26]; and

2) send an appropriate response to the sender of the original INVITE request.

5.4.5.1.2 Release of an existing session

Upon receipt of a network internal indication to release an existing multimedia session, the S-CSCF shall:

1) if the S-CSCF serves the calling user of the session, 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 CSeq value that was 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 proper SIP response code;

- further header fields, based on local policy;

- treat the BYE request as if received directly from the calling user, i.e. the S-CSCF shall send the BYE request to the internal service control and based on the outcome further on towards the called user; and

2) if the S-CSCF serves the calling user of the session, 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 contained either a public or a temporary GRUU, the S-CSCF shall set the Request-URI either to:

a) the contact address bound to the respective GRUU, if the stored Contact header field did not include an "ob" SIP URI parameter; or

b) the contact address that the UE used to send the initial INVITE request, if the stored Contact header field included an "ob" SIP URI parameter;

NOTE 1: Since the same public GRUU can be bound to multiple contact addresses of the UE that were registered as specified in RFC 5626 [92], the S-CSCF selects the contact address that the UE used to send the initial INVITE request.

- 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 CSeq value that was stored for the direction from the called to the calling user, incremented by one – if no CSeq value was stored for that session the S-CSCF shall generate and apply a random number within the valid range for CSeqs;

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

- a Reason header field that contains proper SIP response code;

- further header fields, based on local policy;

- send the BYE request directly to the calling user.

3) if the S-CSCF serves the called user of the session, generate a 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 that the S-CSCF uses to send the in-dialog requests towards the called UE as defined in RFC 5626 [92] and RFC 5627 [93];

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

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

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

- a CSeq header, set to the CSeq value that was stored for the direction from the calling to the called user, incremented by one;

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

- a Reason header that contains proper SIP response code;

- further headers, based on local policy;

- send the BYE request directly to the called user; and

4) if the S-CSCF serves the called user of the session, 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 the stored Contact header field provided by the calling user;

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

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

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

- a CSeq header, set to the CSeq value that was stored for the direction from the called to the calling user, incremented by one – if no CSeq value was stored for that session the BYE shall generate and apply a random number within the valid range for CSeqs;

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

- a Reason header field that contains proper SIP response code;

- further headers, based on local policy;

- treat the BYE request as if received directly from the called user, i.e. the S-CSCF shall send the BYE request to the internal service control and based on the outcome further on towards the calling user..

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

5.4.5.1.2A Release of the existing dialogs due to registration expiration

When:

1) the registration lifetime of the only public user identity currently registered with its associated set of implicitly registered public user identities (i.e. no other is registered) and bound either to the contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used) expires;

2) there are still active multimedia sessions that includes either this user's contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used);

3) the session was initiated by or terminated towards the user using the public user identity currently registered or with one of the implicitly registered public used identities bound either to the contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used);

then the S-CSCF shall:

- release each of these multimedia sessions by applying the steps listed in the subclause 5.4.5.1.2. The S-CSCF shall only release dialogs associated with the multi media sessions originated or terminated towards the registered user's contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used).

5.4.5.1.3 Abnormal cases

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

5.4.5.2 Session release initiated by any other entity

Upon receipt of a 2xx response for a BYE request matching an existing dialog, the S-CSCF shall delete all the stored information related to the dialog.

5.4.5.3 Session expiration

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

5.4.6 Call-related requests

5.4.6.1 ReINVITE

5.4.6.1.1 Determination of served user

Void.

5.4.6.1.2 UE-originating case

For a reINVITE request or UPDATE request from the UE within the same dialog, the S-CSCF shall store the updated access-network-charging-info parameter from P-Charging-Vector header field in the received SIP request. The S-CSCF shall retain the access-network-charging-info parameter in the P-Charging-Vector header field when the request is forwarded to an AS. However, the S-CSCF shall not include the access-network-charging-info parameter in the P-Charging-Vector header field when the request is forwarded outside the home network of the S-CSCF.

For a reINVITE request from the UE, if the request is to be forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the access-network-charging-info parameter from the P-Charging-Vector header field; otherwise, the S-CSCF shall remove the access-network-charging-info parameter from the P-Charging-Vector header field.

5.4.6.1.3 UE-terminating case

For a reINVITE request or UPDATE request destined towards the UE within the same dialog, when the S-CSCF receives the 200 (OK) response (to the INVITE request or UPDATE request), the S-CSCF shall store the updated access-network-charging-info parameter from the P-Charging-Vector header field. The S-CSCF shall retain the access-network-charging-info parameter in the P-Charging-Vector header field when the response is forwarded to the AS. However, the S-CSCF shall not include the access-network-charging-info parameter in the P-Charging-Vector header field when the 200 (OK) response is forwarded outside the home network of the S-CSCF.

For any SIP response to an INVITE request, if the response is to be forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the access-network-charging-info parameter from the P-Charging-Vector header field; otherwise, the S-CSCF shall remove the access-network-charging-info parameter from the P-Charging-Vector header field.

5.4.7 Void

5.4.7A GRUU management

5.4.7A.1 Overview of GRUU operation

The S-CSCF provides a service of assigning and translating GRUUs for use by registered UEs, unless "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in 3GPP TS 29.228 [14] has been provisioned in the service profile of the registered public user identity. This is conducted as specified in RFC 5627 [93] and RFC 5628 [94]. Two kinds of GRUUs are assigned: public GRUUs and temporary GRUUs.

NOTE: If the UE performs the functions of an external attached network (e.g an enterprise network) the UE could have self allocated its own GRUUs. In this version of the specification only UE self allocated public GRUUs are supported. Routeing to a specific UE self-allocated public GRUUs requires that "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in 3GPP TS 29.228 [14] is provisioned in the service profile of the served public user identity. Use of UE self-allocated temporary GRUUs is not supported in this version of the specification and requests addressed to UE self allocated temporary GRUUs will fail to be routed to the UE.

Each assigned GRUU represents an association between a public user identity and an instance ID provided by a registering UE. It is used to address a particular UE that possesses the instance ID and registers with the public user identity. The GRUU also denotes a contact address registered with a public user identity when the contact address has a "+sip.instance" header field parameter containing the GRUU instance ID.

The S-CSCF issues GRUUs as part of the registration process, and also reports GRUUs as part of notifications for subscriptions to the "reg" event package. The S-CSCF always issues GRUUs in pairs – a public GRUU and a temporary GRUU. In case of implicit registration the S-CSCF assigns a unique public GRUU and a unique temporary GRUU for each public user identity.

The S-CSCF may also support the procedures for allocating public GRUUs and supporting the generation of temporary GRUUs by the functionality within the UE that performs the role of registrar as specified in RFC 6140 [191] as well as the procedures to route requests containing such GRUUs.

5.4.7A.2 Representation of public GRUUs

Each public GRUU shall conform to all requirements specified in RFC 5627 [93].

If the Contact URI in the Contact header field does not contain a "bnc" URI parameter, then the S-CSCF constructs a public GRUU by adding a "gr" SIP URI parameter to the canonical for m of the SIP URI which contains a public user identity.

If the Contact URI in the Contact header field contains a "bnc" URI parameter and if the S-CSCF supports RFC 6140 [191], then the S-CSCF constructs a public GRUU by adding both "bnc" and "gr" SIP URI parameters to the canonical form of the SIP URI from the To header field of the REGISTER request

The "gr" SIP URI parameter serves as an indicator that the URI is in fact a GRUU and if the "+sip.instance" header field parameter from the Contact address contains an IMEI URN or a MEID URN then it carries a value that encodes the IMEI based instance ID that is defined in 3GPP TS 23.003 [3] or the MEID based instance ID which is defined in draft-atarius-device-id-meid-urn [187] otherwise it carries the value received in the "+sip.instance" header field parameter.

By default, the value of the "gr" SIP URI parameter is a copy of the value of the "+sip.instance" header field parameter from a Contact address registered with the S-CSCF, with escaping of special characters as specified in RFC3261 [26].

The public GRUU that is returned in the "pub-gruu" parameter in the 200 (OK) response to the REGISTER request is constructed using the canonical form of the SIP URI of the public user identity from the To header field of the REGISTER request provided that public user identity is not barred. If the public user identity from the To header field of the REGISTER request is barred then the public GRUU that is returned in the "pub-gruu" parameter in the 200 (OK) response to the REGISTER request is constructed using the canonical form of the SIP URI of the default public user identity.

NOTE 1: The default public user identity is always provisioned as a SIP URI.

If the "+sip.instance" header field parameter from the Contact address contains an IMEI URN, as specified in RFC 7254 [153] or an MEID URN, as specified in draft-atarius-device-id-meid-urn [187], then the value of the "gr" SIP URI parameter is generated by the S-CSCF using the name-based UUID algorithm defined in RFC 4122 [154]. The following applies to the algorithm:

1) the "name space ID" shall be a UUID generated for use across the administrative domain and shall use the algorithm for creating a UUID from truly random numbers specified in RFC 4122 [154];

NOTE 2: If the generated UUID is changed, then newly created GRUUs will not match those that were created with the previous UUID. Therefore, the UUID needs to remain the same in order to create consistent GRUUs. This means that the namespace UUID needs to be the same for all S-CSCFs within the domain for which the public GRUU is hosted (it cannot be generated at run time by the S-CSCF as that would produce different values).

2) SHA-1 shall be used as the hash algorithm; and

3) the "name" is made up of a concatenation of the ASCII representation (see RFC 20 [212]) of:

a) if IMEI, the TAC and SNR portions of the IMEI; or

b) if MEID, the Manufacturer Code and the Serial Number portions of the MEID;

from the "+sip.instance" header field parameter.

Only the IMEI shall be use for generating an instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined radio access networks, and the S-CSCF shall follow the procedures for an IMEI as described above.

The S-CSCF shall store the "gr" parameter used in a public GRUU and the associated value received in a "+sip.instance" header field parameter.

The public GRUU for a particular association of public user identity and instance ID is persistent. The same public GRUU will be returned each time a registration is performed with a particular pair of public user identity and instance ID.

5.4.7A.3 Representation of temporary GRUUs

NOTE 1: For UEs performing the functions of an external attached network that support RFC 6140 [191] the S-CSCF does not allocate temporary GRUUs but assists the functionality within the UE that performs the role of registrar in allocating it's own temporary GRUUs by providing to the UE the "temp-gruu-cookie" header field parameter that uniquely identifies the registration. The functionality within the UE that performs the role of registrar then is able to allocate its own temporary GRUUs as per RFC 6140 [191] procedures.

Each temporary GRUU shall conform to all requirements specified in RFC 5627 [93].

Because of the limited lifetime of an temporary GRUU, only the S-CSCF that created a temporary GRUU is required to understand how to translate that GRUU to the corresponsing public user identity and instance ID.

The temporary GRUU that is returned in the "temp-gruu" parameter in the 200 (OK) response to the REGISTER request is mapped to the public user identity from the To header field of the REGISTER request provided that public user identity is not barred. If the public user identity from the To header field of the REGISTER request is barred then the temporary GRUU that is returned in the "temp-gruu" parameter in the 200 (OK) response to the REGISTER request is mapped to the default public user identity.

NOTE 2: The default public user identity is always provisioned as a SIP URI.

The specific representation of a temporary GRUU may be decided by each S-CSCF implementation. Temporary GRUUs must route to the assigning S-CSCF without requiring each assigned GRUU to be stored in the HSS.

The S-CSCF may choose a representation of temporary GRUUs that requires no extra state to be retained, such as that specified in RFC 5627 [93]. Alternatively, the S-CSCF may choose a stateful representation. This is an implementation choice.

NOTE 3: One possible implementation is for the S-CSCF to have a statically configured wildcard PSI that routes to it, with each temporary GRUU being encoded so that it matches the wildcard.

5.4.7A.4 GRUU recognition and validity

The S-CSCF shall recognize those GRUUs it has assigned, verify their validity, and extract the associated public user identity or stored identity of the UE that represents the functionality within the UE that performs the role of registrar and instance ID. This is true for both public GRUUs and temporary GRUUs.

NOTE 1: The S-CSCF only validates and extracts the associated public user identity and instance ID for GRUUs that it assigned.

GRUUs are distinguished from other URIs by the presence of a "gr" SIP URI parameter. Public GRUUs are distinguished from temporary GRUUs by the presence of a value for the "gr" SIP URI parameter.

The instance ID is obtained from a public GRUU by using the "gr" parameter to retrieve the stored associated instance ID. The public user identity or stored identity of the UE that represents the functionality within the UE that performs the role of registrar is extracted from a public GRUU by removing the "gr" SIP URI parameter.

The S-CSCF can recognize a public GRUU as valid if the "gr" parameter contains a value that was stored in the S-CSCF during generation of the public GRUU, and the derived public user identity compares equal, according to the comparison rules of RFC3261 [26], to a public user identity active within the S-CSCF or a stored identity of the UE that represents the functionality within the UE that performs the role of registrar from which a public GRUU was created. When validating public GRUUs the S-CSCF shall ignore the presence of any "sg" SIP URI parameter when determining if a public GRUU is one allocated by the S-CSCF.

NOTE 2: The UE that supports RFC 6140 [191] and performs the functions of an external attached network, adds a unique "sg" SIP URI parameter value to the public GRUU supplied by the S-CSCF when generating public GRUUs for its registering UAs.

The public user identity and instance ID are derived from a temporary GRUU via implementation specific means consistent with the way temporary GRUUs are constructed. The S-CSCF shall determine the validity of a temporary GRUU in conformance with RFC 5627 [93], and if the GRUU was allocated using RFC 6140 [191] procedures then in conformance with RFC 6140 [191] or using implementation specific means.

The S-CSCF regards a UE self-allocated public GRUU as valid if "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in 3GPP TS 29.228 [14] is provisioned in the service profile of the served public user identity.

5.4.8 Emergency service

5.4.8.1 General

S-CSCF shall handle the emergency registration as per the needs of the normal registration.

NOTE: Emergency specific procedures for the Cx interface are specified in annex G in 3GPP TS 29.228 [14].

5.4.8.2 Initial emergency registration or user-initiated emergency reregistration

When the S-CSCF receives a REGISTER request; and the Contact header field includes a "sos" SIP URI parameter that indicates that this is an emergency registration, the S-CSCF shall perform the actions as specified in subclause 5.4.1.1 with the following additions:

1) when handling unprotected REGISTER request or protected REGISTER request, the S-CSCF:

a) shall deregister only contacts that were registered as part of emergency registration; and

b) shall not deregister contacts that were registered as part of non-emergency registration;

NOTE 1: other conditions triggering contact deregistration are described in subclause 5.4.1.

2) for the protected REGISTER request, when the S-CSCF receives a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "yes", "tls-yes" or "ip-assoc-yes", i.e. for the protected REGISTER request, and the Contact header field includes a "sos" SIP URI parameter that indicates that this is an emergency registration, the S-CSCF shall identify the user by the public user identity as received in the To header field and the private user identity as received in the Authorization header field of the REGISTER request;

3) if operator policy does not require that emergency service requests are forwarded to the S-CSCF, the S-CSCF shall not include a Service-Route header field in the 200 (OK) response to the REGISTER request;

4) the S-CSCF shall not include a temporary GRUU in the 200 (OK) response to the REGISTER request;

5) the S-CSCF shall in the Contact header field of the 200 (OK) response to the REGISTER request include only the URI that was successfully emergency registered and in this URI include the "sos" SIP URI parameter;

NOTE 2 Only including the emergency registered contact in the 200 (OK) response to the REGISTER request deviates from bullet 8 in section 10.3 of RFC 3261 [26].

NOTE 3: In the case where the S-CSCF returns a GRUU in the Contact header field of the 200 (OK) response to the REGISTER request, the "sos" SIP URI parameter is appended to the URI and not included as a Contact header field parameter. The public GRUU that is returned in the 200 (OK) response includes the "sos" SIP URI parameter as a parameter of the URI included in the "pub-gruu" Contact header field parameter.

6) store the Path header field and the contact information including all header field parameters contained in the Contact header field;

NOTE 4: The Path header field and contact information used for the emergency dialogs destined for the UE and obtained during the emergency registration can be different than the Path header field used for the non-emergency communication and obtained during the non-emergency registration.

NOTE 5: The S-CSCF will not perform the network initiated deregistration procedure for an emergency registration, but will let it expire. A new emergency registration will overwrite any previous emergency registration.

7) the S-CSCF shall not send any third-party REGISTER requests to any AS;

8) the S-CSCF shall not include an empty P-Debug-ID header field;

NOTE 6: Including an empty P-Debug-ID header field in a 200 (OK) response to an emergency registration could delay emergency call setup as it causes the UE to subscribe to the debug event package.

9) determine the duration of the registration by checking the value of the registration expiration interval value in the received REGISTER request and based on local policy; and

NOTE 7: The value of the emergency registration time is subject to national regulation and can be subject to roaming agreements.

10) for any bindings created by the emergency registration, mark those bindings as created by an emergency registration.

5.4.8.3 User-initiated emergency deregistration

When S-CSCF receives a REGISTER request with the registration expiration interval value containing zero and the Contact header field contains a contact address that has been registered for emergency service (i.e. the "sos" SIP URI parameter that indicates that this is an emergency registration is included in the Contact header field), the S-CSCF shall reject the REGISTER request by sending a 501 (Not Implemented) response.

NOTE: The UE cannot deregister its emergency public user identity.

5.4.8.4 Network-initiated emergency deregistration

The S-CSCF shall not perform a network-initiated emergency deregistration.

5.4.8.5 Network-initiated emergency reauthentication

If a given public user identity and the associated contact address have been registered via emergency registration, the S-CSCF shall not reauthenticate this public user identity.

5.4.8.6 Subscription to the event providing registration state

If a S-CSCF receives a SUBSCRIBE request addressed to S-CSCF containing the Event header field with the reg event package with the Contact header field that contains a contact address that has been registered for emergency service, the S-CSCF shall reject the SUBSCRIBE request for the reg-event package by sending a 489 (Bad Event) response.

5.4.8.7 Notification of the registration state

When the user performs an emergency registration or when the emergency registration expires, the S-CSCF shall not send a NOTIFY request to the subscribers to the reg event package of the respective user.

The contact address that has been registered for emergency service shall not be included in the NOTIFY requests sent to the subscribers to the reg event package of the user.

저작자표시

'기타' 카테고리의 다른 글

SIP 소개 (10)	2017.04.20
삼각형 패턴 만들기 (10)	2017.02.03
Windows10에서 Telnet 기능 켜기 (9)	2016.12.15
R studio(0.99.893) vim mode 설정 안 보임 (10)	2016.06.07
XCODE 7.0에서 vim plugin 추가하기 (12)	2016.02.03

+ Recent posts

ENQDEQ

5.4.1.2.1 Unprotected REGISTER

5.4.1.2.1C Challenge with SIP digest with TLS as security mechanism

5.4.1.2.2B Protected REGISTER with SIP digest with TLS as a security mechanism

5.4.1.2.3A Abnormal cases – IMS AKA as security mechanism

5.4.1.2.3C Abnormal cases – SIP digest with TLS as security mechanism

5.4.1.4 User-initiated deregistration

5.4.1.4.1 Normal cases

5.4.1.4.4 Abnormal cases – SIP digest with TLS as security mechanism

5.4.1.7 Notification of Application Servers about registration status

5.4.3.3 Requests terminated at the served user

'기타' 카테고리의 다른 글

티스토리툴바