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

Versions: 00 01 02 03 04                                                
Internet Engineering Task Force
Internet Draft                                               Schulzrinne
draft-schulzrinne-sipping-sos-00.txt                         Columbia U.
July 13, 2001
Expires: December 2001


      Universal Emergency Address for SIP-based Internet Telephony

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://www.ietf.org/ietf/1id-abstracts.txt

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

Abstract

   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                      July 13, 2001


   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   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.,


     sip:sos@local-domain



   Here, "local-domain" is replaced the local domain of the network to
   which the user agent is connected. For examle, if a UA is currently
   in the "example.com" domain, it would use sip:sos@example.com.

   In addition, user agents and proxies SHOULD also recognize the
   telephone number 911 and 112 for this purpose. Where feasible, user
   agents SHOULD recognize 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.

3 Request Handling

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

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


        The multicast mechanism differs slightly from standard SIP
        processing; the use of an outbound proxy conforms to



Schulzrinne                                                   [Page 2]


Internet Draft                    SOS                      July 13, 2001


        standard procedures. Multicast allows systems to make
        emergency calls with minimal configuration.

   Using a 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 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" 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.

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

4 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



Schulzrinne                                                   [Page 3]


Internet Draft                    SOS                      July 13, 2001


   Engineering Task Force, Mar. 1999.

5 Acknowledgements

   James Polk and Brian Rosen contributed helpful comments.

6 Authors' Addresses

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




































Schulzrinne                                                   [Page 4]