Network Working Group                                     H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: August 8, 2004                                 February 8, 2004

       Emergency Services URI for the Session Initiation Protocol

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 8, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.


   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 8, 2004                 [Page 1]

Internet-Draft               Emergency URI                 February 2004

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Emergency URIs . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.1 SIP URIs for Emergency Calls . . . . . . . . . . . . . . . . .  6
   4.2 Tel URIs for Emergency Calls . . . . . . . . . . . . . . . . .  7
   5.  Request Handling . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Identifying the Local Emergency Numbers  . . . . . . . . . . .  9
   7.  Alternative Identifiers Considered . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
       Normative References . . . . . . . . . . . . . . . . . . . . . 14
       Informative References . . . . . . . . . . . . . . . . . . . . 15
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
       Intellectual Property and Copyright Statements . . . . . . . . 16

Schulzrinne              Expires August 8, 2004                 [Page 2]

Internet-Draft               Emergency URI                 February 2004

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.  The overall
   architecture is described in [schulzrinne-sipping-emergency-arch].
   That document describes, for example, how a device that identifies a
   call as an emergency call can route it to the appropriate emergency
   call center (ECC).

   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.

Schulzrinne              Expires August 8, 2004                 [Page 3]

Internet-Draft               Emergency URI                 February 2004

2. Terminology

   In this document, the key words "MUST", "MUSTNOT", "REQUIRED",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119] and indicate requirement levels for compliant

Schulzrinne              Expires August 8, 2004                 [Page 4]

Internet-Draft               Emergency URI                 February 2004

3. Requirements

   o  It should be possible for devices to provide user interfaces that
      can directly cause an emergency call, without the user having to
      "dial" or type a specific address.

   o  Even as each country is likely to operate their emergency calling
      infrastructure differently, SIP devices should be able to reach
      emergency help and, if possible, be located in any country.

   o  While traveling, users must be able to use their familiar "home"
      emergency identifier.  Users should also be able to dial the local
      emergency number in the country they are visiting.

   o  Any mechanism must be deployable incrementally and work even if
      not all SIP entities support emergency calling.  User agents
      conforming to the SIP specification [RFC3261], but unaware of this
      document, must be able to place emergency calls, possibly with
      restricted functionality.

   o  Given incremental deployment, emergency call functionality should
      be testable by the user without causing an emergency response.

   o  Emergency calling mechanisms must support existing emergency call
      centers based on circuit-switched technology as well as future ECC
      that are SIP-capable.

Schulzrinne              Expires August 8, 2004                 [Page 5]

Internet-Draft               Emergency URI                 February 2004

4. Emergency URIs

   A single, global (set of) identifiers 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.

   SIP user agents (UAs) that determine that a dialog or transaction
   relates to an emergency MUST use an emergency call identifier in the
   Request-URI.  The Request-URI MUST be either an emergency SIP URI
   defined in Section Section 4.1 or an emergency tel URI defined in
   Section Section 4.2.

4.1 SIP URIs for Emergency Calls

   It is RECOMMENDED that SIP-based [RFC3261] end systems and proxy
   servers support a uniform emergency call identifier, namely the
   reserved user name "sos" within any domain, e.g.,

   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.  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 addition, we reserve user addresses beginning with the string
   "sos." for specific emergency services:      fire brigade
   sos.rescue    ambulance (rescue)
   sos.marine    marine guard
   sos.police    police (law enforcement)
   sos.mountain  mountain rescue

   The sub-addresses are also case-insensitive.  Additional subaddresses

Schulzrinne              Expires August 8, 2004                 [Page 6]

Internet-Draft               Emergency URI                 February 2004

   can be registered with IANA (Section Section 8).

   (In some areas, these emergency services use different numbers.)

   The SIP URI user name "sos" and user names starting with "sos."
   MUSTNOT be assigned to any regular user.

4.2 Tel URIs for Emergency Calls

   User agents SHOULD determine the local emergency numbers, either by
   consulting their manual configuration for devices that do not move
   across national borders, by DHCP, DNS NAPTR or some other
   configuration mechanism [schulzrinne-sipping-emergency-arch].  If a
   user agent has no knowledge of local emergency numbers, it MUST also
   recognize the digit strings 000, 08, 112, 110, 118, 119, 911 and 999
   as emergency numbers.

   (SIP user agents, such as Ethernet deskphones, that are unlikely to
   move frequently across national borders can easily implement a local
   dialing plan that recognizes local emergency numbers.  Mobile
   devices, including PDAs and laptops, may not have a reliable way of
   determining their current location.  Using automatic configuration
   avoids collisions with extensions that equal one of the eight numbers
   above.  If a local network does not have an outbound proxy server,
   local dial plans also do not apply, so the problem of number
   collision does not arise.  Collisions with non-emergency service
   numbers are still possible, albeit less likely.  For example, 118 is
   used for directory assistance in Finland.)

   If the user dials any of these digit strings, the UAC SHOULD generate
   a request with the "sos" URI described in Section Section 4.1 unless
   it has discovered a local outbound proxy.  In that case, a UAC MAY
   use a "tel" URI [RFC2806] without 'phone-context', such as


   Outbound proxy servers MUST be configurable to recognize additional
   local emergency numbers in "tel" URIs.

      There are about 60 service numbers for emergency services in the
      world; including them all is not practical, as that would
      interfere with existing local two, three and four-digit dialing

