ECRIT Working Group M. Patel
Internet-Draft Nortel
Intended status: Standards Track October 26, 2009
Expires: April 29, 2010
SOS Uniform Resource Identifier (URI) Parameter for Marking of Session
Initiation Protocol (SIP) Requests related to Emergency Services
draft-patel-ecrit-sos-parameter-07.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document defines a new Session Initiation Protocol (SIP) Uniform
Resource Identifier (URI) parameter intended for marking SIP
Patel Expires April 29, 2010 [Page 1]
Internet-Draft SOS URI Parameter for SIP Emergency October 2009
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The "reg-type" URI Parameter . . . . . . . . . . . . . . . . . 4
4.1. REGISTER Request . . . . . . . . . . . . . . . . . . . . . 4
4.2. 2xx Response to REGISTER Request . . . . . . . . . . . . . 5
4.3. Backwards compatibility issues . . . . . . . . . . . . . . 5
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Patel Expires April 29, 2010 [Page 2]
Internet-Draft SOS URI Parameter for SIP Emergency October 2009
1. Introduction
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
[RFC5031] (and used in the IETF emergency services architecture
described in PhoneBCP[I-D.ietf-ecrit-phonebcp]). The 3GPP IP
Multimedia Subsystem (IMS) emergency services architecture,
illustrated in 3GPP TS 23.167 [3GPP.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.
2. Terminology
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 [RFC2119]
Patel Expires April 29, 2010 [Page 3]
Internet-Draft SOS URI Parameter for SIP Emergency October 2009
3. Requirements
Req: Where emergency registration is required prior to placing an
emergency call, it shall be possible to distinguish emergency
registration from non-emergency registration.
4. The "reg-type" URI Parameter
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
[RFC3261]. 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.
4.1. REGISTER Request
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
Patel Expires April 29, 2010 [Page 4]
Internet-Draft SOS URI Parameter for SIP Emergency October 2009
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.
4.2. 2xx Response to REGISTER Request
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.
4.3. Backwards compatibility issues
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[RFC3261]. 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.
5. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC 5234 [RFC5234].
Patel Expires April 29, 2010 [Page 5]
Internet-Draft SOS URI Parameter for SIP Emergency October 2009
The "reg-type" URI parameter is a "uri-parameter", as defined by RFC
3261[RFC3261].
uri-parameter =/ reg-type-param
reg-type-param = "reg-type=" ("sos" / genvalue)
genvalue = 1*(alphanum / "-" / "." )
6. IANA Considerations
This specification defines one new SIP URI parameter, as per the
registry created by RFC 3969 [RFC3969]
Parameter Name: reg-type
Predefined Values: sos
Reference: [RFCXXXX]
[NOTE TO IANA: Please replace XXXX with the RFC number of this
specification.]
7. Security Considerations
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.
8. Acknowledgements
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
Patel Expires April 29, 2010 [Page 6]
Internet-Draft SOS URI Parameter for SIP Emergency October 2009
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.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004.
9.2. Informative References
[I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-13 (work in progress),
July 2009.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031,
January 2008.
[3GPP.23.167]
3GPP, "IP Multimedia Subsystem (IMS) emergency sessions",
3GPP TS 23.167 7.11.0, December 2008.
Patel Expires April 29, 2010 [Page 7]
Internet-Draft SOS URI Parameter for SIP Emergency October 2009
Author's Address
Milan Patel
Nortel
Maidenhead Office Park, Westacott Way
Maidenhead, Berkshire, UK
Email: milanpa@nortel.com
Patel Expires April 29, 2010 [Page 8]