5.4.1 Registration and authentication

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

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

5.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 contains an Authorization header field with an "integrity-protected" header field parameter set to the value "no":

– the security mechanism, in the "algorithm" header field parameter set to the value as received in the Authorization header field i.e. "AKAv2-SHA-256" or "AKAv1-MD5";

NOTE: The "AKAv1-MD5" algorithm is only supported for backward compatibility.

– 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) for each supported digest algorithm the S-CSCF shall create a WWW-Authenticate header field as defined in RFC 7616 [286] and RFC 8760 [287], 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; and

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

The S-CSCF shall include the WWW-Authenticate header fields to the 401 (Unauthorized) response in order of preference, starting with the most preferred algorithm.

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 "AKAv2-SHA-256" or "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 1: 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 "SHA2-256", "SHA2-512/256" or "MD5", check the following additional fields:

NOTE 2: The MD5 algorithm is only supported for backward compatibility.

– 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 "nc" 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 match. The expected response is calculated by the S-CSCF as described in RFC 7616 [286] and RFC 8760 [287] 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 3: 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].

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 6: 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 7: 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 8: 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 9: The way the S-CSCF identifies the dialogs associated with the registration flow being replaced is implementation specific.

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

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

NOTE 12: 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;

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

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 14: 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 7616 [286] and RFC 8760 [287] 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 7616 [286] and RFC 8760 [287];

– a "cnonce" header field parameter matching the "cnonce" Authorization header field parameter sent by the UE; and

– a "nc" header field parameter matching the "nc" 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;

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.

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. 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) void

j) optionally, a Feature-Caps header field including the ICSI values contained in the service profile of the served user except the ones that require explicit support indication of capabilities by intermediary entities and that have not been indicated as supported according to RFC 6809 [190] for the corresponding registration or registration flow (if multiple registration mechanism is used);

k) if the home network supports calling number verification using signature verification and attestation information, as defined in subclause 3.1,a Feature-Caps header field, as specified in RFC 6809 [190], including the "+g.3gpp.verstat" header field parameter; and

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

l) if the home network supports the response code 607 (Unwanted) as specified in RFC 8197 [254], a Feature-Caps header field including the "+sip.607" header field parameter.

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; and

k) void

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 among the set of registrations for the registered URI. The value shall be the same until the UE is deregistered.

NOTE 4: Setting the value of the registration-token to the same value as the S-CSCF will use for the "id" parameter identifying this contact in the "reg" event package allows the AS to retrieve the value using the "reg" event package.

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 5: 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.