Internet Engineering Task Force
Internet Draft Schulzrinne
Columbia U.
draft-schulzrinne-sipping-sos-01.txt
February 19, 2002
Expires: July 2002
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 February 19, 2002
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "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 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
numbers.
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
document.
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
USA
electronic mail: schulzrinne@cs.columbia.edu
Schulzrinne [Page 4]