Content for  TS 24.229  Word version:  18.4.0

When the S-CSCF receives an INVITE request, either from the served user or destined to the served user, the S-CSCF may require the periodic refreshment of the session to avoid hung states in the S-CSCF. If the S-CSCF requires the session to be refreshed, the S-CSCF shall apply the procedures described in Section 8 of RFC 4028. For interworking with a visiting network, where the P-CSCF of the visiting network does not support priority but it is intended or required to give users of that P-CSCF priority in the home network, the S-CSCF in the home network shall recognize the need for priority treatment if such detection is not alternately provided via an IBCF in the home network. When an S-CSCF interworks with a visiting network that does not support priority, and the S-CSCF recognizes the need for priority treatment, the S-CSCF shall insert the temporarily authorised Resource-Priority header field with appropriate namespace and priority value in the INVITE request. When the S-CSCF receives an initial INVITE request destined for the served user, the S-CSCF shall either:

1. examine the SDP offer (the "c=" parameter) to detect if it contains an IP address type that is not supported by the IM CN subsystem; or
2. process the initial INVITE request without examining the SDP.

Subsequently, when the S-CSCF detects that the SDP offer contained an IP address type that is not supported by the IM CN subsystem (i.e., either case a) or b)), the S-CSCF shall either:

• return a 305 (Use Proxy) response to the I-CSCF with the Contact field containing the SIP URI of the IBCF, or
• forward the initial INVITE request to the IBCF. When forwarding the initial INVITE request, the S-CSCF shall not insert its SIP URI into the Record-Route header field.

If overlap signalling using the multiple-INVITE method is supported as a network option, several INVITE requests with the same Call ID and the same From header field (including "tag" header field parameter) can be received outside of an existing dialog. Such INVITE requests relate to the same call. If the S-CSCF receives an INVITE request from the served user outside an existing dialog with the same Call ID and From header field as a previous INVITE request during a certain period of time, it shall route the new INVITE request to the same next hop as the previous INVITE request.

Upon receipt of a 2xx response for a BYE request matching an existing dialog, the S-CSCF shall delete all the stored information related to the dialog.

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

The S-CSCF provides a service of assigning and translating GRUUs for use by registered UEs, unless "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in TS 29.228 has been provisioned in the service profile of the registered public user identity. This is conducted as specified in RFC 5627 and RFC 5628. Two kinds of GRUUs are assigned: public GRUUs and temporary GRUUs. Each assigned GRUU represents an association between a public user identity and an instance ID provided by a registering UE. It is used to address a particular UE that possesses the instance ID and registers with the public user identity. The GRUU also denotes a contact address registered with a public user identity when the contact address has a "+sip.instance" header field parameter containing the GRUU instance ID. The S-CSCF issues GRUUs as part of the registration process, and also reports GRUUs as part of notifications for subscriptions to the "reg" event package. The S-CSCF always issues GRUUs in pairs - a public GRUU and a temporary GRUU. In case of implicit registration the S-CSCF assigns a unique public GRUU and a unique temporary GRUU for each public user identity. The S-CSCF may also support the procedures for allocating public GRUUs and supporting the generation of temporary GRUUs by the functionality within the UE that performs the role of registrar as specified in RFC 6140 as well as the procedures to route requests containing such GRUUs.

