draft-ietf-ecrit-framework-12.txt   draft-ietf-ecrit-framework-13.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Informational H. Schulzrinne Intended status: Informational H. Schulzrinne
Expires: April 28, 2011 Columbia U. Expires: March 11, 2012 Columbia U.
J. Polk J. Polk
Cisco Systems Cisco Systems
A. Newton A. Newton
TranTech/MediaSolv TranTech/MediaSolv
October 25, 2010 September 8, 2011
Framework for Emergency Calling using Internet Multimedia Framework for Emergency Calling using Internet Multimedia
draft-ietf-ecrit-framework-12 draft-ietf-ecrit-framework-13
Abstract Abstract
The IETF has standardized various aspects of placing emergency calls. The IETF has standardized various aspects of placing emergency calls.
This document describes how all of those component parts are used to This document describes how all of those component parts are used to
support emergency calls from citizens and visitors to authorities. support emergency calls from citizens and visitors to authorities.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on April 28, 2011. This Internet-Draft will expire on March 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 . 18 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 . . . . . . . . . . . . . . . . . . . . 23
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 23 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 23
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 24 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 23
6.10. Location validation . . . . . . . . . . . . . . . . . . . 25 6.10. Location validation . . . . . . . . . . . . . . . . . . . 24
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 25 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 30 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 30
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 31 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 30
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 31 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 31
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
19. Informative References . . . . . . . . . . . . . . . . . . . . 33 19. Informative References . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Terminology 1. Terminology
This document uses terms from [RFC3261], [RFC5222] and [RFC5012]. In This document uses terms from [RFC3261], [RFC5222] and [RFC5012]. In
addition the following terms are used: addition the following terms are used:
skipping to change at page 5, line 44 skipping to change at page 5, line 44
will persist long after most systems have been upgraded to IP will persist long after most systems have been upgraded to IP
origination and termination of emergency calls. Many of these legacy origination and termination of emergency calls. Many of these legacy
systems route calls based on telephone numbers. Gateways and systems route calls based on telephone numbers. Gateways and
conversions between existing systems and newer systems defined by conversions between existing systems and newer systems defined by
this document will be required. Since existing systems are governed this document will be required. Since existing systems are governed
primarily by local government regulations and national standards, the primarily by local government regulations and national standards, the
gateway and conversion details will be governed by national standards gateway and conversion details will be governed by national standards
and thus are out of scope for this document. and thus are out of scope for this document.
Existing emergency call systems are organized locally or nationally; Existing emergency call systems are organized locally or nationally;
there are currently no international standards. However, the there are currently few international standards. However, the
Internet crosses national boundaries, and thus international Internet crosses national boundaries, and thus Internet standards are
standards for equipment and software are required. To further required. To further complicate matters, VoIP endpoints can be
complicate matters, VoIP endpoints can be connected through tunneling connected through tunneling mechanisms such as virtual private
mechanisms such as virtual private networks (VPNs). Tunnels can networks (VPNs). Tunnels can obscure the identity of the actual
obscure the identity of the actual access network that knows the access network that knows the location. This significantly
location. This significantly complicates emergency calling, because complicates emergency calling, because the location of the caller and
the location of the caller and the first element that routes the first element that routes emergency calls can be on different
emergency calls can be on different continents, with different continents, with different conventions and processes for handling of
conventions and processes for handling of emergency calls. emergency calls.
The IETF has historically refused to create national variants of its The IETF has historically not created national variants of its
standards. Thus, this document attempts to take into account best standards. Thus, this document attempts to take into account best
practices that have evolved for circuit switched PSAPs, but makes no practices that have evolved for circuit switched PSAPs, but makes no
assumptions on particular operating practices currently in use, assumptions on particular operating practices currently in use,
numbering schemes or organizational structures. numbering schemes or organizational structures.
This document discusses the use of the Session Initiation Protocol This document discusses the use of the Session Initiation Protocol
(SIP) [RFC3261] by PSAPs and calling parties. While other inter- (SIP) [RFC3261] by PSAPs and calling parties. While other inter-
domain call signaling protocols may be used for emergency calling, domain call signaling protocols may be used for emergency calling,
SIP is ubiquitous and possesses the proper support of this use case. SIP is ubiquitous and possesses the proper support of this use case.
Only protocols such as H.323, XMPP/Jingle, ISUP and SIP are suitable Only protocols such as H.323, XMPP/Jingle, ISUP and SIP are suitable
for inter-domain communications, ruling out Media Gateway Controller for inter-domain communications, ruling out Media Gateway Controller
protocols such as MGCP or H.248/Megaco. The latter protocols can be protocols such as MGCP or H.248/Megaco. The latter protocols can be
used by the enterprise or carrier placing the call, but any such call used by the enterprise or carrier placing the call, but any such call
would reach the PSAP through a media gateway controller, similar to would reach the PSAP through a media gateway controller, similar to
how inter-domain VoIP calls would be placed. Other signaling how inter-domain VoIP calls would be placed. Other signaling
protocols may also use protocol translation to communicate with a protocols may also use protocol translation to communicate with a
SIP-enabled PSAP. SIP-enabled PSAP. p2psip is not considered in this document.
Existing emergency services rely exclusively on voice and Existing emergency services rely exclusively on voice and
conventional text telephony ("TTY") media streams. However, more conventional text telephony ("TTY") media streams. However, more
choices of media offer additional ways to communicate and evaluate choices of media offer additional ways to communicate and evaluate
the situation as well as to assist callers and call takers in the situation as well as to assist callers and call takers in
handling emergency calls. For example, instant messaging and video handling emergency calls. For example, instant messaging and video
could improve the ability to communicate and evaluate the situation could improve the ability to communicate and evaluate the situation
and to provide appropriate instruction prior to arrival of emergency and to provide appropriate instruction prior to arrival of emergency
crews. Thus, the architecture described here supports the creation crews. Thus, the architecture described here supports the creation
of sessions of any media type, negotiated between the caller and PSAP of sessions of any media type, negotiated between the caller and PSAP
skipping to change at page 7, line 34 skipping to change at page 7, line 34
the caller. the caller.
o The PSAP must be able to re-establish a session to the caller if o The PSAP must be able to re-establish a session to the caller if
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 obtains his location (Section 6) prior
prior to making emergency calls. To get this location, either a form to making emergency calls. To get this location, either a form of
of measuring, for example, GNSS (Section 6.2.3) is deployed, or the 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.
The following is a quick overview for a typical Ethernet connected The following is a quick overview for a typical Ethernet connected
telephone using SIP signaling. It illustrates one set of choices for telephone using SIP signaling. It illustrates one set of choices for
various options presented later in this document. various options presented later in this document.
o The phone "boots" and connects to its access network. o The phone "boots" and connects to its access network.
o The phone gets location via a Location Configuration Protocol o The phone gets location via a Location Configuration Protocol
(LCP), for example from the DHCP server in civic [RFC4776] and/or (LCP), for example from the DHCP server in civic [RFC4776] and/or
geo [RFC3825] forms, a HELD server [RFC5985] or the first level geo [RFC6225] forms, a HELD server [RFC5985] or the first level
switch's LLDP server [LLDP]. switch's LLDP server [LLDP].
o The phone obtains the local emergency dial string(s) from the LoST o The phone obtains the local emergency dial string(s) from the LoST
[RFC5222] server for its current location. It also receives and [RFC5222] server for its current location. It also receives and
caches the PSAP URI obtained from the LoST server. caches the PSAP URI obtained from the LoST server.
o Some time later, the user places an emergency call. The phone o Some time later, the user places an emergency call. The phone
recognizes an emergency call from the dial strings and uses the recognizes an emergency call from the dial strings and uses the
"urn:service:sos" [RFC5031] URN to mark an emergency call. "urn:service:sos" [RFC5031] URN to mark an emergency call.
o It refreshes its location via DHCP and updates the PSAP's URI by o It refreshes its location via DHCP and updates the PSAP's URI by
querying the LoST mapping server with its location. querying the LoST mapping server with its location.
o It puts its location in the SIP INVITE request in a Geolocation o It puts its location in the SIP INVITE request in a Geolocation
skipping to change at page 17, line 44 skipping to change at page 17, line 44
However, there are always a small number of cases where the automated However, there are always a small number of cases where the automated
mechanisms used by the access network to determine location fail to mechanisms used by the access network to determine location fail to
accurately reflect the actual location of the endpoint. For example, accurately reflect the actual location of the endpoint. For example,
the user may deploy his own WAN behind an access network, effectively the user may deploy his own WAN behind an access network, effectively
removing an endpoint some distance from the access network's notion removing an endpoint some distance from the access network's notion
of its location. To handle these exceptional cases, there must be of its location. To handle these exceptional cases, there must be
some mechanism provided to manually provision a location for an some mechanism provided to manually provision a location for an
endpoint by the user or by the access network on behalf of a user. endpoint by the user or by the access network on behalf of a user.
The use of the mechanism introduces the possibility of users falsely The use of the mechanism introduces the possibility of users falsely
declaring themselves to be somewhere they are not. As an aside, declaring themselves to be somewhere they are not. However, this is
normally, if an emergency caller insists that he is at a location generally not a problem in practice. Commonly, if an emergency
different from what any automatic location determination system caller insists that he is at a location different from what any
reports he is, responders will always be sent to the user's self- automatic location determination system reports he is, responders
declared location. However, this is a matter of local policy and is will always be sent to the user's self-declared location.
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.
skipping to change at page 19, line 23 skipping to change at page 19, line 23
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).
6.2.4. Network measured location information 6.2.4. Network measured location information
The access network may locate end devices. Techniques include: The access network may locate end devices. Techniques various forms
Wireless triangulation: Elements in the network infrastructure of triangulation. Elements in the network infrastructure triangulate
triangulate end systems based on signal strength, angle of arrival end systems based on signal strength, angle of arrival or time of
or time of arrival. Common mechanisms deployed include: arrival. Common mechanisms deployed include:
* Time Difference Of Arrival - TDOA o Time Difference Of Arrival - TDOA
* Uplink Time Difference Of Arrival - U-TDOA o Uplink Time Difference Of Arrival - U-TDOA
* Angle of Arrival - AOA o Angle of Arrival - AOA
* RF fingerprinting o RF fingerprinting
* Advanced Forward Link Trilateration - AFLT o Advanced Forward Link Trilateration - AFLT
* Enhanced Forward Link Trilateration - EFLT o Enhanced Forward Link Trilateration - EFLT
Sometimes multiple mechanisms are combined, for example A-GPS with Sometimes multiple mechanisms are combined, for example A-GPS with
AFLT. AFLT.
Location beacons: A short range wireless beacon, e.g., using
Bluetooth or infrared, announces its location to mobile devices in
the vicinity. This allows devices to get location from the beacon
source's location.
6.3. Who adds location, endpoint or proxy 6.3. Who adds location, endpoint or proxy
The IETF emergency call architecture prefers endpoints to learn their The IETF emergency call architecture prefers endpoints to learn their
location and supply it on the call. Where devices do not support location and supply it on the call. Where devices do not support
location, proxy servers may have to add location to emergency calls. location, proxy servers may have to add location to emergency calls.
Some calling networks have relationships with all access networks the Some calling networks have relationships with all access networks the
device may be connected to, and that may allow the proxy to device may be connected to, and that may allow the proxy to
accurately determine the location of the endpoint. However, NATs and accurately determine the location of the endpoint. However, NATs and
other middleboxes often make it impossible to determine a reference other middleboxes often make it impossible to determine a reference
skipping to change at page 20, line 39 skipping to change at page 20, line 36
represent a time-varying location, but the added complexity of the represent a time-varying location, but the added complexity of the
dereference step introduces a risk that location will not be dereference step introduces a risk that location will not be
available to parties that need it. available to parties that need it.
6.5. End system location configuration 6.5. End system location configuration
Unless a user agent has access to provisioned or locally measured Unless a user agent has access to provisioned or locally measured
location information, it must obtain it from the access network. location information, it must obtain it from the access network.
There are several location configuration protocols (LCPs) that can be There are several location configuration protocols (LCPs) that can be
used for this purpose 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 [RFC6225]
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 [RFC5985] can deliver a civic or geo location object, by value HELD [RFC5985] can deliver a civic or geo location object, by value
or by reference, via a layer 7 protocol. The query typically uses or by reference, via a layer 7 protocol. The query typically uses
the IP address of the requester as an identifier and returns the the IP address of the requester as an identifier and returns the
location value or reference associated with that identifier. HELD location value or reference associated with that identifier. HELD
is typically carried in HTTP. is typically 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 22, line 33 skipping to change at page 22, line 25
tunnels (that assign new IP addresses to communications) can obscure tunnels (that assign new IP addresses to communications) can obscure
identifiers used by LCPs to determine location, especially for HELD. identifiers used by LCPs to determine location, especially for HELD.
In some cases, such as residential NAT devices, the NAT is placed In some cases, such as residential NAT devices, the NAT is placed
between the endpoint and the access network demarcation point and between the endpoint and the access network demarcation point and
thus the IP address seen by the access network is the right thus the IP address seen by the access network is the right
identifier for location of the residence. However, in many identifier for location of the residence. However, in many
enterprise environments, VPN tunnels can obscure the actual IP enterprise environments, VPN tunnels can obscure the actual IP
address. Some VPN mechanisms can be bypassed so that a query to the address. Some VPN mechanisms can be bypassed so that a query to the
LCP can be designated to go through the direct IP path, using the LCP can be designated to go through the direct IP path, using the
correct IP address, and not through the tunnel. In other cases, no correct IP address, and not through the tunnel. In other cases, no
bypass is possible. Of course, LCPs that use layer 2 mechanisms bypass is possible, but location can be configured before the VPN is
(DHCP Location options and LLDP-MED) are usually immune from such established. Of course, LCPs that use layer 2 mechanisms (DHCP
problems because they do not use the IP address as the identifier for Location options and LLDP-MED) are usually immune from such problems
the device seeking location. because they do not use the IP address as the identifier for the
device seeking location.
It is desirable that routing location information be periodically It is desirable that routing location information be periodically
refreshed. A LIS supporting a million subscribers each refreshing refreshed. A LIS supporting a million subscribers each refreshing
once per day would need to support a query rate of 1,000,000 / (24 * once per day would need to support a query rate of 1,000,000 / (24 *
60 * 60) = 12 queries per second. 60 * 60) = 12 queries per second. For networks with mobile devices,
much higher refresh rates could be expected.
It is desirable for routing location information to be requested It is desirable for routing location information to be requested
immediately before placing an emergency call. However, if there is immediately before placing an emergency call. However, if there is
any significant delay in getting more recent location, the call any significant delay in getting more recent location, the call
should be placed with the most recent location information the device should be placed with the most recent location information the device
has. In mobile handsets, routing is often accomplished with the cell has. In mobile handsets, routing is often accomplished with the cell
site and sector of the tower serving the call, because it can take site and sector of the tower serving the call, because it can take
many seconds to start up the location determination mechanism and many seconds to start up the location determination mechanism and
obtain an accurate location. obtain an accurate location.
skipping to change at page 23, line 16 skipping to change at page 23, line 9
location and the accuracy (technically, confidence and uncertainty) location and the accuracy (technically, confidence and uncertainty)
obtained. Routing an emergency call quickly is required. However, obtained. Routing an emergency call quickly is required. However,
if location can be substantially improved by waiting a short time if location can be substantially improved by waiting a short time
(e.g., for some sort of "quick fix"), it's preferable to wait. Three (e.g., for some sort of "quick fix"), it's preferable to wait. Three
seconds, the current nominal time for a quick fix, is a very long seconds, the current nominal time for a quick fix, is a very long
time add to post dial delay. time add to post dial delay.
NENA recommends [NENAi3TRD] that IP based systems complete calls in NENA recommends [NENAi3TRD] that IP based systems complete calls in
two seconds from last dial press to ring at PSAP. two seconds from last dial press to ring at PSAP.
6.7. Conveying location in SIP 6.7. Conveying location
When an emergency call is placed, the endpoint should include When an emergency call is placed, the endpoint should include
location in the call signaling. This is referred to as "conveyance" location in the call signaling. This is referred to as "conveyance"
to distinguish it from "configuration". In SIP, the location to distinguish it from "configuration". In SIP, the location
information is conveyed following the procedures in information is conveyed following the procedures in
[I-D.ietf-sip-location-conveyance]. Since the form of the location [I-D.ietf-sip-location-conveyance]. Since the form of the location
information obtained by the acquisition protocol may not be the same information obtained by the acquisition protocol may not be the same
as the conveyance protocol uses (PIDF-LO [RFC4119]), mapping by the as the conveyance protocol uses (PIDF-LO [RFC4119]), mapping by the
endpoint from the LCP form to PIDF may be required. endpoint from the LCP form to PIDF may be required.
skipping to change at page 25, line 37 skipping to change at page 25, line 29
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
validated may eventually fail validation. Endpoints may wish to validated may eventually fail validation. Endpoints may wish to
validate locations they receive from the access network, and will validate locations they receive from the access network, and will
need to validate manually entered locations. Proxies that insert need to validate manually entered locations. Proxies that insert
location may wish to validate locations they receive from a LIS. location may wish to validate locations they receive from a LIS.
When the test functions (Section 15) are invoked, the location used When the test functions (Section 15) are invoked, the location used
should be validated. should be validated.
When validation fails, the location given must not be used for an When validation fails, the location given should not be used for an
emergency call. If validation is completed when location is first emergency call, unless no other valid location is available. Bad
loaded into a LIS, any problems can be found and fixed before devices location is better than no location. If validation is completed when
could get the bad location. Failure of validation arises because an location is first loaded into a LIS, any problems can be found and
error is made in determining the location, although occasionally the fixed before devices could get the bad location. Failure of
LoST database is not up to date or has faulty information. In either validation arises because an error is made in determining the
case, the problem must be identified and corrected before using the location, although occasionally the LoST database is not up to date
location. or has faulty information. In either case, the problem must be
identified and should be corrected before using the location.
6.11. Default location 6.11. Default location
Occasionally, the access network cannot determine the actual location Occasionally, the access network cannot determine the actual location
of the caller. In these cases, it must supply a default location. of the caller. In these cases, it must supply a default location.
The default location should be as accurate as the network can The default location should be as accurate as the network can
determine. For example, in a cable network, a default location for determine. For example, in a cable network, a default location for
each Cable Modem Termination System (CMTS), with a representative each Cable Modem Termination System (CMTS), with a representative
location for all cable modems served by that CMTS could be provided location for all cable modems served by that CMTS could be provided
if the network is unable to resolve the subscriber to anything more if the network is unable to resolve the subscriber to anything more
skipping to change at page 32, line 36 skipping to change at page 32, line 25
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.ietf-geopriv-arch]. [RFC5069] and [RFC6280].
This document suggests that security (TLS or IPsec) be used hop by
hop on a SIP call to protect location information, identity, etc. It
also suggests that if the attempt to create a security association
fails, the call be retried without the security. It's more important
to get an emergency call through than to protect the data; indeed, in
many jurisdictions privacy is explicitly waived when making emergency
calls. Placing a call without security may reveal user information,
including location. The alternative - failing the call if security
cannot be established, is considered unacceptable.
17. IANA Considerations 17. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
18. Acknowledgments 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.
skipping to change at page 33, line 14 skipping to change at page 33, line 13
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.
19. Informative References 19. Informative References
[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-15 (work in progress), draft-ietf-ecrit-phonebcp-20 (work in progress),
July 2010. September 2011.
[I-D.ietf-geopriv-arch]
Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-03 (work in progress),
October 2010.
[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",
draft-ietf-sip-location-conveyance-13 (work in progress), draft-ietf-sip-location-conveyance-13 (work in progress),
March 2009. March 2009.
[LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control",
Dec 2004. Dec 2004.
skipping to change at page 34, line 29 skipping to change at page 34, line 21
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
skipping to change at page 36, line 41 skipping to change at page 36, line 28
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010. RFC 5985, September 2010.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986, Location Information Server (LIS)", RFC 5986,
September 2010. September 2010.
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic
Host Configuration Protocol Options for Coordinate-Based
Location Configuration Information", RFC 6225, July 2011.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, July 2011.
[WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of [WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of
Defense World Geodetic System 1984, Its Definition and Defense World Geodetic System 1984, Its Definition and
Relationships With Local Geodetic Systems, Third Edition", Relationships With Local Geodetic Systems, Third Edition",
July 1997. July 1997.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar, Inc. NeuStar, Inc.
470 Conrad Dr 470 Conrad Dr
 End of changes. 27 change blocks. 
79 lines changed or deleted 84 lines changed or added

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