Network Working Group H. Schulzrinne
Internet-Draft Columbia U.
Expires: August 1, 2006 January 28, 2006
Emergency Services URI for the Session Initiation Protocol
draft-ietf-sipping-sos-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 August 1, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
As part of an overall architecture for supporting emergency calling
for the Session Initiation Protocol (SIP), this document defines
universal emergency SIP URIs, sip:sos@domain and sips:sos@domain,
that allows SIP user agents to contact the local emergency call
center. It also defines conventions that increase the high
probability of reaching the appropriate emergency call center. The
document does not define any SIP protocol extensions.
Schulzrinne Expires August 1, 2006 [Page 1]
Internet-Draft Emergency URI January 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Emergency URIs . . . . . . . . . . . . . . . . . . . . . . . 3
4. Request Handling . . . . . . . . . . . . . . . . . . . . . . 4
5. Alternative Approaches Considered . . . . . . . . . . . . . 5
6. Media Feature Tag Registration: Service . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1 Normative References . . . . . . . . . . . . . . . . . . 8
10.2 Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . 11
Schulzrinne Expires August 1, 2006 [Page 2]
Internet-Draft Emergency URI January 2006
1. Introduction
Using the public switched telephone network (PSTN), emergency help
can often be summoned at a designated, widely known number,
regardless of where the telephone was purchased. However, this
number differs between localities, even though it is often the same
for a country or continent-size region (such as many countries in the
European Union or North America). For end systems based on the
Session Initiation Protocol (SIP) [RFC3261], it is desirable to have
a universal identifier, independent of location, to simplify the user
experience and to allow the device to perform appropriate processing.
Here, we define a common user identifier, "sos", as the contact
mechanism for emergency assistance. This identifier is meant to be
used in addition to any local emergency numbers.
This document specifies only a small part of a comprehensive set of
recommendations for operating emergency services. Future documents
will describe how a device that identifies a call as an emergency
call can route it to the appropriate Public Safety Answering Point
(PSAP).
This document does not introduce any new SIP header fields, request
methods, status codes, message bodies, or events. User agents
unaware of the recommendations in this draft can place emergency
calls, but may not be able to provide the same user interface
functionality. The document suggests behavior for proxy servers, in
particular outbound proxy servers.
The solution described here is not as general as the alternative
approach, service URNs [I-D.schulzrinne-sipping-service], but
requires no changes to end systems or proxies.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant
implementations.
3. Emergency URIs
Having a single, global identifier for emergency services is highly
desirable, as it allows end system and network devices to be built
that recognize such services and can act appropriately. Such actions
may include restricting the functionality of the end system,
providing special features, overriding user service constraints or
routing session setup messages.
Schulzrinne Expires August 1, 2006 [Page 3]
Internet-Draft Emergency URI January 2006
SIP user agents (UAs) that determine that a dialog or transaction
relates to an emergency MUST use an an emergency SIP URI defined
below as the Request-URI and "To" header field.
It is RECOMMENDED that SIP-based [RFC3261] end systems and proxy
servers support a uniform emergency call identifier, namely the SIP
and SIPS URIs with the reserved user name "sos" within any domain,
e.g.,
sip:sos@example.com
sips:sos@example.com
The reserved name is case-insensitive.
The host part of the emergency URI SHOULD be the host portion of the
address-of-record of the caller. The "sips" form SHOULD be used to
ensure integrity and confidentiality; the "sip" form MAY be used if a
"sips" call fails with status code 416 (Unsupported URI Scheme). All
SIP requests with URIs of this form are assumed to be emergency
calls.
The domain-of-record was chosen since a SIP user agent may not be
able to determine the local domain it is visiting. This also
allows each user to test this facility, as the user can ensure
that such services are operational in his home domain. An
outbound proxy in the visited domain can handle the call if it
believes to be in a position to provide appropriate emergency
services.
In some cases, end users or, more likely, emergency service routing
proxies may want to request specific emergency services. We support
this feature by leveraging the caller preferences [RFC3841] extension
and define a new media feature tag, service, in Section 6.
The SIP URI user name "sos" MUST NOT be assigned to any regular user.
4. Request Handling
Outbound proxy servers SHOULD check whether a tel URIs or a SIP URIs
containing a dial string represents an emergency number within its
geographic service area, but only if they can be reasonably certain
that the call originated from within that area, e.g., if the call
contained location information or the network is known to only be
reachable from a restricted geographic area. Typically, these
service areas encompass whole countries since many countries now have
nationwide emergency numbers. Once they recognize an emergency
number, they translate the Request-URI to an "sos" URI as described
above.
Schulzrinne Expires August 1, 2006 [Page 4]
Internet-Draft Emergency URI January 2006
The proxy MAY use any additional information contained in the call
request to recognize additional numbers as emergency numbers. Such
information includes the Mobile Country Code and the Mobile Network
Code for 3GPP devices or country information in location information
available about the call.
5. Alternative Approaches Considered
The "sos" SIP URI reserved user name proposed here follows the
convention of RFC 2142 [RFC2142] and the "postmaster" convention
documented in RFC 2822 [RFC2822]. The approach has the advantage
that only the home proxy for a user needs to understand the
convention and that the mechanism is likely backwards-compatible with
most SIP user agents, with the only requirement that they have to be
able to generate alphanumeric URLs. One drawback is that it may
conflict with locally assigned addresses of the form "sos@domain".
Also, if proxies not affiliated with the domain translate the URL,
they violate the current SIP protocol conventions.
There are a number of possible alternatives, each with their own set
of advantages and problems:
tel:NNN;context=+C This approach uses tel URIs [RFC3966]. Here, NNN
is the national emergency number, where the country is identified
by the context C. This approach is easy for user agents to
implement, but hard for proxies and other SIP elements to
recognize, as it would have to know about all number-context
combinations in the world and track occasional changes. In
addition, many of these numbers are being used for other services.
For example, the emergency number in Paraguay (00) is also used to
call the international operator in the United States. A number of
countries, such as Italy, use 118 as an emergency number, but it
also connects to directory assistance in Finland.
tel:sos This solution avoids name conflicts, but is not a valid "tel"
[RFC3966] URI. It also only works if every outbound proxy knows
how to route requests to a proxy that can reach emergency services
since tel URIs. The SIP URI proposed here only requires a user's
home domain to be appropriately configured.
urn:service:sos A related document [I-D.schulzrinne-sipping-service]
defines a URN for identifying services, such as emergency calling.
This solution fits most cleanly into the overall URI architecture,
can support a variety of protocols beyond SIP and avoids
dependencies on the home domain, but, like the tel URI solution
above, also requires that every outbound proxy can resolve this
URN and can route calls accordingly. Alternatively, the end
system has to be configured with a suitable URN-resolving proxy,
e.g., in its home domain.
Schulzrinne Expires August 1, 2006 [Page 5]
Internet-Draft Emergency URI January 2006
SIP URI user parameter: One could create a special URI, such as "aor-
domain;user=sos". This avoids the name conflict problem, but
requires mechanism-aware user agents that are capable of emitting
this special URI. Also, the 'user' parameter is meant to describe
the format of the user part of the SIP URI, which this usage does
not do. Adding other parameters still leaves unclear what, if
any, conventions should be used for the user and domain part of
the URL. Neither solution is likely to be backward-compatible
with existing clients.
Special domain: A special domain, such as "sip:fire@sos.int" could be
used to identify emergency calls. This has similar properties as
the "tel:sos" URI, except that it is indeed a valid URI. To make
this usable, the special domain would have to be operational and
point to an appropriate emergency services proxy. Having a
single, if logical, emergency services proxy for the whole world
seems to have undesirable scaling and administrative properties.
6. Media Feature Tag Registration: Service
Instead of defining additional, more specific, emergency services in
the SIP URI, we propose the use of a new media feature tag [RFC3840],
sip.service, that describe the desired emergency service.
For example, a user agent could request to be routed to marine rescue
by including the following header:
Accept-Contact: *;sip.service="sos.marine"
[Note: This mechanism fits with the Caller Preferences model, but
reduces the backward-compatibility of the overall approach.]
This specification defines an additional media feature tag, extending
the SIP tree entries described in [RFC3840] and following the
registration process in Section 12.1 of that document. This section
serves as the IANA registration for the service feature tags, which
are made into the SIP media feature tag tree.
This facility is not meant to encourage end users to select emergency
services where a single PSAP for all such services exist. Rather,
these identifiers reflect current practice in jurisdictions that
already have different numbers for the different emergency services.
For example, in Germany, ambulance and fire use 112, while police
uses 110.
We expect that users will rarely invoke specific emergency
services directly. Rather, they might be generated by outbound
proxy servers translating dial strings or be generated when
pressing icon-bearing speed dial buttons.
Schulzrinne Expires August 1, 2006 [Page 6]
Internet-Draft Emergency URI January 2006
Using feature tags has the advantage that they are not affected by
entities that translate URIs, e.g., to route emergency calls to a
specific PSAP.
The service types for this feature tag are case-insensitive.
Additional service types can be registered with IANA (Section
Section 7).
Media feature tag name: sip.service
ASN.1 Identifier: New assignment by IANA.
Summary of the media feature indicated by this tag: Each feature tag
indicates the type of communication service requested.
Values appropriate for use with this feature tag: Token with an
equality relationship. Initial values include a number of
emergency services:
sos: general emergency service
sos.fire: fire brigade
sos.marine: marine guard
sos.mountain: mountain rescue
sos.police: police (law enforcement)
sos.rescue: ambulance, emergency medical service
sos.test: testing, not a real emergency call
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application, for
describing the capabilities of a user agent providing a particular
type of communication service.
Examples of typical use: Allowing an emergency service proxy to
select the desired emergency service, such as police or ambulance.
Related standards or documents: RFC3840.
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC3840.
7. IANA Considerations
Subaddresses of the "sos" address are registered with IANA This
specification establishes the "sos" subaddres sub-registry under
http://www.iana.org/assignments/sip-parameters.
Subaddresses are registered by the IANA when they are published in
standards track RFCs. The IANA Considerations section of the RFC
must include the following information, which appears in the IANA
registry along with the RFC number of the publication.
o Name of the subaddress. The name MAY be of any length, but SHOULD
be no more than twenty characters long. The name MUST consist of
NVT alphanumeric characters only and is case-insensitive.
Schulzrinne Expires August 1, 2006 [Page 7]
Internet-Draft Emergency URI January 2006
o Descriptive text that describes the emergency service.
8. Security Considerations
The SIP specification [RFC3261] details security considerations that
apply to emergency calls as well. Security for emergency calls has
conflicting goals, namely to make it as easy and reliable as possible
to reach emergency services, while discouraging and possibly tracing
prank calls. It appears unlikely that classical authentication
mechanisms can be required by emergency call centers, but SIP proxy
servers may be able to add identifying information.
Given the sensitive nature of many emergency calls, it is highly
desirable to use the "sips" URI to ensure transport-level
confidentiality and integrity. However, this may cause the call to
fail in some environments.
Allowing the user agent to clearly and unambiguously identify
emergency calls makes it possible for the user agent to make
appropriate policy decisions. For example, a user agent policy may
reveal a different amount of information to the callee when making an
emergency call. Local laws may affect what information network
servers or service providers may be allowed or be required to release
to emergency call centers. They may also base their decision on the
user-declared destination of the call.
Recognizing only "sos" in the user's home domain, i.e., the domain of
the user's AOR, prevents spoofing where a link points to a fake
emergency calling number and leads the user to, for example, include
location information in the request.
Additional security considerations related to call routing,
destination authentication and other issues are detailed in
[I-D.ietf-ecrit-requirements] and [I-D.taylor-ecrit-security-
threats].
9. Acknowledgements
Andrew Allen, Keith Drage, Cullen Jennings, Mike Pierce, James Polk,
Brian Rosen, John Schnizlein and Hannes Tschofenig contributed
helpful comments.
10. References
10.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Schulzrinne Expires August 1, 2006 [Page 8]
Internet-Draft Emergency URI January 2006
[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.
[RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCP-for-IPv4) Option for Session Initiation Protocol
(SIP) Servers", RFC 3361, August 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
10.2 Informative References
[I-D.ietf-ecrit-requirements]
Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-02 (work in progress),
January 2006.
[I-D.schulzrinne-sipping-service]
Schulzrinne, H., "A Uniform Resource Name (URN) for
Services", draft-schulzrinne-sipping-service-01 (work in
progress), October 2005.
[I-D.taylor-ecrit-security-threats]
Schulzrinne, H., "Security Threats and Requirements for
Emergency Calling", draft-taylor-ecrit-security-threats-01
(work in progress), December 2005.
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS", RFC 2142, May 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
Schulzrinne Expires August 1, 2006 [Page 9]
Internet-Draft Emergency URI January 2006
Author's Address
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Schulzrinne Expires August 1, 2006 [Page 10]
Internet-Draft Emergency URI January 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schulzrinne Expires August 1, 2006 [Page 11]