< draft-ietf-ecrit-framework-00.txt   draft-ietf-ecrit-framework-01.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: April 18, 2007 Columbia U. Expires: September 2, 2007 Columbia U.
J. Polk J. Polk
Cisco Systems Cisco Systems
A. Newton A. Newton
SunRocket SunRocket
October 15, 2006 March 01, 2007
Framework for Emergency Calling in Internet Multimedia Framework for Emergency Calling in Internet Multimedia
draft-ietf-ecrit-framework-00 draft-ietf-ecrit-framework-01
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 April 18, 2007. This Internet-Draft will expire on September 2, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Summoning emergency help by the public is a core feature of telephone Summoning emergency help by the public is a core feature of telephone
networks. This document describes a framework of how various IETF networks. This document describes a framework of how various IETF
protocols and mechanisms are combined to place emergency calls. This protocols and mechanisms are combined to place emergency calls. This
includes how these calls are routed to the correct Public Safety includes how these calls are routed to the correct Public Safety
Answering Point (PSAP) based on the physical location of the caller, Answering Point (PSAP) based on the physical location of the caller,
while providing the call taker the necessary information to dispatch while providing the call taker the necessary information to dispatch
a first responder to that location. This document explains how a first responder to that location. This document explains how
skipping to change at page 3, line 21 skipping to change at page 3, line 21
5. Location and Its Role in an Emergency Call . . . . . . . . . . 12 5. Location and Its Role in an Emergency Call . . . . . . . . . . 12
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Types of Location Information . . . . . . . . . . . . . . 12 5.2. Types of Location Information . . . . . . . . . . . . . . 12
5.3. Location Determination . . . . . . . . . . . . . . . . . . 13 5.3. Location Determination . . . . . . . . . . . . . . . . . . 13
5.3.1. User-Entered Location Information . . . . . . . . . . 14 5.3.1. User-Entered Location Information . . . . . . . . . . 14
5.3.2. Access Network "Wire Database" Location Information . 14 5.3.2. Access Network "Wire Database" Location Information . 14
5.3.3. End-System Measured Location Information . . . . . . . 15 5.3.3. End-System Measured Location Information . . . . . . . 15
5.3.4. Third-party Measured Location Information . . . . . . 15 5.3.4. Third-party Measured Location Information . . . . . . 15
5.4. Location and References to Location . . . . . . . . . . . 16 5.4. Location and References to Location . . . . . . . . . . . 16
5.5. End System Location Configuration . . . . . . . . . . . . 16 5.5. End System Location Configuration . . . . . . . . . . . . 16
5.6. Conveyance of Location . . . . . . . . . . . . . . . . . . 17 5.6. Conveyance of Location . . . . . . . . . . . . . . . . . . 18
5.7. Location Updates . . . . . . . . . . . . . . . . . . . . . 18 5.7. Location Updates . . . . . . . . . . . . . . . . . . . . . 18
5.8. Location Validation . . . . . . . . . . . . . . . . . . . 19 5.8. Location Validation . . . . . . . . . . . . . . . . . . . 19
5.9. Default Location . . . . . . . . . . . . . . . . . . . . . 19 5.9. Default Location . . . . . . . . . . . . . . . . . . . . . 19
6. Routing the Call to the PSAP . . . . . . . . . . . . . . . . . 19 6. Routing the Call to the PSAP . . . . . . . . . . . . . . . . . 20
7. Signaling of Emergency Calls . . . . . . . . . . . . . . . . . 21 7. Signaling of Emergency Calls . . . . . . . . . . . . . . . . . 21
8. Caller Preferences . . . . . . . . . . . . . . . . . . . . . . 21 8. Caller Preferences . . . . . . . . . . . . . . . . . . . . . . 22
9. Including a Valid Call-Back Identifier . . . . . . . . . . . . 21 9. Including a Valid Call-Back Identifier . . . . . . . . . . . . 22
10. Mid-Call Services and Behavior . . . . . . . . . . . . . . . . 22 10. Mid-Call Services and Behavior . . . . . . . . . . . . . . . . 23
11. Call Termination . . . . . . . . . . . . . . . . . . . . . . . 22 11. Call Termination . . . . . . . . . . . . . . . . . . . . . . . 23
12. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
13. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
14. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 23 14. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 24
15. Alternatives Considered . . . . . . . . . . . . . . . . . . . 23 15. Alternatives Considered . . . . . . . . . . . . . . . . . . . 24
15.1. tel URIs . . . . . . . . . . . . . . . . . . . . . . . . . 23 15.1. tel URIs . . . . . . . . . . . . . . . . . . . . . . . . . 24
16. Security Considerations . . . . . . . . . . . . . . . . . . . 24 16. Security Considerations . . . . . . . . . . . . . . . . . . . 24
16.1. Caller Authentication . . . . . . . . . . . . . . . . . . 24 16.1. Caller Authentication . . . . . . . . . . . . . . . . . . 25
16.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 24 16.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 26
16.3. PSAP Impersonation . . . . . . . . . . . . . . . . . . . . 24 16.3. PSAP Impersonation . . . . . . . . . . . . . . . . . . . . 26
16.4. Preventing Call Misdirection . . . . . . . . . . . . . . . 25 16.4. Preventing Call Misdirection . . . . . . . . . . . . . . . 26
16.5. Call Signaling Integrity . . . . . . . . . . . . . . . . . 25 16.5. Call Signaling Integrity . . . . . . . . . . . . . . . . . 27
16.6. Media Integrity and Confidentiality . . . . . . . . . . . 25 16.6. Media Integrity and Confidentiality . . . . . . . . . . . 27
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
18.1. Normative References . . . . . . . . . . . . . . . . . . . 26 18.1. Normative References . . . . . . . . . . . . . . . . . . . 27
18.2. Informative References . . . . . . . . . . . . . . . . . . 29 18.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 32
1. Terminology 1. Terminology
As a framework document, we do not define any new protocols or As a framework document, we do not define any new protocols or
articulate new behaviors. Thus we do not use RFC2119 [RFC2119] articulate new behaviors. Thus we do not use RFC2119 [RFC2119]
notation. In this document, we reuse terms, and their definition, notation. In this document, we reuse terms, and their definition,
from [I-D.ietf-ecrit-requirements]. In addition, the following terms from [I-D.ietf-ecrit-requirements]. In addition, the following terms
are used: are used:
(Emergency) call taker: see [I-D.ietf-ecrit-requirements] (Emergency) call taker: see [I-D.ietf-ecrit-requirements]
ESRP (emergency service routing proxy): see ESRP (emergency service routing proxy): see
skipping to change at page 6, line 12 skipping to change at page 6, line 12
We distinguish an individual request for help, usually accomplished We distinguish an individual request for help, usually accomplished
by dialing a short digit sequence like 9-1-1 or 1-1-2 from a call by dialing a short digit sequence like 9-1-1 or 1-1-2 from a call
placed by specially designated persons who have authority to claim placed by specially designated persons who have authority to claim
priority on available Internet communications facilities. This priority on available Internet communications facilities. This
document only discusses the former - a request for help by an document only discusses the former - a request for help by an
ordinary user answered at an emergency call center (i.e. a PSAP). ordinary user answered at an emergency call center (i.e. a PSAP).
Existing emergency call systems are organized locally/nationally; Existing emergency call systems are organized locally/nationally;
there are currently no international standards. However, the there are currently no international standards. However, the
Internet does not respect national boundaries, and thus international Internet does not respect national boundaries, and thus international
standards for equipment and software required. To further complicate standards for equipment and software are required. To further
matters, VoIP endpoints can be connected through tunneling mechanisms complicate matters, VoIP endpoints can be connected through tunneling
such as virtual private networks (VPNs). This significantly mechanisms such as virtual private networks (VPNs). This
complicates emergency calling, because the location of the caller and significantly complicates emergency calling, because the location of
the first element that routes emergency calls can be on different the caller and the first element that routes emergency calls can be
continents, with different conventions and processes for handling of on different continents, with different conventions and processes for
emergency calls. 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) by PSAPs and calling parties. While other inter-domain call (SIP) [RFC3261] by PSAPs and calling parties. While other inter-
signaling protocols may be used for emergency calling, SIP is domain call signaling protocols may be used for emergency calling,
ubiquitous and possesses, through its related specifications, more of SIP is ubiquitous and possesses, through its related specifications,
the needed features for the proper support of this use case. Only more of the needed features for the proper support of this use case.
protocols such as H.323, XMPP/Jingle, ISUP and SIP are suitable for Only protocols such as H.323, XMPP/Jingle, ISUP and SIP are suitable
inter-domain communications, ruling out master-slave protocols such for inter-domain communications, ruling out MG/MGC protocols such as
as MGCP or H.248/Megaco. The latter protocols can naturally be used MGCP or H.248/Megaco. The latter protocols can naturally be used by
by the enterprise or carrier placing the call, but any such call the enterprise or carrier placing the call, but any such call would
would reach the PSAP through a media gateway controller, similar to reach the PSAP through a media gateway controller, similar to how
how interdomain VoIP calls would be placed. Other signaling interdomain VoIP calls would be placed. Other signaling protocols
protocols may also use protocol translation to communicate with a may also use protocol translation to communicate with a SIP-enabled
SIP-enabled PSAP. PSAP.
Existing emergency services rely exclusively on voice and Existing emergency services rely exclusively on voice and
conventional text telephony (known as TTY in the United States) media conventional text telephony (known as TTY in the United States) media
streams. However, more choices of media offer additional ways to streams. However, more choices of media offer additional ways to
communicate and evaluate the situation as well as to assist callers communicate and evaluate the situation as well as to assist callers
and call takers to handle emergency calls. For example, instant and call takers to handle emergency calls. For example, instant
messaging and video could improve the ability to communicate and messaging and video could improve the ability to communicate and
evaluate the situation and to provide appropriate instruction prior evaluate the situation and to provide appropriate instruction prior
to arrival of emergency crews. Thus, the architecture described here to arrival of emergency crews. Thus, the architecture described here
supports the creation of sessions of any media type, negotiated supports the creation of sessions of any media type, negotiated
between the caller and PSAP using existing SIP protocol mechanisms between the caller and PSAP using existing SIP protocol mechanisms
[RFC3264]. To ensure that at least one common means of [RFC3264]. To ensure that at least one common means of
communications, this document recommends certain minimal capabilities communications, this document recommends certain minimal capabilities
in [phonebcp] that call taker user agents and PSAP-operated proxies in [I-D.ietf-ecrit-phonebcp] that call taker user agents and PSAP-
should possess. operated proxies should possess.
This document does not prescribe the detailed network architecture This document does not prescribe the detailed network architecture
for a PSAP or collection of PSAPs. For example, it does not describe for a PSAP or collection of PSAPs. For example, it does not describe
where PSAPs may place firewalls or how many SIP proxies they should where PSAPs may place firewalls or how many SIP proxies they should
use. use.
This document does not introduce any new SIP header fields, request This document does not introduce any new SIP header fields, request
methods, status codes, message bodies, or event packages. User methods, status codes, message bodies, or event packages. User
agents unaware of the recommendations in this draft can place agents unaware of the recommendations in this draft can place
emergency calls, but may not be able to provide the same elevated emergency calls, but may not be able to provide the same elevated
user interface functionality. The document suggests behavior for user interface functionality. The document suggests behavior for
proxy servers, in particular outbound proxy servers. proxy servers, in particular outbound proxy servers.
3. Overview of How Emergency Calls are Placed 3. Overview of How Emergency Calls are Placed
We distinguish (Section 4) an emergency call from any other call by a We distinguish (Section 4) an emergency call from any other call by a
unique Service URN[I-D.ietf-ecrit-service-urn], which is placed in unique Service URN[I-D.ietf-ecrit-service-urn], which is placed in
the initial call set-up signaling when a home or visited dialstring the initial call set-up signaling when a home or visited emergancy
is detected. We route emergency calls based on the location ( dialstring is detected. We route emergency calls based on the
(Section 5)) of the caller. To get this location we either include a location ( (Section 5)) of the caller. To get this location we
form of measuring (e.g. GPS) ( (Section 5.3.3)) device location in either include a form of measuring (e.g. GPS) ( (Section 5.3.3))
the endpoint, or the endpoint is configured ( (Section 5.5)) with its device location in the endpoint, or the endpoint is configured (
location from the access network's Location Information Server (LIS) (Section 5.5)) with its location from the access network's Location
The location is conveyed ( (Section 5.6)) in the SIP signaling with Information Server (LIS) The location is conveyed ( (Section 5.6)) in
the call. We route( (Section 6)) the call based on location using the SIP signaling with the call. We route( (Section 6)) the call
the LoST protocol ( [I-D.ietf-ecrit-lost]) which maps a location to a based on location using the LoST protocol ( [I-D.ietf-ecrit-lost])
set of PSAP URIs. Each URI resolves to a PSAP or an Emergency which maps a location to a set of PSAP URIs. Each URI resolves to a
Services Routing Proxy which serves a group of PSAPs. The call PSAP or an Emergency Services Routing Proxy which serves a group of
arrives at the PSAP with the location included in the INVITE request. PSAPs. The call arrives at the PSAP with the location included in
the INVITE request.
Configuration Servers Configuration Servers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. +--------+ +----------+ . . +--------+ +----------+ .
. +--------+ | +----------+ | . . +--------+ | +----------+ | .
. | LIS | | | SIP | | . . | LIS | | | SIP | | .
. | |-+ | Registrar|-+ . . | |-+ | Registrar|-+ .
. +--------+ +----------+ . . +--------+ +----------+ .
. ^ ^ . . ^ ^ .
. . | . . . . . . . | . . . . . . . . | . . . . . . . | . . . . . .
| | | |
|[1] |[2] |[1][4] |[2]
| | +--------+ | | +--------+
|+--------------+ +--------+ | |+--------------+ +--------+ |
|| | LoST | | || | LoST | |
||+-------------------->| Servers|-+ ||+-------------------->| Servers|-+
||| [3] +--------+ +-------+ ||| [3][5] +--------+ +-------+
||| ^ | | PSAP2 | ||| | PSAP2 |
||| [6] | | [7] +-------+ ||| +-------+
||| | v |||
||| [4] +-------+ [5] +------+ [8] +-------+ [9] ||| [6] +-------+ [7] +------+ [8] +-------+ [9]
Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker
+-------+ +------+ +-------+ +-------+ +------+ +-------+
+-------+ +-------+
| PSAP3 | | PSAP3 |
+-------+ +-------+
Figure 1: Generic ECRIT Component Topology Figure 1: Generic ECRIT Component Topology
Figure 2 shows a generic emergency call establishment. This includes Figure 2 shows a generic emergency call establishment. This includes
the following: the following:
o Alice - who will make the emergency call. o Alice - who will make the emergency call.
o Configuration Servers - Servers providing Alice's UA its IP o Configuration Servers - Servers providing Alice's UA its IP
address and other configuration information, perhaps including address and other configuration information, perhaps including
Location by-value or by-reference. In this flow, we use DHCP as Location by-value or by-reference. In this flow, we use DHCP as
an example location acquisition protocol. To make this flow an example location acquisition protocol. Configuration servers
easier to read, these configuration servers include a SIP also may include a SIP Registrar server, for Alice's UA to
Registrar server, for Alice's UA to register with the local register Alice's UA to register with. Most SIP UAs will register
domain, which will most likely be the case for an emergency call. with a call server, so it will be a common scenario for UAs that
All these configuration messages are labeled M1 through M4, but make emergency calls to be registered with such a server in the
could easily require more messages than 4 to complete. originating calling network. All these configuration messages are
o ESRP - The Emergency Services Routing Proxy Server that recognizes labeled M1 through M3, but could easily require more messages than
any INVITE as an emergency session initiation, and does special 4 to complete.
things (knows to look for Location in the INVITE, dereferences a o ESRP - The Emergency Services Routing Proxy Server that is the
location-by-reference, initiated a LoST Query to learn the PSAP incoming call proxy in the emergency services domain. The ESRP
SIP(S)-URI for a UA at this location, etc). ESRPs are optional makes further routing decisions based on PSAP state and location
elements and in some jurisdictions an emergency call may not pass of the caller to choose the actual PSAP which handles the call.
through one In some jurisdictions, that may involve another LoST dip
o Mapping Server - Processes the LoST request for Location to PSAP- o LoST Server - Processes the LoST request for Location to PSAP-URI
URI Mapping function, either for an initial request from a UA, or Mapping function, either for an initial request from a UA, or an
an in-call establishment request by an ESRP. 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 o PSAP - Call center where emergency calls are destined for in times
of emergencies. of emergencies.
Generally, Alice's UA either has location configured within her UA Generally, Alice's UA either has location configured manually, has an
when her UA boots, or she configures it with location once it boots integral location measurement mechanism, or it runs a location
up, or her UA receives measured location from the network. Her UA configuration protocol to obtain location from the access (broadband)
may have asked for location during boot-time, for example in a network. For most devices, an LCP will be used, for example a
DHCPREQUEST message or another location acquisition mechanism. DHCPREQUEST message or another location acquisition mechanism.
Alice's UA then will most likely register with a SIP domain. This 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 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 an perform an initial LoST Location-to-PSAP SIP(S)-URI query to learn a
early URI, for use if the Lost Query fails during an emergency call. URI, for use if the Lost Query fails during an emergency call. The
This learned early PSAP-URI will be placed in a Route header within LoST query may contain the dialstring for emergency calls appropriate
an emergency INVITE message, message [M7] in Figure 1. for the location provided.
Some time has hopefully passed since Alice's UA booted. In this Some time has hopefully passed since Alice's UA booted. In this
example, she dials or initiated an emergency call. This may have example, she dials or initiates an emergency call. This may have
been through her keypad with her locally known emergency dialstring. been through her keypad with her locally known emergency dialstring.
It is important that this dialstring be recognized by her UA wherever It is important that this dialstring be recognized by her UA wherever
Alice is because she may be in enough distress she forgets what the Alice is because she may be in enough distress she forgets what the
traveled-to emergency dialstring is; as there are more than 60 around traveled-to emergency dialstring is; as there are more than 60 around
the world. the world.
This emergency INVITE arrives at a SIP Proxy that understands the The UA recognizes the dialstring, which means this is an emergency
concept of emergency calling, meaning it is an ESRP. In recognizing call. The UA attempts to refresh its location, and with that
the INVITE as an emergency call set-up, the ESRP looks for Location location, the LoST mapping, to get the most accurate information to
within the message. [I-D.ietf-sip-location-conveyance] defines a SIP use for routing the call. If the location request or the LoST
Location header that either contain the location-by-reference URI, or request fails (or takes too long) the UA uses it's cached values.
a [RFC2396] "cid:" indicating where in the message body the location-
by-value is. The ESRP can dereference the UA provided Location URI,
and insert the location information from the PIDF-LO into the LoST
query. This will prevent any problems of the LoST Mapping server
experiencing dereferencing problems with this request. This is
message [M7] and [M8] in Figure 1. The LoST response provides the
ESRP with the freshest PSAP-URI for that location (of Alice's UA) for
the most up to date routing choice. This is message [M9].
The INVITE message receives a new Request-URI in the ESRP, which was The UA creates an INVITE which includes the location.
returned in the LoST response. This message, [M10] is transmitted [I-D.ietf-sip-location-conveyance] defines a SIP Location header that
towards the most current PSAP for Alice's location. Message [M11], either contain the location-by-reference URI, or a [RFC2396] "cid:"
the 200 OK to the INVITE may traverse one or more proxies if they indicating where in the message body the location-by-value is.
insert a Via header, or if one or more are B2BUAs. Figure 1 does not
show this. The ACK completes the call set-up and the emergency call 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 choses 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 is established, allowing the PSAP call-taker to talk to Alice about
her emergency. 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] DHCP Request(s) (may ask for Location)
----------> ---------->
[M2] DHCP Reply(s) (replies with location if asked) DHCP Reply(s) (replies with location if asked)
<--------- <---------
[M3] SIP REGISTER (perhaps with PIDF-LO) [M2] SIP REGISTER
----------> ---------->
[M4] SIP 200 OK (REGISTER) SIP 200 OK (REGISTER)
<--------- <---------
[M5] Initial LoST Protocol Query (contains Location) [M3] Initial LoST Protocol Query (contains Location)
----------------------------------------> ---------------------------------------->
[M6] Initial LoST Protocol Response (contains PSAP-URI) Initial LoST Protocol Response (contains PSAP-URI)
<---------------------------------------- <----------------------------------------
***Some time later, Alice dials/initiates emergency call*** ***Some time later, Alice dials/initiates emergency call***
[M7] INVITE (sos, Location & early Mapping URI) [M4] DHCP Request(s) (update Location)
---------->
DHCP Reply(s) (replies with location)
<---------
[M5] Update LoST Protocol Query (contains Location)
---------------------------------------->
LoST Protocol Response (contains PSAP-URI)
<----------------------------------------
[M6/7] INVITE (sos URN, Location & early PSAP URI)
---------------------> --------------------->
[M8] LoST Protocol Query (with Location) [M8] INVITE (sos, Location & PSAP-URI)
----------------->
[M9] LoST Protocol Response (with PSAP-URI)
<-----------------
[M10] INVITE (sos, Location & PSAP-URI)
--------------------------------------> -------------------------------------->
[M11] 200 OK 200 OK
<-------------------------------------------------------------- <--------------------------------------------------------------
[M12] 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 This is a very rough example of the operation of an emergency call
establishment. There are no layer 3 routers in the message flow, and establishment. There are no layer 3 routers in the message flow, and
whatever security messages exist in the call are not shown either. whatever security messages exist in the call are not shown either.
Each of those aspects will be addressed individually, to keep each Each of those aspects will be addressed individually, to keep each
skipping to change at page 11, line 26 skipping to change at page 11, line 30
another for fire. It is deemed impractical to change the dialed another for fire. It is deemed impractical to change the dialed
digits to summon help. For end systems, it is desirable to have a digits to summon help. For end systems, it is desirable to have a
universal identifier, independent of location, to allow the automated universal identifier, independent of location, to allow the automated
inclusion of location information and to allow the device and other inclusion of location information and to allow the device and other
entities in the call path to perform appropriate processing within entities in the call path to perform appropriate 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 As part of the overall emergency calling architecture, we define
common emergency call URIs which are defined in common emergency call URIs which are defined in
[I-D.ietf-ecrit-service-urn]. Users are not expected to "dial" an [I-D.ietf-ecrit-service-urn]. Users are not expected to "dial" an
emergency URN. Rather, the current dial sequence should be emergency URN. Rather, the current dialstring should be translated
translated to the appropriate service URN. Such translation could to the appropriate service URN. Such translation could ideally be
ideally be performed in the endpoint, but could be performed in a performed in the endpoint, but could be performed in a signaling
signaling intermediary (proxy server). For devices that are mobile intermediary (proxy server). For devices that are mobile or nomadic,
or nomadic, an issue arises of whether the home or visited dialing an issue arises of whether the home or visited dialing strings should
strings should be used. Many users would prefer that their home be used. Many users would prefer that their home dialing sequences
dialing sequences work no matter where they are. Local laws and work no matter where they are. Local laws and preferences of the
preferences of the emergency response professionals are that the emergency response professionals are such that the visited dialing
visited dialing sequences be used. The best answer seems to be for sequences must always work. Having the home dialstring work is
both to work. optional. The best answer seems to be for both to work.
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] and the procedures location is provided by LoST [I-D.ietf-ecrit-lost]. Where the
for the translation are detailed in [phonebcp]. Where the endpoint endpoint does not support the translation of dialstrings to telephone
does not support the translation of dialstrings to telephone numbers, numbers, the dialing sequence would be represented as a dialstring
the dialing sequence would be represented as a dialstring
[I-D.rosen-iptel-dialstring] and the outgoing proxy would recognize [I-D.rosen-iptel-dialstring] and the outgoing proxy would recognize
the dialstring and translate to the service URN. It should be noted the dialstring and translate to the service URN. It should be noted
that the endpoint would not normally supply location unless it that the endpoint would not normally supply location unless it
understood the call to be an emergency call. To determine the local understood the call to be an emergency call. To determine the local
dialstring, the proxy needs the location of the endpoint. This may dialstring, the proxy needs the location of the endpoint. This may
be difficult in situations where the user can roam or be nomadic. be difficult in situations where the user can roam or be nomadic.
Endpoint recognition of emergency dialstrings is therefore preferred. Endpoint recognition of emergency dialstrings is therefore preferred.
5. Location and Its Role in an Emergency Call 5. Location and Its Role in an Emergency Call
5.1. Introduction 5.1. Introduction
Caller location plays a central role in routing emergency calls. For Caller location plays a central role in routing emergency calls. For
practical reasons, each PSAP generally handles only calls for a practical reasons, each PSAP generally handles only calls for a
certain geographic area (overload arrangements between PSAPs to certain geographic area (overload arrangements between PSAPs to
handle each others calls notwithstanding). Other calls that reach it handle each others calls notwithstanding). Other calls that reach it
skipping to change at page 13, line 29 skipping to change at page 13, line 34
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"), can be measured by the end system,
can be delivered to the end system by some protocol or can be can be delivered to the end system by some protocol or can be
measured by a third party and inserted into the call signaling. We measured by a third party and inserted into the call signaling. We
discuss these in detail below. discuss these in detail below.
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. Handling multiple locations is discussed
in XRef??. Conflicting location information is particularly harmful in [I-D.ietf-geopriv-pdif-lo-profile]. Conflicting location
if it points to multiple distinct PSAPs. Guidelines for dealing with information is particularly harmful if it points to multiple distinct
multiple locations is given in [phonebcp]. PSAPs. Guidelines for dealing with multiple locations is also given
in [I-D.ietf-ecrit-lost].
All location objects MUST be delivered to the PSAP. To facilitate All location objects MUST be delivered to the PSAP. To facilitate
such policy decisions, location information should contain such policy decisions, location information should contain
information about the source of data, such as GPS, manually entered information about the source of data, such as GPS, manually entered
or based on access network topology. In addition, the generator of or based on access network topology. In addition, the generator of
the location information should be included. The ability of the UA the location information should be included. The ability of the UA
to understand how it learned its location, and include this to understand how it learned its location, and include this
information element in the location object that is sent to the PSAP, information element in the location object that is sent to the PSAP,
provides the call-taker with many pieces of information to make provides the call-taker with many pieces of information to make
decisions upon, and ask the caller with. 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 The call should indicate which location information has been used for
routing, so that the same location information is used for all call routing, so that the same location information is used for all call
routing decisions. Otherwise, two proxies might pick different routing decisions. Otherwise, two proxies might pick different
location information from the call request, resulting in different location information from the call request, resulting in different
routing decisions for different transactions. routing decisions for different transactions. The location
conveyance mechanism [I-D.ietf-ecrit-lost] contains a parameter which
can be used for this purpose
End systems and network elements can derive location information from End systems and network elements can derive location information from
a variety of sources. It is not the goal of this document to a variety of sources. It is not the goal of this document to
exhaustively enumerate them, but we provide a few common examples in exhaustively enumerate them, but we provide a few common examples in
the sections below. the sections below.
5.3.1. User-Entered Location Information 5.3.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.
skipping to change at page 15, line 42 skipping to change at page 16, line 4
3. AGPS-device initiated, network determined 3. AGPS-device initiated, network determined
4. AGPS-device initiated, network augmented 4. AGPS-device initiated, network augmented
5. AGPS-network initiated, network determined 5. AGPS-network initiated, network determined
6. AGPS-network initiated, network augmented 6. AGPS-network initiated, network augmented
5.3.4. Third-party Measured Location Information 5.3.4. Third-party Measured Location Information
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 triangulation and measured mechanisms are combined, for
example A-GPS with AFLT example A-GPS with 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.
5.4. Location and References to Location 5.4. Location and References to Location
Location information may be expressed as the actual civic or geo Location information may be expressed as the actual civic or geo
value but can transmitted as by-value (wholly contained within the value but can be transmitted as by-value (wholly contained within the
signaling message) or by-reference (a URI pointing to the value signaling message) or by-reference (a URI pointing to the value
residing on a remote node waiting to be dereferenced). There are residing on a remote node waiting to be dereferenced). There are
pros and cons to each form: pros and cons to each form:
location-by-value: location-by-value:
pro- Value available to each device along the path immediately pro- Value available to each device along the path immediately
for further processing. for further processing.
con- Size, especially if constrained to a UDP transport. Value con- Size, especially if constrained to a UDP transport. Value
fixed at the time the value is acquired from the access fixed at the time the value is acquired from the access
network. Value can be changed by endpoint, which may be network. Value can be changed by endpoint, which may be
considered untrustworthy for this critical usage. considered untrustworthy for this critical usage.
location-by-reference location-by-reference
pro- 'Small size. Value can fixed at time of dereference. Value pro- Small size. Value can be fixed at time of dereference.
cannot be changed by endpoint Value cannot be changed by endpoint
con- URI resolution requires location source be available and con- URI resolution requires location source be available and
accessible by dereferencer. Dereferencing takes time. accessible by dereferencer. Dereferencing takes time.
Dereferencing may fail. Dereferencing may fail.
5.5. End System Location Configuration 5.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 that can be used There are several Location Configuration Protocols that can be used
for this purpose. for this purpose.
DHCP can deliver civic [I-D.ietf-geopriv-dhcp-civil] or geospatial DHCP can deliver civic [RFC4676] or geospatial [RFC3825]
[RFC3825] information. User agents would need to support both information. User agents would need to support both formats.
formats. Note that a user agent can use DHCP, via the DHCP Note that a user agent can use DHCP, via the DHCP REQUEST or
REQUEST or INFORM messages, even if it uses other means to acquire INFORM messages, even if it uses other means to acquire its IP
its IP address. address.
Insert reference to L7 acquisition protocol document> is another Insert reference to L7 acquisition protocol document> is another
choice. choice.
Link-Layer Discovery Protocol [LLDP]), with proposed extensions Link-Layer Discovery Protocol [LLDP]), with proposed extensions
[LLDP-MED], may also be used to deliver location information. [LLDP-MED], may also be used to deliver location information.
SUPL OASIS <insert reference> is yet another choice. SUPL OASIS <insert reference> is yet another choice.
Other LCPs may be devised by other standards bodies. Each LCP has Other LCPs may be devised by other standards bodies. Each LCP has
limitations in the kinds of networks that can reasonably support it. limitations in the kinds of networks that can reasonably support it.
For this reason, it is not possible to choose a single mandatory to For this reason, it is not possible to choose a single mandatory to
deploy LCP. For endpoints with common network connections (such as deploy LCP. For endpoints with common network connections (such as
an Ethernet jack or a WiFi connection), unless every network an Ethernet jack or a WiFi connection), unless every network
supported every protocol, or alternatively, every device supported supported every protocol, or alternatively, every device supported
every protocol, serious incompatibilities would ensue. [phonebcp] every protocol, serious incompatibilities would ensue.
contains a (short) list of protocols such devices must support. [I-D.ietf-ecrit-lost] contains a (short) list of protocols such
devices must support.
Where an access network can control the specification of EVERY Where an access network can control the specification of EVERY
endpoint that could make an emergency call that is directly connected endpoint that could make an emergency call that is directly connected
to the network, or indirectly connected (for example, a device on a to the network, or indirectly connected (for example, a device on a
LAN behind a network attachment unit), it may specify any protocol it LAN behind a network attachment unit), it may specify any protocol it
wishes for each endpoint. This is a very unusual case; nearly every wishes for each endpoint. This is a very unusual case; nearly every
access network can be used to support an Ethernet based LAN behind access network can be used to support an Ethernet based LAN behind it
it. For example, existing mobile networks are being used to support
routers and LANs behind a wireless data network WAN connection. It For example, existing mobile networks are being used to support
is possible that the access network supports a protocol not on the routers and LANs behind a wireless data network WAN connection, with
phonebcp list, but another element which the access network provider Ethernet connected phones connected to that. It is possible that the
controls the specification of can acquire location using that access network supports a protocol not on the phonebcp list, and
protocol and then that element can support one of the phonebcp's list every handset supported in that network could use that protocol for
of protocols. For example, if the access network provider supplies a emergency calls. However, unless another element which the access
router which includes a DHCP server, it can acquire location using an network provider controls the specification of can acquire location
access network specific protocol, and use the location information to using that protocol and then that element can support one of the
supply it to its clients via DHCP. phonebcp's list of protocols, the Ethernt connected phone won't be
able to acquire location. In this case, if the access network
provider supplies a router which includes a DHCP server, it can
acquire location using the access network specific protocol, and then
use the location information to supply it to its clients (e.g. the
Ethernet connected phone) via DHCP.
For most networks, it will not be practical to control the For most networks, it will not be practical to control the
specification of every device, or arrange interworking with network specification of every device, or arrange interworking with network
specific LCPs. For this reason, most devices will need to support specific LCPs. For this reason, most devices will need to support
ALL of the LCPs in [phonebcp], and access networks will have to ALL of the LCPs in [I-D.ietf-ecrit-lost], and access networks will
support at least one of these LCPs. 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 DHCP
is the acquisition protocol, refresh of location may occur when the is the acquisition protocol, refresh of location may occur when the
IP address lease is renewed). At the time of an emergency call, the IP address lease is renewed). At the time of an emergency call, the
location should be refreshed, with the retained location used if the location should be refreshed, with the retained location used if the
location acquisition does not immediately return a value. Mobile 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 refreshed when a TTL expires, the device moves beyond some boundaries
boundaries, etc. Normally, mobile devices will acquire its location (as provided by [I-D.ietf-ecrit-lost]), etc. Normally, mobile
at call time for use in an emergency call, but see Section 5.7 devices will acquire its location at call time for use in an
emergency call routing, but see Section 5.7
5.6. Conveyance of Location 5.6. Conveyance of Location
When an emergency call is placed, the endpoint (normally) puts When an emergency call is placed, the endpoint (normally) puts
location information in the signaling with the call. We refer to location information in the signaling with the call. We refer to
that as "conveyance" to distinguish it from "acquisition". that as "conveyance" to distinguish it from "configuration".
Acquisition gets location from access network to endpoint, conveyance Configuration gets location from access network to endpoint,
sends location from endpoint to elements that route the call based on conveyance sends location from endpoint to elements that route the
that location object and the PSAP. Using SIP, the location call based on that location object and the PSAP. Using SIP, the
information is conveyed following the procedures in 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]). Conversion by as the conveyance protocol uses (PIDF-LO [RFC4119]). Mapping by the
the endpoint may be required. Calling networks which support devices endpoint may be required. Calling networks which support devices
which do not support location may have to add location to emergency which do not support location may have to add location to emergency
calls. Some calling networks have relationships with the access calls. Some calling networks have relationships with the access
network that may allow it to accurately determine location of the network that may allow it to accurately determine location of the
endpoint, although NATs and other middleboxes often make it endpoint, although NATs and other middleboxes usually make it
impossible to determine a reference identifier the access network impossible to determine a reference identifier the access network
could use to determine the location. could use to determine the location.
For emergency call purposes, conversion of location information from For emergency call purposes, conversion of location information from
civic to geo or vice versa is not desirable. The location should be civic to geo or vice versa prior to conveyance is not desirable. The
sent in the form it was determined. The PSAP may convert, if it location should be sent in the form it was determined. The PSAP may
needs to, and if conversion resulted from an earlier conversion, convert, if it needs to, and if conversion resulted from an earlier
unacceptable errors may be introduced. conversion, unacceptable errors may be introduced.
5.7. Location Updates 5.7. Location Updates
Location information may not be available at call setup time for Location information may not be available at call setup time for
mobile devices. For example, if a GPS-enabled cell phone is turned mobile devices. For example, if a GPS-enabled cell phone is turned
on and then immediately places an emergency call, it can take on and then immediately places an emergency call, it can take
significant additional time before the cell phone acquires a GPS fix significant additional time before the cell phone acquires a GPS fix
and its location. Thus, while it is desirous to base emergency and its location. Thus, while it is desirous to base emergency
routing on precise caller location information, it is not possible in routing on precise caller location information, it is not possible in
all circumstances to do so. In some cases, the initial call setup all circumstances to do so. In some cases, the initial call setup
skipping to change at page 19, line 15 skipping to change at page 19, line 29
5.8. Location Validation 5.8. Location Validation
Location must be validated prior to a device placing an actual Location must be validated prior to a device placing an actual
emergency call. Validation in this context means both that there is emergency call. Validation in this context means both that there is
a mapping from the address to a PSAP and that the PSAP understands a 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 how to direct responders to the location. This is not as easy as it
sounds. There are, for example, many cases of two names for the same sounds. There are, for example, many cases of two names for the same
street, or two streets with the same name in a city. In some street, or two streets with the same name in a city. In some
countries, the current system provides validation. For example, in countries, the current system provides validation. For example, in
the United States, the Master Street Address Guide (MSAG) records all the United States, the Master Street Address Guide (MSAG) records all
valid street addresses and is used to ensure that phone billing valid street addresses and is used to ensure that the service
records correspond to valid emergency service street addresses. addresses in phone billing records correspond to valid emergency
Validation is normally a concern for civic addresses, although there service street addresses. Validation is normally a concern for civic
could be a concern that a given geo is within at least one PSAP addresses, although there could be a concern that a given geo is
service boundary; that is, a "valid" geo is one for which there is a within at least one PSAP service boundary; that is, a "valid" geo is
mapping. one for which there is a mapping.
The LoST resolver[I-D.ietf-ecrit-lost] includes a validation The LoST resolver[I-D.ietf-ecrit-lost] includes a validation
function. Validation should ideally be performed when a location is function. Validation should ideally be performed when a location is
entered into a Location Information Server (which is normally a entered into a Location Information Server (which is normally a
provisioning mechanism in the access carrier's operation and support provisioning mechanism in the access carrier's operation and support
system). It should be confirmed periodically, because the mapping system). It should be confirmed periodically, because the mapping
database undergoes slow change; new streets are added or removed, database undergoes slow change; new streets are added or removed,
community names change, postal codes change, etc. Endpoints may wish community names change, postal codes change, etc. Endpoints may wish
to validate locations they receive from the access network, and will to validate locations they receive from the access network, and will
need to validate manually entered locations. Test functions need to validate manually entered locations. Proxies which insert
(Section 13) should also re-validate. location may wish to validate locations they recieve from a LIS.
Test functions (Section 13) should also re-validate.
5.9. Default Location 5.9. Default Location
Occasionally, a failure may occur where the access network cannot Occasionally, a failure may occur where the access network cannot
determine the actual location of the caller. In these cases, it must determine the actual location of the caller. In these cases, it must
supply a default location. The default location should be as supply a default location. The default location should be as
accurate as the network can determine. For example, in a cable accurate as the network can determine. For example, in a cable
network, a default location for each CMTS, with a representative network, a default location for each Cable Modem Termination System
location for all cable modems served by that CMTS could be provided (CMTS), with a representative location for all cable modems served by
if the network is unable to resolve the subscriber to any unit less that CMTS could be provided if the network is unable to resolve the
than the CMTS. Default locations must be marked as such (how?) so subscriber to any unit less than the CMTS. Default locations must be
that the PSAP knows that the location is not accurate. marked as such (how?) so that the PSAP knows that the location is not
accurate.
6. Routing the Call to the PSAP 6. 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
skipping to change at page 20, line 41 skipping to change at page 21, line 7
identifier, and returns an xml data structure containing a URI (or identifier, and returns an xml data structure containing a URI (or
set of URIs) to route the call to. Normal SIP [RFC3261] routing set of URIs) to route the call to. Normal SIP [RFC3261] routing
functions are used to resolve the URI to a next hop destination. functions are used to resolve 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, and if accessing either its location acquisition
function or mapping function fails, it should use this cached value. function or mapping function fails, it should use this cached value.
The call would follow its normal outbound call processing. Networks The call would follow its normal outbound call processing. Networks
that support devices that do not implement LoST mapping would have that support devices that do not implement LoST mapping themseleves
the outbound proxy do the mapping. The proxy must have the location would have the outbound proxy do the mapping. The proxy must have
of the endpoint, which is often difficult for the calling network to the location of the endpoint, which is often difficult for the
accurately determine. The endpoint may have its location, but would calling network to accurately determine. The endpoint may have its
not normally include it on the call signaling. There is no mechanism location, but would not normally include it on the call signaling.
provided in [I-D.ietf-sip-location-conveyance] to allow a proxy to There is no mechanism provided in [I-D.ietf-sip-location-conveyance]
require the endpoint supply location, because that would open the to allow a proxy to require the endpoint supply location, because
endpoint to an attack by any proxy on the path to get it to reveal that would open the endpoint to an attack by any proxy on the path to
location. The Proxy CAN redirect a call to the service URN which, if get it to reveal location. The Proxy CAN redirect a call to the
the device recognized the significance, would include location in the service URN which, if the device recognized the significance, would
redirected call. All networks should detect emergency calls and include location in the redirected call. All networks should detect
supply default location and/or routing if it is not already emergency calls and supply default location and/or routing if it is
performed. 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] mechanisms are
used to route calls to the URI obtained from the LoST dip. used to route calls to the URI obtained from the LoST dip.
Often, the SIP routing of an emergency call will first route to an
incoming call proxy in the domain operated by the emergency service.
That proxy is called an "Emergency Services Routing Proxy" (ESRP).
The ESRP, which is a normal SIP proxy server, may use a variety of
PSAP state information, the location of the caller, and other
criteria to onward route the call to the PSAP.
7. Signaling of Emergency Calls 7. Signaling of Emergency Calls
Since emergency calls carry privacy-sensitive information, they are As discussed above, location is carried in all emergency calls in the
subject to the requirements for geospatial protocols [RFC3693]. In call signaling. Since emergency calls carry privacy-sensitive
particular, signaling information should be carried in TLS, i.e., in information, they are subject to the requirements for geospatial
'sips' mode. While requiring TLS is actually the way the standards protocols [RFC3693]. In particular, signaling information should be
are written, it is unacceptable to have an emergency call fail to carried in TLS, i.e., in 'sips' mode. While requiring TLS is
complete because a TLS connection was not created, for any reason. actually the way the standards are written, it is unacceptable to
In many cases, persistent TLS connections can be maintained between have an emergency call fail to complete because a TLS connection was
elements to minimize the time needed to establish them. not created, for any reason. In many cases, persistent TLS
connections can be maintained between elements to minimize the time
needed to establish them.
Details can be found in [I-D.ietf-sip-location-conveyance]. The use of SIP Identity [RFC4474] to protect the headers of the
message could improve end-to-end integrity of the information.
Details of how location is carried in call signaling can be found in
[I-D.ietf-sip-location-conveyance].
8. Caller Preferences 8. Caller Preferences
SIP Caller Preferences [RFC3841] may be used to signal how the PSAP SIP Caller Preferences [RFC3841] may be used to signal how the PSAP
should handle the call. For example, a language preference expressed should handle the call. For example, a language preference expressed
in an Accept-Language header may used as a hint to cause the PSAP to in an Accept-Language header may used as a hint to cause the PSAP to
route the call to a call taker who speaks the requested language. route the call to a call taker who speaks the requested language.
9. Including a Valid Call-Back Identifier 9. Including a Valid Call-Back Identifier
skipping to change at page 21, line 47 skipping to change at page 22, line 29
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.
In addition, a call-back identifier should be included either as the In addition, a call-back identifier should be included either as the
URI in the From header field [RFC3261] preferably verified by SIP URI in the From header field [RFC3261] preferably verified by SIP
Identity[RFC4474]. This identifier would be used to initiate a call- Identity[RFC4474]. This identifier would be used to initiate a call-
back at a later time and may reach the caller, not necessarily on the back at a later time and may reach the caller, not necessarily on the
same device (and at the same location) as the original emergency same device (and at the same location) as the original emergency
call. call. Both the Contact and From specific requirements are detailed
in [I-D.ietf-ecrit-phonebcp]
Finally, there may be two other call identifiers included in an Finally, there may be two other call identifiers included in an
emergency call. An identifier may be included which can be used to emergency call. An identifier may be included which can be used to
identify the caller, as opposed to the device or the subscriber of a identify the caller, as opposed to the device or the subscriber of a
specific calling service. This identifier may be used to retrieve specific calling service. This identifier may be used to retrieve
information about the caller that is independent of calling service. information about the caller that is independent of calling service.
For example, Alice may have home, office and mobile telephony For example, Alice may have home, office and mobile telephony
services, but she is the same Alice in all of them. Information services, but she is the same Alice in all of them. Information
about Alice may be kept by an entity independent of any telephony 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 service provider. The caller identity is a URI and is placed in a
SIP Call-Info header [RFC3261] using the token "?" following the SIP Call-Info header [RFC3261] using the token "?" following the
recommendations in ???. recommendations in [I-D.ietf-ecrit-phonebcp].
The communications service provider may also include an identifier The communications service provider may also include an identifier
that may be used to retrieve information specific to the call held by 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 service provider. This identifier, also a URI may be placed in
the Call-Info header using the token "?". the Call-Info header using the token "?" per
[I-D.ietf-ecrit-phonebcp].
10. Mid-Call Services and Behavior 10. Mid-Call Services and 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[I-D.ietf-sipping-service-examples]. per[I-D.ietf-sipping-service-examples].
While in a call, a number of of other call features, such as call
waiting, must be disabled. This is also discussed in
[I-D.ietf-ecrit-phonebcp].
11. Call Termination 11. 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 Strategies for devices to handle caller attempts to terminate may be
found in [phonebcp]. PSAP call termination is accomplished with found in [I-D.ietf-ecrit-phonebcp]. PSAP call termination is
normal SIP call termination procedures. accomplished with normal SIP call termination procedures.
12. Media 12. Media
PSAPs should accept media streams on RTP [RFC3550]. Traditionally, PSAPs should accept media streams on RTP [RFC3550]. Traditionally,
voice has been the only media stream accepted by PSAPs. In some voice has been the only media stream accepted by PSAPs. In some
countries, text, in the form of BAUDOT codes or similar tone encoded countries, text, in the form of BAUDOT codes or similar tone encoded
signaling within a voiceband is accepted ("TTY") for persons who have signaling within a voiceband is accepted ("TTY") for persons who have
hearing disabilities. With the Internet comes a wider array of hearing disabilities. With the Internet comes a wider array of
potential media which a PSAP should accept. Using SIP signaling potential media which a PSAP should accept. Using SIP signaling
includes the capability to negotiate media. Normal SIP offer/answer includes the capability to negotiate media. Normal SIP offer/answer
skipping to change at page 23, line 16 skipping to change at page 23, line 49
13. Testing 13. 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.
[phonebcp] includes a description of an automated test procedure that [I-D.ietf-ecrit-phonebcp] includes a description of an automated test
validates routing, signaling and media path continuity. This test procedure that validates routing, signaling and media path
would be used at boot time, and whenever the device location changes continuity. This test would be used at boot time, and whenever the
enough that a new PSAP mapping is returned from LoST. A manual device location changes enough that a new PSAP mapping is returned
operation for the test should also be possible. from LoST. A manual operation for the test should also be possible.
14. Example Call Flows 14. Example Call Flows
TBD TBD
15. Alternatives Considered 15. Alternatives Considered
This is a non-normative appendix. During discussions of emergency This is a non-normative appendix. During discussions of emergency
calling, a number of suggestions are commonly made. Below, we calling, a number of suggestions are commonly made. Below, we
discuss some of the reasons why these alternatives do not satisfy the discuss some of the reasons why these alternatives do not satisfy the
skipping to change at page 24, line 13 skipping to change at page 24, line 45
an outbound proxy would have to ascertain the location of the caller an outbound proxy would have to ascertain the location of the caller
to guess whether the "tel" URI identifies an emergency call or some to guess whether the "tel" URI identifies an emergency call or some
other number. other number.
Thus, "tel" URIs are not likely to be appropriate or sufficient for Thus, "tel" URIs are not likely to be appropriate or sufficient for
identifying emergency calls and do not, by themselves, solve the call identifying emergency calls and do not, by themselves, solve the call
routing problem. routing problem.
16. Security Considerations 16. Security Considerations
Connecting ANY service to the Internet creates threads to the service
which did not exist before. The emergency call service is especially
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 specifially 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 16.1. Caller Authentication
Fraudulent calls to PSAPs is a significant concern. Current systems Fraudulent calls to PSAPs is a significant concern. Current systems
rely on inherent security mechanisms in the PSTN to make sure the rely on inherent security mechanisms in the PSTN to make sure the
identity of the caller is known. As Internet technologies are identity of the owner of the telephone is known. As Internet
increasingly used to place calls, it is becoming easier to hide the technologies are increasingly used to place calls, it is becoming
indentity of a caller. Use of the SIP Identity mechanism [RFC4474] i easier to hide the identity of a caller. Use of the SIP Identity
is recommended. If SIP Identity cannot be provided, carriers should mechanism [RFC4474] i is recommended. If SIP Identity cannot be
make use of P-Asserted-Identity, [RFC3325] provided, carriers should make use of P-Asserted-Identity, [RFC3325]
In keeping with established customs in circuit-switched emergency In keeping with established customs in circuit-switched emergency
calling, authentication cannot be made a prerequisite for routing or calling, authentication cannot be made a prerequisite for routing or
accepting an emergency call. However, a call taker may be more accepting an emergency call. However, a call taker may be more
suspicious of a caller and request additional information if the call suspicious of a caller and request additional information if the call
authenticity cannot be verified. authenticity cannot be verified.
16.2. Location Privacy 16.2. Location Privacy
Location is sensitive information, it must be protected against Location is sensitive information, it must be protected against
skipping to change at page 26, line 17 skipping to change at page 27, line 38
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.
18. References 18. References
18.1. Normative References 18.1. Normative References
[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-02 (work in progress), Protocol", draft-ietf-ecrit-lost-04 (work in progress),
February 2007.
[I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-00 (work in progress),
October 2006. October 2006.
[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-12 (work in progress), draft-ietf-ecrit-requirements-12 (work in progress),
August 2006. August 2006.
[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-05 (work in Services", draft-ietf-ecrit-service-urn-05 (work in
progress), August 2006. progress), August 2006.
[I-D.ietf-geopriv-dhcp-civil] [I-D.ietf-geopriv-pdif-lo-profile]
Schulzrinne, H., "Dynamic Host Configuration Protocol Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
(DHCPv4 and DHCPv6) Option for Civic Addresses Considerations and Recommendations",
Configuration Information", draft-ietf-geopriv-pdif-lo-profile-05 (work in progress),
draft-ietf-geopriv-dhcp-civil-09 (work in progress), October 2006.
January 2006.
[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-10 (work in progress), (SIP)", draft-ietf-sip-gruu-11 (work in progress),
August 2006. October 2006.
[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, "Session Initiation Protocol
Location Conveyance", Location Conveyance",
draft-ietf-sip-location-conveyance-04 (work in progress), draft-ietf-sip-location-conveyance-07 (work in progress),
August 2006. February 2007.
[I-D.ietf-sipping-config-framework] [I-D.ietf-sipping-config-framework]
Petrie, D., "A Framework for Session Initiation Protocol Petrie, D. and S. Channabasappa, "A Framework for Session
User Agent Profile Delivery", Initiation Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-09 (work in progress), draft-ietf-sipping-config-framework-10 (work in progress),
October 2006. January 2007.
[I-D.rosen-iptel-dialstring] [I-D.rosen-iptel-dialstring]
Rosen, B., "Dialstring parameter for the Session Rosen, B., "Dialstring parameter for the Session
Initiation Protocol Uniform Resource Identifier", Initiation Protocol Uniform Resource Identifier",
draft-rosen-iptel-dialstring-04 (work in progress), draft-rosen-iptel-dialstring-05 (work in progress),
June 2006. March 2007.
[LLDP] "IEEE802.1ab Station and Media Access Control", Dec 2004. [LLDP] "IEEE802.1ab Station and Media Access Control", 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.
skipping to change at page 28, line 52 skipping to change at page 30, line 30
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4103] "", 2005. [RFC4103] "", 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.
[RFC4474] "", 2005. [RFC4474] "", 2005.
[phonebcp] [RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol
Rosen, B. and J. Polk, "Best Current Practice for (DHCPv4 and DHCPv6) Option for Civic Addresses
Communications Services in support of Emergency Configuration Information", RFC 4676, October 2006.
CallingOcti", October 2006.
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-11 (work in Examples", draft-ietf-sipping-service-examples-12 (work in
progress), October 2006. progress), January 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.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar, Inc. NeuStar, Inc.
470 Conrad Dr 470 Conrad Dr
Mars, PA 16046 Mars, PA 16046
skipping to change at page 30, line 4 skipping to change at page 31, line 34
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
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 SunRocket
8045 Leesburg Pike, Suite 300 8045 Leesburg Pike, Suite 300
Vienna, VA 22182 Vienna, VA 22182
US US
Phone: +1 703 636 8052 Phone: +1 703 636 8052
Email: andy@hxr.us Email: andy@hxr.us
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). 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.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 76 change blocks. 
260 lines changed or deleted 342 lines changed or added

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