Each public GRUU shall conform to all requirements specified in RFC 5627. If the Contact URI in the Contact header field does not contain a "bnc" URI parameter, then the S-CSCF constructs a public GRUU by adding a "gr" SIP URI parameter to the canonical for m of the SIP URI which contains a public user identity. If the Contact URI in the Contact header field contains a "bnc" URI parameter and if the S-CSCF supports RFC 6140, then the S-CSCF constructs a public GRUU by adding both "bnc" and "gr" SIP URI parameters to the canonical form of the SIP URI from the To header field of the REGISTER request The "gr" SIP URI parameter serves as an indicator that the URI is in fact a GRUU and if the "+sip.instance" header field parameter from the Contact address contains an IMEI URN or a MEID URN then it carries a value that encodes the IMEI based instance ID that is defined in TS 23.003 or the MEID based instance ID which is defined in RFC 8464 otherwise it carries the value received in the "+sip.instance" header field parameter. By default, the value of the "gr" SIP URI parameter is a copy of the value of the "+sip.instance" header field parameter from a Contact address registered with the S-CSCF, with escaping of special characters as specified in RFC 3261. The public GRUU that is returned in the "pub-gruu" parameter in the 200 (OK) response to the REGISTER request is constructed using the canonical form of the SIP URI of the public user identity from the To header field of the REGISTER request provided that public user identity is not barred. If the public user identity from the To header field of the REGISTER request is barred then the public GRUU that is returned in the "pub-gruu" parameter in the 200 (OK) response to the REGISTER request is constructed using the canonical form of the SIP URI of the default public user identity. If the "+sip.instance" header field parameter from the Contact address contains an IMEI URN, as specified in RFC 7254 or an MEID URN, as specified in RFC 8464, then the value of the "gr" SIP URI parameter is generated by the S-CSCF using the name-based UUID algorithm defined in RFC 4122. The following applies to the algorithm:

1. the "name space ID" shall be a UUID generated for use across the administrative domain and shall use the algorithm for creating a UUID from truly random numbers specified in RFC 4122;
2. SHA-1 shall be used as the hash algorithm; and
3. the "name" is made up of a concatenation of the ASCII representation (see RFC 20) of:
   1. if IMEI, the TAC and SNR portions of the IMEI; or
   2. if MEID, the Manufacturer Code and the Serial Number portions of the MEID;
   from the "+sip.instance" header field parameter.

Only the IMEI shall be use for generating an instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined radio access networks, and the S-CSCF shall follow the procedures for an IMEI as described above. The S-CSCF shall store the "gr" parameter used in a public GRUU and the associated value received in a "+sip.instance" header field parameter. The public GRUU for a particular association of public user identity and instance ID is persistent. The same public GRUU will be returned each time a registration is performed with a particular pair of public user identity and instance ID.

Each temporary GRUU shall conform to all requirements specified in RFC 5627. Because of the limited lifetime of an temporary GRUU, only the S-CSCF that created a temporary GRUU is required to understand how to translate that GRUU to the corresponsing public user identity and instance ID. The temporary GRUU that is returned in the "temp-gruu" parameter in the 200 (OK) response to the REGISTER request is mapped to the public user identity from the To header field of the REGISTER request provided that public user identity is not barred. If the public user identity from the To header field of the REGISTER request is barred then the temporary GRUU that is returned in the "temp-gruu" parameter in the 200 (OK) response to the REGISTER request is mapped to the default public user identity. The specific representation of a temporary GRUU may be decided by each S-CSCF implementation. Temporary GRUUs must route to the assigning S-CSCF without requiring each assigned GRUU to be stored in the HSS. The S-CSCF may choose a representation of temporary GRUUs that requires no extra state to be retained, such as that specified in RFC 5627. Alternatively, the S-CSCF may choose a stateful representation. This is an implementation choice.

