SOS Uniform Resource
Identifier (URI) Parameter for Marking of Session Initiation Protocol
(SIP) Requests related to Emergency Services
Nortel
Maidenhead Office Park, Westacott Way
Maidenhead
Berkshire, UK
milanpa@nortel.com
RAI
ECRIT Working Group
Emergency
Session Initiation Protocol
This document defines a new Session Initiation Protocol (SIP) Uniform
Resource Identifier (URI) parameter intended for marking SIP
registration requests related to emergency services. The URI parameter
is extensible to allow future values to be defined if required by other
use cases that require specific SIP registrations to be distinctly
identified. The usage of this new URI parameter complements the usage of
the Service Uniform Resource Name (URN) and is not intended to replace
it.
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 can not be fulfilled by the use of the Service URN.
In some countries, it is a regulatory requirement that devices be
able to place emegency 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.
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 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 is unlikely to include the "reg-type" URI parameter in the
Contact header field since this registration is treated as a
non-emergency registration.
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.