SOS Uniform Resource Identifier (URI) Parameter for Marking of Session Initiation Protocol (SIP) Requests related to Emergency Services

One way to differentiate a SIP-based emergency call from an ordinary call is by the presence of the Service URN as defined in RFC 5031 (and used in the IETF emergency services architecture described in PhoneBCP). The 3GPP IP Multimedia Subsystem (IMS) emergency services architecture, illustrated in 3GPP TS 23.167 , specifies that the User Equipment (UE) performs emergency registration prior to or during the initiation of an emergency call. The circumstances where such an emergency registration is beneficial are listed below: - the UE is not registered with its home network;- the UE is currently registered but roaming (to ensure that the emergency call is handled in the visited network, as required by some jurisdictions). Emergency registration is possible only when the UE has sufficient credentials to register with its home network and can detect that an emergency session is initiated. Unfortunately, marking of the emergency registration cannot be fulfilled by the use of the Service URN. In some countries, it is a regulatory requirement that devices be able to place emergency calls in circumstances where other calls may not be permitted. When a UAC issues an emergency marked REGISTER request it informs the registrar that the contact address and the address-of-record being registered are to be used for emergency calls, and roaming and barring restrictions should not be applied for the registered address-of-record. Furthermore, distinguishing emergency registration from non-emergency registration allows the registrar to ensure that the contact address associated with previous registration of the address-of-record included in the emergency REGISTER request is not replaced. For incoming calls, for example, a PSAP call back to a previously made emergency call, addressed to the emergency registered address-of-record can be correctly routed to the contact address and UA from which the original emergency call was placed. In addition, any network based services or UA endpoint based services which may prevent the emergency call or PSAP call back from being successful can be disabled if it can be distinguished that the registered contact address and address-of-record pertain to emergency calls. This document concentrates on a use case defined by 3GPP as described above. However, the solution proposed does not preclude other systems that require emergency registration to occur prior to placing an emergency call. This document proposes a way to mark a REGISTER request as an emergency registration.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119

Req: Where emergency registration is required prior to placing an emergency call, it shall be possible to distinguish emergency registration from non-emergency registration.

This section provides an overview of the proposed new URI parameter to be used for marking REGISTER requests related to emergency services. A new URI parameter "reg-type" is defined in this document. The "reg-type" parameter is appended to a URI consistent with RFC 3261 . It is proposed that use of this URI parameter is restricted to the Contact header included in the REGISTER request (and the 2xx response to the REGISTER request) related to an emergency call only. The "reg-type" URI parameter SHALL take a value of "sos" to indicate that the REGISTER request pertains to emergency registration. The "reg-type" URI parameter with value "sos" MUST NOT be considered as a replacement for the Service URN for emergency calls originated by a UA. Other use cases where specific instances of SIP registration need to be identified are also possible. One such case may be by an end-user registering their address-of-record with the specific purpose of making "test" calls within a network. Such cases not specific to the use case identified in this draft for identifying emergency registration are not dealt with in this document. However the "reg-type" URI parameter is extensible to allow other "reg-type" values to be defined in the future.

In networks where the UA sends a REGISTER request for emergency registration prior to placing an emergency call, the "reg-type" URI parameter with value "sos" MUST be appended to the URI in the Contact header. This serves as an indication to the registrar that the request is for emergency registration. Example:Contact: "Alice" <sip:alice@example.com;reg-type=sos> ;q=0.7; expires=3600 In the event that more than one Contact header field is included in the REGISTER request, only the contact addresses that include the "reg-type" URI parameter with value "sos" shall be considered as emergency registered contact addresses. The "reg-type" URI parameter with value "sos" MUST NOT be included in non-REGISTER requests, and MUST NOT be included in REGISTER requests that do not pertain to emergency calls.

If the registrar receives a REGISTER request that includes the "reg-type" URI parameter with value "sos" in the Contact heade field, the registrar MUST include the "reg-type" URI parameter with value "sos" in the Contact header field in the 200 (OK) response sent by the registrar upon successful registration. The "reg-type" URI parameter with value "sos" is appended to the URI included in the Contact header, thus indicating to the UA that it needs to include this contact address in the Contact header of an INVITE request for emergency call initiation.

The backwards compatibility scenario considered in this document is where a legacy registrar does not support the "reg-type" URI parameter with value "sos". In this case, if the registrar receives a REGISTER request that includes the "reg-type" URI parameter with value "sos" in the Contact header field, the registrar proceeds with registration procedures and silently ignores the URI-parameter in accordance with RFC 3261. This ensures the user is registered and thus can successfully initiate an emergency call. The drawback of proceeding with registration is if the address-of-record is for example barred or has roaming restrictions applied, then these restrictions will not be lifted and thus registration will be unsuccessful. This can limit the UAC's ability to successfully place an emergency call. If registration is successful, the 200 (OK) response from a legacy registrar includes the "reg-type" URI parameter with value "sos" in the Contact header field. Thus the UA is unaware that the registrar does not support the “reg-type” URI parameter with value “sos”. Providing the registration was successful, the UA’s ability to place an emergency call is not compromised. The UA need not know that the registrar does not support the URI parameter. The consequence of the registrar not supporting the “reg-type” URI parameter with value “sos”, in addition to the drawback pertaining to restrictions applied to the address-of-record, are as follows: - the risk of the registrar overwriting previous registrations of the registered address-of-record, and thus disrupting any on-going non-emergency sessions associated with the UA, its address-of-record and previously registered contact address. - incoming calls, such as a PSAP call back (to a previously made emergency call) to the registered address-of-record might not be routed correctly to the UA that placed the emergency call, due to not suppressing any network based services such as call forwarding, or UA based services which can divert the call elsewhere, or if the address-of-record is associated to more than one contact address.

The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 5234 .The "reg-type" URI parameter is a "uri-parameter", as defined by RFC 3261.uri-parameter =/ reg-type-paramreg-type-param = "reg-type=" ("sos" / genvalue)genvalue = 1*(alphanum / "-" / "." )

This specification defines one new SIP URI parameter, as per the registry created by RFC 3969 Parameter Name: reg-typePredefined Values: sosReference: [RFCXXXX][NOTE TO IANA: Please replace XXXX with the RFC number of this specification.]

As an identifier, the "reg-type" parameter itself does not raise any particular security issues. The semantic described by the "reg-type" parameter are meant to be well-known so privacy considerations do not apply to the URI parameter. The main possibility of attack involves use of the "reg-type" parameter to bypass the normal procedures in order to achieve fraudulent use of services or to bypass security procedures. The usage of this parameter as described in this document is purely for the purpose of the REGISTER request and hence in presence of user authentication it is ensured that the respective user can be held accountable. It is RECOMMENDED to log events of misuse of the "reg-type" URI parameter with value "sos", for example by including it in a request or response not related to an emergency call.

The author would like to thank Keith Drage, Milo Orsic, Deb Barclay, John-Luc Bakker, Andrew Allen, Hiroshi Ishikawa, Sean Schneyer, Peter Leis, Georg Mayer, Marvin Bienn, Ricky Kaura, Steve Norreys, Laura Liess, AC Mahendran, Roozbeh Atarius, Ramachandran Subramanian and Sandeep Sharma, Brian Rosen, Hannes Tschofenig, Christer Holmberg and Henning Schulzrinne for the discussions and contributions that led to this work.