5.4.8 Emergency service

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

5.4.8.1 General

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

NOTE 1: Emergency specific procedures for the Cx interface are specified in annex G in 3GPP TS 29.228 [14].

NOTE 2: When receiving an emergency service request then the S-CSCF handles the emergency service request as per the procedures in subclause 5.4.3.2. The Route header field indicating the URI associated with the E-CSCF is included by a P-CSCF or an AS.

5.4.8.2 Initial emergency registration or user-initiated emergency reregistration

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

1) when handling unprotected REGISTER request or protected REGISTER request, the S-CSCF:

a) shall deregister only contacts that were registered as part of emergency registration; and

b) shall not deregister contacts that were registered as part of non-emergency registration;

NOTE 1: other conditions triggering contact deregistration are described in subclause 5.4.1.

2) for the protected REGISTER request, when the S-CSCF receives a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "yes", "tls-yes" or "ip-assoc-yes", i.e. for the protected REGISTER request, and the Contact header field includes a "sos" SIP URI parameter that indicates that this is an emergency registration, the S-CSCF shall identify the user by the public user identity as received in the To header field and the private user identity as received in the Authorization header field of the REGISTER request;

3) if operator policy does not require that emergency service requests are forwarded to the S-CSCF, the S-CSCF shall not include a Service-Route header field in the 200 (OK) response to the REGISTER request;

4) the S-CSCF shall not include a temporary GRUU in the 200 (OK) response to the REGISTER request;

5) the S-CSCF shall in the Contact header field of the 200 (OK) response to the REGISTER request include only the URI that was successfully emergency registered and in this URI include the "sos" SIP URI parameter;

NOTE 2 Only including the emergency registered contact in the 200 (OK) response to the REGISTER request deviates from bullet 8 in section 10.3 of RFC 3261 [26].

NOTE 3: In the case where the S-CSCF returns a GRUU in the Contact header field of the 200 (OK) response to the REGISTER request, the "sos" SIP URI parameter is appended to the URI and not included as a Contact header field parameter. The public GRUU that is returned in the 200 (OK) response includes the "sos" SIP URI parameter as a parameter of the URI included in the "pub-gruu" Contact header field parameter.

6) store the Path header field and the contact information including all header field parameters contained in the Contact header field;

NOTE 4: The Path header field and contact information used for the emergency dialogs destined for the UE and obtained during the emergency registration can be different than the Path header field used for the non-emergency communication and obtained during the non-emergency registration.

NOTE 5: The S-CSCF will not perform the network initiated deregistration procedure for an emergency registration, but will let it expire. A new emergency registration will overwrite any previous emergency registration.

7) the S-CSCF shall not send any third-party REGISTER requests to any AS;

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

NOTE 6: The value of the emergency registration time is subject to national regulation and can be subject to roaming agreements.

10) for any bindings created by the emergency registration, mark those bindings as created by an emergency registration.

5.4.8.3 User-initiated emergency deregistration

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

NOTE: The UE cannot deregister its emergency public user identity.

5.4.8.4 Network-initiated emergency deregistration

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

5.4.8.5 Network-initiated emergency reauthentication

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

5.4.8.6 Subscription to the event providing registration state

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

5.4.8.7 Notification of the registration state

When the user performs an emergency registration or when the emergency registration expires, the S-CSCF shall not send a NOTIFY request to the subscribers to the reg event package of the respective user.

The contact address that has been registered for emergency service shall not be included in the NOTIFY requests sent to the subscribers to the reg event package of the user.