draft-ietf-ecrit-framework-10.txt   draft-ietf-ecrit-framework-11.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Informational H. Schulzrinne Intended status: Informational H. Schulzrinne
Expires: January 28, 2010 Columbia U. Expires: January 14, 2011 Columbia U.
J. Polk J. Polk
Cisco Systems Cisco Systems
A. Newton A. Newton
TranTech/MediaSolv TranTech/MediaSolv
July 27, 2009 July 13, 2010
Framework for Emergency Calling using Internet Multimedia Framework for Emergency Calling using Internet Multimedia
draft-ietf-ecrit-framework-10 draft-ietf-ecrit-framework-11
Abstract
The IETF has standardized various aspects of placing emergency calls.
This document describes how all of those component parts are used to
support emergency calls from citizens and visitors to authorities.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 This Internet-Draft will expire on January 14, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 28, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The IETF has standardized various aspects of placing emergency calls. described in the Simplified BSD License.
This document describes how all of those component parts are used to
support emergency calls from citizens and visitors to authorities.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of how emergency calls are placed . . . . . . . . . . 7 3. Overview of how emergency calls are placed . . . . . . . . . . 7
4. Which devices and services should support emergency calls . . 11 4. Which devices and services should support emergency calls . . 11
5. Identifying an emergency call . . . . . . . . . . . . . . . . 12 5. Identifying an emergency call . . . . . . . . . . . . . . . . 12
6. Location and its role in an emergency call . . . . . . . . . . 13 6. Location and its role in an emergency call . . . . . . . . . . 13
6.1. Types of location information . . . . . . . . . . . . . . 15 6.1. Types of location information . . . . . . . . . . . . . . 15
6.2. Location determination . . . . . . . . . . . . . . . . . . 16 6.2. Location determination . . . . . . . . . . . . . . . . . . 16
6.2.1. User-entered location information . . . . . . . . . . 17 6.2.1. User-entered location information . . . . . . . . . . 17
6.2.2. Access network "wire database" location information . 17 6.2.2. Access network "wire database" location information . 18
6.2.3. End-system measured location information . . . . . . . 18 6.2.3. End-system measured location information . . . . . . . 18
6.2.4. Network measured location information . . . . . . . . 19 6.2.4. Network measured location information . . . . . . . . 19
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 19 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 19
6.4. Location and references to location . . . . . . . . . . . 20 6.4. Location and references to location . . . . . . . . . . . 20
6.5. End system location configuration . . . . . . . . . . . . 20 6.5. End system location configuration . . . . . . . . . . . . 20
6.6. When location should be configured . . . . . . . . . . . . 22 6.6. When location should be configured . . . . . . . . . . . . 22
6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 23 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 23
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 23 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 23
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 23 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 24
6.10. Location validation . . . . . . . . . . . . . . . . . . . 24 6.10. Location validation . . . . . . . . . . . . . . . . . . . 25
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 25 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 26
6.12. Location format conversion . . . . . . . . . . . . . . . . 26 6.12. Location format conversion . . . . . . . . . . . . . . . . 26
7. LIS and LoST discovery . . . . . . . . . . . . . . . . . . . . 26 7. LIS and LoST discovery . . . . . . . . . . . . . . . . . . . . 26
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 26 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 26
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 28 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 28
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. SIP signaling requirements for User Agents . . . . . . . . 29 9.2. SIP signaling requirements for User Agents . . . . . . . . 29
9.3. SIP signaling requirements for proxy servers . . . . . . . 29 9.3. SIP signaling requirements for proxy servers . . . . . . . 29
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 30 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 31
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 30 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 31
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 30 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 31
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
19. Informative References . . . . . . . . . . . . . . . . . . . . 32 19. Informative References . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Terminology 1. Terminology
This document uses terms from [RFC3261] and [RFC5012]. In addition This document uses terms from [RFC3261], [RFC5222] and [RFC5012]. In
the following terms are used: addition the following terms are used:
Access network: The access network supplies IP packet service to an Access network: The access network supplies IP packet service to an
endpoint. Examples of access networks include digital subscriber endpoint. Examples of access networks include digital subscriber
lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local
area networks and cellular data networks. area networks and cellular data networks.
(Emergency) Call taker: An emergency call taker answers an emergency
call at the PSAP.
Confidence: Confidence is an estimate indicating how sure the Confidence: Confidence is an estimate indicating how sure the
measuring system is that the actual location of the endpoint is measuring system is that the actual location of the endpoint is
within the bounds defined by the uncertainty value, expressed as a within the bounds defined by the uncertainty value, expressed as a
percentage. For example, a value of 90% indicates that the actual percentage. For example, a value of 90% indicates that the actual
location is within the uncertainty nine times out of ten. location is within the uncertainty nine times out of ten.
Dispatch Location: The dispatch location is the location used for Dispatch Location: The dispatch location is the location used for
dispatching responders to the person in need of assistance. The dispatching responders to the person in need of assistance. The
dispatch location must be sufficiently precise to easily locate dispatch location must be sufficiently precise to easily locate
the caller; it typically needs to be more accurate than the the caller; it typically needs to be more accurate than the
routing location. routing location.
Emergency services routing proxy (ESRP): An emergency services
routing proxy provides routing services for a group of PSAPs.
Location configuration: During location configuration, an endpoint Location configuration: During location configuration, an endpoint
learns its physical location. learns its physical location.
Location Configuration Protocol (LCP): A protocol used by an Location Configuration Protocol (LCP): A protocol used by an
endpoint to learn its location. endpoint to learn its location.
Location conveyance: Location conveyance delivers location Location conveyance: Location conveyance delivers location
information to another element. information to another element.
Location determination: Location determination finds where an Location determination: Location determination finds where an
endpoint is physically located. For example, the endpoint may endpoint is physically located. For example, the endpoint may
contain a GPS receiver used to measure its own location or the contain a Global Navigation Satellite System (GNSS) receiver used
location may be determined by a network administrator using a to measure its own location or the location may be determined by a
wiremap database. network administrator using a wiremap database.
Location Information Server (LIS): A Location Information Server Location Information Server (LIS): A Location Information Server
stores location information for retrieval by an authorized entity. stores location information for retrieval by an authorized entity.
Mobile device: A mobile device is a user agent that may change its Mobile device: A mobile device is a user agent that may change its
physical location and possibly its network attachment point during physical location and possibly its network attachment point during
an emergency call. an emergency call.
NENA (National Emergency Number Association): The National Emergency NENA (National Emergency Number Association): The National Emergency
Number Association is an organization of professionals to "foster Number Association is an organization of professionals to "foster
the technological advancement, availability and implementation of the technological advancement, availability and implementation of
a universal emergency telephone number system." It develops a universal emergency telephone number system in North America."
emergency calling specifications and procedures. It develops emergency calling specifications and procedures.
Nomadic device (user): A nomadic user agent is connected to the Nomadic device (user): A nomadic user agent is connected to the
network temporarily, for relatively short durations, but does not network temporarily, for relatively short durations, but does not
move significantly during the during the emergency call. Examples move significantly during the during the emergency call. Examples
include a laptop using an IEEE 802.11 hotspot or a desk IP phone include a laptop using an IEEE 802.11 hotspot or a desk IP phone
that is moved occasionally from one cubicle to another. that is moved occasionally from one cubicle to another.
Physical location: A physical location describes where a person or Physical location: A physical location describes where a person or
device is located in physical space, described by a coordinate device is located in physical space, described by a coordinate
system. It is distinguished from the network location, described system. It is distinguished from the network location, described
by a network address. by a network address.
RoutinglLocation: The routing location of a device is used for PSAP: Public Safety Answering Point, the call center that answers
emergency calls.
Routing Location: The routing location of a device is used for
routing an emergency call and may not be as precise as the routing an emergency call and may not be as precise as the
Dispatch Location. Dispatch Location.
Stationary device: An stationary device is not mobile and is Stationary device: An stationary device is not mobile and is
connected to the network at a fixed, long-term-stable physical connected to the network at a fixed, long-term-stable physical
location. Examples include home PCs or pay phones. location. Examples include home PCs or pay phones.
Uncertainty: Uncertainty is an estimate, expressed in a unit of Uncertainty: Uncertainty is an estimate, expressed in a unit of
length, indicating the diameter of a circle that contains the length, indicating the diameter of a circle that contains the
endpoint with the probability indicated by the confidence value. endpoint with the probability indicated by the confidence value.
2. Introduction 2. Introduction
skipping to change at page 5, line 15 skipping to change at page 5, line 17
potentially lowering its cost and complexity. 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 (Public Switched Telephone the differences between traditional (Public Switched Telephone
Network) and IP-based telephony, but calling on the Internet is Network) and IP-based telephony, but calling on the Internet is
characterized by: 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 media other than voice (e.g. video and text in several forms); o media other than voice (for example, video and text in several
forms);
o the potential mobility of all end systems, including endpoints o the 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, consider a wired phone radio access technology. For example, consider a wired phone
connected to a router using a mobile data network such as EV-DO as connected to a router using a mobile data network such as EV-DO as
an uplink. 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
skipping to change at page 7, line 33 skipping to change at page 7, line 36
for any reason the original session is disrupted. for any reason the original session is disrupted.
3. Overview of how emergency calls are placed 3. Overview of how emergency calls are placed
An emergency call can be distinguished (Section 5) from any other An emergency call can be distinguished (Section 5) from any other
call by a unique Service URN [RFC5031] that is placed in the call call by a unique Service URN [RFC5031] that is placed in the call
set-up signaling when a home or visited emergency dial string is set-up signaling when a home or visited emergency dial string is
detected. Because emergency services are local to specific detected. Because emergency services are local to specific
geographic regions, a caller must obtain his location (Section 6) geographic regions, a caller must obtain his location (Section 6)
prior to making emergency calls. To get this location, either a form prior to making emergency calls. To get this location, either a form
of measuring, for example, GPS (Section 6.2.3) is deployed, or the of measuring, for example, GNSS (Section 6.2.3) is deployed, or the
endpoint is configured (Section 6.5) with its location from the endpoint is configured (Section 6.5) with its location from the
access network's Location Information Server (LIS) using a Location access network's Location Information Server (LIS) using a Location
Configuration Protocol (LCP). The location is conveyed (Section 6.7) Configuration Protocol (LCP). The location is conveyed (Section 6.7)
in the SIP signaling with the call. The call is routed (Section 8) in the SIP signaling with the call. The call is routed (Section 8)
based on location using the LoST protocol [RFC5222], which maps a based on location using the LoST protocol [RFC5222], which maps a
location to a set of PSAP URIs. Each URI resolves to a PSAP or an location to a set of PSAP URIs. Each URI resolves to a PSAP or an
Emergency Services Routing Proxy (ESRP) that serves as an incoming Emergency Services Routing Proxy (ESRP) that serves as an incoming
proxy for a group of PSAPs. The call arrives at the PSAP with the proxy for a group of PSAPs. The call arrives at the PSAP with the
location included in the INVITE request. location included in the INVITE request.
skipping to change at page 10, line 17 skipping to change at page 10, line 17
LIS -> Alice: LCP Reply(s) (replies with location) LIS -> Alice: LCP Reply(s) (replies with location)
[M2] Alice -> Registrar: SIP REGISTER [M2] Alice -> Registrar: SIP REGISTER
Registrar -> Alice: SIP 200 OK (REGISTER) Registrar -> Alice: SIP 200 OK (REGISTER)
[M3] Alice -> LoST Server: Initial LoST Query (contains location) [M3] Alice -> LoST Server: Initial LoST Query (contains location)
Lost Server -> Alice: Initial LoST Response (contains Lost Server -> Alice: Initial LoST Response (contains
PSAP-URI and dial string) PSAP-URI and dial string)
Some time later, Alice dials or otherwise initiates an emergency call: Some time later, Alice dials or otherwise initiates an emergency call:
[M4] Alice -> LIS: LCP Request (update location) [M4] Alice -> LIS: LCP Request (update location)
LIS -> AliceE: LCP Reply (replies with location) LIS -> Alice: LCP Reply (replies with location)
[M5] Alice -> LoST Server: Update LoST Query (contains location) [M5] Alice -> LoST Server: Update LoST Query (contains location)
Lost Server -> Alice: LoST Response (contains PSAP-URI) Lost Server -> Alice: LoST Response (contains PSAP-URI)
[M6] Alice -> Outgoing Proxy: INVITE (service URN, [M6] Alice -> Outgoing Proxy: SIP INVITE (service URN,
Location and PSAP URI) Location and PSAP URI)
Outgoing Proxy -> ESRP: INVITE (service URN, [M7] Outgoing Proxy -> ESRP: SIP INVITE (service URN,
Location and PSAP URI) Location and PSAP URI)
ESRP -> PSAP: INVITE (service URN, Location and PSAP URI) [M8] ESRP -> PSAP: SIP INVITE (service URN, Location and PSAP URI)
The 200 OK response is propagated back from the PSAP to Alice and the The 200 OK response is propagated back from the PSAP to Alice and the
ACK response is propagated from Alice to the PSAP. ACK response is propagated from Alice to the PSAP.
Figure 2 Figure 2: Message Flow
Figure 1 shows emergency call component topology and the text above Figure 1 shows emergency call component topology and the text above
shows call establishment. These include the following components: shows call establishment. These include the following components:
o Alice - who places the emergency call. o Alice - who places 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. Configuration servers also may location by-value or by-reference. Configuration servers also may
include a SIP registrar for Alice's UA. Most SIP UAs will include a SIP registrar for Alice's UA. Most SIP UAs will
register, so it will be a common scenario for UAs that make register, so it will be a common scenario for UAs that make
emergency calls to be registered with such a server in the emergency calls to be registered with such a server in the
originating calling network. Registration would be required for originating calling network. Registration would be required for
the PSAP to be able to call back after an emergency call is the PSAP to be able to call back after an emergency call is
completed. All the configuration messages are labeled M1 through completed. All the configuration messages are labeled M1 through
M3, but could easily require more than 3 messages to complete. M3, but could easily require more than 3 messages to complete.
o LoST server - Processes the LoST request for location plus a o LoST server - Processes the LoST request for location plus a
Service URN to a PSAP-URI, either for an initial request from a Service URN to a PSAP-URI, either for an initial request from a
UA, or an in-call routing by the proxy server in the originating UA, or an in-call routing by the proxy server in the originating
network, or possibly by an ESRP. network, or possibly by an ESRP.
o ESRP - Emergency Services Routing Proxy, a sip proxy server that o ESRP - Emergency Services Routing Proxy, a SIP proxy server that
is the incoming call proxy in the emergency services domain. The is the incoming call proxy in the emergency services domain. The
ESRP makes further routing decisions (e.g. based on PSAP state and ESRP makes further routing decisions (e.g., based on PSAP state
the location of the caller) to choose the actual PSAP that handles and the location of the caller) to choose the actual PSAP that
the call. In some jurisdictions, this may involve another LoST handles the call. In some jurisdictions, this may involve another
query. LoST query.
o PSAP - Emergency calls are answered at a Public Safety Answering o PSAP - Emergency calls are answered at a Public Safety Answering
Point, a call center. Point, a call center.
Generally, Alice's UA either has location configured manually, has an Generally, Alice's UA either has location configured manually, has an
integral location measurement mechanism, or it runs a LCP [M1] to integral location measurement mechanism, or it runs a LCP [M1] to
obtain location from the access (broadband) network. Alice's UA then obtain location from the access (broadband) network. Alice's UA then
will most likely register [M2] with a SIP registrar. This allows her will most likely register [M2] with a SIP registrar. This allows her
to be contacted by other SIP entities. Next, her UA will perform an 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 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 fails during an emergency call, or to use to test the emergency call
skipping to change at page 13, line 32 skipping to change at page 13, line 32
[RFC4967] and the outgoing proxy must recognize the dial string and [RFC4967] and the outgoing proxy must recognize the dial string and
translate it to the equivalent service URN. To determine the local translate it to the equivalent service URN. To determine the local
emergency dial string, the proxy needs the location of the endpoint. emergency dial string, the proxy needs the location of the endpoint.
This may be difficult in situations where the user can roam or be This may be difficult in situations where the user can roam or be
nomadic. Endpoint recognition of emergency dial strings is therefore nomadic. Endpoint recognition of emergency dial strings is therefore
preferred. If a service provider is unable to guarantee that it can preferred. If a service provider is unable to guarantee that it can
correctly determine local emergency dialstrings, wherever its correctly determine local emergency dialstrings, wherever its
subscribers may be, then it is required that the endpoint do the subscribers may be, then it is required that the endpoint do the
recognition. recognition.
Note: It is undesirable to have a single button emergency call user Note: The emergency call practitioners consider it undesirable to
interface element. These mechanisms tend to result in a very high have a single button emergency call user interface element. These
rate of false or accidental emergency calls. In order to minimize mechanisms tend to result in a very high rate of false or accidental
this rate, devices should only initiate emergency calls based on emergency calls. In order to minimize this rate, practitioners
recommend that device should only initiate emergency calls based on
entry of specific emergency call dial strings. Speed dial mechanisms entry of specific emergency call dial strings. Speed dial mechanisms
may effectively create single button emergency call invocation and may effectively create single button emergency call invocation and
should not be permitted. practitioners recommend they not be permitted.
6. Location and its role in an emergency call 6. Location and its role in an emergency call
Location is central to the operation of emergency services. Location Location is central to the operation of emergency services. Location
is used for two purposes in emergency call handling: routing of the is used for two purposes in emergency call handling: routing of the
call and dispatch of responders. It is frequently the case that the call and dispatch of responders. It is frequently the case that the
caller reporting an emergency is unable to provide a unique, valid caller reporting an emergency is unable to provide a unique, valid
location themselves. For this reason, location provided by the location themselves. For this reason, location provided by the
endpoint or the access network is needed. For practical reasons, endpoint or the access network is needed. For practical reasons,
each PSAP generally handles only calls for a certain geographic area, each PSAP generally handles only calls for a certain geographic area,
skipping to change at page 14, line 51 skipping to change at page 15, line 4
use "routing location" and "dispatch location" when the distinction use "routing location" and "dispatch location" when the distinction
matters. matters.
Accuracy of dispatch location is sometimes determined by local Accuracy of dispatch location is sometimes determined by local
regulation, and is constrained by available technology. The actual regulation, and is constrained by available technology. The actual
requirement is more stringent than available technology can deliver: requirement is more stringent than available technology can deliver:
It is required that a device making an emergency call close to the It is required that a device making an emergency call close to the
"demising" or separation wall between two apartments in a high rise "demising" or separation wall between two apartments in a high rise
apartment building report location with sufficient accuracy to apartment building report location with sufficient accuracy to
determine on what side of the wall it is on. This implies perhaps a 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 3 cm accuracy requirement. As of the date of this memo, assisted
assisted GPS uncertainty in mobile phones with 95% confidence is 100 GNSS uncertainty in mobile phones with 95% confidence cannot be
m. As technology advances, the accuracy requirements for location relied upon to be less than hundreds of meters. As technology
will need to be tightened. Wired systems using wire tracing advances, the accuracy requirements for location will need to be
mechanisms can provide location to a wall jack in specific room on a tightened. Wired systems using wire tracing mechanisms can provide
floor in a building, and may even specify a cubicle or even smaller location to a wall jack in specific room on a floor in a building,
resolution. As this discussion illustrates, emergency call systems and may even specify a cubicle or even smaller resolution. As this
demand the most stringent location accuracy available. discussion illustrates, emergency call systems demand the most
stringent location accuracy available.
In Internet emergency calling, where the endpoint is located is In Internet emergency calling, where the endpoint is located is
determined using a variety of measurement or wire-tracing methods. determined using a variety of measurement or wire-tracing methods.
Endpoints may be configured with their own location by the access Endpoints may be configured with their own location by the access
network. In some circumstances, a proxy server may insert location network. In some circumstances, a proxy server may insert location
into the signaling on behalf of the endpoint. The location is mapped 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 to the URI to send the call to, and the location is conveyed to the
PSAP (and other elements) in the signaling. The terms PSAP (and other elements) in the signaling. The terms
'determination', 'configuration', 'mapping', and 'conveyance' are 'determination', 'configuration', 'mapping', and 'conveyance' are
used for specific aspects of location handling in IETF protocols. used for specific aspects of location handling in IETF protocols.
skipping to change at page 15, line 39 skipping to change at page 15, line 41
warranted, in future documents. warranted, in future documents.
6.1. Types of location information 6.1. Types of location information
Location can be specified in several ways: Location can be specified in several ways:
Civic: Civic location information describes the location of a person 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. Civic location may include more fine grained other structure. Civic location may include more fine 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 refers to a civic location using actual political 'Jurisdictional': refers to a civic location using actual
subdivisions, especially for the community name. political subdivisions, especially for the community name.
Postal refers to a civic location for mail delivery. The name of 'Postal': refers to a civic location for mail delivery. The
the post office sometimes does not correspond to the community name of the post office sometimes does not correspond to the
name and a postal address may contain post office boxes or community name and a postal address may contain post office
street addresses that do not correspond to an actual building. boxes or street addresses that do not correspond to an actual
Postal addresses are generally unsuitable for emergency call building. Postal addresses are generally unsuitable for
dispatch because the post office conventions (for community emergency call dispatch because the post office conventions
name, for example) do not match those known by the responders. (for community name, for example) do not match those known by
The fact that they are unique can sometimes be exploited to the responders. The fact that they are unique can sometimes be
provide a mapping between a postal address and a civic address exploited to provide a mapping between a postal address and a
suitable to dispatch a responder to. In IETF location civic address suitable to dispatch a responder to. In IETF
protocols, there is an element (Postal Community Name) that can location protocols, there is an element (Postal Community Name)
be included in a location to provide the post office name as that can be included in a location to provide the post office
well as the actual jurisdictional community name. There is name as well as the actual jurisdictional community name.
also an element for a postal code. There is no other There is also an element for a postal code. There is no other
accommodation for postal addresses in these protocols. accommodation for postal addresses in these protocols.
Geospatial (geo): Geospatial addresses contain longitude, latitude Geospatial (geo): Geospatial addresses contain longitude, latitude
and altitude information based on an understood datum and earth and altitude information based on an understood datum and earth
shape model. While there have been many datums developed over shape model (datum). While there have been many datums developed
time, most modern systems are using or moving towards the WGS84 over time, most modern systems are using or moving towards the
[WGS84] datum. WGS84 [WGS84] datum.
Cell tower/sector: Cell tower/sector is often used for identifying Cell tower/sector: Cell tower/sector is often used for identifying
the location of a mobile handset, especially for routing of the location of a mobile handset, especially for routing of
emergency calls. Cell tower and sectors identify the cell tower emergency calls. Cell tower and sectors identify the cell tower
and the antenna sector that a mobile device is currently using. and the antenna sector that a mobile device is currently using.
Traditionally, the tower location is represented as a point chosen Traditionally, the tower location is represented as a point chosen
to be within a certain PSAP service boundary who agrees to take to be within a certain PSAP service boundary who agrees to take
calls originating from that tower/sector, and routing decisions calls originating from that tower/sector, and routing decisions
are made on that point. Cell/sector information could also be are made on that point. Cell/sector information could also be
represented as an irregularly shaped polygon of geospatial represented as an irregularly shaped polygon of geospatial
coordinates reflecting the likely geospatial location of the coordinates reflecting the likely geospatial location of the
skipping to change at page 17, line 5 skipping to change at page 17, line 8
6.2. Location determination 6.2. Location determination
As noted above, location information can be entered by the user or As noted above, location information can be entered by the user or
installer of a device ("manual configuration"), measured by the end installer of a device ("manual configuration"), measured by the end
system, can be delivered to the end system by some protocol or system, can be delivered to the end system by some protocol or
measured by a third party and inserted into the call signaling. measured by a third party and inserted into the call signaling.
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. Although self measured location (e.g. system and a third party. Although self measured location (e.g.,
GPS) is attractive, location information provided by the access GNSS) is attractive, location information provided by the access
network could be much more accurate, and more reliable in some network could be much more accurate, and more reliable in some
environments such as high rise buildings in dense urban areas. environments such as high rise buildings in dense urban areas.
The closer an entity is to the source of location, the more likely it The closer an entity is to the source of location, the more likely it
is able to determine which location is most appropriate for a is able to determine which location is most appropriate for a
particular purpose when there are more than one location particular purpose when there are more than one location
determinations for a given endpoint. In emergency calling, the PSAP determinations for a given endpoint. In emergency calling, the PSAP
is the least likely to be able to appropriately choose which location is the least likely to be able to appropriately choose which location
to use when multiple conflicting locations are presented to it. to use when multiple conflicting locations are presented to it.
While all available locations can be sent towards the PSAP, the order While all available locations can be sent towards the PSAP, the order
of the locations should be the sender's best attempt to guide the of the locations should be the sender's best attempt to guide the
recipient of which one(s) to use. recipient of which one(s) to use.
6.2.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 provided by end users is almost always less Location information routinely provided by end users is almost always
reliable than measured or wire database information, as users may less reliable than measured or wire database information, as users
mistype location information or may enter civic address information may mistype location information or may enter civic address
that does not correspond to a recognized (i.e., valid, see Section information that does not correspond to a recognized (i.e., valid,
Section 6.10) address. Users can forget to change the data when the see Section Section 6.10) address. Users can forget to change the
location of a device changes during or after movement. data when the location of a device changes.
All that said, there are always a small number of cases where the However, there are always a small number of cases where the automated
automated mechanisms used by the access network to determine location mechanisms used by the access network to determine location fail to
fail to accurately reflect the actual location of the endpoint. For accurately reflect the actual location of the endpoint. For example,
example, the user may deploy his own WAN behind an access network, the user may deploy his own WAN behind an access network, effectively
effectively removing an endpoint some distance from the access removing an endpoint some distance from the access network's notion
network's notion of its location. There must be some mechanism of its location. To handle these exceptional cases, there must be
provided to provision a location for an endpoint by the user or by some mechanism provided to manually provision a location for an
the access network on behalf of a user. The use of the mechanism endpoint by the user or by the access network on behalf of a user.
introduces the possibility of users falsely declaring themselves to The use of the mechanism introduces the possibility of users falsely
be somewhere they are not. As an aside, normally, if an emergency declaring themselves to be somewhere they are not. As an aside,
caller insists that he is at a location different from what any normally, if an emergency caller insists that he is at a location
automatic location determination system reports he is, responders different from what any automatic location determination system
will always be sent to the user's self-declared location. However, reports he is, responders will always be sent to the user's self-
this is a matter of local policy and is outside the scope of this declared location. However, this is a matter of local policy and is
document. outside the scope of this document.
6.2.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 locations. In DSL databases map Ethernet switch ports to building locations. In DSL
installations, the local telephone carrier maintains a mapping of installations, the local telephone carrier 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. Accuracy of location historically has been to a street address level.
However, this is not sufficient for larger structures. The PIDF However, this is not sufficient for larger structures. The PIDF
Location Object [RFC4119] with a recent extension [RFC5139] permits Location Object [RFC4119] extended by [RFC5139] and [RFC5491] permits
interior building/floor/room and even finer specification of location interior building/floor/room and even finer specification of location
within a street address. When possible, interior location should be within a street address. When possible, interior location should be
supported. supported.
The threshold for when interior location is needed is approximately The threshold for when interior location is needed is approximately
650 square meters. This value is derived from fire brigade 650 square meters. This value is derived from USA fire brigade
recommendations of spacing of alarm pull stations. However, interior recommendations of spacing of alarm pull stations. However, interior
space layout, construction materials and other factors should be space layout, construction materials and other factors should be
considered. considered.
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 as determined by the wiremap may be supplied as the location point as determined by the wiremap may be supplied as the location
for each of the clients of the access point. However, this may not for each of the clients of the access point. However, this may not
be true for larger-scale systems such as IEEE 802.16 (WiMAX) and IEEE be true for larger-scale systems such as IEEE 802.16 (WiMAX) and IEEE
802.22 that typically have larger cells than those of IEEE 802.11. 802.22 that typically have larger cells than those of IEEE 802.11.
skipping to change at page 18, line 40 skipping to change at page 18, line 45
kilometers away from the base station. kilometers away from the base station.
Wire databases are likely to be the most promising solution for Wire databases are likely to be the most promising solution for
residential users where a service provider knows the customer's residential users where a service provider knows the customer's
service address. The service provider can then perform address service address. The service provider can then perform address
validation (see Section 6.10), similar to the current system in some validation (see Section 6.10), similar to the current system in some
jurisdictions. jurisdictions.
6.2.3. End-system measured location information 6.2.3. End-system measured location information
Global Positioning System (GPS) and similar satellite based (e.g., Global Positioning System (GPS) and similar Global Navigation
Galileo) receivers may be embedded directly in the end device. GPS Satellite Systems (e.g., GLONAS and Galileo) receivers may be
produces relatively high precision location fixes in open-sky embedded directly in the end device. GNSS produces relatively high
conditions, but the technology still faces several challenges in precision location fixes in open-sky conditions, but the technology
terms of performance (time-to-fix and time-to-first-fix), as well as still faces several challenges in terms of performance (time-to-fix
obtaining successful location fixes within shielded structures, or and time-to-first-fix), as well as obtaining successful location
underground. It also requires all devices to be equipped with the fixes within shielded structures, or underground. It also requires
appropriate GPS capability. Many mobile devices require using some all devices to be equipped with the appropriate GNSS capability.
kind of "assist", that may be operated by the access network (A-GPS)
or by a government (WAAS). A device may be able to use multiple
sources of assist data.
GPS systems may be always enabled and thus location will always be Many mobile devices require using some kind of "assist", that may be
operated by the access network (A-GPS) or by a government (WAAS). A
device may be able to use multiple sources of assist data.
GNSS systems may be always enabled and thus location will always be
available accurately immediately (assuming the device can "see" available accurately immediately (assuming the device can "see"
enough satellites). Mobile devices may not be able to sustain the enough satellites). Mobile devices may not be able to sustain the
power levels required to keep the measuring system active. In such power levels required to keep the measuring system active. In such
circumstances, when location is needed, the device has to start up circumstances, when location is needed, the device has to start up
the measurement mechanism. This typically takes tens of seconds, far the measurement mechanism. This typically takes tens of seconds, far
too long to wait to be able to route an emergency call. For this too long to wait to be able to route an emergency call. For this
reason, devices that have end-system measured location mechanisms but reason, devices that have end-system measured location mechanisms but
need a cold start period lasting more than a couple seconds need need a cold start period lasting more than a couple seconds need
another way to get a routing location. Typically this would be a another way to get a routing location. Typically this would be a
location associated with a radio link (cell site/sector). location associated with a radio link (cell site/sector).
skipping to change at page 20, line 43 skipping to change at page 20, line 46
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 including DHCP, HELD and LLDP: used for this purpose including DHCP, HELD and LLDP:
DHCP can deliver civic [RFC4776] or geospatial [RFC3825] DHCP can deliver civic [RFC4776] or geospatial [RFC3825]
information. User agents need to support both formats. Note that information. User agents need to support both formats. Note that
a user agent can use DHCP, via the DHCP REQUEST or INFORM a user agent can use DHCP, via the DHCP REQUEST or INFORM
messages, even if it uses other means to acquire its IP address. messages, even if it uses other means to acquire its IP address.
HELD [I-D.ietf-geopriv-http-location-delivery] can deliver a civic HELD [I-D.ietf-geopriv-http-location-delivery] can deliver a civic
or geo location object, by value or by reference, via a layer 7 or geo location object, by value or by reference, via a layer 7
protocol. The query typically uses the IP address of the protocol. The query typically uses the IP address of the
requestor as an identifier and returns the location value or requester as an identifier and returns the location value or
reference associated with that identifier. HELD is typically reference associated with that identifier. HELD is typically
carried in HTTP. carried in HTTP.
Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device
extensions [LLDP-MED] can be used to deliver location information extensions [LLDP-MED] can be used to deliver location information
directly from the Layer 2 network infrastructure, and also directly from the Layer 2 network infrastructure, and also
supports both civic and geo formats identical in format to DHCP supports both civic and geo formats identical in format to DHCP
methods. methods.
Each LCP has limitations in the kinds of networks that can reasonably Each LCP has limitations in the kinds of networks that can reasonably
support it. For this reason, it is not possible to choose a single support it. For this reason, it is not possible to choose a single
mandatory-to-deploy LCP. For endpoints with common network mandatory-to-deploy LCP. For endpoints with common network
connections (such as an Ethernet jack or a WiFi connection) serious connections (such as an Ethernet jack or a WiFi connection) serious
skipping to change at page 25, line 12 skipping to change at page 25, line 21
Validation in this context means both that there is a mapping from Validation in this context means both that there is a mapping from
the address to a PSAP and that the PSAP understands how to direct the address to a PSAP and that the PSAP understands how to direct
responders to the location. It is recommended that location be responders to the location. It is recommended that location be
validated prior to a device placing an actual emergency call; some validated prior to a device placing an actual emergency call; some
jurisdictions require that this be done. jurisdictions require that this be done.
Determining the addresses that are valid can be difficult. There Determining the addresses that are valid can be difficult. There
are, for example, many cases of two names for the same street, or two are, for example, many cases of two names for the same street, or two
streets with the same name, but different "suffixes" (Avenue, Street, streets with the same name, but different "suffixes" (Avenue, Street,
Circle) in a city. In some countries, the current system provides Circle) in a city. In some countries, the current system provides
validation. For example, in the United States, the Master Street validation. For example, in the United States of America, the Master
Address Guide (MSAG) records all valid street addresses and is used Street Address Guide (MSAG) records all valid street addresses and is
to ensure that the service addresses in phone billing records used to ensure that the service addresses in phone billing records
correspond to valid emergency service street addresses. Validation correspond to valid emergency service street addresses. Validation
is normally only a concern for civic addresses, although there could is normally only a concern for civic addresses, although there could
be some determination that a given geo is within at least one PSAP be some determination that a given geo is within at least one PSAP
service boundary; that is, a "valid" geo is one where there is a service boundary; that is, a "valid" geo is one where there is a
mapping in the LoST server. mapping in the LoST server.
LoST [RFC5222] includes a location validation function. Validation LoST [RFC5222] includes a location validation function. Validation
is normally performed when a location is entered into a Location is normally performed when a location is entered into a Location
Information Server. It should be confirmed periodically, because the Information Server. It should be confirmed periodically, because the
mapping database undergoes slow change and locations which previously mapping database undergoes slow change and locations which previously
skipping to change at page 27, line 29 skipping to change at page 27, line 46
Determining when the device leaves the area provided by the LoST Determining when the device leaves the area provided by the LoST
service can tax small mobile devices. For this reason, the LoST service can tax small mobile devices. For this reason, the LoST
server should return a simple (small number of points) polygon for server should return a simple (small number of points) polygon for
geospatial location. This can be a simple enclosing rectangle of the geospatial location. This can be a simple enclosing rectangle of the
PSAP service area when the reported point is not near an edge, or a PSAP service area when the reported point is not near an edge, or a
smaller polygonal edge section when the reported location is near an smaller polygonal edge section when the reported location is near an
edge. Civic location is uncommon for mobile devices, but reporting edge. Civic location is uncommon for mobile devices, but reporting
that the same mapping is good within a community name, or even a that the same mapping is good within a community name, or even a
street, may be very helpful for WiFi connected devices that roam and street, may be very helpful for WiFi connected devices that roam and
obtain civic location from the AP they are connected to. obtain civic location from the access point they are connected to.
Networks that support devices that do not implement LoST mapping Networks that support devices that do not implement LoST mapping
themselves may need the outbound proxy do the mapping. If the themselves may need the outbound proxy do the mapping. If the
endpoint recognized the call was an emergency call, provided the endpoint recognized the call was an emergency call, provided the
correct service URN and/or included location on the call in a correct service URN and/or included location on the call in a
Geolocation header, a proxy server could easily accomplish the Geolocation header, a proxy server could easily accomplish the
mapping. mapping.
However, if the endpoint did not recognize the call was an emergency However, if the endpoint did not recognize the call was an emergency
call, and thus did not include location, the proxy's task is more call, and thus did not include location, the proxy's task is more
skipping to change at page 28, line 24 skipping to change at page 28, line 40
the call, may use a variety of PSAP state information, the location the call, may use a variety of PSAP state information, the location
of the caller, and other criteria to onward route the call to the of the caller, and other criteria to onward route the call to the
PSAP. In order for the ESRP to route on media choice, the initial PSAP. In order for the ESRP to route on media choice, the initial
INVITE request has to supply an SDP offer. INVITE request has to supply an SDP offer.
9. Signaling of emergency calls 9. Signaling of emergency calls
9.1. Use of TLS 9.1. Use of TLS
Best Current Practice for SIP user agents [RFC4504] including Best Current Practice for SIP user agents [RFC4504] including
handling of audio, video and real-time text xref target="RFC4103"/> handling of audio, video and real-time text [RFC4103] should be
should be applied. As discussed above, location is carried in all applied. As discussed above, location is carried in all emergency
emergency calls in the call signaling. Since emergency calls carry calls in the call signaling. Since emergency calls carry privacy-
privacy-sensitive information, they are subject to the requirements sensitive information, they are subject to the requirements for
for geospatial protocols [RFC3693]. In particular, signaling geospatial protocols [RFC3693]. In particular, signaling information
information should be carried in TLS, i.e., in 'sips' mode with a should be carried in TLS, i.e., in 'sips' mode with a ciphersuite
ciphersuite which includes strong encryption (e.g., AES). There are which includes strong encryption (e.g., AES). There are exceptions
exceptions in [RFC3693] for emergency calls. For example, local in [RFC3693] for emergency calls. For example, local policy may
policy may dictate that location is sent with an emergency call even dictate that location is sent with an emergency call even if the
if the user's policy would otherwise prohibit that. Nevertheless, user's policy would otherwise prohibit that. Nevertheless,
protection from eavesdropping of location by encryption should be protection from eavesdropping of location by encryption should be
provided. provided.
It is unacceptable to have an emergency call fail to complete because It is unacceptable to have an emergency call fail to complete because
a TLS connection was not created for any reason. Thus, the call a TLS connection was not created for any reason. Thus, the call
should be attempted with TLS, but if the TLS session establishment should be attempted with TLS, but if the TLS session establishment
fails, the call should be automatically retried without TLS. fails, the call should be automatically retried without TLS.
[I-D.ietf-sip-sips] recommends that to achieve this effect the target [I-D.ietf-sip-sips] recommends that to achieve this effect the target
specifies a sip URI, but use TLS on the outbound connection. An specifies a sip URI, but use TLS on the outbound connection. An
element that receives a request over a TLS connection should attempt element that receives a request over a TLS connection should attempt
to create a TLS connection to the next hop. to create a TLS connection to the next hop.
In many cases, persistent TLS connections can be maintained between In many cases, persistent TLS connections can be maintained between
elements to minimize the time needed to establish them elements to minimize the time needed to establish them
[I-D.ietf-sip-outbound]. In other circumstances, use of session [I-D.ietf-sip-outbound]. In other circumstances, use of session
resumption [RFC5077] is recommended. IPSEC [RFC4301] is an resumption [RFC5077] is recommended. IPsec [RFC4301] is an
acceptable alternative to TLS when used with an equivalent crypto acceptable alternative to TLS when used with an equivalent crypto
suite. suite.
Location may be used for routing by multiple proxy servers on the Location may be used for routing by multiple proxy servers on the
path. Confidentiality mechanisms such as S/MIME encryption of SIP path. Confidentiality mechanisms such as S/MIME encryption of SIP
signaling [RFC3261] cannot be used because they obscure location. signaling [RFC3261] cannot be used because they obscure location.
Only hop-by-hop mechanisms such as TLS should be used. Implementing Only hop-by-hop mechanisms such as TLS should be used. Implementing
location conveyance in SIP mandates inclusion of TLS support. location conveyance in SIP mandates inclusion of TLS support.
9.2. SIP signaling requirements for User Agents 9.2. SIP signaling requirements for User Agents
skipping to change at page 29, line 31 skipping to change at page 29, line 48
SIP caller preferences [RFC3841] can be used to signal how the PSAP SIP caller preferences [RFC3841] can 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 be used as a hint to cause the PSAP in an Accept-Language header may be used as a hint to cause the PSAP
to route the call to a call taker who speaks the requested language. to route the call to a call taker who speaks the requested language.
SIP caller preferences may also be used to indicate a need to invoke SIP caller preferences may also be used to indicate a need to invoke
a relay service for communication with people with disabilities in a relay service for communication with people with disabilities in
the call. the call.
9.3. SIP signaling requirements for proxy servers 9.3. SIP signaling requirements for proxy servers
SIP proxy servers in the path of an emergency call must be able to At least one SIP proxy server in the path of an emergency call must
assist UAs that are unable to provide any of the location based be able to assist UAs that are unable to provide any of the location
routing steps and recognition of dial strings. They should recognize based routing steps and recognition of dial strings. A Proxy can
emergency dial strings, inserting the Route header with the recognize the lack of location awareness by the lack of a Geolocation
appropriate service URN. They should obtain the location of the header. They can recognize the lack of dial string recognition by
endpoint if possible, and use a default location if they can not, the presence of the local emergency call dial string in the From
inserting it in a Geolocation header. They should query LoST with header without the service URN being present. They should obtain the
the location and put the resulting URI in the Request URI. They are location of the endpoint if possible, and use a default location if
also expected to provide identity information for the caller using they can not, inserting it in a Geolocation header. They should
SIP Identity or P-Asserted-Identity. query LoST with the location and put the resulting URI in a Route,
with the appropriate service URN in the Request URI. In any event,
they are also expected to provide information for the caller using
SIP Identity or P-Asserted-Identity. It is often a regulatory matter
whether calls normally marked as anonymous are passed as anonymous
when they are emergency calls. Proxies must conform to the local
regulation or practice.
10. Call backs 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. There are two kinds of call backs. When a call is for this purpose. There are two kinds of call backs. When a call is
dropped, or the call taker realizes that some important information dropped, or the call taker realizes that some important information
is needed that it doesn't have, it must call back the device that is needed that it doesn't have, it must call back the device that
placed the emergency call. The PSAP, or a responder, may need to placed the emergency call. The PSAP, or a responder, may need to
call back the caller much later, and for that purpose, it wants a call back the caller much later, and for that purpose, it wants a
normal SIP Address of Record. In SIP systems, the caller must normal SIP Address of Record. In SIP systems, the caller must
include a Contact header field indicating its device URI, if globally include a Contact header field in an emergency call containing a
routable, or possibly a GRUU [I-D.ietf-sip-gruu] if calls need to be globally routable URI, possibly a GRUU [I-D.ietf-sip-gruu]. This
routed via a proxy. This identifier would be used to initiate call- identifier would be used to initiate call-backs immediately by the
backs immediately by the call-taker if, for example, the call is call-taker if, for example, the call is prematurely dropped. A
prematurely dropped. This is a change from [RFC3261] where the concern arises with B2BUAs that manipulate Contact headers. Such
Contact: header is optional. A concern arises with B2BUAs that B2BUAs should always include a Contact header that routes to the same
manipulate Contact headers. Such manipulation should always result device being available for call backs.
in the Contact header being available for call backs.
In addition, a call-back identifier as an AoR must be included either In addition, a call-back identifier as an Address of Record (AoR)
as the URI in the From header field [RFC3261] verified by SIP must be included either as the URI in the From header field [RFC3261]
Identity [RFC4474] or as a network asserted URI [RFC3325]. This verified by SIP Identity [RFC4474] or as a network asserted URI
[RFC3325]. If the latter, the PSAP will need to establish a suitable
spec(t) with the proxies that send it emergency calls. This
identifier would be used to initiate a call-back at a later time and identifier would be used to initiate a call-back at a later time and
may reach the caller, not necessarily on the same device (and at the may reach the caller, not necessarily on the same device (and at the
same location) as the original emergency call as per normal SIP same location) as the original emergency call as per normal SIP
rules. rules. It is often a regulatory matter whether calls normally marked
as anonymous are passed as anonymous when they are emergency calls.
Proxies must conform to the local regulation or practice.
11. Mid-call behavior 11. Mid-call behavior
Some PSAPs often include dispatchers, responders or specialists on a Some PSAPs often include dispatchers, responders or specialists on a
call. Some responder's dispatchers are not located in the primary call. Some responder's dispatchers are not located in the primary
PSAP, the call may have to be transferred to another PSAP. Most PSAP, the call may have to be transferred to another PSAP. Most
often this will be an attended transfer, or a bridged transfer. often this will be an attended transfer, or a bridged transfer.
Therefore a PSAP may need to a REFER request [RFC3515] a call to a Therefore a PSAP may need to a REFER request [RFC3515] a call to a
bridge for conferencing. Devices which normally involve the user in bridge for conferencing. Devices which normally involve the user in
transfer operations should consider the effect of such interactions transfer operations should consider the effect of such interactions
when a stressed user places an emergency call. Requiring UI when a stressed user places an emergency call. Requiring UI
manipulation during such events may not be desirable. Relay services manipulation during such events may not be desirable. Relay services
for communication with people with disabilities may be included in for communication with people with disabilities may be included in
the call with the bridge. The UA should be prepared to have the call the call with the bridge. The UA should be prepared to have the call
transferred (usually attended, but possibly blind) per [RFC5359]. transferred (usually attended, but possibly blind) per [RFC5359].
12. 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.
PSAP terminates a call using the normal SIP call termination PSAP terminates a call using the normal SIP call termination
procedures, i.e with a BYE request. procedures, i.e., with a BYE request.
13. Disabling of features 13. Disabling of features
Certain features that can be invoked while a normal call is active Certain features that can be invoked while a normal call is active
are not permitted when the call is an emergency call. Services such are not permitted when the call is an emergency call. Services such
as call waiting, call transfer, three way call and hold should be as call waiting, call transfer, three way call and hold should be
disabled. disabled.
Certain features such as call forwarding can interfere with calls Certain features such as call forwarding can interfere with calls
from a PSAP and should be disabled. There is no way to reliably from a PSAP and should be disabled. There is no way to reliably
skipping to change at page 31, line 33 skipping to change at page 32, line 15
[RFC3264] negotiations should be used to agree on the media streams [RFC3264] negotiations should be used to agree on the media streams
to be used. PSAPs should accept real-time text [RFC4103]. All PSAPs 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 should accept G.711 A-law (and mu-law in North America) encoded voice
as described in [RFC3551]. Newer text forms are rapidly appearing, as described in [RFC3551]. Newer text forms are rapidly appearing,
with instant messaging now very common, PSAPs should accept IM with with instant messaging now very common, PSAPs should accept IM with
at least "pager-mode" MESSAGE request [RFC3428] as well as Message at least "pager-mode" MESSAGE request [RFC3428] as well as Message
Session Relay Protocol [RFC4975]. Video may be important to support Session Relay Protocol [RFC4975]. Video may be important to support
Video Relay Service (sign language interpretation) as well as modern Video Relay Service (sign language interpretation) as well as modern
video phones. video phones.
While it is desirable for media to be kept secure, preferably by use It is desirable for media to be kept secure by the use of Secure RTP
of Secure RTP [RFC3711], there is not yet consensus on how best to [RFC3711], using SDES [RFC4568] for keying.
signal keying material for SRTP. As a consequence, no recommendation
to support SRTP can be made yet for emergency calls.
15. Testing 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.
includes a description of an automated test procedure that validates [I-D.ietf-ecrit-phonebcp]includes a description of an automated test
routing, signaling and media path continuity. This test would be procedure that validates routing, signaling and media path
used within some random interval after boot time, and whenever the continuity. This test would be used within some random interval
device location changes enough that a new PSAP mapping is returned by after boot time, and whenever the device location changes enough that
the LoST server. a new PSAP mapping is returned by the LoST server.
The PSAP needs to be able to control frequency and duration of the The PSAP needs to be able to control frequency and duration of the
test, and since the process could be abused, it may temporarily or test, and since the process could be abused, it may temporarily or
permanently suspend its operation. permanently suspend its operation.
There is a concern associated with testing during a so-called There is a concern associated with testing during a so-called
"avalanche-restart" event where, for example a large power outage "avalanche-restart" event where, for example a large power outage
affects a large number of endpoints, that, when power is restored, affects a large number of endpoints, that, when power is restored,
all attempt to reboot and, possibly, test. Devices need to randomize all attempt to reboot and, possibly, test. Devices need to randomize
their initiation of a boot time test to avoid the problem. their initiation of a boot time test to avoid the problem.
16. Security Considerations 16. Security Considerations
Security considerations for emergency calling have been documented in Security considerations for emergency calling have been documented in
[RFC5069] and [I-D.barnes-geopriv-lo-sec]. [RFC5069] and [I-D.barnes-geopriv-lo-sec].
17. IANA Considerations 17. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
18. Acknowledgements 18. Acknowledgments
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
Martin Dolly, Stu Goldman, Ted Hardie, Marc Linsner, Roger Marshall, Martin Dolly, Stu Goldman, Ted Hardie, Marc Linsner, Roger Marshall,
Shida Schubert, Tom Taylor and Hannes Tschofenig,. Further comments Shida Schubert, Tom Taylor and Hannes Tschofenig,. Further comments
and input were provided by Richard Barnes, Barbara Stark and James and input were provided by Richard Barnes, Barbara Stark and James
Winterbottom. Winterbottom.
skipping to change at page 33, line 5 skipping to change at page 33, line 32
[I-D.barnes-geopriv-lo-sec] [I-D.barnes-geopriv-lo-sec]
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
draft-barnes-geopriv-lo-sec-05 (work in progress), draft-barnes-geopriv-lo-sec-05 (work in progress),
March 2009. March 2009.
[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-12 (work in progress), draft-ietf-ecrit-phonebcp-14 (work in progress),
July 2009. January 2010.
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-15 (work in draft-ietf-geopriv-http-location-delivery-16 (work in
progress), June 2009. progress), August 2009.
[I-D.ietf-geopriv-lis-discovery] [I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-11 (work in progress), draft-ietf-geopriv-lis-discovery-15 (work in progress),
May 2009. March 2010.
[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-15 (work in progress), (SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007. October 2007.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
skipping to change at page 35, line 28 skipping to change at page 36, line 9
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 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.
[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony
Device Requirements and Configuration", RFC 4504, Device Requirements and Configuration", RFC 4504,
May 2006. May 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006. Configuration Information", RFC 4776, November 2006.
[RFC4967] Rosen, B., "Dial String Parameter for the Session [RFC4967] Rosen, B., "Dial String Parameter for the Session
Initiation Protocol Uniform Resource Identifier", Initiation Protocol Uniform Resource Identifier",
RFC 4967, July 2007. RFC 4967, July 2007.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007. Session Relay Protocol (MSRP)", RFC 4975, September 2007.
skipping to change at page 36, line 42 skipping to change at page 37, line 25
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
Brian Rosen Brian Rosen
NeuStar, Inc. NeuStar, Inc.
470 Conrad Dr 470 Conrad Dr
Mars, PA 16046 Mars, PA 16046
US USA
Email: br@brianrosen.net Email: br@brianrosen.net
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US USA
Phone: +1 212 939 7042 Phone: +1 212 939 7042
Email: hgs@cs.columbia.edu Email: hgs@cs.columbia.edu
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 USA
Phone: +1-817-271-3552 Phone: +1-817-271-3552
Email: jmpolk@cisco.com Email: jmpolk@cisco.com
Andrew Newton Andrew Newton
TranTech/MediaSolv TranTech/MediaSolv
4900 Seminary Road 4900 Seminary Road
Alexandria, VA 22311 Alexandria, VA 22311
US USA
Phone: +1 703 845 0656 Phone: +1 703 845 0656
Email: andy@hxr.us Email: andy@hxr.us
 End of changes. 64 change blocks. 
192 lines changed or deleted 204 lines changed or added

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