[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
Internet Engineering Task Force
Internet Draft                                               Schulzrinne
                                                             Columbia U.
February 19, 2002
Expires: July 2002

      Universal Emergency Address for SIP-based Internet Telephony


   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-

   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

   To view the list Internet-Draft Shadow Directories, see


   This document defines a universal emergency SIP URL, sip:sos@domain,
   that allows SIP user agents to contact the local emergency number.

1 Introduction

   Using the 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. For SIP-based end
   systems, 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.

1.1 Terminology

Schulzrinne                                                   [Page 1]

Internet Draft                    SOS                  February 19, 2002

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
   indicate requirement levels for compliant SIP implementations.

2 Emergency URL

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


   Here, "local-domain" is replaced the local domain of the network to
   which the user agent is connected. For example, if a UA is currently
   in the "example.com" domain, it would use sip:sos@example.com.  If
   the system does not know the local domain, it MAY use the domain from
   its address-of-record.

   In addition, user agents and proxies SHOULD also recognize the
   telephone numbers 911 and 112, expressed as a tel URL  such as
   tel:911 and tel:112, for this purpose. Where feasible, user agents
   SHOULD recognize additional, local emergency numbers. Outbound proxy
   servers MUST be configurable to recognize additional local emergency
   numbers. [? TBD]

        There are about 60 short 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 plans.

   In addition, we define subaddresses of sos, sos.fire, sos.rescue,
   sos.police, to represent the local fire, rescue (ambulance) and
   police emergency contacts, respectively.

        In some areas, these emergency services use different

3 Request Handling

   A user agent SHOULD direct such a request to a outbound proxy server,
   if configured, or send the request to the SIP multicast address.

Schulzrinne                                                   [Page 2]

Internet Draft                    SOS                  February 19, 2002

   It is possible that there are several SIP proxies listening to the
   same multicast address, each routing the request independently to
   different emergency call centers. Proxies in such configurations MUST
   take steps to prevent this from occuring, for example to route the
   call based on the caller's identity or location. Determining and
   conveying the location of the caller is beyond the scope of this

        The multicast mechanism differs slightly from standard SIP
        processing; the use of an outbound proxy conforms to
        standard procedures. Multicast allows systems to make
        emergency calls with minimal configuration.

   Using a proxy server that is local to the user agent is more likely
   to reach a geographically local server, although that is not
   guaranteed if virtual private networks are being used.

   The "sos" user name and user names starting with "sos." MUST NOT be
   assigned to any regular user. It is RECOMMENDED that SIP MESSAGE
   requests are directed to a TTY-for-the-deaf translator.

   User agent servers and proxy servers MUST NOT require that the user
   agent client be registered or authenticated in order to place an
   emergency call.

   For testing purposes, OPTIONS messages to the user "sos" and the
   "sos.*" addresses (sos.fire, etc.) SHOULD return an indication
   whether the address is defined, but 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 SHOULD NOT be less than
   once per day and MUST be randomly placed over the testing interval.

   Any proxy, outbound or otherwise, that receives such a request MUST
   forward (proxy) or redirect the request to the appropriate local
   emergency number (e.g., 911 in the United States or 112 in Europe).
   Typically, the proxy server routes the call to an appropriate PSTN
   gateway, translating the request URI to the local emergency number.
   Any SIP PSTN gateway shall translate this emergency identifier to the
   locally supported emergency number.

   If a proxy receives a "sos.*" request (such as sos.fire), the proxy
   forwards it to the appropriate emergency service. If it does not
   recognize the suffix (e.g., fire), it MUST forward the request to the
   appropriate general emergency contact, handling it as if the address
   was "sos".

Schulzrinne                                                   [Page 3]

Internet Draft                    SOS                  February 19, 2002

   It is beyond the scope of this document how the proxy determines the
   appropriate public safety answering point or how it determines the
   physical location of the SIP UA making the request.

   TBD: Should something like sip:sos@localhost be supported, for SIP
   phones that do not know which is the local domain? (Generally, SIP
   UAs would determine this information via DHCP or inverse DNS lookup
   of their IP address.) Alternatively, should a UA always use the AOR
   domain if the UA knows that sos is supported "at home"? This avoids
   that a non-sos-supporting local proxy bounces the request, but still
   allows intercept by the outbound proxy.

4 Security Considerations

   The SIP specification [2] details a number of security
   considerations. 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.

5 Bibliography

   [1] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments 2119, Internet Engineering Task Force,
   Mar. 1997.

   [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments 2543, Internet
   Engineering Task Force, Mar. 1999.

   A. Vaha-Sipila, "URLs for telephone calls," Request for Comments
   2806, Internet Engineering Task Force, Apr. 2000.

6 Acknowledgements

   James Polk and Brian Rosen contributed helpful comments.

7 Authors' Addresses

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027
   electronic mail:  schulzrinne@cs.columbia.edu

Schulzrinne                                                   [Page 4]