Network Working Group H. Schulzrinne
Internet-Draft Columbia U.
Expires: January 16, 2005 B. Rosen
Marconi
July 18, 2004
Emergency Services for Internet Telephony Systems
draft-schulzrinne-sipping-emergency-arch-01
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 16, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Summoning emergency help is a core feature of telephone networks.
This document describes how the Session Initiation Protocol (SIP) can
be used to provide advanced emergency services for voice-over-IP
(VoIP). The architecture employs standard SIP features and requires
no new protocol mechanisms. DNS is used to map civil and geospatial
locations to the appropriate emergency call center.
Schulzrinne & Rosen Expires January 16, 2005 [Page 1]
Internet-Draft Emergency Arch July 2004
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Identifying an Emergency Call . . . . . . . . . . . . . . . . 6
5. Location and Its Role in an Emergency Call . . . . . . . . . . 7
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 Types of Location Information . . . . . . . . . . . . . . 7
5.3 Sources of Location Information . . . . . . . . . . . . . 8
5.3.1 Manually-Entered Location Information . . . . . . . . 9
5.3.2 End-System Measured Location Information . . . . . . . 9
5.3.3 Third-party Measured Location Information . . . . . . 9
5.3.4 Conveying Location to End Systems . . . . . . . . . . 10
5.4 Using Location Information for Call Routing . . . . . . . 10
5.5 Address Verification . . . . . . . . . . . . . . . . . . . 10
6. Routing the Call to the PSAP . . . . . . . . . . . . . . . . . 11
6.1 Routing the First Request . . . . . . . . . . . . . . . . 11
6.2 DNS-based Mapping from Civic Coordinates to PSAP URIs . . 13
6.3 Updating Location Information . . . . . . . . . . . . . . 13
7. Signaling of Emergency Calls . . . . . . . . . . . . . . . . . 14
8. Preventing Call Misdirection . . . . . . . . . . . . . . . . . 14
9. Including a Valid Call-Back Identifier . . . . . . . . . . . . 14
10. Mid-Call Services and Behavior . . . . . . . . . . . . . . . 14
11. Requirements for SIP Proxy Servers . . . . . . . . . . . . . 15
12. Configuration . . . . . . . . . . . . . . . . . . . . . . . 15
13. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1 Testing Mechanism . . . . . . . . . . . . . . . . . . . . 16
13.2 Manual Testing . . . . . . . . . . . . . . . . . . . . . . 16
13.3 Automatic 'sos' Resolution Testing . . . . . . . . . . . . 17
14. Requirements for SIP User Agents . . . . . . . . . . . . . . 17
14.1 Emergency call taker . . . . . . . . . . . . . . . . . . . 17
14.2 Calling users . . . . . . . . . . . . . . . . . . . . . . 17
15. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 18
16. Alternatives Considered . . . . . . . . . . . . . . . . . . 18
16.1 tel URIs . . . . . . . . . . . . . . . . . . . . . . . . . 18
16.2 DHCP for Configuring the PSAP URI . . . . . . . . . . . . 18
17. Security Considerations . . . . . . . . . . . . . . . . . . 19
17.1 Caller Authentication . . . . . . . . . . . . . . . . . . 19
17.2 PSAP Impersonation . . . . . . . . . . . . . . . . . . . . 19
17.3 Call Signaling Integrity . . . . . . . . . . . . . . . . . 20
17.4 Media Integrity and Confidentiality . . . . . . . . . . . 20
17.5 PSAP Hiding . . . . . . . . . . . . . . . . . . . . . . . 20
18. Changes Since the Last Version . . . . . . . . . . . . . . . 20
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
19.1 Normative References . . . . . . . . . . . . . . . . . . . . 20
19.2 Informative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Schulzrinne & Rosen Expires January 16, 2005 [Page 2]
Internet-Draft Emergency Arch July 2004
Intellectual Property and Copyright Statements . . . . . . . . 25
Schulzrinne & Rosen Expires January 16, 2005 [Page 3]
Internet-Draft Emergency Arch July 2004
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Terminology
(Emergency) call taker: An emergency call taker is the person that
answers an emergency call, typically located in an emergency call
center.
ECC (emergency control center): Facilities used by emergency
organizations to accept and handle emergency calls. A PSAP
(below) forwards emergency calls to the emergency control center,
which dispatches polic, fire and rescue services. An ECC serves a
limited geographic area. A PSAP and ECC can be combined into one
facility.
ESRP (emergency service routing proxy): SIP proxy that routes
incoming emergency calls to the appropriate ECC.
PSAP (public safety answering point): Physical location where
emergency calls are received under the responsibility of a public
authority. (This terminology is used by both ETSI and NENA.) In
the United Kingdom, PSAPs are called Operator Assistance Centres,
in New Zealand Communications Centres.
SIP proxy: see [RFC3261].
SIP UA (user agent): see [RFC3261].
Stationary device (user): User agent that is connected to the network
at a fixed, long-term-stable geographic location. Examples
include a home PC or a payphone.
Nomadic device (user): User agent that is connected to the network
temporarily, for relatively short durations, but does not move
significantly during the lifetime of a network connection or
during the emergency call. Examples include a laptop using an
802.11 hotspot or a desk IP phone that is moved from one cubicle
to another.
Mobile device (user): User agent that changes geographic location and
possibly its network attachment point during an emergency call.
3. Overview
Summoning police, the fire department or an ambulance in emergencies
is one of the fundamental and most-valued functions of the telephone.
As telephone functionality moves from circuit-switched telephony to
Internet telephony, its users rightfully expect that this core
functionality works at least as well as for the older technology.
However, many of the technical advantages of Internet telephony
require re-thinking of the traditional emergency calling
architecture. This challenge also offers an opportunity to improve
Schulzrinne & Rosen Expires January 16, 2005 [Page 4]
Internet-Draft Emergency Arch July 2004
the working of emergency calling technology, while potentially
lowering its cost and complexity.
It is beyond the scope of this document to enumerate and discuss all
the differences between traditional (PSTN) and Internet telephony,
but the core differences can be summarized as separation of signaling
and media data, the emergence of application-independent carriers,
and the potential mobility of all end systems, including landline
systems and not just those using radio access technology.
This document focuses on how emergency call centers (PSAPs) (Section
2) can natively handle Internet telephony emergency calls, rather
than describing how circuit-switched PSAPs can handle VoIP calls.
However, in many cases, PSAPs making the transition from
circuit-switched interfaces to packet-switched interfaces may be able
to use some of the mechanisms described here, in combination with
gateways that translate packet-switched calls into legacy interfaces,
e.g., to continue to be able to use existing call taker equipment.
Existing emergency call systems are organized nationally; there are
currently no international standards. However, Internet telephony
does not respect national boundaries, and thus an international
standard is required.
Furthermore, VoIP endpoints can be connected through tunneling
mechanisms such as virtual private networks (VPNs). This
significantly complicates emergency calling, because the location of
the caller and the first element that routes emergency calls can be
on different continents, with different conventions and processes for
handling of emergency calls. The IETF has historically refused to
create national variants of its standards. Thus, this document
attempts to take into account best practices that have evolved for
circuit switched PSAPs, but makes no assumptions on particular
operating practices currently in use, numbering schemes or
organizational structures.
This document assumes that PSAP interface is using the Session
Initation Protocol (SIP). Use of a single protocol greatly
simplifies the design and operation of the emergency calling
infrastructure. Only peer-to-peer protocols such as H.323, ISUP and
SIP are suitable for inter-domain communications, ruling out
master-slave protocols such as MGCP or H.248/Megaco. The latter
protocols can natually be used by the enterprise or carrier placing
the call, but any such call would reach the PSAP through a media
gateway controller, similar to how interdomain VoIP calls would be
placed. Other signaling protocols may also use protocol translation
to communicate with a SIP-enabled PSAP.
Schulzrinne & Rosen Expires January 16, 2005 [Page 5]
Internet-Draft Emergency Arch July 2004
Existing emergency services rely exclusively on voice and
conventional text telephony (known as TDD in the United States) media
streams. However, more choices of media offer additional ways to
communicate, evaluate and assist callers and call takers to handle
emergency calls. For example, instant messaging and video could
improve the ability to evaluate the situation and provide appropriate
instruction prior to arrival of emergency crews. Thus, the
architecture described here supports the creation of sessions of any
media type, negotiated between the caller and PSAP using existing SIP
protocol mechanisms [RFC3264].
While, traditionally, emergency services have been summoned by voice
calls only, this document does not rule out the use of additional
media during an emergency call, both to support callers with
disabilities (e.g., through interactive text or video communications)
and to provide additional information to the call taker and caller.
For example, video from the caller to the PSAP may allow the call
taker to better assess the emergency situation; a video session from
the PSAP to the emergency caller may allow the call taker to provide
instructions for first aid.
The choice of media and encodings is negotiated on a call-by-call
basis using standard SIP mechanisms [RFC3264]. To ensure that at
least one common means of communications, this document recommends
certain minimal capabilities in Section 14 that call taker user
agents and PSAP-operated proxies should possess.
This document does not prescribe the detailed network architecture
for PSAPs or collection of PSAPs. For example, it does not describe
where PSAPs may place firewalls or how many SIP proxies they should
use.
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.
4. Identifying an Emergency Call
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, even though it is
often the same for a country or region (such as many countries in the
European Union). For end systems based on the Session Initiation
Protocol (SIP), it is desirable to have a universal identifier,
independent of location, to simplify the user experience, allow the
Schulzrinne & Rosen Expires January 16, 2005 [Page 6]
Internet-Draft Emergency Arch July 2004
automated inclusion of location information and to allow the device
and other entities in the call path to perform appropriate
processing.
As part of the overall emergency calling architecture, we define a
common user identifier, "sos", as the contact mechanism for emergency
assistance. We refer to this URI as the "emergency calling URI".
The calling user agent sets both the "To" header and the request-URI
to the emergency URI, so that entities after the ESRP can still
readily determine that this is an emergency call. Details are
described in [I-D.ietf-sipping-sos]. The draft also discusses how a
user agent or outbound proxy determines whether a dialed number
represents an emergency number and thus should be translated into a
"sos" URI.
In addition, user agents SHOULD detect emergency calls following
local emergency calling conventions. There are two local
conventions, namely those local to the user's SIP domain, e.g., a
user's network at work, and those at the caller's current geographic
location, e.g., while traveling. The former can be obtained using
SIP/XCAP and DNS configuration mechanisms (Section 12).
Location information can be provided by the user agent or a proxy. If
the user agent provides this information, the user agent needs to be
able to determine that a call is indeed an emergency call as it is
unlikely to include location information in each call.
5. Location and Its Role in an Emergency Call
5.1 Introduction
Caller location plays a central role in routing emergency calls. For
practical reasons, each PSAP generally handles only calls for a
certain geographic area. Other calls that reach it by accident must
be manually re-routed (transferred) to the appropriate PSAP,
increasing call handling delay and the chance for errors. The area
covered by each PSAP differs by jurisdiction, where some countries
have only a small number of PSAPs, while others devolve PSAP
responsibilities down to the community level.
In most cases, PSAPs cover at least a city or town, but there are
some areas where PSAP coverage areas follow old telephone rate center
boundaries and may straddle more than one city.
5.2 Types of Location Information
There are four primary types of location information: civic, postal,
geospatial, and cellular cell tower and sector.
Schulzrinne & Rosen Expires January 16, 2005 [Page 7]
Internet-Draft Emergency Arch July 2004
Civic: Civic location information describes the location of a person
or object by a floor and street address that corresponds to a
building or other structure. (This is sometimes also called
"civil" location information.)
Postal: Postal addresses are similar to civic addresses, but the may
contain post office boxes or street addresses that do not
correspond to an actual building. Also, the name of the post
office sometimes does not correspond to the actual community name.
Postal addresses are generally unsuitable for emergency call
routing, but may be the only address available to a service
provider, derived from billing records.
Geospatial: Geospatial addresses contain longitude, latitude and
altitude information.
Cell tower/sector: Cell tower and sectors identify the cell tower and
the antenna sector that the mobile device is currently using.
(Cell/sector information could also be transmitted as an
irregularly shaped polygon of geospatial coordinates reflecting
the likely geospatial location of the mobile device, but since
these boundaries are not sharp, transmitting the raw information
is probaby preferable.)
5.3 Sources of Location Information
Location information can be entered by the user or installer of a
device ("manual configuration"), can be measured by the end system,
can be conveyed to the end system or can be measured by a third party
and inserted into the call signaling. We discuss these in detail
below.
In some cases, an entity may have multiple sources of location
information, possibly partially contradictory. This is particularly
likely if the location information is determined both by the end
system and a third party. This document provides no recommendation
on how to reconcile conflicting location information or which one is
to be used by routing elements. Conflicting location information is
particularly harmful if it points to multiple distinct PSAPs. If
there is no other basis for choice, the ESRP SHOULD determine the
appropriate PSAP for all location objects and, if there is a
conflict, route based on the most accurate one.
To facilitate such policy decisions, location information SHOULD
contain information about the source of data, such as GPS, manually
entered or based on subscriber address information. In addition, the
author of the location information SHOULD be included.
TBD: SIP system should indicate which location information has been
used for routing, so that the same location information is used for
all call routing decisions. Otherwise, two proxies might pick
Schulzrinne & Rosen Expires January 16, 2005 [Page 8]
Internet-Draft Emergency Arch July 2004
different location information from the call request, each pointing
to the other one.
End systems and network elements can derive location information from
a variety of sources. It is not the goal of this document to
exhaustively enumerate them, but we provide a few common examples in
the sections below.
5.3.1 Manually-Entered Location Information
Location information can be maintained by the end user or the
installer of a network connection ("wire database"). In LANs, wire
databases map Ethernet switch ports to office locations. In DSL
installations, the local telephone carrier maintains a mapping of
wire pairs to subscriber addresses.
Even for IEEE 802.11 wireless access points, wire data bases may
provide sufficient location accuracy.
Location information added by end users is almost always inferior to
measured or wire database information, as users may mistype civic
location information, may not know the meaning of geospatial
coordinates or may use address information that does not correspond
to a recognized civic address.
Wire databases are likely to be the most promising solution for
residential users where a service provider knows the customer's
service address. The service provider can then perform address
verification, similar to the current system in some jurisdictions.
5.3.2 End-System Measured Location Information
GPS: Global Positioning System (GPS) information is generally only
available where there is a clear view of a large swath of the sky.
It is accurate to tens of feet.
5.3.3 Third-party Measured Location Information
Wireless triangulation: Elements in the network infrastructure
triangulate end systems based on signal strength or time of
arrival. Signal strength may be reported by access points,
special measurement devices or the end systems.
Location beacons: A short range wireless beacon, e.g., using
BlueTooth or infrared, announces its location to mobile devices in
the vicinity.
Schulzrinne & Rosen Expires January 16, 2005 [Page 9]
Internet-Draft Emergency Arch July 2004
5.3.4 Conveying Location to End Systems
Unless a user agent has access to locally measured location
information, it MUST use DHCP to obtain location information. DHCP
can deliver civic [I-D.ietf-geopriv-dhcp-civil] or geospatial
[I-D.ietf-geopriv-dhcp-lci-option] information. User agents MUST
support both formats. Note that a user agent can use DHCP, via the
INFORM request, even if it uses other means to acquire its IP
address.
5.4 Using Location Information for Call Routing
Since all existing emergency services have limited geographic and
jurisdictional coverage, all emergency calls need to be routed to the
appropriate PSAP. Rather than to the geographically closest PSAP,
calls need to be directed to the most jurisdictionally appropriate
one, which may well be further away.
Location information may not be available at call setup time. For
example, if a GPS-enabled cell phone is turned on and then
immediately places an emergency call, it can take an additional 20-25
seconds before the cell phone acquires a GPS fix and its location.
Thus, while it is necessary and expedient to include caller location
information in the call setup message, this is not sufficient in all
circumstances. In some cases, the initial call setup will proceed
based on, for example, cell and sector information and then add
location information during the call, rather than delaying the
initial call setup by an unacceptable amount of time.
In addition, the location of a mobile caller, e.g., in a vehicle or
aircraft, can change significantly during the emergency call.
5.5 Address Verification
Users of SIP endpoints must be able to verify that their address is
valid ahead of an actual emergency call. For example, in the United
States, the Master Street Address Guide (MSAG) records all valid
street addresses and is used to ensure that phone billing records
correspond to valid emergency service street addresses.
There are several ways to verify this information, depending on its
source. If the location information is provided by the network
service provider via DHCP, SIP end systems SHOULD display this
information at boot-up and at regular intervals thereafter to allow
users to confirm that the information is correct.
If the DNS emergency services directory contains street-level
addresses rather than just towns or