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]