Network Working Group                                     H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: April 26, 2006                                 October 23, 2005

       Emergency Services URI for the Session Initiation Protocol

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-

   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

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

   This Internet-Draft will expire on April 26, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   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 April 26, 2006                 [Page 1]

Internet-Draft                Emergency URI                 October 2005

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   Requirements . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.   Emergency URIs . . . . . . . . . . . . . . . . . . . . . . .   4
   5.   Identifying the Local Emergency Numbers  . . . . . . . . . .   5
   6.   Request Handling . . . . . . . . . . . . . . . . . . . . . .   6
   7.   Alternative Approaches Considered  . . . . . . . . . . . . .   6
   8.   Media Feature Tag Registration: Service  . . . . . . . . . .   7
   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   8
   10.  Security Considerations  . . . . . . . . . . . . . . . . . .   8
   11.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .   9
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .   9
     12.1   Normative References . . . . . . . . . . . . . . . . . .   9
     12.2   Informative References . . . . . . . . . . . . . . . . .  10
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  10
        Intellectual Property and Copyright Statements . . . . . . .  11

Schulzrinne              Expires April 26, 2006                 [Page 2]

Internet-Draft                Emergency URI                 October 2005

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

   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",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119] and indicate requirement levels for compliant

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.

Schulzrinne              Expires April 26, 2006                 [Page 3]

Internet-Draft                Emergency URI                 October 2005

   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 should be able to use their familiar "home"
      emergency number.  Users must 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.

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

   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,

   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

Schulzrinne              Expires April 26, 2006                 [Page 4]

Internet-Draft                Emergency URI                 October 2005

      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

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

   The SIP URI user name "sos" MUST NOT be assigned to any regular user.

   Outbound proxy servers MUST be configurable to recognize additional
   emergency numbers valid in their geographic service area in "tel"

      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

5.  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 [I-D.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.

   Regardless of the mechanism chosen and whether any of the
   configuration mechanisms succeed, the digit strings "112" and "911"
   MUST always be recognized as emergency numbers.

   User agents SHOULD allow users and/or administrators to configure
   additional emergency numbers.

   User agents SHOULD attempt to ascertain the set of emergency numbers
   that are valid in the geographic region that the user agent is
   currently located in.  Two such mechanisms included XCAP and DNS,
   discussed in [I-D.schulzrinne-sipping-emergency-arch].

Schulzrinne              Expires April 26, 2006                 [Page 5]

Internet-Draft                Emergency URI                 October 2005

   If and only if an end system is unable to determine the emergency
   numbers valid in its current geographical location, it SHOULD
   recognize any of the number 000, 08, 110, 999, 118 and 119 as
   emergency numbers.  Since these numbers are also used for non-
   emergency purposes, their automatic transformation incurs the risk of
   accidentally dialing an emergency number when, for example, directory
   assistance was desired.  To minimize such mistakes, end systems
   SHOULD alert users that they are dialing a recognized emergency

      This behavior corresponds to the guidelines in 3GPP TS 22.101.
      Since general SIP end points cannot be assumed to have SIMs or
      USIMs, this document uses the default list (000, 08, 110, 999, 118
      and 119) only if no other configuration information about
      geographically local emergency numbers is available.

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

   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, The [I-D.schulzrinne-sipping-emergency-
   arch] document describes a possible DNS-based mechanism to obtain
   country-specific 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.

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

Schulzrinne              Expires April 26, 2006                 [Page 6]

Internet-Draft                Emergency URI                 October 2005

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

8.  Media Feature Tag Registration: Service

   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 uniform ECC 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.
      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 ECC.

   The service types for this feature tag are case-insensitive.

Schulzrinne              Expires April 26, 2006                 [Page 7]

Internet-Draft                Emergency URI                 October 2005

   Additional service types can be registered with IANA (Section
   Section 9).

   Media feature tag name: sip.emergency-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 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.

9.  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
      NVT alphanumeric characters only and is case-insensitive.
   o  Descriptive text that describes the emergency service.

10.  Security Considerations

   The SIP specification [RFC3261] details security considerations that

Schulzrinne              Expires April 26, 2006                 [Page 8]

Internet-Draft                Emergency URI                 October 2005

   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

11.  Acknowledgements

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

12.  References

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

   [RFC3361]  Schulzrinne, H., "Dynamic Host Configuration Protocol

Schulzrinne              Expires April 26, 2006                 [Page 9]

Internet-Draft                Emergency URI                 October 2005

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

12.2  Informative References

              Schulzrinne, H. and B. Rosen, "Emergency Services for
              Internet Telephony Systems",
              draft-schulzrinne-sipping-emergency-arch-02 (work in
              progress), October 2004.

              Schulzrinne, H., "A Uniform Resource Name (URN) for
              Services", draft-schulzrinne-sipping-service-00 (work in
              progress), July 2005.

              FUNCTIONS", RFC 2142, May 1997.

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

Author's Address

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

   Phone: +1 212 939 7004

Schulzrinne              Expires April 26, 2006                [Page 10]

Internet-Draft                Emergency URI                 October 2005

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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


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

Schulzrinne              Expires April 26, 2006                [Page 11]