Schulzrinne              Expires August 8, 2004                 [Page 7]

Internet-Draft               Emergency URI                 February 2004

5. Request Handling

   Once identified, a user agent can either determine the appropriate
   ECC locally or delegate this task to an outbound proxy.  Details are
   in [schulzrinne-sipping-emergency-arch].

   Outbound proxy servers MUST recognize all local emergency numbers as
   well as the tel URIs enumerated in Section Section 4.2. The proxy MAY
   use any additional information contained in the call request, such as
   Mobile Country Code and the Mobile Network Code for 3GPP devices, to
   recognize additional numbers as emergency numbers.

   It is RECOMMENDED that gateway SIP MESSAGE requests are directed to a
   TTY-for-the-deaf translator or a short-message service (SMS) if the
   emergency call center cannot handle SIP instant messaging.

   OPTIONS requests to the user "sos" and the "sos.*" addresses
   (, etc.) can be used to test if the "sos" addresses are
   valid. As in standard SIP, a 200 (OK) response indicates that the
   address was recognized and a 404 (Not found) that it was not.  Such
   request cause no further action.  It is RECOMMENDED that user agents
   periodically automatically check for the availability of the "sos"
   identifier and alert the user if the check fails.  The period of such
   automated checks SHOULDNOT be less than once per day and MUST be
   randomly placed over the testing interval.

Schulzrinne              Expires August 8, 2004                 [Page 8]

Internet-Draft               Emergency URI                 February 2004

6. Identifying the Local Emergency Numbers

   There are many ways that a user agent can configure emergency numbers
   for use in analyzing calls made with telephony-type user input.  Such
   numbers become part of the device dialplan.  Mechanisms include
   configuration tokens such as SIM cards in mobile devices,
   network-specific solutions (e.g., for 3GPP networks) or
   protocol-based solutions.  Protocol-based solutions, using XCAP and
   DNS, are discussed in [schulzrinne-sipping-emergency-arch.] Given the
   different trade-offs in user agent implementation complexity and
   deployment difficulty, it appears likely that multiple such
   mechanisms will co-exist.

Schulzrinne              Expires August 8, 2004                 [Page 9]

Internet-Draft               Emergency URI                 February 2004

7. Alternative Identifiers 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].  One drawback is that it may
   conflict with locally assigned addresses of the form "sos@somewhere".

   There are a number of possible alternatives, each with their own set
   of advantages and problems:

   tel:sos This solution avoids name conflicts, but is not a valid "tel"
      URI.  It also only works if every outbound proxy knows how to
      route requests to a proxy that can reach emergency services.  The
      SIP URI proposed here only requires a user's home domain to be
      appropriately configured.

   URI 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.

   Special domain: A special domain, such as "" could be
      used to identify emergency calls.  This has similar properties as
      the "tel:sos" URI, except that it is indeed a valid URI.

Schulzrinne              Expires August 8, 2004                [Page 10]

Internet-Draft               Emergency URI                 February 2004

8. IANA Considerations

   Subaddresses of the "sos" address are registered with IANA This
   specification establishes the "sos" subaddres sub-registry under

   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
      alphanumeric characters only and is case-insensitive.

   o  Descriptive text that describes the emergency service.

Schulzrinne              Expires August 8, 2004                [Page 11]

Internet-Draft               Emergency URI                 February 2004

9. 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.

   Additional security considerations related to call routing,
   destination authentication and other issues are detailed in

Schulzrinne              Expires August 8, 2004                [Page 12]

Internet-Draft               Emergency URI                 February 2004

10. Acknowledgements

   Andrew Allen, Keith Drage, Mike Pierce, James Polk, Brian Rosen and
   John Schnizlein contributed helpful comments.

Schulzrinne              Expires August 8, 2004                [Page 13]

Internet-Draft               Emergency URI                 February 2004

Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2806]  Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806,
              April 2000.

   [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.

Schulzrinne              Expires August 8, 2004                [Page 14]

Internet-Draft               Emergency URI                 February 2004

Informative References

              FUNCTIONS", RFC 2142, May 1997.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April

Author's Address

   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027

   Phone: +1 212 939 7042

Schulzrinne              Expires August 8, 2004                [Page 15]

Internet-Draft               Emergency URI                 February 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive

Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an

Schulzrinne              Expires August 8, 2004                [Page 16]

Internet-Draft               Emergency URI                 February 2004



   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Schulzrinne              Expires August 8, 2004                [Page 17]