draft-ietf-ecrit-framework-02.txt   draft-ietf-ecrit-framework-03.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track H. Schulzrinne Intended status: Standards Track H. Schulzrinne
Expires: January 9, 2008 Columbia U. Expires: March 22, 2008 Columbia U.
J. Polk J. Polk
Cisco Systems Cisco Systems
A. Newton A. Newton
SunRocket TranTech/MediaSolv
July 08, 2007 September 19, 2007
Framework for Emergency Calling using Internet Multimedia Framework for Emergency Calling using Internet Multimedia
draft-ietf-ecrit-framework-02 draft-ietf-ecrit-framework-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 9, 2008. This Internet-Draft will expire on March 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Summoning emergency help by the public is a core feature of telephone The IETF has several efforts targeted at standardizing various
networks. This document describes how various IETF protocols and aspects of placing emergency calls. This document describes how all
mechanisms are combined to place emergency calls. This includes how of those component parts are used to support emergency calls from
these calls are routed to the correct Public Safety Answering Point citizens and visitors to authorities.
(PSAP) based on the physical location of the caller, while providing
the call taker the necessary information to dispatch a first
responder to that location and to call back the caller if necessary.
It describes at a high level how the pieces (recognizing a call as an
emergency call, marking it as such, determining the location of the
caller, routing the call based on location) go together, and
references the Internet standards that define the details of these
mechanisms.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of How Emergency Calls are Placed . . . . . . . . . . 7 3. Overview of how emergency calls are placed . . . . . . . . . . 7
4. Identifying an Emergency Call . . . . . . . . . . . . . . . . 12 4. Which devices and services should support emergency calls . . 11
5. Location and Its Role in an Emergency Call . . . . . . . . . . 12 5. Identifying an emergency call . . . . . . . . . . . . . . . . 11
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 13 6. Location and its role in an emergency call . . . . . . . . . . 13
5.2. Types of Location Information . . . . . . . . . . . . . . 13 6.1. Types of location information . . . . . . . . . . . . . . 14
5.3. Location Determination . . . . . . . . . . . . . . . . . . 14 6.2. Location Determination . . . . . . . . . . . . . . . . . . 16
5.3.1. User-Entered Location Information . . . . . . . . . . 15 6.2.1. User-entered location information . . . . . . . . . . 16
5.3.2. Access Network "Wire Database" Location Information . 15 6.2.2. Access network "wire database" location information . 17
5.3.3. End-System Measured Location Information . . . . . . . 16 6.2.3. End-system measured location information . . . . . . . 17
5.3.4. Third-party Measured Location Information . . . . . . 16 6.2.4. Network measured location information . . . . . . . . 18
5.4. Location and References to Location . . . . . . . . . . . 17 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 18
5.5. End System Location Configuration . . . . . . . . . . . . 17 6.4. Location and references to location . . . . . . . . . . . 19
5.6. Conveyance of Location . . . . . . . . . . . . . . . . . . 19 6.5. End system location configuration . . . . . . . . . . . . 19
5.7. Location Updates . . . . . . . . . . . . . . . . . . . . . 19 6.6. When location should be configured . . . . . . . . . . . . 21
5.8. Location Validation . . . . . . . . . . . . . . . . . . . 20 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 22
5.9. Default Location . . . . . . . . . . . . . . . . . . . . . 21 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 22
5.10. Uninitialized Devices and Location . . . . . . . . . . . . 21 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 23
6. Routing the Call to the PSAP . . . . . . . . . . . . . . . . . 21 6.10. Location validation . . . . . . . . . . . . . . . . . . . 23
7. Signaling of Emergency Calls . . . . . . . . . . . . . . . . . 23 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 24
8. Caller Preferences . . . . . . . . . . . . . . . . . . . . . . 23 6.12. Other location considerations . . . . . . . . . . . . . . 24
9. Including a Valid Call-Back Identifier . . . . . . . . . . . . 23 7. Uninitialized devices . . . . . . . . . . . . . . . . . . . . 24
10. Mid-Call Services and Behavior . . . . . . . . . . . . . . . . 24 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 25
11. Call Termination . . . . . . . . . . . . . . . . . . . . . . . 24 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 26
12. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 26
13. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.2. SIP signaling requirements for User Agents . . . . . . . 27
14. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 25 9.3. SIP signaling requirements for proxy servers . . . . . . . 27
15. Alternatives Considered . . . . . . . . . . . . . . . . . . . 25 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 27
15.1. tel URIs . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 28
16. Security Considerations . . . . . . . . . . . . . . . . . . . 26 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 28
16.1. Caller Authentication . . . . . . . . . . . . . . . . . . 27 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 28
16.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 27 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
16.3. PSAP Impersonation . . . . . . . . . . . . . . . . . . . . 28 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
16.4. Preventing Call Misdirection . . . . . . . . . . . . . . . 28 16. Security Considerations . . . . . . . . . . . . . . . . . . . 29
16.5. Call Signaling Integrity . . . . . . . . . . . . . . . . . 28 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
16.6. Media Integrity and Confidentiality . . . . . . . . . . . 28 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 18.1. Normative References . . . . . . . . . . . . . . . . . . . 30
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 18.2. Informative References . . . . . . . . . . . . . . . . . . 34
18.1. Normative References . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
18.2. Informative References . . . . . . . . . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 34
1. Terminology 1. Terminology
As a framework document, we do not define any new protocols or The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
articulate new behaviors. Thus we do not use RFC2119 [RFC2119] "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
notation. The following terms are used: document are to be interpreted as described in [RFC2119].
(Emergency) call taker: see [I-D.ietf-ecrit-requirements]
ESRP (emergency service routing proxy): see This document uses terms from [RFC3261] and
[I-D.ietf-ecrit-requirements] [I-D.ietf-ecrit-requirements]. In addition the following terms are
Access Network: The network that supplies IP packet service to an used:
Access network: The network that supplies IP packet service to an
endpoint. In a residential or small business environment, this endpoint. In a residential or small business environment, this
might be a DSL or cable modem or WiMax service. In a large might be a DSL or cable modem or WiMax service. In a large
enterprise environment, this would be the enterprise network. In enterprise environment, this would be the enterprise network. In
a mobile environment, this might be a mobile (cellular) data a mobile environment, this might be a mobile (cellular) data
network or a WiFi network. network or a WiFi network
Location Configuration: The process by which an endpoint learns its (Emergency) Call taker: The person who answers an emergency call at
physical location. the PSAP
Location Conveyance: The process of sending location to another Confidence The mathematically derived statistical estimate
element. indicating how sure the measuring system is that the location data
Location Determination: The process of finding where an endpoint is estimate is accurate, within the bounds defined by the Uncertainty
value. This is expressed as a percentage, such as 90%, or 45%
etc.
Dispatch Location Location used for dispatching responders to the
person in need of assistance. Must be precise as opposed to that
needed for Routing Location.
Emergency services routing proxy (ESRP): A proxy server that
provides routing services for a group of PSAPs
Location configuration: The process where an endpoint learns its
physical location
Location conveyance: The process of sending location to another
element
Location determination: The process of finding where an endpoint is
physically. For example, the endpoint may contain a GPS receiver physically. For example, the endpoint may contain a GPS receiver
used to measure its own location. used to measure its own location or location may be determined by
Location Information Server: An element that stores location administration using a wiremap database or similar
Location Information Server (LIS): An element that stores location
information for retrieval by an authorized entity information for retrieval by an authorized entity
Location Validation: see [I-D.ietf-ecrit-requirements] Mobile device: User agent that changes geographic location and
Mapping: see [I-D.ietf-ecrit-requirements] possibly its network attachment point during an emergency call
NENA (National Emergency Number Association): A North American NENA (National Emergency Number Association): A North American
organization of public safety focused individuals defining organization of public safety focused individuals defining
emergency calling specifications and procedures. emergency calling specifications and procedures
PSAP (public safety answering point): see
[I-D.ietf-ecrit-requirements]
SIP B2BUA: see [RFC3261]
SIP proxy: see [RFC3261]
SIP Server: see [RFC3261]
SIP UA (user agent): see [RFC3261]
Stationary device (user): An immobile 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 Nomadic device (user): User agent that is connected to the network
temporarily, for relatively short durations, but does not move temporarily, for relatively short durations, but does not move
significantly during the lifetime of a network connection or significantly during the lifetime of a network connection or
during the emergency call. Examples include a laptop using an during the emergency call. Examples include a laptop using an
IEEE 802.11 hotspot or a desk IP phone that is moved from one IEEE 802.11 hotspot or a desk IP phone that is moved from one
cubicle to another. cubicle to another
Mobile device (user): User agent that changes geographic location Routing Location: The location of an endpoint that is used for
and possibly its network attachment point during an emergency routing an emergency call. May not be as precise as the Dispatch
call. Location.
Stationary device: An immobile user agent that is connected to the
network at a fixed, long-term-stable geographic location.
Examples include a home PC or a pay phone
Uncertainty The mathematically derived statistical estimate,
expressed in meters, indicating the size of the area used in the
calculation of Confidence.
2. Introduction 2. Introduction
Summoning police, the fire department or an ambulance in emergencies Requesting help in an emergency using a communications device such as
is one of the fundamental and most-valued functions of the telephone. a telephone or mobile is an accepted practice in most of the world.
As telephone functionality moves from circuit-switched telephony to As communications devices increasingly utilize the Internet to
Internet telephony, its users rightfully expect that this core interconnect and communicate, users will continue to expect to use
functionality will continue to work at least as well as it has for such devices to request help, regardless of whether or not they
the older technology. New devices and services are being made communicate using IP. This document describes establishment of a
available which could be used to make a request for help which are communications session by a user to a "Public Safety Answering Point"
not traditional telephones, and users are increasingly expecting them (PSAP) that is a call center established by response agencies to
to be used to place emergency calls. However, many of the technical accept emergency calls. Such citizen/visitor-to-authority calls can
advantages of Internet multimedia require re-thinking of the be distinguished from those that are created by responders
traditional emergency calling architecture. This challenge also (authority-to-authority) using public communications infrastructure
offers an opportunity to improve the operation of emergency calling often involving some kind of priority access as defined in Emergency
technology, while potentially lowering its cost and complexity. Telecommunications Service (ETS) in IP Telephony [RFC4190]. They
also can be distinguished from emergency warning systems that are
authority-to-citizen.
Supporting emergency calling requires cooperation by a number of
elements, their vendors and service providers. It discusses how end
device and applications create emergency calls, how access networks
supply location for some of these devices, how service providers
assist the establishment and routing, and how PSAPs receive calls
from the Internet.
The emergency response community will have to upgrade their
facilities to support the wider range of communications services, but
cannot be expected to handle wide variation in device and service
capability. New devices and services are being made available that
could be used to make a request for help that are not traditional
telephones, and users are increasingly expecting them to be used to
place emergency calls. However, many of the technical advantages of
Internet multimedia require re-thinking of the traditional emergency
calling architecture. This challenge also offers an opportunity to
improve the operation of emergency calling technology, while
potentially lowering its cost and complexity.
It is beyond the scope of this document to enumerate and discuss all It is beyond the scope of this document to enumerate and discuss all
the differences between traditional (PSTN) and IP based telephony, the differences between traditional (Public Switched Telephone
but calling on the Internet is characterized by: Network) and IP based telephony, but calling on the Internet is
o the interleaving of signaling and media data packets; characterized by:
o the interleaving over the same infrastructure of a wider variety o the interleaving over the same infrastructure of a wider variety
of services; of services;
o the separation of the access provider from the application o the separation of the access provider from the application
provider; provider;
o the plethora of different media that can be accommodated; o the plethora of different media that can be accommodated;
o potential mobility of all end systems, including endpoints o potential mobility of all end systems, including endpoints
nominally thought of as fixed systems and not just those using nominally thought of as fixed systems and not just those using
radio access technology. For example, a wired phone connected to radio access technology. For example, a wired phone connected to
a router using a mobile data network such as EV-DO as an uplink; a router using a mobile data network such as EV-DO as an uplink.
This document focuses on how devices using the Internet can place This document focuses on how devices using the Internet can place
emergency calls and how PSAPs can handle Internet multimedia emergency calls and how PSAPs can handle Internet multimedia
emergency calls natively, rather than describing how circuit-switched emergency calls natively, rather than describing how circuit-switched
PSAPs can handle VoIP calls. In many cases, PSAPs making the PSAPs can handle VoIP calls. In many cases, PSAPs making the
transition from circuit-switched interfaces to packet-switched transition from circuit-switched interfaces to packet-switched
interfaces may be able to use some of the mechanisms described here, interfaces may be able to use some of the mechanisms described here,
in combination with gateways that translate packet-switched calls in combination with gateways that translate packet-switched calls
into legacy interfaces, e.g., to continue to be able to use existing into legacy interfaces, e.g., to continue to be able to use existing
call taker equipment. call taker equipment. There are many legacy telephone networks that
will persist long after most systems have been upgraded to IP
We distinguish an individual request for help, usually accomplished origination and termination of emergency calls. There will be PSAPs
by dialing a short digit sequence like 9-1-1 or 1-1-2, from a call that require new systems to terminate to existing mechanisms for some
placed by specially designated persons who have authority to claim time. Many of these legacy systems use telephone number based
priority on available Internet communications facilities. This routing. Gateways and conversions between existing systems and newer
document only discusses a request for help by an ordinary user systems defined by this document will be required. Since existing
answered at an emergency call center (i.e. a PSAP). systems are governed primarily by local government regulations and
national standards, the gateway and conversion details will be
governed by national standards and thus are out of scope for this
document.
Existing emergency call systems are organized locally or nationally; Existing emergency call systems are organized locally or nationally;
there are currently no international standards. However, the there are currently no international standards. However, the
Internet crosses national boundaries, and thus international Internet crosses national boundaries, and thus international
standards for equipment and software are required. To further standards for equipment and software are required. To further
complicate matters, VoIP endpoints can be connected through tunneling complicate matters, VoIP endpoints can be connected through tunneling
mechanisms such as virtual private networks (VPNs). This mechanisms such as virtual private networks (VPNs). Tunnels can
significantly complicates emergency calling, because the location of obscure the identity of the actual access network that knows the
the caller and the first element that routes emergency calls can be location. This significantly complicates emergency calling, because
on different continents, with different conventions and processes for the location of the caller and the first element that routes
handling of emergency calls. 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 The IETF has historically refused to create national variants of its
standards. Thus, this document attempts to take into account best standards. Thus, this document attempts to take into account best
practices that have evolved for circuit switched PSAPs, but makes no practices that have evolved for circuit switched PSAPs, but makes no
assumptions on particular operating practices currently in use, assumptions on particular operating practices currently in use,
numbering schemes or organizational structures. numbering schemes or organizational structures.
This document discusses the use of the Session Initiation Protocol This document discusses the use of the Session Initiation Protocol
(SIP) [RFC3261] by PSAPs and calling parties. While other inter- (SIP) [RFC3261] by PSAPs and calling parties. While other inter-
domain call signaling protocols may be used for emergency calling, domain call signaling protocols may be used for emergency calling,
SIP is ubiquitous and possesses, through its related specifications SIP is ubiquitous and possesses the proper support of this use case.
the proper support of this use case. Only protocols such as H.323, Only protocols such as H.323, XMPP/Jingle, ISUP and SIP are suitable
XMPP/Jingle, ISUP and SIP are suitable for inter-domain for inter-domain communications, ruling out MGC protocols such as
communications, ruling out MGC protocols such as MGCP or H.248/ MGCP or H.248/Megaco. The latter protocols can naturally be used by
Megaco. The latter protocols can naturally be used by the enterprise the enterprise or carrier placing the call, but any such call would
or carrier placing the call, but any such call would reach the PSAP reach the PSAP through a media gateway controller, similar to how
through a media gateway controller, similar to how interdomain VoIP inter-domain VoIP calls would be placed. Other signaling protocols
calls would be placed. Other signaling protocols may also use may also use protocol translation to communicate with a SIP-enabled
protocol translation to communicate with a SIP-enabled PSAP. PSAP.
Existing emergency services rely exclusively on voice and Existing emergency services rely exclusively on voice and
conventional text telephony ("TTY") media streams. However, more conventional text telephony ("TTY") media streams. However, more
choices of media offer additional ways to communicate and evaluate choices of media offer additional ways to communicate and evaluate
the situation as well as to assist callers and call takers in the situation as well as to assist callers and call takers in
handling emergency calls. For example, instant messaging and video handling emergency calls. For example, instant messaging and video
could improve the ability to communicate and evaluate the situation could improve the ability to communicate and evaluate the situation
and to provide appropriate instruction prior to arrival of emergency and to provide appropriate instruction prior to arrival of emergency
crews. Thus, the architecture described here supports the creation crews. Thus, the architecture described here supports the creation
of sessions of any media type, negotiated between the caller and PSAP of sessions of any media type, negotiated between the caller and PSAP
using existing SIP protocol mechanisms [RFC3264]. To ensure that, using existing SIP protocol mechanisms [RFC3264].
[I-D.ietf-ecrit-phonebcp] recommends certain minimal capabilities in
that call taker user agents and PSAP-operated proxies should possess.
Supporting emergency calling does not require any new SIP header Supporting emergency calling does not require any specialized SIP
fields, request methods, status codes, message bodies, or event header fields, request methods, status codes, message bodies, or
packages. User agents unaware of the recommendations in this draft event packages, but does require that existing mechanisms be used in
may be able to place emergency calls, but functionality may be certain specific ways, as described below. User agents unaware of
impared. For example, if the UA does not implement the location the recommendations in this draft may be able to place emergency
mechanisms described, an emergency call may not be routed to the calls, but functionality may be impaired. For example, if the UA
correct PSAP, and if the caller is unable to supply his exact does not implement the location mechanisms described, an emergency
location, response may be delayed. Suggested behavior for both call may not be routed to the correct PSAP, and if the caller is
endpoints and servers is provided unable to supply his exact location, dispatch of emergency responders
may be delayed. Suggested behavior for both endpoints and servers is
provided.
3. Overview of How Emergency Calls are Placed From the point of view of the PSAP three essential elements
characterize an emergency call:
o The call is routed to the most appropriate PSAP, selected
principally by the location of the caller.
o The PSAP must be able to automatically obtain the location of the
caller sufficiently accurate to dispatch a responder to help the
caller.
We distinguish (Section 4) an emergency call from any other call by a o The PSAP must be able to re-establish a session to the caller if
unique Service URN[I-D.ietf-ecrit-service-urn], which is placed in for any reason the original session is lost.
the initial call set-up signaling when a home or visited emergency
dial string is detected. We route emergency calls based on the 3. Overview of how emergency calls are placed
location ( (Section 5)) of the caller. To get this location we
either include a form of measuring (e.g. GPS) ( (Section 5.3.3)) An emergency call can be distinguished (Section 5) from any other
device location in the endpoint, or the endpoint is configured ( call by a unique Service URN [I-D.ietf-ecrit-service-urn], that is
(Section 5.5)) with its location from the access network's Location placed in the call set-up signaling when a home or visited emergency
Information Server (LIS) The location is conveyed ( (Section 5.6)) in dial string is detected. Because emergency services are local to
the SIP signaling with the call. We route( (Section 6)) the call specific geographic regions, a caller must obtain his location
based on location using the LoST protocol ( [I-D.ietf-ecrit-lost]) (Section Section 6) prior to making emergency calls. To get this
which maps a location to a set of PSAP URIs. Each URI resolves to a location, either a form of measuring (e.g., GPS) (Section 6.2.3)
PSAP or an Emergency Services Routing Proxy which serves a group of device location in the endpoint is deployed, or the endpoint is
PSAPs. The call arrives at the PSAP with the location included in configured (Section 6.5) with its location from the access network's
the INVITE request. Location Information Server (LIS). The location is conveyed
(Section 6.7) in the SIP signaling with the call. The call is routed
(Section 8) based on location using the LoST protocol
[I-D.ietf-ecrit-lost], that maps a location to a set of PSAP or URIs.
Each URI resolves to a PSAP or an Emergency Services Routing Proxy
(ESRP) that serves a group of PSAPs. The call arrives at the PSAP
with the location included in the INVITE request.
The following is a quick overview for a typical Ethernet connected
telephone using SIP signaling. It illustrates one set of choices for
various options presented later in this document.
o The phone "boots" and connects to its access network
o The phone gets location from the DHCP server [RFC4676] or
[RFC3825], a HELD server [I-D.ietf-geopriv-http-location-delivery]
or the first level switch's LLDP server [LLDP].
o The phone obtains the local emergency dial string(s) from the
[I-D.ietf-ecrit-lost] server for its current location. It also
receives and caches the PSAP URI obtained from LoST.
o It recognizes an emergency call from the dial strings and uses
"urn:service:sos" [I-D.ietf-ecrit-service-urn] to mark an
emergency call.
o It determines the PSAP's URI by querying the LoST mapping server
with its location.
o It puts its location in the SIP INVITE in a Geolocation header
[I-D.ietf-sip-location-conveyance] and forwards the call using its
normal outbound call processing, that commonly involves an
outgoing proxy.
o The proxy recognizes the call as an emergency call and routes the
call using normal SIP routing mechanisms to the URI specified.
o The call routing commonly traverses an incoming proxy server in
the emergency services network. That proxy would route to the
PSAP.
o The call is established with the PSAP and common media streams are
created.
o The location of the caller is displayed to the call taker.
Configuration Servers Configuration Servers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. +--------+ +----------+ . . +--------+ +----------+ .
. +--------+ | +----------+ | . . +--------+ | +----------+ | .
. | LIS | | | SIP | | . . | LIS | | | SIP | | .
. | |-+ | Registrar|-+ . . | |-+ | Registrar|-+ .
. +--------+ +----------+ . . +--------+ +----------+ .
. ^ ^ . . ^ ^ .
. . | . . . . . . . | . . . . . . . . | . . . . . . . | . . . . . .
| | | |
|[1][4] |[2] |[M1][M4] |[M2]
| | +--------+ | | +--------+
|+--------------+ +--------+ | |+--------------+ +--------+ |
|| | LoST | | || | LoST | |
||+-------------------->| Servers|-+ ||+-------------------->| Servers|-+
||| [3][5] +--------+ +-------+ ||| [M3][M5] +--------+ +-------+
||| | PSAP2 | ||| | PSAP2 |
||| +-------+ ||| +-------+
||| |||
||| [6] +-------+ [7] +------+ [8] +-------+ [9] ||| [M6] +-------+ [M7]+------+ [M8]+-------+
Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker
+-------+ +------+ +-------+ +-------+ +------+ +-------+
+-------+ +-------+
| PSAP3 | | PSAP3 |
+-------+ +-------+
Figure 1: Generic ECRIT Component Topology Figure 1: Emergency Call Component Topology
Figure 2 shows a generic emergency call establishment. This includes
the following:
o Alice - who will make the emergency call.
o Configuration Servers - Servers providing Alice's UA its IP
address and other configuration information, perhaps including
Location by-value or by-reference. In this flow, we use DHCP as
an example location configuration protocol. Configuration servers
also may include a SIP Registrar server, for Alice's UA to
register Alice's UA to register with. Most SIP UAs will register
with a call server, so it will be a common scenario for UAs that
make emergency calls to be registered with such a server in the
originating calling network. Registration would be required for
the PSAP to be able to call back after an emergency call is
completed. All the configuration messages are labeled M1 through
M3, but could easily require more messages than 4 to complete.
o ESRP - The Emergency Services Routing Proxy Server that is the
incoming call proxy in the emergency services domain. The ESRP
makes further routing decisions based on PSAP state and location
of the caller to choose the actual PSAP which handles the call.
In some jurisdictions, that may involve another LoST query
o LoST Server - Processes the LoST request for Location + Service
URN to PSAP-URI Mapping function, either for an initial request
from a UA, or an in-call routing by the Proxy server in the
originating network, or possibly by an ESRP.
o PSAP - Call center where emergency calls are destined for in times
of emergencies.
Generally, Alice's UA either has location configured manually, has an
integral location measurement mechanism, or it runs a location
configuration protocol to obtain location from the access (broadband)
network. For most devices, a location configuration protocol will be
used, for example a DHCPREQUEST message or another location
acquisition mechanism. Alice's UA then will most likely register
with a SIP domain. This allows her to be contacted by other SIP
entities. Next, her UA will perform an initial LoST Location-to-PSAP
SIP(S)-URI query to learn a URI, for use if the Lost Query fails
during an emergency call or to use it to test the emergency call
mechanism. The LoST query may contain the dial string for emergency
calls appropriate for the location provided.
Some time has hopefully passed since Alice's UA booted. In this
example, she dials or initiates an emergency call. This may have
been through her keypad with her locally known emergency dial string.
It is important that this dial string be recognized by her UA
wherever Alice is because she may be in enough distress she forgets
what the traveled-to emergency dial string is; as there are more than
60 around the world.
The UA recognizes the dial string, which means this is an emergency
call. The UA attempts to refresh its location, and with that
location, the LoST mapping, to get the most accurate information to
use for routing the call. If the location request or the LoST
request fails (or takes too long) the UA uses it's cached values.
The UA creates an INVITE which includes the location.
[I-D.ietf-sip-location-conveyance] defines a SIP Location header that
either contain the location-by-reference URI, or a [RFC2396] "cid:"
indicating where in the message body the location-by-value is.
The INVITE message routes to the ESRP, which is the first inbound
proxy for the emergency services domain. This message, is then
routed by the ESRP towards the most current PSAP for Alice's
location, which uses PSAP state, location and other state information
to choose this PSAP.
A proxy in the PSAP chooses an available call taker and extends the
call to its UA.
The 200 OK to the INVITE traverses the path in reverse, from call
taker UA to PSAP proxy to ESRP to originating network proxy to
Alice's UA. The ACK completes the call set-up and the emergency call
is established, allowing the PSAP call-taker to talk to Alice about
her emergency.
Configuration LoST Configuration LoST
Alice Servers ESRP Server PSAP Alice Servers ESRP Server PSAP
[M1] DHCP Request(s) (may ask for Location) [M1] LCP Request(s) (ask for location)
----------> ---------->
DHCP Reply(s) (replies with location if asked) LCP Reply(s) (replies with location)
<--------- <---------
[M2] SIP REGISTER [M2] SIP REGISTER
----------> ---------->
SIP 200 OK (REGISTER) SIP 200 OK (REGISTER)
<--------- <---------
[M3] Initial LoST Protocol Query (contains Location) [M3] Initial LoST Protocol Query (contains location)
----------------------------------------> ---------------------------------------->
Initial LoST Protocol Response (contains PSAP-URI) Initial LoST Protocol Response (contains PSAP-URI and dial
string)
<---------------------------------------- <----------------------------------------
***Some time later, Alice dials/initiates emergency call*** ***Some time later, Alice dials/initiates emergency call***
[M4] DHCP Request(s) (update Location) [M4] LCP Request (update location)
----------> ---------->
DHCP Reply(s) (replies with location) LCP Reply (replies with location)
<--------- <---------
[M5] Update LoST Protocol Query (contains Location) [M5] Update LoST Protocol Query (contains location)
----------------------------------------> ---------------------------------------->
LoST Protocol Response (contains PSAP-URI) LoST Protocol Response (contains PSAP-URI)
<---------------------------------------- <----------------------------------------
[M6/7] INVITE (sos URN, Location & early PSAP URI) [M6/7] INVITE (service URN, Location & PSAP URI)
---------------------> --------------------->
[M8] INVITE (sos, Location & PSAP-URI) [M8] INVITE (urm:service:sos, Location & PSAP-URI)
--------------------------------------> -------------------------------------->
200 OK 200 OK
<-------------------------------------------------------------- <--------------------------------------------------------------
ACK ACK
--------------------------------------------------------------> -------------------------------------------------------------->
Emergency Session Established Emergency Session Established
<=============================================================> <=============================================================>
Figure 2: General Flow of an Emergency Call Establishment Figure 2: General Flow of an Emergency Call Establishment
This is a very rough example of the operation of an emergency call Figure 1 shows emergency call component topology and Figure 2 shows
establishment. There are no layer 3 routers in the message flow, and call establishment. These include the following:
whatever security messages exist in the call are not shown either. o Alice - who makes the emergency call.
Each of those aspects will be addressed individually, to keep each o Configuration Servers - Servers providing Alice's UA its IP
discussion in context of that subject, for clarity. address and other configuration information, perhaps including
location by-value or by-reference. In this flow, DHCP is used as
an example location configuration protocol (LCP). Configuration
servers also may include a SIP registrar for Alice's UA. Most SIP
UAs will register, so it will be a common scenario for UAs that
make emergency calls to be registered with such a server in the
originating calling network. Registration would be required for
the PSAP to be able to call back after an emergency call is
completed. All the configuration messages are labeled M1 through
M3, but could easily require more than 3 messages to complete.
o ESRP - The emergency services routing proxy server that is the
incoming call proxy in the emergency services domain. The ESRP
makes further routing decisions (e.g. based on PSAP state and the
location of the caller) to choose the actual PSAP that handles the
call. In some jurisdictions, this may involve another LoST query.
o LoST server - Processes the LoST request for Location + Service
URN to PSAP-URI Mapping function, either for an initial request
from a UA, or an in-call routing by the Proxy server in the
originating network, or possibly by an ESRP.
o PSAP - Call center where emergency calls are destined for.
4. Identifying an Emergency Call Generally, Alice's UA either has location configured manually, has an
integral location measurement mechanism, or it runs a LCP [M1] to
obtain location from the access (broadband) network. For most
devices, a LCP will be used, for example a DHCPREQUEST message or
another location acquisition mechanism. Alice's UA then will most
likely register [M2] with a SIP domain. This allows her to be
contacted by other SIP entities. Next, her UA will perform an
initial LoST query [M3] to learn a URI for use if the LoST query
fails during an emergency call, or to use to test the emergency call
mechanism. The LoST response may contain the dial string for
emergency calls appropriate for the location provided.
At some time after her device has booted, Alice initiates an
emergency call. She may do this by dialing an emergency dial string
valid for her current ("local") location, or for her "home" location.
The UA recognizes the dial string. The UA attempts to refresh its
location [M4], and with that location, to refresh the LoST mapping
[M5], in order to get the most accurate information to use for
routing the call. If the location request or the LoST request fails,
or takes too long, the UA uses values it has cached.
The UA creates a SIP INVITE [M6] request that includes the location.
[I-D.ietf-sip-location-conveyance] defines a SIP Geolocation header
that contains either a location-by-reference URI or a [RFC2396] "cid"
URL indicating where in the message body the location-by-value is.
The INVITE message is routed to the ESRP [M7], that is the first
inbound proxy for the emergency services domain. This message is
then routed by the ESRP towards the most appropriate PSAP for Alice's
location [M8], as determined by PSAP state, location and other
information.
A proxy in the PSAP chooses an available call taker and extends the
call to its UA.
The 200 OK response to the INVITE request traverses the path in
reverse, from call taker UA to PSAP proxy to ESRP to originating
network proxy to Alice's UA. The ACK completes the call set-up and
the emergency call is established, allowing the PSAP call-taker to
talk to Alice about Alice's emergency.
4. Which devices and services should support emergency calls
Support for voice calls and real-time text calls placed through PSTN
facilities or systems connected to the PSTN is found in present
PSAPs. Future PSAPs will however support Internet connectivity and a
wider range of media types and provide higher functionality. In
general, if a user could reasonably expect to be able to place a call
for help with the device, then the device or service should support
emergency calling. Certainly, any device or service that looks like
and works like a telephone (wired or mobile) should support emergency
calling, but increasingly, users have expectations that other devices
and services should work.
Certainly, any device or service that looks like and works like a
telephone (wired or mobile) should support emergency calling, but
increasingly, users have expectations that other devices and services
should work.
Using current (evolving) standards, devices that create media
sessions and exchange audio, video and/or text, and have the
capability to establish sessions to a wide variety of addresses, and
communicate over private IP networks or the Internet, should support
emergency calls.
5. Identifying an emergency call
Using the PSTN, emergency help can often be summoned by dialing a Using the PSTN, emergency help can often be summoned by dialing a
nationally designated, widely known number, regardless of where the nationally designated, widely known number, regardless of where the
telephone was purchased. The appropriate number is determined by telephone was purchased. The appropriate number is determined by the
which infrastructure the telephone is connected to. However, this infrastructure the telephone is connected to. However, this number
number differs between localities, even though it is often the same differs between localities, even though it is often the same for a
for a country or region, such as many countries in the European country or region, as it is in many countries in the European Union.
Union. In some countries, there is a single digit sequence that is In some countries, there is a single digit sequence that is used for
used for all types of emergencies. In others, there are several all types of emergencies. In others, there are several sequences
sequences that are specific to the responder, e.g., one for police, that are specific to the type of responder needed, e.g., one for
another for fire. It is deemed impractical to change the dialed police, another for fire. For end systems, on the other hand, it is
digits to summon help. For end systems, it is desirable to have a desirable to have a universal identifier, independent of location, to
universal identifier, independent of location, to allow the automated allow the automated inclusion of location information and to allow
inclusion of location information and to allow the device and other the device and other entities in the call path to perform appropriate
entities in the call path to perform appropriate processing within processing within the signaling protocol in an emergency call set-up.
the signaling protocol in an emergency call set-up.
As part of the overall emergency calling architecture, we define Since there is no such universal identifier, as part of the overall
common emergency call URIs which are defined in emergency calling architecture, common emergency call URNs are
[I-D.ietf-ecrit-service-urn]. Users are not expected to "dial" an defined in [I-D.ietf-ecrit-service-urn]. An example, for a single
emergency URN. Rather, the current dial string should be translated number environment is "urn:service:sos". Users are not expected to
to the appropriate service URN. Such translation could ideally be "dial" an emergency URN. Rather, appropriate emergency dial strings
performed in the endpoint, but could be performed in a signaling is translated to corresponding service URNs, carried in the Request-
intermediary (proxy server). For devices that are mobile or nomadic, URI of the INVITE. Such translation is best done by the endpoint,
an issue arises of whether the home or visited dialing strings should because emergency calls convey location in the signaling, but non
be used. Many users would prefer that their home dialing sequences emergency calls do not normally do that. If the device recognizes
work no matter where they are. Local laws and preferences of the the emergency call, it can include location. Dial string recognition
emergency response professionals are such that the visited dialing could be performed in a signaling intermediary (proxy server) if for
sequences must always work. Having the home dial string work is some reason, the endpoint does not recognize it. For devices that
optional. The best answer seems to be for both to work. are mobile or nomadic, an issue arises of whether the home or visited
dialing strings should be used. Many users would prefer that their
home dialing sequences work no matter where they are. Local laws and
regulations may require the visited dialing sequence(s) always work.
Having the home dial string work is optional.
The mechanism for obtaining the dialing sequences for a given The mechanism for obtaining the dialing sequences for a given
location is provided by LoST [I-D.ietf-ecrit-lost]. Where the location is provided by LoST [I-D.ietf-ecrit-lost]. If the endpoint
endpoint does not support the translation of dial strings to does not support the translation of dial strings to telephone
telephone numbers, the dialing sequence would be represented as a numbers, the dialing sequence would be represented as a dial string
dial string [I-D.rosen-iptel-dialstring] and the outgoing proxy would [RFC4967] and the outgoing proxy would recognize the dial string and
recognize the dial string and translate to the service URN. To translate to the service URN. To determine the local dial string,
determine the local dial string, the proxy needs the location of the the proxy needs the location of the endpoint. This may be difficult
endpoint. This may be difficult in situations where the user can in situations where the user can roam or be nomadic. Endpoint
roam or be nomadic. Endpoint recognition of emergency dial strings recognition of emergency dial strings is therefore preferred.
is therefore preferred.
5. Location and Its Role in an Emergency Call Note: It is undesirable to have a single "button" emergency call user
interface element. These mechanisms tend to result in a very high
rate of false or accidental emergency calls. In order to minimize
this rate, devices SHOULD only initiate emergency calls based on
entry of specific emergency call dial strings.
5.1. Introduction While in some countries there is a single 3 digit dial string that is
used for all emergency calls (i.e. 9-1-1 in North America), in some
countries there are several 3 digit numbers used for different types
of calls. For example, in Switzerland, 1-1-7 is used to call police,
1-1-8 is used to call the fire brigade, and 1-4-4 is used for
emergency medical assistance. In other countries, there are no
"short codes" or "service codes" for 3 digit dialing of emergency
services and local (PSTN) numbers are used.
Caller location plays a central role in routing emergency calls. For [I-D.ietf-ecrit-service-urn] introduces a universal emergency service
practical reasons, each PSAP generally handles only calls for a URN scheme. On the wire, emergency calls include this type of URI in
certain geographic area (overload arrangements between PSAPs to the Request-URI [RFC3261]. The scheme includes a single emergency
handle each others calls notwithstanding). Other calls that reach it URN (urn:service:sos) for use in countries with a single emergency
by accident must be manually re-routed (transferred) to the dial string, and responder-specific ones (urn:service:sos.police) for
appropriate PSAP, increasing call handling delay and the chance for countries where the user dials each service with separate numbers.
errors. The area covered by each PSAP differs by jurisdiction, where Using the service:sos URN scheme, emergency calls can be recognized
some countries have only a small number of PSAPs, while others as such throughout the Internet.
decentralize PSAP responsibilities to the level of counties or
municipalities. 6. Location and its role in an emergency call
Location is central to the operation of emergency services. It is
frequently the case that the user in an emergency is unable to
provide a unique, valid location themselves. For this reason,
location provided by the endpoint or the access network is needed.
For practical reasons, each PSAP generally handles only calls for a
certain geographic area, with overload arrangements between PSAPs to
handle each others calls. Other calls that reach it by accident must
be manually re-routed (transferred) to the most 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 decentralize PSAP
responsibilities to the level of counties or municipalities.
In most cases, PSAPs cover at least a city or town, but there are 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 some areas where PSAP coverage areas follow old telephone rate center
boundaries and may straddle more than one city. Irregular boundaries boundaries and may straddle more than one city. Irregular boundaries
are common, often for historical reasons. Routing must be done on are common, often for historical reasons. Routing must be done based
PSAP service boundaries, not "closest" or "best fit" algorithms. on PSAP service boundaries, the closest PSAP, or the PSAP that serves
the nominal city name provided in the location may not be the correct
PSAP.
5.2. Types of Location Information Accuracy of routing location is a complex subject. Calls must be
routed quickly, but accurately, and location determination is often a
time/accuracy tradeoff, especially with mobile devices or self
measuring mechanisms. It is considered acceptable to base a routing
decision on an accuracy equal to the area of one sector of a mobile
cell site if no more accurate routing location is available.
There are four primary types of location information: civic, postal, Routing to the most appropriate PSAP is always calculated on the
geospatial, and cellular cell tower and sector. location of the caller, despite the fact that some emergency calls
are placed on behalf of someone else, and the location of the
incident is sometimes not the location of the caller. In some cases,
there are other factors that enter into the choice of the PSAP that
gets the call, which may include factors other than location (such as
caller media and language preference, PSAP state, etc.). However,
location of the caller is the primary input to the routing decision.
Civic: Civic location information describes the location of a person Routing is but one of two uses for location in an emergency call.
The other is for dispatch of a responder. Many mechanisms used to
locate a caller have a relatively long "cold start" time. To get a
location accurate enough for dispatch may take as much as 30 seconds.
This is too long to wait for emergencies. Accordingly, it is common,
especially in mobile systems to use a coarse location, for example,
the cell site and sector serving the call, for routing purposes, and
then to update the location when a more precise value is known prior
to dispatch. In this document we use "routing location" and
"dispatch location" when the distinction matters.
Accuracy of dispatch location is sometimes determined by local
regulation, and is constrained by available technology. The actual
requirement exceeds available technology. It is required that a
device making an emergency call close to the "demising" or separation
wall between two apartments in a high rise apartment building report
location with sufficient accuracy to determine on what side of the
wall it is on. This implies perhaps a 3 cm accuracy requirement. As
of the date of this memo, typical assisted GPS uncertainty with 95%
confidence is 100 m.
Location usually involves several steps to process and multiple
elements are involved. In Internet emergency calling, where the
endpoint is located is "Determined" using a variety of measurement or
wire-tracing methods. Endpoints may be "Configured" with their own
location by the access network. In some circumstances, a proxy
server may insert location into the signaling on behalf of the
endpoint. The location is "Mapped" to the URI to send the call to,
and the location is "Conveyed" to the PSAP (and other elements) in
the signaling. Likewise, we employ Location Configuration Protocols,
Location Mapping Protocols, and Location Conveyance Protocols for
these functions. The Location-to-Service Translation protocol
[I-D.ietf-ecrit-lost] is the Location Mapping Protocol defined by the
IETF.
6.1. Types of location information
There are several ways location can be specified:
Civic Civic location information describes the location of a person
or object by a street address that corresponds to a building or or object by a street address that corresponds to a building or
other structure. (This is sometimes also called "civil" location other structure. Civic location may include more finely grained
information.) Civic location may include more finely grained
location information such as floor, room and cubicle. Civic location information such as floor, room and cubicle. Civic
information comes in two forms: information comes in two forms:
Jurisdictional - This refers to a civic location using actual
Jurisdictional This refers to a civic location using actual
political subdivisions, especially for the community name. political subdivisions, especially for the community name.
Postal - This refers to a civic location used to mail a letter Postal This refers to a civic location for mail delivery. The
to. The name of the post office sometimes does not correspond name of the post office sometimes does not correspond to the
to the actual community name and a postal address may contain community name and a postal address may contain post office
post office boxes or street addresses that do not correspond to boxes or street addresses that do not correspond to an actual
an actual building. Postal addresses are generally unsuitable building. Postal addresses are generally unsuitable for
for emergency call routing, but may be the only address emergency call dispatch because the post office conventions
available. (for community name, for example) do not match those known by
Geospatial: Geospatial addresses contain longitude, latitude and the responders. The fact that they are unique can sometimes be
altitude information based on an understood datum (starting point) exploited to provide a mapping between a postal address and a
and earth shape model. While there have been many datum developed civic address suitable to dispatch a responder to. In IETF
over time, most modern systems are using or moving towards the location protocols, there is a element (Postal Community Name)
[WGS84] datum. that can be included in a location to provide the post office
name as well as the actual jurisdictional community name.
There is no other accommodation for postal addresses in these
protocols.
Geospatial (geo): Geospatial addresses contain longitude, latitude
and altitude information based on an understood datum and earth
shape model. While there have been many datums developed over
time, most modern systems are using or moving towards the
WGS84[WGS84] datum.
Cell tower/sector: Cell tower/sector is often used for identifying
the location of a mobile handset, especially for routing of
emergency calls. Cell tower and sectors identify the cell tower
and the antenna sector that a mobile device is currently using.
Traditionally, the tower location is represented as a point chosen
to be within a certain PSAP service boundary who agrees to take
calls originating from that tower/sector, and routing decisions
are made on that point. Cell/sector information could also be
represented as an irregularly shaped polygon of geospatial
coordinates reflecting the likely geospatial location of the
mobile device. Whatever representation is used must route
correctly in the LoST database, where "correct" is determined by
local PSAP management.
Cell tower/sector: Cell tower and sectors identify the cell tower In IETF protocols, civic and geospatial forms are both supported.
and the antenna sector that the mobile device is currently using. The civic forms include both postal and jurisdictional fields. A
Traditionally, the tower location is expressed as a point, and cell tower/sector can be represented as a point (geo or civic) or
routing decisions are made on that point. Cell/sector information polygon. Other forms of location representation must be mapped into
could also be transmitted as an irregularly shaped polygon of either a geo or civic for use in emergency calls.
geospatial coordinates reflecting the likely geospatial location
of the mobile device.
In IETF protocols, civic and geo forms are both supported. The civic For emergency call purposes, conversion of location information from
forms include both the postal and jurisdictional fields. The cell civic to geo or vice versa prior to conveyance is not desirable. The
tower/sector can be represented as a point. location should be sent in the form it was determined. Conversion
between geo and civic requires a database. PSAPs may need to convert
from whatever form they receive to another for responder purposes.
They have a suitable database. However, if a conversion is done
before the PSAP, and the database used is not exactly the one the
PSAP uses, the double conversion has a high probability of
introducing an error.
5.3. Location Determination 6.2. Location Determination
Location information can be entered by the user or installer of a Location information can be entered by the user or installer of a
device ("manual configuration"), can be measured by the end system, device ("manual configuration"), measured by the end system, can be
can be delivered to the end system by some protocol or can be delivered to the end system by some protocol or measured by a third
measured by a third party and inserted into the call signaling. We party and inserted into the call signaling. Choice of location
discuss these in detail below. determination mechanisms and their properties are out of scope for
this document.
In some cases, an entity may have multiple sources of location In some cases, an entity may have multiple sources of location
information, possibly partially contradictory. This is particularly information, possibly partially contradictory. This is particularly
likely if the location information is determined both by the end likely if the location information is determined both by the end
system and a third party. Handling multiple locations is discussed system and a third party. Although self measured location (e.g.
in [I-D.ietf-geopriv-pdif-lo-profile]. Conflicting location GPS) is attractive, access network provided location could be much
information is particularly harmful if it points to multiple distinct more accurate, and more reliable in some environments (indoor high
PSAPs. Guidelines for dealing with multiple locations is also given rise in dense urban areas for example).
in [I-D.ietf-ecrit-lost].
All location objects MUST be delivered to the PSAP. Location
information should contain information about the source of data, such
as GPS, manually entered or based on access network topology. In
addition, the source of the location information should be included
(PIDF "provided-by"). The ability of the UA to understand how it
learned its location, and include this information element in the
location object that is sent to the PSAP, provides the call-taker
with many pieces of information to make decisions upon, and guidance
for what to ask the caller and what to tell the responders.
The call 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 different
location information from the call request, resulting in different
routing decisions for different transactions. The location
conveyance mechanism [I-D.ietf-sip-location-conveyance] contains a
parameter which can be used for this purpose
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. User-Entered Location Information 6.2.1. User-entered location information
Location information can be maintained by the end user or the Location information can be maintained by the end user or the
installer of an endpoint in the endpoint itself, or in a database. installer of an endpoint in the endpoint itself, or in a database.
Location information added by end users is almost always inferior to Location information provided by end users is almost always less
measured or wire database information, as users may mistype civic reliable than measured or wire database information, as users may
location information, may not know the meaning of geospatial mistype location information or may enter civic address information
coordinates or may use address information that does not correspond that does not correspond to a recognized (i.e. valid, see Section
to a recognized civic address. A user-entered location can fail to Section 6.10) address. Users can neglect to change the data when the
be changed when the location of a device changes during or after location of a device changes during or after movement.
movement. For example, a user could move their residence to another
dwelling, not update their device/equipment with this new location,
and place an emergency call with old location information.
All that said, there are always a small number of cases where the All that said, there are always a small number of cases where the
mechanisms used by the access network to determine location fail to automated mechanisms used by the access network to determine location
accurately reflect the actual location of the endpoint. For example, fail to accurately reflect the actual location of the endpoint. For
the user may deploy his own WAN behind an access network, effectively example, the user may deploy his own WAN behind an access network,
remoting an endpoint some distance from the access network's notion effectively removing an endpoint some distance from the access
of its location. There must be some mechanism provided to provision network's notion of its location. There must be some mechanism
a location for an endpoint by the user or by the access network on provided to provision a location for an endpoint by the user or by
behalf of a user. The use of the mechanism introduces the the access network on behalf of a user. The use of the mechanism
possibility of users falsely declaring themselves to be somewhere introduces the possibility of users falsely declaring themselves to
they are not. As an aside, normally, if an emergency caller insists be somewhere they are not. As an aside, normally, if an emergency
he is at a location different from what any automatic location caller insists that he is at a location different from what any
determination system reports he is, responders will always be sent to automatic location determination system reports he is, responders
the user's self-declared location. However this is a matter of local will always be sent to the user's self-declared location. However
policy and is outside the scope of this document. this is a matter of local policy and is outside the scope of this
document.
5.3.2. Access Network "Wire Database" Location Information 6.2.2. Access network "wire database" location information
Location information can be maintained by the access network, Location information can be maintained by the access network,
relating some form of identifier for the end subscriber or device to relating some form of identifier for the end subscriber or device to
a location database ("wire database"). In enterprise LANs, wiremap a location database ("wire database"). In enterprise LANs, wiremap
databases map Ethernet switch ports to building layouts at known databases map Ethernet switch ports to building locations. In DSL
locations. In DSL installations, the local telephone carrier installations, the local telephone carrier maintains a mapping of
maintains a mapping of wire-pairs to subscriber addresses. wire-pairs to subscriber addresses.
Accuracy of location historically has been to a street address level.
However, this is not sufficient for larger structures. The PIDF-LO
[RFC4119] with a recent extension [I-D.ietf-geopriv-revised-civic-lo]
permits interior building/floor/room and even finer specification of
location within a street address. When possible, interior location
should be supported.
The threshold for when interior location is needed is approximately
650 m2 (that is derived from fire brigade recommendations of spacing
of alarm pull stations) should have, but interior space layout,
construction materials and other factors should be considered. The
ultimate goal is to be able to find the person in need quickly if
responders arrive at the location given.
Even for IEEE 802.11 wireless access points, wire databases may Even for IEEE 802.11 wireless access points, wire databases may
provide sufficient location resolution; the location of the access provide sufficient location resolution. The location of the access
point may be sufficient location information for each of the clients point as determined by the wiremap may be supplied as the location
served by that access point. However, this may not be true for for each of the clients of the access point. However, this may not
larger scale systems such as IEEE 802.16 and IEEE 802.22 which be true for larger-scale systems such as IEEE 802.16 (WiMAX) and IEEE
typically have larger cells than those of IEEE 802.11. A Wire 802.22 that typically have larger cells than those of IEEE 802.11.
database may be the source of location information for both The civic location of an IEEE 802.16 base station may be of little
residential users of DSL and Cable Modem installations, as well as use to emergency personnel, since the endpoint could be several
the only infrastructure at a WiFi hotspot, such as a coffee shop. kilometers away from the base station.
Each of these cases will have a known civic address of the dwelling/
business, likely providing sufficient location resolution. However,
the civic location of an IEEE 802.16 base station may be of little
use to emergency personnel
Wire databases to the home are likely to be the most promising Wire databases to the home are likely to be the most promising
solution for residential users where a service provider knows the solution for residential users where a service provider knows the
customer's service address. The service provider can then perform customer's service address. The service provider can then perform
address verification, similar to the current system in some address validation (see Section 6.10), similar to the current system
jurisdictions. in some jurisdictions.
5.3.3. End-System Measured Location Information 6.2.3. End-system measured location information
Global Positioning System (GPS) sensors may be embedded directly in Global Positioning System (GPS) and similar satellite based (e.g.
the end device. GPS produces relatively high precision location Galileo) receivers may be embedded directly in the end device. GPS
fixes in open-sky conditions, but the technology still faces several produces relatively high precision location fixes in open-sky
challenges in terms of performance (time-to-fix and time-to-first- conditions, but the technology still faces several challenges in
fix), as well as obtaining successful location fixes within shielded terms of performance (time-to-fix and time-to-first-fix), as well as
structures, or underneath the ground (tunnels, basements, etc.). It obtaining successful location fixes within shielded structures, or
also requires all devices to be equipped with the appropriate GPS underground. It also requires all devices to be equipped with the
capability. GPS technology is improving (e.g. Galileo), and is appropriate GPS capability. GPS-derived locations are currently
increasingly successful in more difficult conditions such as dense accurate to tens of meters. Many mobile devices require using some
urban canyons and inside commercial structures. It is currently kind of "assist", that may be operated by the access network (A-GPS)
accurate to tens of meters using some kind of "assist", which may be or by a government (WAAS).
operated by the access network (A-GPS) or by a government (WAAS).
Newer multi-frequency systems will improve accuracy without assist.
GPS equipped devices vary depending on which element initiates GPS systems may be always on; where location will always be available
requests, which element actually determines final location, assist accurately (assuming the device can "see" enough satellites). Mobile
mechanisms, etc. Some common implementations include: devices may not be able to sustain the power levels required to keep
1. GPS S/A (standalone), device initiated the measuring system active. This means that when location is
2. GPS S/A, network initiated needed, the device has to start up the measurement mechanism. This
3. AGPS-device initiated, network determined typically takes tens of seconds, far too long to wait to be able to
4. AGPS-device initiated, network augmented route an emergency call. For this reason, devices that don't have
5. AGPS-network initiated, network determined end-system measured location mechanisms always on need another way to
6. AGPS-network initiated, network augmented get a routing location. Typically this would be a location
associated with a radio link (cell site/sector).
5.3.4. Third-party Measured Location Information 6.2.4. Network measured location information
The access network may locate end devices. Techniques include:
Wireless triangulation: Elements in the network infrastructure Wireless triangulation: Elements in the network infrastructure
triangulate end systems based on signal strength, angle of arrival triangulate end systems based on signal strength, angle of arrival
or time of arrival. Common mechanisms deployed include. or time of arrival. Common mechanisms deployed include:
1. Time Difference Of Arrival - TDOA 1. Time Difference Of Arrival - TDOA
2. Uplink Time Difference Of Arrival - U-TDOA 2. Uplink Time Difference Of Arrival - U-TDOA
3. Angle of Arrival - AOA 3. Angle of Arrival - AOA
4. RF-Fingerprinting 4. RF-Fingerprinting
5. Advanced Forward Link Trilateration - AFLT 5. Advanced Forward Link Trilateration - AFLT
6. Enhanced Forward Link Trilateration - EFLT 6. Enhanced Forward Link Trilateration - EFLT
Sometimes triangulation and measured mechanisms are combined, for Sometimes multiple mechanisms are combined, for example A-GPS with
example A-GPS with AFLT AFLT
Location beacons: A short range wireless beacon, e.g., using Location beacons: A short range wireless beacon, e.g., using
Bluetooth or infrared, announces its location to mobile devices in Bluetooth or infrared, announces its location to mobile devices in
the vicinity. the vicinity. This allows devices to get location from the beacon
source's location.
5.4. Location and References to Location 6.3. Who adds location, endpoint or proxy
Location information may be expressed as the actual civic or geo The IETF emergency call architecture prefers endpoints to learn their
value but can be transmitted as by-value (wholly contained within the location and supply it on the call. Outbound proxies that support
signaling message) or by-reference (a URI pointing to the value devices that do not support location may have to add location to
residing on a remote node waiting to be dereferenced). There are emergency calls at a proxy server. Some calling networks have
pros and cons to each form: relationships with all access networks the device may be connected
location-by-value: to, and that may allow the proxy to accurately determine location of
pro- Value available to each device along the path immediately the endpoint. However NATs and other middleboxes often make it
for further processing. impossible to determine a reference identifier the access network
con- Size, especially if constrained to a UDP transport. Value could use to determine the location. Systems designers are
fixed at the time the value is acquired from the access discouraged from relying on proxies to add location. The technique
network. Value can be changed by the endpoint, which may be may be useful in some limited circumstances as devices are upgraded
considered untrustworthy for this critical usage. to meet the requirements of this document, or where relationships
location-by-reference between access networks and calling networks are feasible and can be
pro- Small size. Value can be fixed at time of dereference. relied upon to get accurate location.
Value cannot be changed by endpoint
con- URI resolution requires location source be available and
accessible by dereferencer. Dereferencing takes time.
Dereferencing may fail.
5.5. End System Location Configuration Proxy insertion of location complicates dial string recognition. As
noted in Section Section 6, local dial strings depend on the location
of the caller. If the device does not know its own location, it
cannot use the LoST service to learn the local emergency dial
strings. The calling network must provide another way for the device
to learn the local dial string (and update it when the user moves to
a location where the dial string(s) change) or do the dial string
determination itself.
6.4. Location and references to location
Location information may be expressed as the actual civic or
geospatial value but can be transmitted as by value (wholly contained
within the signaling message) or by reference (a URI pointing to the
value residing on a remote node waiting to be dereferenced). Each
form is better suited to some applications than others.
When location is transmitted by value, the location information is
available to each device; on the other hand, location objects can be
large, and only represent a single snapshot of the device's location.
Location references are small and can be used to represent a time-
varying location, but the added complexity of the dereference step
introduces a risk that location will not be available to parties that
need it.
6.5. End system location configuration
Unless a user agent has access to provisioned or locally measured Unless a user agent has access to provisioned or locally measured
location information, it must obtain it from the access network. location information, it must obtain it from the access network.
There are several Location Configuration Protocols (LCPs) that can be There are several location configuration protocols (LCPs) that can be
used for this purpose. used for this purpose such as:
DHCP DHCP can deliver civic [RFC4676] or geospatial [RFC3825]
DHCP can deliver civic [RFC4676] or geospatial [RFC3825] information. User agents need to support both formats. Note that
information. User agents would need to support both formats. a user agent can use DHCP, via the DHCP REQUEST or INFORM
Note that a user agent can use DHCP, via the DHCP REQUEST or messages, even if it uses other means to acquire its IP address.
INFORM messages, even if it uses other means to acquire its IP HELD HELD [I-D.ietf-geopriv-http-location-delivery] can deliver a
address. civic or geo, by value or by reference, as a layer 7 protocol.
The query typically uses the IP address of the requestor as an
identifier and returns the location value or reference associated
with that identifier. HELD is typically transported on HTTP.
Insert reference to L7 acquisition protocol document> is another Link-Layer Discovery Protocol Layer Discovery Protocol [LLDP] with
choice. Media Endpoint Device extensions [LLDP-MED] can be used to deliver
Link-Layer Discovery Protocol [LLDP]), with proposed extensions location information directly from the Layer 2 network
[LLDP-MED], may also be used to deliver location information. infrastructure, and also supports both civic and geospatial
SUPL OMA <insert reference> is yet another choice. formats identical in format to DHCP methods.
Other LCPs may be devised by other standards bodies. Each LCP has Each LCP has limitations in the kinds of networks that can reasonably
limitations in the kinds of networks that can reasonably support it. support it. For this reason, it is not possible to choose a single
For this reason, it is not possible to choose a single mandatory to mandatory-to-deploy LCP. For endpoints with common network
deploy LCP. For endpoints with common network connections (such as connections (such as an Ethernet jack or a WiFi connection) serious
an Ethernet jack or a WiFi connection), unless every network incompatibilities would ensue unless every network supported every
supported every protocol, or alternatively, every device supported protocol, or alternatively, every device supported every protocol.
every protocol, serious incompatibilities would ensue. For this reason, a list of LCPs is established in
[I-D.ietf-ecrit-phonebcp] contains a (short) list of protocols such [I-D.ietf-ecrit-phonebcp]. Every endpoint that could be used to
devices must support. place emergency calls must implement all of the protocols on the
list. Every access network must deploy at least one of them. It is
recognized that this is an onerous requirement, that it would be
desirable to eliminate. However, since it is the variability of the
networks that prevent a single protocol from being acceptable, it
must be the endpoints that implement all of them, and to accommodate
a wide range of devices, networks must deploy at least one of them.
Where an access network can control the specification of EVERY Often, network operators and device designers believe that they have
endpoint that could make an emergency call that is directly connected a simpler environment and some other network specific mechanism can
to the network, or indirectly connected (for example, a device on a be used to provide location. Unfortunately, it is very rare to
LAN behind a network attachment unit), it may specify any protocol it actually be able to limit the range of devices that may be connected
wishes for each endpoint. This is a very unusual case; nearly every to a network.
access network can be used to support an Ethernet based LAN behind it
For example, existing mobile networks are being used to support For example, existing mobile networks are being used to support
routers and LANs behind a wireless data network WAN connection, with routers and LANs behind a wireless data network WAN connection, with
Ethernet connected phones connected to that. It is possible that the Ethernet connected phones connected to that. It is possible that the
access network supports a protocol not on the phonebcp list, and access network could support a protocol not on the list, and require
every handset supported in that network could use that protocol for every handset in that network to use that protocol for emergency
emergency calls. However, unless another element which the access calls. However, the Ethernet connected phone won't be able to
network provider controls the specification of can acquire location acquire location, and the user of the phone is unlikely to be
using that protocol and then that element can support one of the dissuaded from placing an emergency call on that phone. The
phonebcp's list of protocols, the Ethernet connected phone won't be widespread availability of gateways, routers and other network-
able to acquire location. In this case, if the access network broadening devices means that indirectly connected endpoints are
provider supplies a router which includes a DHCP server, it can possible on nearly every network. Network operators and vendors are
acquire location using the access network specific protocol, and then cautioned that shortcuts to meeting this requirement are seldom
use the location information to supply it to its clients (e.g. the successful.
Ethernet connected phone) via DHCP.
For most networks, it will not be practical to control the
specification of every device, or arrange interworking with network
specific LCPs. For this reason, most devices will need to support
ALL of the LCPs in [I-D.ietf-ecrit-lost], and access networks will
have to support at least one of these LCPs.
Location for non-mobile devices is normally expected to be acquired Location for non-mobile devices is normally expected to be acquired
at network attachment time and retained by the device. It should be at network attachment time and retained by the device. It should be
refreshed when the cached value becomes invalid (for example, if DHCP refreshed when the cached value becomes invalid. For example, if
is the acquisition protocol, refresh of location may occur when the DHCP is the acquisition protocol, refresh of location may occur when
IP address lease is renewed). At the time of an emergency call, the the IP address lease is renewed. At the time of an emergency call,
location should be refreshed, with the retained location used if the the location should be refreshed, with the retained location used if
location acquisition does not immediately return a value. Mobile the location acquisition does not immediately return a value. Mobile
devices may determine location at network attachment time and devices may determine location at network attachment time and
periodically thereafter as a backup in case location determination at periodically thereafter as a backup in case location determination at
the time of call does not work. Mobile device location may be the time of call does not work. Mobile device location may be
refreshed when a TTL expires, the device moves beyond some boundaries refreshed when a TTL expires, the device moves beyond some boundaries
(as provided by [I-D.ietf-ecrit-lost]), etc. Normally, mobile (as provided by [I-D.ietf-ecrit-lost]). Normally, mobile devices
devices will acquire its location at call time for use in an will acquire its location at call time for use in an emergency call
emergency call routing, but see Section 5.7 routing. See Section Section 6.8 for a further discussion on
location updates for dispatch location.
5.6. Conveyance of Location 6.6. When location should be configured
When an emergency call is placed, the endpoint (normally) puts Devices should get routing location immediately after obtaining local
location information in the signaling with the call. We refer to network configuration information. The presence of NAT and VPN
that as "conveyance" to distinguish it from "configuration". tunnels (that assign new IP addresses to communications) can obscure
Configuration gets location from access network to endpoint, identifiers used by LCPs to determine location, especially using
conveyance sends location from endpoint to elements that route the HELD. In some cases, such as residential NAT devices, the NAT is
call based on that location object and the PSAP. Using SIP, the before the access network demarcation point and thus the IP address
location information is conveyed following the procedures in seen by the access network is the right identifier for location of
the residence. In many enterprise environments, VPN tunnels can
obscure the actual IP address. Some VPN mechanisms can be bypassed
(a query to the LCP can be designated to go through the direct IP
path, using the correct IP address, and not through the tunnel). In
other cases, no bypass is possible. Of course, LCPs that use Layer 2
mechanisms (DHCP Location options and LLDP-MED) are usually immune
from such problems because they do not use the IP address as the
identifier for the device seeking location.
It is desirable that routing location information be periodically
refreshed. A LIS supporting a million subscribers each refreshing
once per day would need to support a query rate of 1,000,00 / (24 *
60 * 60) = 12 queries per second.
It is desirable for routing location information to be requested
immediately before placing an emergency call. However, if there is
any significant delay in getting more recent location, the call
should be placed with the most recent location information the device
has. In mobile handsets, routing is often accomplished with the cell
site and sector of the tower serving the call, because it can take
many seconds to start up the location determination mechanism and
obtain an accurate location.
There is a tradeoff between the time it takes to get a routing
location and the accuracy (technically, confidence and uncertainty)
obtained. Routing an emergency call quickly is required. However,
if location can be substantially improved by waiting a short time
(e.g. for some sort of "quick fix"), it's preferable to wait. 3
seconds, that is the current nominal time for a quick fix, is a very
long time to wait for help, and systems designers should attempt to
provide accurate routing location in much less time.
NENA recommends IP based systems complete calls in two seconds (last
dial press to ring at PSAP).
6.7. Conveying location in SIP
When an emergency call is placed, the endpoint should put location in
the signaling with the call. That is referred to as "conveyance" to
distinguish it from "configuration". In SIP, the location
information is conveyed following the procedures in
[I-D.ietf-sip-location-conveyance]. The form of the location [I-D.ietf-sip-location-conveyance]. The form of the location
information obtained by the acquisition protocol may not be the same information obtained by the acquisition protocol may not be the same
as the conveyance protocol uses (PIDF-LO [RFC4119]). Mapping by the as the conveyance protocol uses (PIDF-LO [RFC4119]). Mapping by the
endpoint may be required. Calling networks which support devices endpoint to PIDF may be required.
which do not support location may have to add location to emergency
calls. Some calling networks have relationships with the access
network that may allow it to accurately determine location of the
endpoint, although NATs and other middleboxes usually make it
impossible to determine a reference identifier the access network
could use to determine the location.
For emergency call purposes, conversion of location information from
civic to geo or vice versa prior to conveyance is not desirable. The
location should be sent in the form it was determined. The PSAP may
convert, if it needs to, and if conversion resulted from an earlier
conversion, unacceptable errors may be introduced.
5.7. Location Updates 6.8. Location updates
Location information may not be available at call setup time for As discussed above, it make take some time for some measurement
mobile devices. For example, if a GPS-enabled cell phone is turned mechanisms to get a location accurate enough for dispatch, and a
on and then immediately places an emergency call, it can take routing location with less accuracy may be provided to get the call
significant additional time before the cell phone acquires a GPS fix established early. The PSAP needs the dispatch location before it
and its location. Thus, while it is desirous to base emergency sends the call to the responder. This requires an update of the
routing on precise caller location information, it is not possible in location.
all circumstances to do so. 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 In addition, the location of a mobile caller, e.g., in a vehicle or
aircraft, can change significantly during the emergency call. The aircraft, can change significantly during the emergency call. While
PSAP must be able to get updated location information while it is most often this change is not significant, the PSAP must be able to
processing the call. get updated location information while it is processing the call.
Location updates where the location is conveyed by value may be Subscription is preferred so that the LIS notifies the PSAP when
conveyed either in a re-INVITE or UPDATE [RFC3311] request message accurate location is updated rather than requiring a poll operation
(where UPDATE is preferred) or the PSAP may subscribe to the location from the PSAP to the LIS.
information of the caller, using SIP presence mechanisms RFC 3856
[RFC3856]). Authorization for subscriptions is for future study.
When location is conveyed by reference, additional dereference
operations yield updated location.
5.8. Location Validation A PSAP has no way to request an update of a location-by-value. If
the UAC gets new location, it must reINVITE or UPDATE to supply the
new location.
In some jurisdictions, location must be validated prior to a device Generally, the PSAP can wait for an accurate location for dispatch.
placing an actual emergency call, and is always a recommended However, there is no fixed limit known in advance; it depends on the
practice. Validation in this context means both that there is a nature of the emergency. At some point the PSAP must dispatch. In a
subscription environment, the PSAP could update the parameters in the
filter (immediate response required). In a HELD dereference, there
is no way to cancel and the PSAP will have to choose a ResponseTime
that it will wait for even if it wants to dispatch sooner than that.
(Change as the discussion on ResponseTime evolves).
6.9. Multiple locations
Handling multiple locations is discussed in
[I-D.ietf-geopriv-pdif-lo-profile]. Conflicting location information
is particularly harmful if different routes (PSAPs) result from LoST
queries for the multiple locations. Guidelines for dealing with
multiple locations are also given in [I-D.ietf-ecrit-lost].
Generally, if a UA gets multiple locations, it must choose the one to
use. If a proxy is inserting location and has multiple locations, it
must choose the one to use.
The ability of the UA or proxy to understand how and from whom it
learned its location, and include this information element in the
location object that is sent to the PSAP, provides the call-taker
with many pieces of information to make decisions upon, and guidance
for what to ask the caller and what to tell the responders.
The call should indicate the location information that has been used
for routing, so that the same location information is used for all
call routing decisions. The location conveyance mechanism
[I-D.ietf-sip-location-conveyance] contains a parameter for this
purpose.
6.10. Location validation
It is recommended that location must be validated prior to a device
placing an actual emergency call; some jurisdictions require that
this be done. Validation in this context means both that there is a
mapping from the address to a PSAP and that the PSAP understands how mapping from the address to a PSAP and that the PSAP understands how
to direct responders to the location. This is not as easy as it to direct responders to the location. Determining the addresses that
sounds. There are, for example, many cases of two names for the same are valid can be difficult. There are, for example, many cases of
street, or two streets with the same name in a city. In some two names for the same street, or two streets with the same name in a
countries, the current system provides validation. For example, in city. In some countries, the current system provides validation.
the United States, the Master Street Address Guide (MSAG) records all For example, in the United States, the Master Street Address Guide
valid street addresses and is used to ensure that the service (MSAG) records all valid street addresses and is used to ensure that
addresses in phone billing records correspond to valid emergency the service addresses in phone billing records correspond to valid
service street addresses. Validation is normally a concern for civic emergency service street addresses. Validation is normally a concern
addresses, although there could be a concern that a given geo is for civic addresses, although there could be a concern that a given
within at least one PSAP service boundary; that is, a "valid" geo is geo is within at least one PSAP service boundary; that is, a "valid"
one for which there is a mapping. geo is one where there is a mapping.
The LoST resolver[I-D.ietf-ecrit-lost] includes a validation LoST [I-D.ietf-ecrit-lost] includes a location validation function.
function. Validation should ideally be performed when a location is Validation should ideally be performed when a location is entered
entered into a Location Information Server (which is normally a into a Location Information Server. It should be confirmed
provisioning mechanism in the access carrier's operation and support periodically, because the mapping database undergoes slow change; new
system). It should be confirmed periodically, because the mapping streets are added or removed, community names change, postal codes
database undergoes slow change; new streets are added or removed, change, etc. Endpoints may wish to validate locations they receive
community names change, postal codes change, etc. Endpoints may wish from the access network, and will need to validate manually entered
to validate locations they receive from the access network, and will locations. Proxies that insert location may wish to validate
need to validate manually entered locations. Proxies which insert locations they receive from a LIS. Test functions (Section 15)
location may wish to validate locations they receive from a LIS. should also re-validate.
Test functions (Section 13) should also re-validate.
5.9. Default Location 6.11. Default location
Occasionally, a failure may occur where the access network cannot Occasionally, the access network cannot determine the actual location
determine the actual location of the caller. In these cases, it must of the caller. In these cases, it must supply a default location.
supply a default location. The default location should be as The default location should be as accurate as the network can
accurate as the network can determine. For example, in a cable determine. For example, in a cable network, a default location for
network, a default location for each Cable Modem Termination System each Cable Modem Termination System (CMTS), with a representative
(CMTS), with a representative location for all cable modems served by location for all cable modems served by that CMTS could be provided
that CMTS could be provided if the network is unable to resolve the if the network is unable to resolve the subscriber to any unit less
subscriber to any unit less than the CMTS. Default locations must be than the CMTS. Default locations must be marked as such so that the
marked as such (how?) so that the PSAP knows that the location is not PSAP knows that the location is not accurate.
accurate.
5.10. Uninitialized Devices and Location 6.12. Other location considerations
Support of devices that are not registered, and don't have valid call The endpoint is responsible for mapping any form of location it
back identifiers is complex. In some jurisdictions, for some receives from an LCP into PIDF-LO form if the LCP did not directly
services, support of emergency calls from so called "uninitialized" return a PIDF.
devices, for example, a mobile phone which does not have an active
service contract in the United States is required to support calls to
9-1-1. It is attractive for such devices to be able to be used in an
emergency. However, the requirement to do so has caused a huge
number of prank calls to the emergency service. In some countries,
it is common to attempt to place an emergency call from an
unitialized device in the local bazaars to prove to a would-be
purchaser that the phone works. An unitialized device that can place
an emergency call must supply location the same as a fully enabled
device.
6. Routing the Call to the PSAP To prevent against spoofing of the DHCP server, devices implementing
DHCP for location configuration should use DHCP security mechanisms
[RFC3118].
Location may be used for routing by multiple proxy servers on the
path. Mechanism such as S/MIME in SIP signaling [RFC3261] cannot be
used because they obscure location. Only hop-by-hop mechanisms such
as TLS should be used. Location information is sensitive and must be
protected [RFC3693]. Although support of TLS is mandatory in
[RFC3261], many devices do not support it. Implementing location
conveyance in SIP mandates inclusion of TLS support.
7. Uninitialized devices
Support of devices that are not registered, or that don't have valid
call back identifiers is complex. In some jurisdictions, for some
services, support of emergency calls from so-called "uninitialized"
devices is required. For example, cellular providers in the United
States must support calls to 9-1-1 from a mobile phone that does not
have an active service contract. It is attractive for such devices
to be able to be used in an emergency. However, the requirement to
do so has caused a huge number of prank calls to the emergency
service. In some countries, it is common to attempt to place an
emergency call from an unitialized device in the local bazaars to
prove to a would-be purchaser that the phone works. For this reason,
PSAP authorities discourage support for unititialized devices.
An unitialized device that can place an emergency call must supply
location the same as a fully enabled device, must carry a call back
URI that can be used to call the device back, and should have
identifiers in the signaling that can be used to identify the device.
8. Routing the call to the PSAP
Emergency calls are routed based on one or more of the following Emergency calls are routed based on one or more of the following
criteria expressed in the call setup request (INVITE): criteria expressed in the call setup request (INVITE):
Location: Since each PSAP serves a limited geographic region and Location: Since each PSAP serves a limited geographic region and
transferring existing calls delays the emergency response, calls transferring existing calls delays the emergency response, calls
need to be routed to the most appropriate PSAP. In this need to be routed to the most appropriate PSAP. In this
architecture, emergency call setup requests contain location architecture, emergency call setup requests contain location
information, expressed in civic or geospatial coordinates, that information, expressed in civic or geospatial coordinates, that
allows such routing. If there is no or imprecise (e.g., cell allows such routing. If there is no or imprecise (e.g., cell
tower and sector) information at call setup time, an on-going tower and sector) information at call setup time, an on-going
emergency call may also be transferred to another PSAP based on emergency call may also be transferred to another PSAP based on
location information that becomes available in mid-call. location information that becomes available in mid-call.
Type of emergency service: In some jurisdictions, emergency calls Type of emergency service: In some jurisdictions, emergency calls
for fire, police, ambulance or mountain rescue are directed to for fire, police, ambulance or mountain rescue are directed to
just those emergency-specific PSAPs. We support this mechanism by just those emergency-specific PSAPs. This mechanism is supported
optionally labeling calls with a service identifier by marking emergency calls with the proper service identifier
[I-D.ietf-ecrit-service-urn]. [I-D.ietf-ecrit-service-urn].
Media capabilities of caller: In some cases, emergency call centers Media capabilities of caller: In some cases, emergency call centers
for specific caller media preferences, such as typed text or for specific caller media preferences, such as typed text or
video, are separate from voice systems. Also, even if media video, are separate from PSAPs serving voice calls. Routing based
on media would be accomplished at an ESRP. Also, even if media
capability does not affect the selection of the PSAP, there may be capability does not affect the selection of the PSAP, there may be
call takers within the PSAP that are specifically trained, e.g., call takers within the PSAP that are specifically trained, e.g.,
in interactive text or sign language communications. Again, we in interactive text or sign language communications, where routing
use the caller capabilities [RFC3840] mechanism to label and route within the PSAP based on the media offer would be provided.
such calls.
Routing for calls by location and by service is the primary function Routing for calls by location and by service is the primary function
LoST [I-D.ietf-ecrit-lost] provides. LoST accepts a query with LoST [I-D.ietf-ecrit-lost] provides. LoST accepts a query with
location (by-value) in either civic or geo form, plus a service location (by-value) in either civic or geospatial form, plus a
identifier, and returns an xml data structure containing a URI (or service identifier, and returns a URI (or set of URIs) to route the
set of URIs) to route the call to. Normal SIP [RFC3261] routing call to. Normal SIP [RFC3261] routing functions are used to resolve
functions are used to resolve the URI to a next hop destination. the URI to a next hop destination.
The endpoint can complete the LoST mapping from its location at boot The endpoint can complete the LoST mapping from its location at boot
time, and periodically thereafter. It should attempt to obtain a time, and periodically thereafter. It should attempt to obtain a
"fresh" location, and from that a current mapping when it places an "fresh" location, and from that a current mapping when it places an
emergency call, and if accessing either its location acquisition emergency call. If accessing either its location acquisition or
function or mapping function fails, it should use this cached value. mapping functions fail, it should use this cached value. The call
The call would follow its normal outbound call processing. Networks would follow its normal outbound call processing.
that support devices that do not implement LoST mapping themselves
would have the outbound proxy do the mapping. The proxy must have Determining when the device leaves the area provided by the LoST
the location of the endpoint, which is often difficult for the service can tax small mobile devices. For this reason, the LoST
calling network to accurately determine. The endpoint may have its server should return a simple (small number of points) polygon for
location, but would not normally include it on the call signaling. geo reported location [I-D.ietf-geopriv-pdif-lo-profile]. This can
There is no mechanism provided in [I-D.ietf-sip-location-conveyance] be an enclosing subset of the area when the reported point is not
to allow a proxy to require the endpoint supply location, because near an edge or a smaller edge section when the reported location is
that would open the endpoint to an attack by any proxy on the path to near an edge. Civic location is uncommon for mobile devices, but
get it to reveal location. The Proxy CAN redirect a call to the reporting that the same mapping is good within a community name, or
service URN which, if the device recognized the significance, would even a street, may be very helpful for WiFi connected devices that
include location in the redirected call. All networks should detect roam and obtain civic location from the AP they are connected to.
emergency calls and supply default location and/or routing if it is
not already performed. Networks that support devices that do not implement LoST mapping
themselves would have the outbound proxy do the mapping. The proxy
must have the location of the endpoint, that is often difficult for
the calling network to accurately determine. The endpoint may have
its location, but would not normally include it on the call
signaling. There is no mechanism provided in
[I-D.ietf-sip-location-conveyance] to allow a proxy to require the
endpoint supply location, because that would open the endpoint to an
attack by any proxy on the path to get it to reveal location. The
Proxy can redirect a call to the service URN that, if the device
recognized the significance, would include location in the redirected
call. All networks should detect emergency calls and supply default
location and/or routing if it is not already performed.
With the URI obtained from mapping, whether by the endpoint or the With the URI obtained from mapping, whether by the endpoint or the
proxy, the proxy routes the call. Normal SIP[RFC3261] mechanisms are proxy, the proxy routes the call. Normal SIP [RFC3261] and [RFC3263]
used to route calls to the URI obtained from the LoST query. mechanisms are used to route calls to the URI obtained from the LoST
query.
Often, the SIP routing of an emergency call will first route to an Often, the SIP routing of an emergency call will first route to an
incoming call proxy in the domain operated by the emergency service. incoming call proxy in the domain operated by the emergency service.
That proxy is called an "Emergency Services Routing Proxy" (ESRP). That proxy is called an "Emergency Services Routing Proxy" (ESRP).
The ESRP, which is a normal SIP proxy server, may use a variety of The ESRP, which is a normal SIP proxy server, may use a variety of
PSAP state information, the location of the caller, and other PSAP state information, the location of the caller, and other
criteria to onward route the call to the PSAP. criteria to onward route the call to the PSAP. In order for the ESRP
to route on media choice, the initial INVITE has to supply an SDP
Offer.
7. Signaling of Emergency Calls 9. Signaling of emergency calls
9.1. Use of TLS
As discussed above, location is carried in all emergency calls in the As discussed above, location is carried in all emergency calls in the
call signaling. Since emergency calls carry privacy-sensitive call signaling. Since emergency calls carry privacy-sensitive
information, they are subject to the requirements for geospatial information, they are subject to the requirements for geospatial
protocols [RFC3693]. In particular, signaling information should be protocols [RFC3693]. In particular, signaling information should be
carried in TLS, i.e., in 'sips' mode. While requiring TLS is carried in TLS, i.e., in 'sips' mode. However, it is unacceptable to
actually the way the standards are written, it is unacceptable to
have an emergency call fail to complete because a TLS connection was have an emergency call fail to complete because a TLS connection was
not created, for any reason. In many cases, persistent TLS not created, for any reason. Thus the call should be attempted with
TLS, but if the TLS session establishment fails, the call should be
automatically retried without TLS. In many cases, persistent TLS
connections can be maintained between elements to minimize the time connections can be maintained between elements to minimize the time
needed to establish them. needed to establish them [I-D.ietf-sip-outbound]. In other
circumstances, use of session resumption [RFC4507] is recommended.
IPSEC [RFC2401] is an acceptable alternative to TLS.
The use of SIP Identity [RFC4474] to protect the headers of the 9.2. SIP signaling requirements for User Agents
message could improve end-to-end integrity of the information.
Details of how location is carried in call signaling can be found in SIP UAs that do local dial string interpretation, location, and
[I-D.ietf-sip-location-conveyance]. emergency call route will create SIP INVITE messages with the Service
URN in the Request URI, the LoST-determined URI for the PSAP in a
Route header, and the location in a Geolocation header. The INVITE
must also have appropriate call back identifiers To enable media
sensitive routing, the call should include an SDP offer.
8. Caller Preferences 9.3. SIP signaling requirements for proxy servers
SIP Caller Preferences [RFC3841] may be used to signal how the PSAP SIP Proxy servers in the path of an emergency call must be able to
should handle the call. For example, a language preference expressed assist UAs that are unable to provide any of the location based
in an Accept-Language header may used as a hint to cause the PSAP to routing steps and recognition of dial strings. They are also
route the call to a call taker who speaks the requested language. expected to provide identity information for the caller.
9. Including a Valid Call-Back Identifier 10. Call backs
The call-taker must be able to reach the emergency caller if the The call-taker must be able to reach the emergency caller if the
original call is disconnected. In traditional emergency calls, original call is disconnected. In traditional emergency calls,
wireline and wireless emergency calls include a callback identifier wireline and wireless emergency calls include a callback identifier
for this purpose. In SIP systems, the caller should include a for this purpose. In SIP systems, the caller must include a Contact
Contact header field indicating its device URI, if available, or header field indicating its device URI, if globally routable, or
possibly a GRUU[I-D.ietf-sip-gruu] if calls need to be routed via a possibly a GRUU[I-D.ietf-sip-gruu] if calls need to be routed via a
proxy. This identifier would be used to initiate call-backs proxy. This identifier would be used to initiate call-backs
immediately by the call-taker if, for example, the call is immediately by the call-taker if, for example, the call is
prematurely dropped. prematurely dropped. This is a change from [RFC3261] where Contact:
is optional.
In addition, a call-back identifier should be included either as the In addition, a call-back identifier must be included either as the
URI in the From header field [RFC3261] preferably verified by SIP URI in the From header field [RFC3261] verified by SIP Identity
Identity[RFC4474]. This identifier would be used to initiate a call- [RFC4474] , or as a network asserted URI [RFC3325]. This identifier
back at a later time and may reach the caller, not necessarily on the would be used to initiate a call-back at a later time and may reach
same device (and at the same location) as the original emergency the caller, not necessarily on the same device (and at the same
call. Both the Contact and From specific requirements are detailed location) as the original emergency call as per normal SIP rules.
in [I-D.ietf-ecrit-phonebcp]
Emergency authorities generally discourage support of unitialized Emergency authorities generally discourage support of unitialized
devices (see Section 5.10. If an uninitialized device does place an devices (see Section 7. If an uninitialized device does place an
emergency call, some kind of call back URI must be provided. emergency call, some kind of call back URI must be provided (e.g. a
GRUU) in the Contact: header. It is useful to be able to call the
Finally, there may be two other call identifiers included in an device back some time later as well by including some form of URI in
emergency call. An identifier may be included which can be used to a network asserted identity.
identify the caller, as opposed to the device or the subscriber of a
specific calling service. This identifier may be used to retrieve
information about the caller that is independent of calling service.
For example, Alice may have home, office and mobile telephony
services, but she is the same Alice in all of them. Information
about Alice may be kept by an entity independent of any telephony
service provider. The caller identity is a URI and is placed in a
SIP Call-Info header [RFC3261] using the token "?" following the
recommendations in [I-D.ietf-ecrit-phonebcp].
The communications service provider may also include an identifier
that may be used to retrieve information specific to the call held by
the service provider. This identifier, also a URI may be placed in
the Call-Info header using the token "?" per
[I-D.ietf-ecrit-phonebcp].
10. Mid-Call Services and Behavior 11. Mid-call behavior
A PSAP may need to REFER[RFC3515] a call to a bridge for A PSAP may need to REFER[RFC3515] a call to a bridge for
conferencing. The caller should also be prepared to have the call conferencing. The caller should also be prepared to have the call
transferred (usually attended, but possibly blind) as transferred (usually attended, but possibly blind) as per
per[I-D.ietf-sipping-service-examples]. [I-D.ietf-sipping-service-examples].
While in a call, a number of other call features, such as call
waiting, must be disabled. This is also discussed in
[I-D.ietf-ecrit-phonebcp].
11. Call Termination 12. Call termination
It is undesirable for the caller to terminate an emergency call. It is undesirable for the caller to terminate an emergency call.
Strategies for devices to handle caller attempts to terminate may be PSAP call termination is accomplished with normal SIP call
found in [I-D.ietf-ecrit-phonebcp]. PSAP call termination is termination procedures.
accomplished with normal SIP call termination procedures.
12. Media 13. Disabling of features
PSAPs should accept media streams on RTP [RFC3550]. Traditionally, Certain features that can be invoked while a normal call is active
voice has been the only media stream accepted by PSAPs. In some are not permitted when the call is an emergency call. Services such
countries, text, in the form of BAUDOT codes or similar tone encoded as Call Waiting, Call Transfer, Three Way Call and Flash Hold should
signaling within a voiceband is accepted ("TTY") for persons who have be disabled.
hearing disabilities. With the Internet comes a wider array of
potential media which a PSAP should accept. Using SIP signaling
includes the capability to negotiate media. Normal SIP offer/answer
[RFC3264] negotiations should be used to agree on the media streams
to be used. PSAPs should accept real-time text [RFC4103]. All PSAPs
should accept G.711 A law (and mu Law in North America) encoded voice
as described in [RFC3551]. Newer text forms are rapidly appearing,
with Instant Messaging now very common, PSAPs should accept IM with
at least [RFC3428] as well as [RFC3920].
13. Testing Certain features can interfere with calls from a PSAP and should be
disabled. The domain of a PSAP can be determined from the domain
answering an emergency call. A time limit after an emergency call
should be established during which any call from the same domain and
directed to the supplied Contact: or AoR should be accepted as a
call-back from the PSAP.
14. Media
PSAPs should always accept RTP media streams [RFC3550].
Traditionally, voice has been the only media stream accepted by
PSAPs. In some countries, text, in the form of BAUDOT codes or
similar tone encoded signaling within a voiceband is accepted ("TTY")
for persons who have hearing disabilities. With the Internet comes a
wider array of potential media that a PSAP should accept. Using SIP
signaling includes the capability to negotiate media. Normal SIP
offer/answer [RFC3264] negotiations should be used to agree on the
media streams to be used. PSAPs should accept real-time text
[RFC4103]. All PSAPs should accept G.711 A law (and mu Law in North
America) encoded voice as described in [RFC3551]. Newer text forms
are rapidly appearing, with Instant Messaging now very common, PSAPs
should accept IM with at least [RFC3428] as well as [RFC3920]. Video
may be important to support Video Relay Service (Sign language
interpretation) as well as modern video phones.
Media should be kept secure, preferably by use of Secure RTP
[RFC3711].
15. Testing
Since the emergency calling architecture consists of a number of Since the emergency calling architecture consists of a number of
pieces operated by independent entities, it is important to be able pieces operated by independent entities, it is important to be able
to test whether an emergency call is likely to succeed without to test whether an emergency call is likely to succeed without
actually occupying the human resources at a PSAP. Both signaling and actually occupying the human resources at a PSAP. Both signaling and
media paths need to be tested since NATs and firewalls may allow the media paths need to be tested since NATs and firewalls may allow the
session setup request to reach the PSAP, while preventing the session setup request to reach the PSAP, while preventing the
exchange of media. exchange of media.
[I-D.ietf-ecrit-phonebcp] includes a description of an automated test [I-D.ietf-ecrit-phonebcp] includes a description of an automated test
procedure that validates routing, signaling and media path procedure that validates routing, signaling and media path
continuity. This test would be used at boot time, and whenever the continuity. This test would be used at boot time, and whenever the
device location changes enough that a new PSAP mapping is returned device location changes enough that a new PSAP mapping is returned
from LoST. A manual operation for the test should also be possible. from LoST. A manual operation for the test should also be possible.
14. Example Call Flows The PSAP needs to be able to control frequency and duration of the
test, and since the process could be overused, it may temporarily or
TBD permanently suspend its operation.
15. Alternatives Considered
This is a non-normative appendix. During discussions of emergency
calling, a number of suggestions are commonly made. Below, we
discuss some of the reasons why these alternatives do not satisfy the
requirements of emergency calling.
15.1. tel URIs
Instead of providing URIs to call routing proxies or end systems, it
has been suggested that end systems be configured with a "tel" URI
[RFC3966]. Such a "tel" URI would have to be routed to a
geographically appropriate telephony gateway, as it is unlikely that
every building, enterprise or residence will have its own gateway.
VoIP devices can be used in networks that are completely unaware of
VoIP services, with VoIP service providers that are physically far
removed from the caller's network location. Thus, the use of a tel
URI simply moves the problem to the outbound proxy, which has to use
the caller's location to determine the appropriate telephony gateway.
In addition, emergency telephone numbers are far from universal, with
some such numbers used for non-emergency purposes elsewhere. Thus,
an outbound proxy would have to ascertain the location of the caller
to guess whether the "tel" URI identifies an emergency call or some
other number.
Thus, "tel" URIs are not likely to be appropriate or sufficient for There is a concern associated with testing during a so-called
identifying emergency calls and do not, by themselves, solve the call "avalanche-restart" event where, for example a large power outage
routing problem. affects a large number of endpoints, that, when power is restored,
all attempt to reboot and, possibly, test. Devices need to randomize
their initiation of a boot time test to avoid the problem.
16. Security Considerations 16. Security Considerations
Connecting ANY service to the Internet creates threads to the service Security considerations for emergency calling have been documented in
which did not exist before. The emergency call service is especially [I-D.ietf-ecrit-security-threats], and [I-D.barnes-geopriv-lo-sec].
critical compared to other services lately connected to the Internet.
It must work reliably even in case of a major disaster when thousands
of citizens call for help simultaneously. Not only does the service
need to be protected but also the liberties of the citizens who might
need to use the service must be considered.
The emergency service is an obvious target for a deliberate attack,
and specifically a denial of service attack. Mechanisms must be
provided to help the emergency networks survive such attacks while
continuing to provide service to genuine callers.
Failure of any security mechanism should normally not prevent an
emergency call to be established. Unlike most systems, suspicious
calls (that is, those where normal security mechanisms are not
attempted or they fail to produce expected valid credentials) are
normally not dropped, but are processed with the call taker made
aware that the information given (location, for example), may not be
accurate. As the discussion in Section 5 shows, providing accurate
location in the presence of a very wide variety of circumstances is
challenging. Exceptions may result in some of the security
mechanisms not being able to be deployed, and yet the information may
be valid.
When the emergency service is under deliberate attack, the policies
on call acceptance may be changed. More stringent compliance to
security recommendations may be enforced, or at least calls with full
security mechanisms in place may be processed before calls without
them.
The decision whether other security mechanisms should be tried or the
call be dropped depends on the policy of the citizen, the policy of
the call router and the policy of the PSAP and out of the scope of
this document.
16.1. Caller Authentication
Fraudulent calls to PSAPs is a significant concern. Current systems
rely on inherent security mechanisms in the PSTN to make sure the
identity of the owner of the telephone is known. As Internet
technologies are increasingly used to place calls, it is becoming
easier to hide the identity of a caller. Use of the SIP Identity
mechanism [RFC4474] is recommended. If SIP Identity cannot be
provided, carriers should make use of P-Asserted-Identity, [RFC3325]
In keeping with established customs in circuit-switched emergency
calling, authentication cannot be made a prerequisite for routing or
accepting an emergency call. However, a call taker may be more
suspicious of a caller and request additional information if the call
authenticity cannot be verified.
16.2. Location Privacy
Location is sensitive information, it must be protected against
disclosure to unauthorized persons. In most jurisdictions placing an
emergency call implies disclosure of location to all the entities
needing location to properly route and respond to the call.
Nevertheless, even in an emergency, callers have an expectation that
their location will not be divulged outside of that implied release.
During acquisition of the location information, an eavesdropper or
impersonator may obtain location. When DHCP is used, authentication
[RFC3118] should be used to protect the location option. Use of TLS
in other LCPs should be used. Similarly, TLS should be used with SIP
signaling when location is conveyed. However, failure to establish a
security association should never be used to drop an emergency call.
Rather, the operation should be attempted without the security
mechanism.
16.3. PSAP Impersonation
See Section 16.4.
With LoST-based call routing (Section 6), an attacker could modify
the mapping entries for one or more locations, re-routing calls
destined for them. The security mechanisms for provisioning the data
in the LoST database must be robust.
LoST is a distributed database, with many replicas of authoritative
data. An attacker may impersonate a valid LoST server and supply
fraudulent data. An attacker may also perpetrate a denial of service
attack on LoST servers. These issues are addressed in
[I-D.ietf-ecrit-lost].
Finally, the URI LoST returns would normally contain a domain name.
The domain can be hijacked by several known attacks. TLS should be
used to place calls, with the domain name verified. Using DNSSEC
[RFC4033] on the DNS entries is recommended. As above, failure of
the security mechanism must not impede the processing of an emergency
call; the operation should proceed without security rather than
abandoning the call.
16.4. Preventing Call Misdirection
We need to prevent an emergency call reaching a destination other
than a PSAP. For example, a rogue UA able to intercept SIP requests
might be able to impersonate a PSAP.
In the absence of a globally recognized certificate that ensures that
the owner is a legitimate PSAP, we rely on a chain of trust enforced
by the 'sips' URI schema. The 'sips' URI schema forces each SIP hop
to route the call only to destinations supporting TLS transport.
Each ESRP verifies that the next-hop destination chosen as described
in Section 6 corresponds to the server certificate offered by that
destination.
16.5. Call Signaling Integrity
Preventing a malicious outsider from manipulating call information in
SIP requests can be assured by using "sips" (that is, TLS, hop-by-hop
from caller to emergency call taker.
16.6. Media Integrity and Confidentiality
Media integrity and confidentiality can be assured by the use of Ed. Note: go through that doc and make sure any actions needed are
SRTP[RFC3711]. captured in the BCP text.
17. Acknowledgements 17. Acknowledgements
This draft was created from a This draft was created from a
draft-schulzrinne-sipping-emergency-arch-02 together with sections draft-schulzrinne-sipping-emergency-arch-02 together with sections
from draft-polk-newton-ecrit-arch-considerations-02. from draft-polk-newton-ecrit-arch-considerations-02.
Design Team members participating in this draft creation include Design Team members participating in this draft creation include
Hannes Tschofenig, Ted Hardie, Martin Dolly, Marc Linsner, Roger Hannes Tschofenig, Ted Hardie, Martin Dolly, Marc Linsner, Roger
Marshall, Stu Goldman, Shida Schubert and Tom Taylor. Marshall, Stu Goldman, Shida Schubert and Tom Taylor. Further
comments and input was provided by Richard Barnes, Barbara Stark and
James Winterbottom.
18. References 18. References
18.1. Normative References 18.1. Normative References
[I-D.barnes-geopriv-lo-sec]
Barnes, R., "Threats to GEOPRIV Location Objects",
draft-barnes-geopriv-lo-sec-00 (work in progress),
July 2007.
[I-D.ietf-ecrit-lost] [I-D.ietf-ecrit-lost]
Hardie, T., "LoST: A Location-to-Service Translation Hardie, T., "LoST: A Location-to-Service Translation
Protocol", draft-ietf-ecrit-lost-05 (work in progress), Protocol", draft-ietf-ecrit-lost-06 (work in progress),
March 2007. August 2007.
[I-D.ietf-ecrit-phonebcp] [I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-01 (work in progress), draft-ietf-ecrit-phonebcp-01 (work in progress),
March 2007. March 2007.
[I-D.ietf-ecrit-requirements] [I-D.ietf-ecrit-requirements]
Schulzrinne, H. and R. Marshall, "Requirements for Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress), draft-ietf-ecrit-requirements-13 (work in progress),
March 2007. March 2007.
[I-D.ietf-ecrit-security-threats]
Taylor, T., "Security Threats and Requirements for
Emergency Call Marking and Mapping",
draft-ietf-ecrit-security-threats-05 (work in progress),
August 2007.
[I-D.ietf-ecrit-service-urn] [I-D.ietf-ecrit-service-urn]
Schulzrinne, H., "A Uniform Resource Name (URN) for Schulzrinne, H., "A Uniform Resource Name (URN) for
Services", draft-ietf-ecrit-service-urn-06 (work in Emergency and Other Well-Known Services",
progress), March 2007. draft-ietf-ecrit-service-urn-07 (work in progress),
August 2007.
[I-D.ietf-geopriv-http-location-delivery]
Barnes, M., "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-01 (work in
progress), July 2007.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-geopriv-pdif-lo-profile]
Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
Considerations and Recommendations", Considerations and Recommendations",
draft-ietf-geopriv-pdif-lo-profile-08 (work in progress), draft-ietf-geopriv-pdif-lo-profile-08 (work in progress),
July 2007. July 2007.
[I-D.ietf-geopriv-revised-civic-lo]
Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for PIDF-LO",
draft-ietf-geopriv-revised-civic-lo-05 (work in progress),
February 2007.
[I-D.ietf-sip-gruu] [I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-14 (work in progress), (SIP)", draft-ietf-sip-gruu-14 (work in progress),
June 2007. June 2007.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Session Initiation Protocol Polk, J. and B. Rosen, "Location Conveyance for the
Location Conveyance", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-07 (work in progress), draft-ietf-sip-location-conveyance-08 (work in progress),
February 2007. July 2007.
[I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-10 (work in progress), July 2007.
[I-D.ietf-sipping-config-framework] [I-D.ietf-sipping-config-framework]
Petrie, D. and S. Channabasappa, "A Framework for Session Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery", Initiation Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-12 (work in progress), draft-ietf-sipping-config-framework-12 (work in progress),
June 2007. June 2007.
[I-D.rosen-iptel-dialstring]
Rosen, B., "Dialstring parameter for the Session
Initiation Protocol Uniform Resource Identifier",
draft-rosen-iptel-dialstring-05 (work in progress),
March 2007.
[LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control",
Dec 2004. Dec 2004.
[LLDP-MED] [LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery". Endpoint Discovery".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002. UPDATE Method", RFC 3311, October 2002.
skipping to change at page 32, line 4 skipping to change at page 33, line 36
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005. Conversation", RFC 4103, June 2005.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
Supporting Emergency Telecommunications Service (ETS) in
IP Telephony", RFC 4190, November 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 4507, May 2006.
[RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4676, October 2006. Configuration Information", RFC 4676, October 2006.
[RFC4967] Rosen, B., "Dial String Parameter for the Session
Initiation Protocol Uniform Resource Identifier",
RFC 4967, July 2007.
18.2. Informative References 18.2. Informative References
[I-D.ietf-sipping-service-examples] [I-D.ietf-sipping-service-examples]
Johnston, A., "Session Initiation Protocol Service Johnston, A., "Session Initiation Protocol Service
Examples", draft-ietf-sipping-service-examples-12 (work in Examples", draft-ietf-sipping-service-examples-13 (work in
progress), January 2007. progress), July 2007.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of [WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of
Defense World Geodetic System 1984, Its Definition and Defense World Geodetic System 1984, Its Definition and
Relationships With Local Geodetic Systems, Third Edition", Relationships With Local Geodetic Systems, Third Edition",
July 1997. July 1997.
Authors' Addresses Authors' Addresses
skipping to change at page 33, line 25 skipping to change at page 35, line 25
James Polk James Polk
Cisco Systems Cisco Systems
3913 Treemont Circle 3913 Treemont Circle
Colleyville, Texas 76034 Colleyville, Texas 76034
US US
Phone: +1-817-271-3552 Phone: +1-817-271-3552
Email: jmpolk@cisco.com Email: jmpolk@cisco.com
Andrew Newton Andrew Newton
SunRocket TranTech/MediaSolv
8045 Leesburg Pike, Suite 300 4900 Seminary Road
Vienna, VA 22182 Alexandria, VA 22311
US US
Phone: +1 703 636 8052 Phone: +1 703 845 0656
Email: andy@hxr.us Email: andy@hxr.us
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 147 change blocks. 
874 lines changed or deleted 1063 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/