The S-CSCF shall recognize those GRUUs it has assigned, verify their validity, and extract the associated public user identity or stored identity of the UE that represents the functionality within the UE that performs the role of registrar and instance ID. This is true for both public GRUUs and temporary GRUUs. GRUUs are distinguished from other URIs by the presence of a "gr" SIP URI parameter. Public GRUUs are distinguished from temporary GRUUs by the presence of a value for the "gr" SIP URI parameter. The instance ID is obtained from a public GRUU by using the "gr" parameter to retrieve the stored associated instance ID. The public user identity or stored identity of the UE that represents the functionality within the UE that performs the role of registrar is extracted from a public GRUU by removing the "gr" SIP URI parameter. The S-CSCF can recognize a public GRUU as valid if the "gr" parameter contains a value that was stored in the S-CSCF during generation of the public GRUU, and the derived public user identity compares equal, according to the comparison rules of RFC 3261, to a public user identity active within the S-CSCF or a stored identity of the UE that represents the functionality within the UE that performs the role of registrar from which a public GRUU was created. When validating public GRUUs the S-CSCF shall ignore the presence of any "sg" SIP URI parameter when determining if a public GRUU is one allocated by the S-CSCF. The public user identity and instance ID are derived from a temporary GRUU via implementation specific means consistent with the way temporary GRUUs are constructed. The S-CSCF shall determine the validity of a temporary GRUU in conformance with RFC 5627, and if the GRUU was allocated using RFC 6140 procedures then in conformance with RFC 6140 or using implementation specific means. The S-CSCF regards a UE self-allocated public GRUU as valid if "Loose-Route Indication" indicating the HSS requires the loose-route mechanism as described in TS 29.228 is provisioned in the service profile of the served public user identity.

The S-CSCF shall handle the emergency registration as per the needs of the normal registration.

When the S-CSCF receives a REGISTER request; and the Contact header field includes a "sos" SIP URI parameter that indicates that this is an emergency registration, the S-CSCF shall perform the actions as specified in subclause 5.4.1.1 with the following additions:

1. when handling unprotected REGISTER request or protected REGISTER request, the S-CSCF:
   1. shall deregister only contacts that were registered as part of emergency registration; and
   2. shall not deregister contacts that were registered as part of non-emergency registration;
2. for the protected REGISTER request, when the S-CSCF receives a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "yes", "tls-yes" or "ip-assoc-yes", i.e. for the protected REGISTER request, and the Contact header field includes a "sos" SIP URI parameter that indicates that this is an emergency registration, the S-CSCF shall identify the user by the public user identity as received in the To header field and the private user identity as received in the Authorization header field of the REGISTER request;
3. if operator policy does not require that emergency service requests are forwarded to the S-CSCF, the S-CSCF shall not include a Service-Route header field in the 200 (OK) response to the REGISTER request;
4. the S-CSCF shall not include a temporary GRUU in the 200 (OK) response to the REGISTER request;
5. the S-CSCF shall in the Contact header field of the 200 (OK) response to the REGISTER request include only the URI that was successfully emergency registered and in this URI include the "sos" SIP URI parameter;
6. store the Path header field and the contact information including all header field parameters contained in the Contact header field;
7. the S-CSCF shall not send any third-party REGISTER requests to any AS;
8. void
9. determine the duration of the registration by checking the value of the registration expiration interval value in the received REGISTER request and based on local policy; and
10. for any bindings created by the emergency registration, mark those bindings as created by an emergency registration.

When S-CSCF receives a REGISTER request with the registration expiration interval value containing zero and the Contact header field contains a contact address that has been registered for emergency service (i.e. the "sos" SIP URI parameter that indicates that this is an emergency registration is included in the Contact header field), the S-CSCF shall reject the REGISTER request by sending a 501 (Not Implemented) response.

The S-CSCF shall not perform a network-initiated emergency deregistration.

If a given public user identity and the associated contact address have been registered via emergency registration, the S-CSCF shall not re-authenticate this public user identity.

If a S-CSCF receives a SUBSCRIBE request addressed to S-CSCF containing the Event header field with the reg event package with the Contact header field that contains a contact address that has been registered for emergency service, the S-CSCF shall reject the SUBSCRIBE request for the reg-event package by sending a 489 (Bad Event) response.

When the user performs an emergency registration or when the emergency registration expires, the S-CSCF shall not send a NOTIFY request to the subscribers to the reg event package of the respective user. The contact address that has been registered for emergency service shall not be included in the NOTIFY requests sent to the subscribers to the reg event package of the user.