draft-ietf-ecrit-framework-13.txt   rfc6443.txt 
ecrit B. Rosen Internet Engineering Task Force (IETF) B. Rosen
Internet-Draft NeuStar Request for Comments: 6443 NeuStar
Intended status: Informational H. Schulzrinne Category: Informational H. Schulzrinne
Expires: March 11, 2012 Columbia U. ISSN: 2070-1721 Columbia U.
J. Polk J. Polk
Cisco Systems Cisco Systems
A. Newton A. Newton
TranTech/MediaSolv TranTech/MediaSolv
September 8, 2011 December 2011
Framework for Emergency Calling using Internet Multimedia Framework for Emergency Calling Using Internet Multimedia
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
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on March 11, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6443.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology .....................................................6
3. Overview of how emergency calls are placed . . . . . . . . . . 7 3. Overview of How Emergency Calls Are Placed ......................8
4. Which devices and services should support emergency calls . . 11 4. Which Devices and Services Should Support Emergency Calls? .....12
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 .....................14
6.1. Types of location information . . . . . . . . . . . . . . 15 6.1. Types of Location Information .............................16
6.2. Location determination . . . . . . . . . . . . . . . . . . 16 6.2. Location Determination ....................................17
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
6.2.3. End-system measured location information . . . . . . . 18 Information ........................................18
6.2.4. Network measured location information . . . . . . . . 19 6.2.3. End System Measured Location Information ...........19
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 19 6.2.4. Network Measured Location Information ..............19
6.4. Location and references to location . . . . . . . . . . . 20 6.3. Who Adds Location, Endpoint, or Proxy? ....................20
6.5. End system location configuration . . . . . . . . . . . . 20 6.4. Location and References to Location .......................20
6.6. When location should be configured . . . . . . . . . . . . 22 6.5. End System Location Configuration .........................21
6.7. Conveying location . . . . . . . . . . . . . . . . . . . . 23 6.6. When Location Should Be Configured ........................22
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 23 6.7. Conveying Location ........................................23
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 23 6.8. Location Updates ..........................................24
6.10. Location validation . . . . . . . . . . . . . . . . . . . 24 6.9. Multiple Locations ........................................24
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 25 6.10. Location Validation ......................................25
6.12. Location format conversion . . . . . . . . . . . . . . . . 26 6.11. Default Location .........................................26
7. LIS and LoST discovery . . . . . . . . . . . . . . . . . . . . 26 6.12. Location Format Conversion ...............................26
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 26 7. LIS and LoST Discovery .........................................26
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 28 8. Routing the Call to the PSAP ...................................27
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Signaling of Emergency Calls ...................................29
9.2. SIP signaling requirements for User Agents . . . . . . . . 29 9.1. Use of TLS ................................................29
9.3. SIP signaling requirements for proxy servers . . . . . . . 29 9.2. SIP Signaling Requirements for User Agents ................30
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.3. SIP Signaling Requirements for Proxy Servers ..............30
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 30 10. Call Backs ....................................................30
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 30 11. Mid-Call Behavior .............................................31
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 31 12. Call Termination ..............................................31
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 13. Disabling of Features .........................................32
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. Media .........................................................32
16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 15. Testing .......................................................32
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 16. Security Considerations .......................................33
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 17. Acknowledgments ...............................................33
19. Informative References . . . . . . . . . . . . . . . . . . . . 33 18. Informative References ........................................34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Terminology
This document uses terms from [RFC3261], [RFC5222] and [RFC5012]. In
addition the following terms are used:
Access network: The access network supplies IP packet service to an
endpoint. Examples of access networks include digital subscriber
lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local
area networks and cellular data networks.
Confidence: Confidence is an estimate indicating how sure the
measuring system is that the actual location of the endpoint is
within the bounds defined by the uncertainty value, expressed as a
percentage. For example, a value of 90% indicates that the actual
location is within the uncertainty nine times out of ten.
Dispatch Location: The dispatch location is the location used for
dispatching responders to the person in need of assistance. The
dispatch location must be sufficiently precise to easily locate
the caller; it typically needs to be more accurate than the
routing location.
Location configuration: During location configuration, an endpoint
learns its physical location.
Location Configuration Protocol (LCP): A protocol used by an
endpoint to learn its location.
Location conveyance: Location conveyance delivers location
information to another element.
Location determination: Location determination finds where an
endpoint is physically located. For example, the endpoint may
contain a Global Navigation Satellite System (GNSS) receiver used
to measure its own location or the location may be determined by a
network administrator using a wiremap database.
Location Information Server (LIS): A Location Information Server
stores location information for retrieval by an authorized entity.
Mobile device: A mobile device is a user agent that may change its
physical location and possibly its network attachment point during
an emergency call.
NENA (National Emergency Number Association): The National Emergency
Number Association is an organization of professionals to "foster
the technological advancement, availability and implementation of
a universal emergency telephone number system in North America."
It develops emergency calling specifications and procedures.
Nomadic device (user): A nomadic user agent is connected to the
network temporarily, for relatively short durations, but does not
move significantly during the during the emergency call. Examples
include a laptop using an IEEE 802.11 hotspot or a desk IP phone
that is moved occasionally from one cubicle to another.
Physical location: A physical location describes where a person or
device is located in physical space, described by a coordinate
system. It is distinguished from the network location, described
by a network address.
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
Dispatch Location.
Stationary device: An stationary device is not mobile and is
connected to the network at a fixed, long-term-stable physical
location. Examples include home PCs or pay phones.
Uncertainty: Uncertainty is an estimate, expressed in a unit of
length, indicating the diameter of a circle that contains the
endpoint with the probability indicated by the confidence value.
2. Introduction 1. Introduction
Requesting help in an emergency using a communications device such as Requesting help in an emergency using a communications device such as
a telephone or mobile phone is an accepted practice in many parts of a telephone (landline or mobile) is an accepted practice in many
the world. As communications devices increasingly utilize the parts of the world. As communications devices increasingly utilize
Internet to interconnect and communicate, users will expect to use the Internet to interconnect and communicate, users will expect to
such devices to request help. This document describes establishment use such devices to request help. This document describes
of a communications session by a user to a "Public Safety Answering establishment of a communications session by a user to a "Public
Point" (PSAP), that is, a call center established by response Safety Answering Point" (PSAP), that is, a call center established by
agencies to accept emergency calls. Such citizen/ response agencies to accept emergency calls. Such citizen-/
visitor-to-authority calls can be distinguished from those that are visitor-to-authority calls can be distinguished from those that are
created by responders (authority-to-authority) using public created by responders (authority-to-authority) using public
communications infrastructure often involving some kind of priority communications infrastructure often involving some kind of priority
access as defined in Emergency Telecommunications Service (ETS) in IP access as defined in Emergency Telecommunications Service (ETS) in IP
Telephony [RFC4190]. They also can be distinguished from emergency Telephony [RFC4190]. They can also be distinguished from emergency
warning systems that are authority-to-citizen. warning systems that are authority-to-citizen.
Supporting emergency calling requires cooperation by a number of Supporting emergency calling requires cooperation by a number of
elements, their vendors and service providers. This document elements, their vendors, and service providers. This document
discusses how end device and applications create emergency calls, how discusses how end devices and applications create emergency calls,
access networks supply location for some of these devices, how how access networks supply location for some of these devices, how
service providers assist the establishment and routing, and how PSAPs service providers assist the establishment and routing, and how PSAPs
receive calls from the Internet. receive calls from the Internet.
The emergency response community will have to upgrade their The emergency response community will have to upgrade their
facilities to support a wider range of communications services, but facilities to support a wider range of communications services, but
cannot be expected to handle wide variations in device and service cannot be expected to handle wide variations in device and service
capability. New devices and services are being made available that capability. New devices and services are being made available that
could be used to make a request for help that are not traditional could be used to make a request for help that are not traditional
telephones, and users are increasingly expecting to use them to place telephones, and users are increasingly expecting to use them to place
emergency calls. However, many of the technical advantages of emergency calls. However, many of the technical advantages of
Internet multimedia require re-thinking of the traditional emergency Internet multimedia require re-thinking the traditional emergency
calling architecture. This challenge also offers an opportunity to calling architecture. This challenge also offers an opportunity to
improve the operation of emergency calling technology, while improve the operation of emergency calling technology, while
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
of services; o interleaving over the same infrastructure of a wider variety of
o the separation of the access provider from the application services;
provider;
o separation of the access provider from the application provider;
o media other than voice (for example, video and text in several o media other than voice (for example, video and text in several
forms); forms);
o the potential mobility of all end systems, including endpoints
o potential mobility of all end systems, including endpoints
nominally thought of as fixed systems and not just those using nominally thought of as fixed systems and not just those using
radio access technology. For example, 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
an uplink. Evolution Data Optimized (EV-DO) as an uplink.
This document focuses on how devices using the Internet can place This document focuses on how devices using the Internet can place
emergency calls and how PSAPs can handle Internet multimedia emergency calls and how PSAPs can handle Internet multimedia
emergency calls natively, rather than describing how circuit-switched emergency calls natively, rather than describing how circuit-switched
PSAPs can handle VoIP calls. In many cases, PSAPs making the PSAPs can handle Voice over IP (VoIP) calls. In many cases, PSAPs
transition from circuit-switched interfaces to packet-switched making the transition from circuit-switched interfaces to packet-
interfaces may be able to use some of the mechanisms described here, switched interfaces may be able to use some of the mechanisms
in combination with gateways that translate packet-switched calls described here, in combination with gateways that translate packet-
into legacy interfaces, e.g., to continue to be able to use existing switched calls into legacy interfaces, e.g., to continue to be able
call taker equipment. There are many legacy telephone networks that to use existing call taker equipment. There are many legacy
will persist long after most systems have been upgraded to IP telephone networks that will persist long after most systems have
origination and termination of emergency calls. Many of these legacy been upgraded to IP origination and termination of emergency calls.
systems route calls based on telephone numbers. Gateways and Many of these legacy systems route calls based on telephone numbers.
conversions between existing systems and newer systems defined by Gateways and conversions between existing systems and newer systems
this document will be required. Since existing systems are governed defined by this document will be required. Since existing systems
primarily by local government regulations and national standards, the are governed primarily by local government regulations and national
gateway and conversion details will be governed by national standards standards, the gateway and conversion details will be governed by
and thus are out of scope for this document. national standards and thus are out of scope for this document.
Existing emergency call systems are organized locally or nationally; Existing emergency call systems are organized locally or nationally;
there are currently few international standards. However, the there are currently few international standards. However, the
Internet crosses national boundaries, and thus Internet standards are Internet crosses national boundaries, and thus Internet standards are
required. To further complicate matters, VoIP endpoints can be required. To further complicate matters, VoIP endpoints can be
connected through tunneling mechanisms such as virtual private connected through tunneling mechanisms such as virtual private
networks (VPNs). Tunnels can obscure the identity of the actual networks (VPNs). Tunnels can obscure the identity of the actual
access network that knows the location. This significantly access network that knows the location. This significantly
complicates emergency calling, because the location of the caller and complicates emergency calling, because the location of the caller and
the first element that routes emergency calls can be on different the first element that routes emergency calls can be on different
continents, with different conventions and processes for handling of continents, with different conventions and processes for handling of
emergency calls. emergency calls.
The IETF has historically not created 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 it makes
assumptions on particular operating practices currently in use, no 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 the Media Gateway Control Protocol (MGCP) or H.248/
used by the enterprise or carrier placing the call, but any such call Megaco. The latter protocols can be used by the enterprise or
would reach the PSAP through a media gateway controller, similar to carrier placing the call, but any such call would reach the PSAP
how inter-domain VoIP calls would be placed. Other signaling through a media gateway controller, similar to how inter-domain VoIP
protocols may also use protocol translation to communicate with a calls would be placed. Other signaling protocols may also use
SIP-enabled PSAP. p2psip is not considered in this document. protocol translation to communicate with a SIP-enabled PSAP. Peer-
to-peer SIP (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 making
handling emergency calls. For example, instant messaging and video and handling emergency calls, respectively. For example, instant
could improve the ability to communicate and evaluate the situation messaging and video could improve the ability to communicate and
and to provide appropriate instruction prior to arrival of emergency evaluate the situation and to provide appropriate instruction prior
crews. Thus, the architecture described here supports the creation to arrival of emergency crews. Thus, the architecture described here
of sessions of any media type, negotiated between the caller and PSAP supports the creation of sessions of any media type, negotiated
using existing SIP protocol mechanisms [RFC3264]. between the caller and PSAP using existing SIP mechanisms [RFC3264].
This document focuses on the case in which all three steps in the This document focuses on the case in which all three steps in the
emergency calling process -- location configuration, call routing, emergency calling process -- location configuration, call routing,
and call placement - can be and are performed by the calling and call placement -- can be and are performed by the calling
endpoint, with the endpoint's Access Service Provider supporting the endpoint, with the endpoint's Access Service Provider supporting the
process by providing location information. Calls in this case may be process by providing location information. In this case, calls may
routed via an application-layer Communications Service Provider be routed via an application-layer Communications Service Provider
(e.g., a Voice Service Provider), but need not be. The underlying (e.g., a Voice Service Provider) but need not be. The underlying
protocols can also be used to support other models in which parts of protocols can also be used to support other models in which parts of
the process are delegated to the Communications Service Provider. the process are delegated to the Communications Service Provider.
This document does not address in detail either these models or This document does not address in detail either these models or
interoperability issues between them and the model described here. interoperability issues between them and the model described here.
Since this document is a framework document, it does not include Since this document is a framework document, it does not include
normative behavior. A companion document, [I-D.ietf-ecrit-phonebcp], normative behavior. [PHONEBCP] describes the best current practice
describes Best Current Practice for this subject and contains for this subject and contains normative language for devices as well
normative language for devices, access and calling network elements. as access and calling network elements.
Supporting emergency calling does not require any specialized SIP Supporting emergency calling does not require any specialized SIP
header fields, request methods, status codes, message bodies, or header fields, request methods, status codes, message bodies, or
event packages, but does require that existing mechanisms be used in event packages, but it does require that existing mechanisms be used
certain specific ways, as described below. User Agents (UAs) unaware in certain specific ways, as described below. User agents (UAs)
of the recommendations in this draft may be able to place emergency unaware of the recommendations in this document may be able to place
calls, but functionality may be impaired. For example, if the UA emergency calls, but functionality may be impaired. For example, if
does not implement the location mechanisms described, an emergency the UA does not implement the location mechanisms described, an
call may not be routed to the correct PSAP, and if the caller is emergency call may not be routed to the correct PSAP, and if the
unable to supply his exact location, dispatch of emergency responders caller is unable to supply his exact location, dispatch of emergency
may be delayed. Suggested behavior for both endpoints and servers is responders may be delayed. Suggested behavior for both endpoints and
provided. servers is provided.
From the point of view of the PSAP, three essential elements From the point of view of the PSAP, three essential elements
characterize an emergency call: characterize an emergency call:
o The call is routed to the most appropriate PSAP, based primarily o The call is routed to the most appropriate PSAP, based primarily
on the location of the caller. on the location of the caller.
o The PSAP must be able to automatically obtain the location of the o The PSAP must be able to automatically obtain the location of the
caller with sufficient accuracy to dispatch a responder to help caller with sufficient accuracy to dispatch a responder to help
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 2. Terminology
This document uses terms from [RFC3261], [RFC5222], and [RFC5012].
In addition, the following terms are used:
Access network: The access network supplies IP packet service to an
endpoint. Examples of access networks include digital subscriber
lines (DSLs), cable modems, IEEE 802.11, WiMaX, enterprise local
area networks, and cellular data networks.
Confidence: Confidence is an estimate indicating how sure the
measuring system is that the actual location of the endpoint is
within the bounds defined by the uncertainty value, expressed as a
percentage. For example, a value of 90% indicates that the actual
location is within the uncertainty nine times out of ten.
Dispatch location: The dispatch location is the location used for
dispatching responders to the person in need of assistance. The
dispatch location must be sufficiently precise to easily locate
the caller; typically, it needs to be more accurate than the
routing location.
Location configuration: During location configuration, an endpoint
learns its physical location.
Location Configuration Protocol (LCP): A protocol used by an
endpoint to learn its location.
Location conveyance: Location conveyance delivers location
information to another element.
Location determination: Location determination finds where an
endpoint is physically located. For example, the endpoint may
contain a Global Navigation Satellite System (GNSS) receiver used
to measure its own location or the location may be determined by a
network administrator using a wiremap database.
Location Information Server (LIS): A Location Information Server
stores location information for retrieval by an authorized entity.
Mobile device: A mobile device is a user agent that may change its
physical location and possibly its network attachment point during
an emergency call.
National Emergency Number Association (NENA): The National Emergency
Number Association is an organization of professionals to "foster
the technological advancement, availability and implementation of
a universal emergency telephone number system in North America".
It develops emergency calling specifications and procedures.
Nomadic device (user): A nomadic user agent is connected to the
network temporarily, for relatively short durations, but does not
move significantly during the emergency call. Examples include a
laptop using an IEEE 802.11 hotspot or a desk IP phone that is
moved occasionally from one cubicle to another.
Physical location: A physical location describes where a person or
device is located in physical space, described by a coordinate
system. It is distinguished from the network location, described
by a network address.
Public Safety Answering Point (PSAP): A PSAP is a 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
dispatch location.
Stationary device: An stationary device is not mobile and is
connected to the network at a fixed, long-term-stable physical
location. Examples include home PCs or pay phones.
Uncertainty: Uncertainty is an estimate, expressed in a unit of
length, indicating the diameter of a circle that contains the
endpoint with the probability indicated by the confidence value.
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 setup 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 obtains his location (Section 6) prior geographic regions, a caller obtains his location (Section 6) prior
to making emergency calls. To get this location, either a form of to making emergency calls. To get this location, either a form 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 Location-to-Service Translation (LoST)
location to a set of PSAP URIs. Each URI resolves to a PSAP or an protocol [RFC5222], which maps a location to a set of PSAP URIs.
Emergency Services Routing Proxy (ESRP) that serves as an incoming Each URI resolves to a PSAP or an Emergency Services Routing Proxy
proxy for a group of PSAPs. The call arrives at the PSAP with the (ESRP) that serves as an incoming proxy for a group of PSAPs. The
location included in the INVITE request. call arrives at the PSAP with the 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 [RFC6225] forms, a HELD server [RFC5985] or the first level geo [RFC6225] forms, a HTTP-Enabled Location Delivery (HELD)
switch's LLDP server [LLDP]. server [RFC5985] or the first-level switch's Link-Layer Discovery
Protocol (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
header [I-D.ietf-sip-location-conveyance] and forwards the call header [RFC6442] and forwards the call using its normal outbound
using its normal outbound call processing, which commonly involves call processing, which commonly involves an outbound proxy.
an outbound proxy.
o The proxy recognizes the call as an emergency call and routes the o The proxy recognizes the call as an emergency call and routes the
call using normal SIP routing mechanisms to the URI specified. call using normal SIP routing mechanisms to the URI specified.
o The call routing commonly traverses an incoming proxy server o The call routing commonly traverses an incoming proxy server
(ESRP) in the emergency services network. That proxy would route (ESRP) in the emergency services network. That proxy then routes
the call to the PSAP. the call to the PSAP.
o The call is established with the PSAP and mutually agreed upon o The call is established with the PSAP and mutually agreed upon
media streams are created. media streams are created.
o The location of the caller is displayed to the call taker. o The location of the caller is displayed to the call taker.
Configuration Servers Configuration Servers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. +--------+ +----------+ . . +--------+ +----------+ .
. +--------+ | +----------+ | . . +--------+ | +----------+ | .
. | LIS | | | SIP | | . . | LIS | | | SIP | | .
. | |-+ | Registrar|-+ . . | |-+ | Registrar|-+ .
. +--------+ +----------+ . . +--------+ +----------+ .
skipping to change at page 9, line 26 skipping to change at page 9, line 38
|[M1][M4] |[M2] |[M1][M4] |[M2]
| | +--------+ | | +--------+
|+--------------+ +--------+ | |+--------------+ +--------+ |
|| | LoST | | || | LoST | |
||+-------------------->| Servers|-+ ||+-------------------->| Servers|-+
||| [M3][M5] +--------+ +-------+ ||| [M3][M5] +--------+ +-------+
||| | PSAP2 | ||| | PSAP2 |
||| +-------+ ||| +-------+
||| |||
||| [M6] +-------+ [M7]+------+ [M8]+-------+ ||| [M6] +-------+ [M7]+------+ [M8]+-------+
Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call Taker
+-------+ +------+ +-------+ +-------+ +------+ +-------+
+-------+ +-------+
| PSAP3 | | PSAP3 |
+-------+ +-------+
Figure 1: Emergency Call Component Topology Figure 1: Emergency Call Component Topology
The typical message flow for this example using Alice as the caller: The typical message flow for this example using Alice as the caller:
[M1] Alice -> LIS: LCP Request(s) (ask for location) [M1] Alice -> LIS: LCP Request(s) (ask for location)
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:
skipping to change at page 10, line 16 skipping to change at page 10, line 17
[M1] Alice -> LIS: LCP Request(s) (ask for location) [M1] Alice -> LIS: LCP Request(s) (ask for location)
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 (updates location)
LIS -> Alice: 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: SIP INVITE (service URN, [M6] Alice -> Outgoing Proxy: SIP INVITE (contains service URN,
Location and PSAP URI) Location and PSAP URI)
[M7] Outgoing Proxy -> ESRP: SIP INVITE (service URN, [M7] Outgoing Proxy -> ESRP: SIP INVITE (contains service URN,
Location and PSAP URI)
[M8] ESRP -> PSAP: SIP INVITE (contains service URN,
Location and PSAP URI) 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: Message Flow 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 Configuration Servers - Servers providing Alice's UA its IP o Alice - the user of a UA that places the emergency call.
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 location-by-reference. Configuration servers
include a SIP registrar for Alice's UA. Most SIP UAs will also may include a SIP registrar for Alice's UA. Most SIP UAs
register, so it will be a common scenario for UAs that make will 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. In most cases, a UA would have to
the PSAP to be able to call back after an emergency call is register in order for the PSAP to be able to call it back after an
completed. All the configuration messages are labeled M1 through emergency call has been completed. All the configuration messages
M3, but could easily require more than 3 messages to complete. are labeled M1 through M3, but could easily require more than
three 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
UA, or an in-call routing by the proxy server in the originating 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 ESRP makes further routing decisions (e.g., based on PSAP state
and the location of the caller) to choose the actual PSAP that and the location of the caller) to choose the actual PSAP that
handles the call. In some jurisdictions, this may involve another handles the call. In some jurisdictions, this may involve another
LoST 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 runs an LCP [M1] to
obtain location from the access (broadband) network. Alice's UA then obtain location from the access (broadband) network. Then, Alice's
will most likely register [M2] with a SIP registrar. This allows her UA will most likely register [M2] with a SIP registrar. This allows
to be contacted by other SIP entities. Next, her UA will perform an her to be contacted by other SIP entities. Next, her UA will perform
initial LoST query [M3] to learn a URI for use if the LoST query an initial LoST query [M3] to learn a URI for use if the LoST query
fails during an emergency call, or to use to test the emergency call fails during an emergency call or to use to test the emergency call
mechanism. The LoST response contains the dial string for emergency mechanism. The LoST response contains the dial string for emergency
calls appropriate for the location provided. calls appropriate for the location provided.
At some time after her device has booted, Alice initiates an At some time after her device has booted, Alice initiates an
emergency call. She may do this by dialing an emergency dial string emergency call. She may do this by dialing an emergency dial string
valid for her current ("local") location, or for her "home" location. valid for her current ("local") location or for her "home" location.
The UA recognizes the dial string. The UA attempts to refresh its The UA recognizes either dial string. The UA attempts to refresh its
location [M4], and with that location, to refresh the LoST mapping location [M4], and with that location, to refresh the LoST mapping
[M5], in order to get the most accurate information to use for [M5], in order to get the most accurate information to use for
routing the call. If the location request or the LoST request fails, routing the call. If the location request or the LoST request fails,
or takes too long, the UA uses values it has cached. or takes too long, the UA uses values it has cached.
The UA creates a SIP INVITE [M6] request that includes the location. The UA creates a SIP INVITE [M6] request that includes the location.
[I-D.ietf-sip-location-conveyance] defines a SIP Geolocation header [RFC6442] defines a SIP Geolocation header that contains either a
that contains either a location-by-reference URI or a [RFC3986] "cid" location-by-reference URI or a [RFC3986] "cid:" URL indicating where
URL indicating where in the message body the location-by-value is. in the message body the location-by-value is.
The INVITE message is routed to the ESRP [M7], which is the first The INVITE message is routed to the ESRP [M7], which is the first
inbound proxy for the emergency services domain. This message is inbound proxy for the emergency services domain. This message is
then routed by the ESRP towards the most appropriate PSAP for Alice's then routed by the ESRP towards the most appropriate PSAP for Alice's
location [M8], as determined by the location and other information. location [M8], as determined by the location and other information.
A proxy in the PSAP chooses an available call taker and extends the A proxy in the PSAP chooses an available call taker and extends the
call to its UA. call to its UA.
The 200 OK response to the INVITE request traverses the path in The 200 OK response to the INVITE request traverses the path in
reverse, from call taker UA to PSAP proxy to ESRP to originating reverse, from call taker UA to PSAP proxy to ESRP to originating
network proxy to Alice's UA. The ACK request completes the call network proxy to Alice's UA. The ACK request completes the call
set-up and the emergency call is established, allowing the PSAP call- setup and the emergency call is established, allowing the PSAP call
taker to talk to Alice about Alice's emergency. taker to talk to Alice about Alice's emergency.
4. Which devices and services should support emergency calls 4. Which Devices and Services Should Support Emergency Calls?
Current PSAPs support voice calls and real-time text calls placed Current PSAPs support voice calls and real-time text calls placed
through PSTN facilities or systems connected to the PSTN. Future through PSTN facilities or systems connected to the PSTN. However,
PSAPs will however support Internet connectivity and a wider range of future PSAPs will support Internet connectivity and a wider range of
media types and provide higher functionality. In general, if a user media types and provide higher functionality. In general, if a user
could reasonably expect to be able to place a call for help with the could reasonably expect to be able to place a call for help with the
device, then the device or service should support emergency calling. device, then the device or service should support emergency calling.
Certainly, any device or service that looks like and works like a Certainly, any device or service that looks like and works like a
telephone (wired or mobile) should support emergency calling, but telephone (wired or mobile) should support emergency calling, but
increasingly, users have expectations that other devices and services increasingly, users have expectations that other devices and services
should work. should work.
Devices that create media sessions and exchange audio, video and/or Devices that create media sessions and exchange audio, video, and/or
text, and have the capability to establish sessions to a wide variety text and that have the capability to establish sessions to a wide
of addresses, and communicate over private IP networks or the variety of addresses and communicate over private IP networks or the
Internet, should support emergency calls. Internet should support emergency calls.
Traditionally, enterprise support of emergency calling is provided by Traditionally, enterprise support of emergency calling is provided by
the telephony service provider to the enterprise. In some more the telephony service provider to the enterprise. In some more
recent systems, the enterprise PBX assists emergency calling by recent systems, the enterprise Private Branch Exchange (PBX) assists
providing more fine grained location in larger enterprises. In the emergency calling by providing more fine-grained location in larger
future, the enterprise may provide the connection to emergency enterprises. In the future, the enterprise may provide the
services itself, not relying on the telephony service provider. connection to emergency services itself, not relying on the telephony
service provider.
5. Identifying an emergency call 5. Identifying an Emergency Call
Using the PSTN, emergency help can often be summoned by dialing a Using the PSTN, emergency help can often be summoned by dialing a
nationally designated, widely known number, regardless of where the nationally designated, widely known number, regardless of where the
telephone was purchased. The appropriate number is determined by the telephone was purchased. The appropriate number is determined by the
infrastructure the telephone is connected to. However, this number infrastructure to which the telephone is connected. However, this
differs between localities, even though it is often the same for a number differs between localities, even though it is often the same
country or region, as it is in many countries in the European Union. for a country or region, as it is in many countries in the European
In some countries, there is only one uniform digit sequence that is Union. In some countries, there is only one uniform digit sequence
used for all types of emergencies. In others, there are several that is used for all types of emergencies. In others, there are
sequences that are specific to the type of responder needed, e.g., several sequences that are specific to the type of responder needed,
one for police, another for fire. For end systems, on the other e.g., one for police, another for fire. For end systems, on the
hand, it is desirable to have a universal identifier, independent of other hand, it is desirable to have a universal identifier,
location, to allow the automated inclusion of location information independent of location, to allow the automated inclusion of location
and to allow the device and other entities in the call path to information and to allow the device and other entities in the call
perform appropriate processing within the signaling protocol in an path to perform appropriate processing within the signaling protocol
emergency call set-up. in an emergency call setup.
Since there is no such universal identifier, as part of the overall Since no such universal identifier existed, the overall emergency
emergency calling architecture, common emergency call URNs are calling architecture described here defines common emergency call
defined in [RFC5031]. For a single number environment the urn is URNs [RFC5031]. When all emergency services use a single number, the
"urn:service:sos". Users are not expected to "dial" an emergency URN is "urn:service:sos". Users are not expected to "dial" an
URN. Rather, appropriate emergency dial strings are translated to emergency URN. Rather, appropriate emergency dial strings are
corresponding service URNs, carried in the Request-URI of the INVITE translated to corresponding service URNs, carried in the Request-URI
request. Such translation is best done by the endpoint, because, of the INVITE request. Such translation is best done by the
among other reasons, emergency calls convey location in the endpoint, because, among other reasons, emergency calls convey
signaling, but non-emergency calls do not normally do that. If the location in the signaling but non-emergency calls normally do not.
device recognizes the emergency call, it can include location. A If the device recognizes the emergency call, it can include location,
signaling intermediary (proxy server) can also recognize emergency if known. A signaling intermediary (proxy server) can also recognize
dial strings if the endpoint fails to do so. emergency dial strings if the endpoint fails to do so.
For devices that are mobile or nomadic, an issue arises of whether For devices that are mobile or nomadic, an issue arises of whether
the home or visited dial strings should be used. Many users would the home or visited dial strings should be used. Many users would
prefer that their home dialing sequences work no matter where they prefer that their home dialing sequences work no matter where they
are. However, local laws and regulations may require that the are. However, local laws and regulations may require that the
visited dialing sequence(s) work. Therefore, the visited dial string visited dialing sequence(s) work. Therefore, the visited dial string
must work. Devices may have a way to be configured or learn home must work. Devices may have a way to be configured or learn home
dial strings. dial strings.
LoST [RFC5222] provides the mechanism for obtaining the dialing LoST [RFC5222] provides the mechanism for obtaining the dialing
sequences for a given location. LoST servers must return dial sequences for a given location. LoST servers must return dial
strings for emergency services. If the endpoint does not support the strings for emergency services. If the endpoint does not support the
translation of dial strings to service URNs, the dialing sequence translation of dial strings to service URNs, the dialing sequence
from the endpoint to its proxy is represented as a dial string from the endpoint to its proxy is represented as a dial string
[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 dial strings, 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: The emergency call practitioners consider it undesirable to Note: The emergency call practitioners consider it undesirable to
have a single button emergency call user interface element. These have a single-button emergency call user interface element. These
mechanisms tend to result in a very high rate of false or accidental mechanisms tend to result in a very high rate of false or accidental
emergency calls. In order to minimize this issue, practitioners emergency calls. In order to minimize this issue, practitioners
recommend that device should only initiate emergency calls based on recommend that devices 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
practitioners recommend they 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 callers reporting an emergency are 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,
with overload arrangements between PSAPs to handle each others' with overload arrangements between PSAPs to handle each others'
calls. Other calls that reach it by accident must be manually re- calls. Other calls that reach it by accident must be manually
routed (transferred) to the most appropriate PSAP, increasing call re-routed (transferred) to the more appropriate PSAP, increasing call
handling delay and the chance for errors. The area covered by each handling delay and the chance for errors. The area covered by each
PSAP differs by jurisdiction, where some countries have only a small PSAP differs by jurisdiction, where some countries have only a small
number of PSAPs, while others decentralize PSAP responsibilities to number of PSAPs, while others decentralize PSAP responsibilities to
the level of counties or municipalities. the level of counties or municipalities.
In most cases, PSAPs cover at least a city or town, but there are In most cases, PSAPs cover at least a city or town, but there are
some areas where PSAP coverage areas follow old telephone rate center some areas where PSAP coverage areas follow old telephone rate center
boundaries and may straddle more than one city. Irregular boundaries boundaries and may straddle more than one city. Irregular boundaries
are common, often for historical reasons. Routing must be done based are common, often due to historical reasons. Routing must be done
on actual PSAP service boundaries -- the closest PSAP, or the PSAP based on actual PSAP service boundaries -- the closest PSAP, or the
that serves the nominal city name provided in the location, may not PSAP that serves the nominal city name provided in the location, may
be the correct PSAP. not be the correct PSAP.
Accuracy of routing location is a complex subject. Calls must be Accuracy of routing location is a complex subject. Calls must be
routed quickly, but accurately, and location determination is often a routed quickly, but accurately, and location determination is often a
time/accuracy tradeoff, especially with mobile devices or self time/accuracy trade-off, especially with mobile devices or self-
measuring mechanisms. if more accurate routing location is not measuring mechanisms. If a more accurate routing location is not
available it is considered acceptable to base a routing decision on available, it is considered acceptable to base a routing decision on
an accuracy equal to the area of one sector of a mobile cell site. an accuracy equal to the area of one sector of a mobile cell site.
Routing to the most appropriate PSAP is always based on the location Routing to the most appropriate PSAP is always based on the location
of the caller, despite the fact that some emergency calls are placed of the caller, despite the fact that some emergency calls are placed
on behalf of someone else, and the location of the incident is on behalf of someone else, and the location of the incident is
sometimes not the location of the caller. In some cases, there are sometimes not the location of the caller. In some cases, there are
other factors that enter into the choice of the PSAP that gets the other factors that enter into the choice of the PSAP that gets the
call, such as time of day, caller media requests and language call, such as time of day, caller media requests, language
preference and call load. However, location of the caller is the preference, and call load. However, location of the caller is the
primary input to the routing decision. primary input to the routing decision.
Many mechanisms used to locate a caller have a relatively long "cold Many mechanisms used to locate a caller have a relatively long "cold
start" time. To get a location accurate enough for dispatch may take start" time. To get a location accurate enough for dispatch may take
as much as 30 seconds. This is too long to wait for emergencies. as much as 30 seconds. This is too long to wait for emergencies.
Accordingly, it is common, especially in mobile systems, to use a Accordingly, it is common, especially in mobile systems, to use a
coarse location, for example, the cell site and sector serving the coarse location, for example, the cell site and sector serving the
call, for call routing purposes, and then to update the location when call, for call-routing purposes, and then to update the location when
a more precise value is known prior to dispatch. In this document we a more precise value is known prior to dispatch. In this document,
use "routing location" and "dispatch location" when the distinction we use "routing location" and "dispatch location" when the
matters. distinction 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. This implies perhaps a 3
3 cm accuracy requirement. As of the date of this memo, assisted cm accuracy requirement. As of the date of this memo, assisted GNSS
GNSS uncertainty in mobile phones with 95% confidence cannot be uncertainty in mobile phones with 95% confidence cannot be relied
relied upon to be less than hundreds of meters. As technology upon to be less than hundreds of meters. As technology advances, the
advances, the accuracy requirements for location will need to be accuracy requirements for location will need to be tightened. Wired
tightened. Wired systems using wire tracing mechanisms can provide systems using wire-tracing mechanisms can provide location to a wall
location to a wall jack in specific room on a floor in a building, jack in specific room on a floor in a building, and may even specify
and may even specify a cubicle or even smaller resolution. As this a cubicle or even smaller resolution. As this discussion
discussion illustrates, emergency call systems demand the most illustrates, emergency call systems demand the most stringent
stringent location accuracy available. 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.
Likewise, we employ Location Configuration Protocols, Location Likewise, we employ Location Configuration Protocols, Location
Mapping Protocols, and Location Conveyance Protocols for these Mapping Protocols, and Location Conveyance Protocols for these
functions. functions.
This document provides guidance for generic network configurations This document provides guidance for generic network configurations
with respect to location. It is recognized that unique issues may with respect to location. It is recognized that unique issues may
exist in some network deployments. The IETF will continue to exist in some network deployments. The IETF will continue to
investigate these unique situations and provide further guidance, if investigate these unique situations and provide further guidance, if
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
"Jurisdictional" refers to a civic location using actual
political subdivisions, especially for the community name. political subdivisions, especially for the community name.
'Postal': refers to a civic location for mail delivery. The
"Postal" refers to a civic location for mail delivery. The
name of the post office sometimes does not correspond to the name of the post office sometimes does not correspond to the
community name and a postal address may contain post office community name and a postal address may contain post office
boxes or street addresses that do not correspond to an actual boxes or street addresses that do not correspond to an actual
building. Postal addresses are generally unsuitable for building. Postal addresses are generally unsuitable for
emergency call dispatch because the post office conventions emergency call dispatch because the post office conventions
(for community name, for example) do not match those known by (for community name, for example) do not match those known by
the responders. The fact that they are unique can sometimes be the responders. The fact that they are unique can sometimes be
exploited to provide a mapping between a postal address and a exploited to provide a mapping between a postal address and a
civic address suitable to dispatch a responder to. In IETF civic address suitable to which to dispatch a responder. In
location protocols, there is an element (Postal Community Name) IETF location protocols, there is an element (Postal Community
that can be included in a location to provide the post office Name) that can be included in a location to provide the post
name as well as the actual jurisdictional community name. office name as well as the actual jurisdictional community
There is also an element for a postal code. There is no other name. There is also an element for a postal code. There is no
accommodation for postal addresses in these protocols. other 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 (datum). While there have been many datums developed shape model (datum). While there have been many datums developed
over time, most modern systems are using or moving towards the over time, most modern systems are using or moving towards the
WGS84 [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 that 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 tower/sector information could also
represented as an irregularly shaped polygon of geospatial be represented as an irregularly shaped polygon of geospatial
coordinates reflecting the likely geospatial location of the coordinates reflecting the likely geospatial location of the
mobile device. Whatever representation is used must route mobile device. Whatever representation is used must route
correctly in the LoST database, where "correct" is determined by correctly in the LoST database, where "correct" is determined by
local PSAP management. local PSAP management.
In IETF protocols, both civic and geospatial forms are supported. In IETF protocols, both civic and geospatial forms are supported.
The civic forms include both postal and jurisdictional fields. A The civic forms include both postal and jurisdictional fields. A
cell tower/sector can be represented as a geo point or polygon or cell tower/sector can be represented as a geo point or polygon or
civic location. Other forms of location representation must be civic location. Other forms of location representation must be
mapped into either a geo or civic for use in emergency calls. mapped into either a geo or civic value for use in emergency calls.
For emergency call purposes, conversion of location information from For emergency call purposes, conversion of location information from
civic to geo or vice versa prior to conveyance is not desirable. The civic to geo or vice versa prior to conveyance is not desirable. The
location should be sent in the form it was determined. Conversion location should be sent in the form it was determined. Conversion
between geo and civic requires a database. Where PSAPs need to between geo and civic requires a database. Where PSAPs need to
convert from whatever form they receive to another for responder convert from whatever form they received to another for responder
purposes, they have a suitable database. However, if a conversion is purposes, they have a suitable database. However, if a conversion is
done before the PSAP's, and the database used is not exactly the same done before the PSAP's, and the database used is not exactly the same
one the PSAP uses, the double conversion has a high probability of one the PSAP uses, the double conversion has a high probability of
introducing an error. introducing an error.
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, be delivered to the end system by some protocol or measured
measured by a third party and inserted into the call signaling. by a third party, and be 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 some that are partially contradictory. This is
likely if the location information is determined both by the end particularly likely if the location information is determined both by
system and a third party. Although self measured location (e.g., the end system and a third party. Although self-measured location
GNSS) is attractive, location information provided by the access (e.g., GNSS) is attractive, location information provided by the
network could be much more accurate, and more reliable in some access 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 is more than one location determination
determinations for a given endpoint. In emergency calling, the PSAP for a given endpoint. In emergency calling, the PSAP is the least
is the least likely to be able to appropriately choose which location likely to be able to appropriately choose which location to use when
to use when multiple conflicting locations are presented to it. multiple conflicting locations are presented to it. While all
While all available locations can be sent towards the PSAP, the order available locations can be sent towards the PSAP, the order of the
of the locations should be the sender's best attempt to guide the locations should be the sender's best attempt to guide the recipient
recipient of which one(s) to use. 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 routinely provided by end users is almost always Location information routinely provided by end users is almost always
less reliable than measured or wire database information, as users less reliable than measured or wire database information, as users
may mistype location information or may enter civic address may mistype location information or may enter civic address
information that does not correspond to a recognized (i.e., valid, information that does not correspond to a recognized (i.e., valid,
see Section Section 6.10) address. Users can forget to change the see Section 6.10) address. Users can forget to change the data when
data when the location of a device changes. the location of a device changes.
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. However, this is declaring themselves to be somewhere they are not. However, this is
generally not a problem in practice. Commonly, if an emergency generally not a problem in practice. Commonly, if an emergency
caller insists that he is at a location different from what any caller insists that he is at a location different from what any
automatic location determination system reports he is, responders automatic location determination system reports he is, responders
will always be sent to the user's self-declared location. will always be sent to the user's self-declared location.
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 Presence
Location Object [RFC4119] extended by [RFC5139] and [RFC5491] permits Information Data Format (PIDF) Location Object [RFC4119], extended by
interior building/floor/room and even finer specification of location [RFC5139] and [RFC5491], permits interior building, floor, and room
within a street address. When possible, interior location should be and even finer specification of location within a street address.
supported. When possible, interior location should be 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 USA fire brigade 650 square meters. This value is derived from US 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.
The civic location of an IEEE 802.16 base station may be of little The civic location of an IEEE 802.16 base station may be of little
use to emergency personnel, since the endpoint could be several use to emergency personnel, since the endpoint could be several
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 Global Navigation Global Positioning System (GPS) and similar Global Navigation
Satellite Systems (e.g., GLONAS and Galileo) receivers may be Satellite Systems (e.g., GLONAS and Galileo) receivers may be
embedded directly in the end device. GNSS produces relatively high embedded directly in the end device. GNSS produces relatively high
precision location fixes in open-sky conditions, but the technology precision location fixes in open-sky conditions, but the technology
still faces several challenges in terms of performance (time-to-fix still faces several challenges in terms of performance (time-to-fix
and time-to-first-fix), as well as obtaining successful location and time-to-first-fix), as well as obtaining successful location
fixes within shielded structures, or underground. It also requires fixes within shielded structures, or underground. It also requires
all devices to be equipped with the appropriate GNSS capability. all devices to be equipped with the appropriate GNSS capability.
Many mobile devices require using some kind of "assist", that may 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 operated by the access network (A-GPS) or by a government (WAAS). A
device may be able to use multiple sources of assist data. device may be able to use multiple sources of assist data.
GNSS systems may be always enabled and thus location will always be The GNSS satellites are active continuously; thus, location will
available accurately immediately (assuming the device can "see" always be available as long as the device can "see" enough
enough satellites). Mobile devices may not be able to sustain the satellites. However, mobile devices may not be able to afford 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. Typically, this takes tens of seconds,
too long to wait to be able to route an emergency call. For this far 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 tower/sector).
6.2.4. Network measured location information 6.2.4. Network Measured Location Information
The access network may locate end devices. Techniques include
various forms of triangulation. Elements in the network
infrastructure triangulate end systems based on signal strength,
angle of arrival or time of arrival. Common mechanisms deployed
include the following:
The access network may locate end devices. Techniques various forms
of triangulation. Elements in the network infrastructure triangulate
end systems based on signal strength, angle of arrival or time of
arrival. Common mechanisms deployed include:
o Time Difference Of Arrival - TDOA o Time Difference Of Arrival - TDOA
o Uplink Time Difference Of Arrival - U-TDOA o Uplink Time Difference Of Arrival - U-TDOA
o Angle of Arrival - AOA o Angle of Arrival - AOA
o RF fingerprinting
o Radio Frequency (RF) fingerprinting
o Advanced Forward Link Trilateration - AFLT o Advanced Forward Link Trilateration - AFLT
o 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.
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
identifier the access network could provide to a LIS to determine the identifier the access network could provide to a LIS to determine the
location of the device. Systems designers are discouraged from location of the device. System designers are discouraged from
relying on proxies to add location. The technique may be useful in relying on proxies to add location. The technique may be useful in
some limited circumstances as devices are upgraded to meet the some limited circumstances as devices are upgraded to meet the
requirements of this document, or where relationships between access requirements of this document, or where relationships between access
networks and calling networks are feasible and can be relied upon to networks and calling networks are feasible and can be relied upon to
get accurate location. get accurate location.
Proxy insertion of location complicates dial string recognition. As Proxy insertion of location complicates dial-string recognition. As
noted in Section 6, local dial strings depend on the location of the noted in Section 6, local dial strings depend on the location of the
caller. If the device does not know its own location, it cannot use caller. If the device does not know its own location, it cannot use
the LoST service to learn the local emergency dial strings. The the LoST service to learn the local emergency dial strings. The
calling network must provide another way for the device to learn the calling network must provide another way for the device to learn the
local dial string, and update it when the user moves to a location local dial string, and update it when the user moves to a location
where the dial string(s) change, or do the dial string determination where the dial string(s) change, or do the dial-string determination
itself. itself.
6.4. Location and references to location 6.4. Location and References to Location
Location information may be expressed as the actual civic or Location information may be expressed as the actual civic or
geospatial value but can be transmitted as by value (wholly contained geospatial value but can be transmitted as by value, i.e., wholly
within the signaling message) or by reference (i.e., as a URI contained within the signaling message, or by reference, i.e., as a
pointing to the value residing on a remote node waiting to be URI pointing to the value residing on a remote node waiting to be
dereferenced). dereferenced.
When location is transmitted by value, the location information is When location is transmitted by value, the location information is
available to entity in the call path. On the other hand, location available to entities in the call path. On the other hand, location
objects can be large, and only represent a single snapshot of the objects can be large and only represent a single snapshot of the
device's location. Location references are small and can be used to device's location. Location references are small and can be used to
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 if the dereference transaction were
to fail.
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 [RFC6225]
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
or by reference, via a layer 7 protocol. The query typically uses HELD [RFC5985] can deliver a civic or geo location object, by
the IP address of the requester as an identifier and returns the value or by reference, via a Layer 7 protocol. The query
location value or reference associated with that identifier. HELD typically uses the IP address of the requester as an identifier
is typically carried in HTTP. and returns the location value or reference associated with that
Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device identifier. HELD is typically carried in HTTP.
extensions [LLDP-MED] can be used to deliver location information
directly from the Layer 2 network infrastructure, and also Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device
supports both civic and geo formats identical in format to DHCP (MED) extensions [LLDP-MED] can be used to deliver location
methods. information directly from the Layer 2 network infrastructure and
also supports both civic and geo formats identical in format to
DHCP 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, location
incompatibilities would ensue unless every network supported every determination could easily fail unless every network supported every
protocol, or alternatively, every device supported every protocol. protocol, or alternatively, every device supported every protocol.
For this reason, a mandatory-to-implement list of LCPs is established For this reason, a mandatory-to-implement list of LCPs is established
in [I-D.ietf-ecrit-phonebcp]. Every endpoint that could be used to in [PHONEBCP]. Every endpoint that could be used to place emergency
place emergency calls must implement all of the protocols on the calls must implement all of the protocols on the list. Every access
list. Every access network must deploy at least one of them. Since network must deploy at least one of them. Since it is the
it is the variability of the networks that prevent a single protocol variability of the networks that prevent a single protocol from being
from being acceptable, it must be the endpoints that implement all of acceptable, it must be the endpoints that implement all of them, and
them, and to accommodate a wide range of devices, networks must to accommodate a wide range of devices, networks must deploy at least
deploy at least one of them. one of them.
Often, network operators and device designers believe that they have Often, network operators and device designers believe that they have
a simpler environment and some other network specific mechanism can a simpler environment and some other network specific mechanism can
be used to provide location. Unfortunately, it is very rare to be used to provide location. Unfortunately, it is very rare to
actually be able to limit the range of devices that may be connected actually be able to limit the range of devices that may be connected
to a network. For example, existing mobile networks are being used to a network. For example, existing mobile networks are being used
to support routers and LANs behind a wireless data network WAN to support routers and LANs behind the WAN connection of a wireless
connection, with Ethernet connected phones connected to that. It is data network, with Ethernet connected phones connected to that. It
possible that the access network could support a protocol not on the is possible that the access network could support a protocol not on
list, and require every handset in that network to use that protocol the list and require every handset in that network to use that
for emergency calls. However, the Ethernet-connected phone won't be protocol for emergency calls. However, the Ethernet-connected phone
able to acquire location, and the user of the phone is unlikely to be will not be able to acquire location, and the user of the phone is
dissuaded from placing an emergency call on that phone. The unlikely to be dissuaded from placing an emergency call on that
widespread availability of gateways, routers and other network- phone. The widespread availability of gateways, routers, and other
broadening devices means that indirectly connected endpoints are network-broadening devices means that indirectly connected endpoints
possible on nearly every network. Network operators and vendors are are possible on nearly every network. Network operators and vendors
cautioned that shortcuts to meeting this requirement are seldom are cautioned that shortcuts to meeting this requirement are seldom
successful. successful.
Location for non-mobile devices is normally expected to be acquired Location for non-mobile devices is normally expected to be acquired
at network attachment time and retained by the device. It should be at network attachment time and retained by the device. It should be
refreshed when the cached value expires. For example, if DHCP is the refreshed when the cached value expires. For example, if DHCP is the
acquisition protocol, refresh of location may occur when the IP acquisition protocol, refresh of location may occur when the IP
address lease is renewed. At the time of an emergency call, the address lease is renewed. At the time of an emergency call, the
location should be refreshed, with the retained location used if the location should be refreshed, with the retained location used if the
location acquisition does not immediately return a value. Mobile location acquisition does not immediately return a value. Mobile
devices may determine location at network attachment time and devices may determine location at network attachment time and
periodically thereafter as a backup in case location determination at periodically thereafter as a backup in case location determination at
the time of call does not work. Mobile device location may be the time of call does not work. Mobile device location may be
refreshed when a TTL expires or the device moves beyond some refreshed when a Time-to-Live (TTL) expires or the device moves
boundaries (as provided by [RFC5222]). Normally, mobile devices will beyond some boundaries (as provided by [RFC5222]). Normally, mobile
acquire its location at call time for use in an emergency call devices will acquire their location at call time for use in an
routing. See Section 6.8 for a further discussion on location emergency call routing. See Section 6.8 for a further discussion on
updates for dispatch location. location updates for dispatch location.
There are many examples of endpoints which are user agent There are many examples of endpoints that are user agent applications
applications running on a more general purpose device, such as a running on a more general purpose device, such as a personal
personal computer. On some systems, layer 2 protocols like DHCP and computer. On some systems, Layer 2 protocols like DHCP and LLDP may
LLDP may not be directly accessible to applications. It is desirable not be directly accessible to applications. It is desirable for an
for an operating system to have an API which provides the location of operating system to have an API that provides the location of the
the device for use by any application, especially those supporting device for use by any application, especially those supporting
emergency calls. emergency calls.
6.6. When location should be configured 6.6. When Location Should Be Configured
Devices should get routing location immediately after obtaining local Devices should get routing location immediately after obtaining local
network configuration information. The presence of NAT and VPN network configuration information. The presence of NAT and VPN
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, but location can be configured before the VPN is bypass is possible, but location can be configured before the VPN is
established. Of course, LCPs that use layer 2 mechanisms (DHCP established. Of course, LCPs that use Layer 2 mechanisms (DHCP
Location options and LLDP-MED) are usually immune from such problems location options and LLDP-MED) are usually immune from such problems
because they do not use the IP address as the identifier for the because they do not use the IP address as the identifier for the
device seeking location. 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. For networks with mobile devices, 60 * 60) = 12 queries per second. For networks with mobile devices,
much higher refresh rates could be expected. 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.
There is a tradeoff between the time it takes to get a routing There is a trade-off between the time it takes to get a routing
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 (location) fix"), it is preferable to
seconds, the current nominal time for a quick fix, is a very long wait. Three seconds, the current nominal time for a quick fix, is a
time add to post dial delay. very long time add to post-dial delay. NENA recommends [NENAi3TRD]
that IP-based systems complete calls in two seconds from last dial
NENA recommends [NENAi3TRD] that IP based systems complete calls in press to ring at the PSAP.
two seconds from last dial press to ring at PSAP.
6.7. Conveying location 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 [RFC6442]. Since
[I-D.ietf-sip-location-conveyance]. Since the form of the location the form of the location information obtained by the acquisition
information obtained by the acquisition protocol may not be the same protocol may not be the same as the conveyance protocol uses (PIDF-LO
as the conveyance protocol uses (PIDF-LO [RFC4119]), mapping by the [RFC4119]), mapping by the endpoint from the LCP form to PIDF may be
endpoint from the LCP form to PIDF may be required. required.
6.8. Location updates 6.8. Location Updates
As discussed above, it may take some time for some measurement As discussed above, it may take some time for some measurement
mechanisms to get a location accurate enough for dispatch, and a mechanisms to get a location accurate enough for dispatch, and a
routing location with less accuracy may be provided to get the call routing location with less accuracy may be provided to get the call
established quickly. The PSAP needs the dispatch location before it established quickly. The PSAP needs the dispatch location before it
sends the call to the responder. This requires an update of the sends the call to the responder. This requires an update of the
location. In addition, the location of some mobile callers, e.g., in location. In addition, the location of some mobile callers, e.g., in
a vehicle or aircraft, can change significantly during the emergency a vehicle or aircraft, can change significantly during the emergency
call. call.
A PSAP has no way to request an update of a location provided by A PSAP has no way to request an update of a location provided by
value. If the UAC gets new location, it must signal the PSAP using a value. If the User Agent Client (UAC) gets new location information,
new INVITE or an UPDATE transaction with a new Geolocation header to it must signal the PSAP using a new INVITE or an UPDATE transaction
supply the new location. with a new Geolocation header field to supply the new location.
With the wide variation in determination mechanisms, the PSAP does With the wide variation in determination mechanisms, the PSAP does
not know when accurate location may be available. The preferred not know when accurate location may be available. The preferred
mechanism is that the LIS notifies the PSAP when an accurate location mechanism is that the LIS notifies the PSAP when an accurate location
is available rather than requiring a poll operation from the PSAP to is available rather than requiring a poll operation from the PSAP to
the LIS. The SIP Presence subscription [RFC3856] provides a suitable the LIS. The SIP Presence subscription [RFC3856] provides a suitable
mechanism. mechanism.
When using a HELD dereference, the PSAP must specify the value When using a HELD dereference, the PSAP must specify the value
"emergencyDispatch" for the ResponseTime parameter. Since typically "emergencyDispatch" for the ResponseTime parameter. Since,
the LIS is local relative to the PSAP, the LIS can be aware of the typically, the LIS is local relative to the PSAP, the LIS can be
update requirements of the PSAP aware of the update requirements of the PSAP.
6.9. Multiple locations 6.9. Multiple Locations
Getting multiple locations all purported to describe the location of Getting multiple locations all purported to describe the location of
the caller is confusing to all, and should be avoided. Handling the caller is confusing to all, and should be avoided. Handling
multiple locations at the point where a PIDF is created is discussed multiple locations at the point where a PIDF is created is discussed
in [RFC5491]. Conflicting location information is particularly in [RFC5491]. Conflicting location information is particularly
harmful if different routes (PSAPs) result from LoST queries for the harmful if different routes (PSAPs) result from LoST queries for the
multiple locations. When they occur anyway, the general guidance is multiple locations. When they occur anyway, the general guidance is
that the entity earliest in the chain generally has more knowledge that the entity earliest in the chain generally has more knowledge
than later elements to make an intelligent decision, especially about than later elements to make an intelligent decision, especially about
which location will be used for routing. It is permissible to send which location will be used for routing. It is permissible to send
multiple locations towards the PSAP, but the element that chooses the multiple locations towards the PSAP, but the element that chooses the
route must select exactly one location to use with LoST. route must select exactly one location to use with LoST.
Guidelines for dealing with multiple locations are also given in Guidelines for dealing with multiple locations are also given in
[RFC5222]. If a UA gets multiple locations, it must choose the one [RFC5222]. If a UA gets multiple locations, it must choose the one
to use for routing, but it may send all of the locations it has in to use for routing, but it may send all of the locations it has in
the signaling. If a proxy is inserting location and has multiple the signaling. If a proxy is inserting location and has multiple
locations, it must choose exactly one to use for routing, marking it locations, it must choose exactly one to use for routing and send it
as such (per [I-D.ietf-sip-location-conveyance], and send it as well as well as any other locations it has that correspond to this UA.
as any others it has.
The UA or proxy should have the ability to understand how and from The UA or proxy should have the ability to understand how and from
whom it learned its location, and should include this information in whom it learned its location, and should include this information in
the location objects that are sent to the PSAP. That labeling the location objects that are sent to the PSAP. That labeling
provides the call-taker with information to make decisions upon, as provides the call taker with information to make decisions upon, as
well as guidance for what to ask the caller and what to tell the well as guidance for, what to ask the caller and what to tell the
responders. responders.
Endpoints or proxies may be tempted to send multiple versions of the Endpoints or proxies may be tempted to send multiple versions of the
same location. For example a database may be used to "geocode" or same location. For example a database may be used to "geocode" or
"reverse geocode", that is, convert from civic to geo or vice versa. "reverse geocode", that is, convert from civic to geo or vice versa.
It is very problematic to use derived locations in emergency calls. It is very problematic to use derived locations in emergency calls.
The PSAP and the responders have very accurate databases which they The PSAP and the responders have very accurate databases that they
use to convert, most commonly from a reported geo to a civic suitable use to convert most commonly from a reported geo to a civic suitable
for dispatching responders. If one database is used to convert from, for dispatching responders. If one database is used to convert from,
say, civic to geo, and another converts from geo to civic, errors say, civic to geo, and another converts from geo to civic, errors
will often occur where the databases are slightly different. "Off by will often occur where the databases are slightly different. Errors
one" errors are serious when responders go to the wrong location. of even a single house number are serious as it may lead first
Derived locations should be marked with a "derived" method token responders to the wrong building. Derived locations should be marked
[RFC4119]. If an entity gets a location which has a measured or with a "derived" method token [RFC4119]. If an entity gets a
other original method, and another with a derived method, it must use location that has a measured or other original method, and another
the original value for the emergency call. with a derived method, it must use the original value for the
emergency call.
6.10. Location validation 6.10. Location Validation
Validation in this context means both that there is a mapping from Validation, in this context, means that there is a mapping from the
the address to a PSAP and that the PSAP understands how to direct 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 whether an address is valid can be difficult. There are,
are, for example, many cases of two names for the same street, or two 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 of America, the Master validation. For example, in the United States of America, the Master
Street Address Guide (MSAG) records all valid street addresses and is Street Address Guide (MSAG) records all valid street addresses and is
used 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 that 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 should not be used for an When validation fails, the location given should not be used for an
emergency call, unless no other valid location is available. Bad emergency call, unless no other valid location is available. Bad
location is better than no location. If validation is completed when location is better than no location. If validation is completed when
location is first loaded into a LIS, any problems can be found and location is first loaded into a LIS, any problems can be found and
fixed before devices could get the bad location. Failure of fixed before devices could get the bad location. Failure of
validation arises because an error is made in determining the validation arises because an error is made in determining the
location, although occasionally the LoST database is not up to date location, although occasionally the LoST database is not up to date
or has faulty information. In either case, the problem must be or has faulty information. In either case, the problem must be
identified and should be corrected before using the location. 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
precise than the CMTS. Default locations must be marked as such so precise than the CMTS. Default locations must be marked as such so
that the PSAP knows that the location is not accurate. that the PSAP knows that the location is not accurate.
6.12. Location format conversion 6.12. Location Format Conversion
The endpoint is responsible for mapping any form of location it The endpoint is responsible for mapping any form of location it
receives from an LCP into PIDF-LO form if the LCP did not directly receives from an LCP into PIDF-LO form if the LCP did not directly
return a PIDF-LO. return a PIDF-LO.
7. LIS and LoST discovery 7. LIS and LoST Discovery
Endpoints must be able to discover a LIS if the HELD protocol is Endpoints must be able to discover a LIS, if the HELD protocol is
used, and a LoST server. DHCP options are defined for this purpose, used and a LoST server. DHCP options are defined for this purpose,
namely [RFC5986] and [RFC5223]. namely [RFC5986] and [RFC5223].
Until such DHCP records are widely available, it may be necessary for Until such DHCP records are widely available, it may be necessary for
the service provider to provision a LoST server address in the the service provider to provision a LoST server address in the
device. The endpoint can also do a DNS SRV query to find a LoST device. The endpoint can also do a DNS SRV query to find a LoST
server. In any environment, more than one of these mechanisms may server. In any environment, more than one of these mechanisms may
yield a LoST server, and they may be different. The recommended yield a LoST server, and they may be different. The recommended
priority is DHCP first, provisioned value second, and DNS SRV query priority is DHCP first, provisioned value second, and DNS SRV query
in the SIP domain third. in the SIP domain third.
8. Routing the call to the PSAP 8. Routing the Call to the PSAP
Emergency calls are routed based on one or more of the following Emergency calls are routed based on one or more of the following
criteria expressed in the call setup request (INVITE): criteria expressed in the call setup request (INVITE):
Location: Since each PSAP serves a limited geographic region and Location: Since each PSAP serves a limited geographic region and
transferring existing calls delays the emergency response, calls transferring existing calls delays the emergency response, calls
need to be routed to the most appropriate PSAP. In this need to be routed to the most appropriate PSAP. In this
architecture, emergency call setup requests contain location architecture, emergency call setup requests contain location
information, expressed in civic or geospatial coordinates, that information, expressed in civic or geospatial coordinates, that
allows such routing. allows such routing.
Type of emergency service: In some jurisdictions, emergency calls Type of emergency service: In some jurisdictions, emergency calls
for specific emergency services such as fire, police, ambulance or for specific emergency services such as fire, police, ambulance,
mountain rescue are directed to just those emergency-specific or mountain rescue are directed to just those emergency-specific
PSAPs. This mechanism is supported by marking emergency calls PSAPs. This mechanism is supported by marking emergency calls
with the proper service identifier [RFC5031]. Even in single with the proper service identifier [RFC5031]. Even in single-
number jurisdictions, not all services are dispatched by PSAPs and number jurisdictions, not all services are dispatched by PSAPs and
may need alternate URNs to route calls to the appropriate call may need alternate URNs to route calls to the appropriate call
center. center.
Media capabilities of caller: In some cases, emergency call centers Media capabilities of caller: In some cases, emergency call centers
for specific caller media preferences, such as typed text or for specific caller media preferences, such as typed text or
video, are separate from PSAPs serving voice calls. ESRPs are video, are separate from PSAPs serving voice calls. ESRPs are
expected to be able to provide routing based on media. Also, even expected to be able to provide routing based on media. Also, even
if media capability does not affect the selection of the PSAP, if media capability does not affect the selection of the PSAP,
there may be call takers within the PSAP that are specifically there may be call takers within the PSAP that are specifically
trained, e.g., in interactive text or sign language trained, e.g., in real-time text or sign language communications,
communications, where routing within the PSAP based on the media where routing within the PSAP based on the media offer would be
offer would be provided. provided.
Providing a URL to route emergency calls by location and by type of Providing a URL to route emergency calls by location and by type of
service is the primary function LoST [RFC5222] provides. LoST service is the primary function LoST [RFC5222] provides. LoST
accepts a query with location (by-value) in either civic or geo form, accepts a query with location (by-value) in either civic or geo form,
plus a service identifier, and returns a URI (or set of URIs) to plus a service identifier, and returns a URI (or set of URIs) to
route the call to. Normal SIP [RFC3261] routing functions are used which to route the call. Normal SIP [RFC3261] routing functions are
to resolve the URI to a next hop destination. used to resolve the URI to a next-hop destination.
The endpoint can complete the LoST mapping from its location at boot The endpoint can complete the LoST mapping from its location at boot
time, and periodically thereafter. It should attempt to obtain a time, and periodically thereafter. It should attempt to obtain a
"fresh" location, and from that a current mapping when it places an "fresh" location, and from that a current mapping when it places an
emergency call. If accessing either its location acquisition or emergency call. If accessing either its location acquisition or its
mapping functions fail, it should use its cached value. The call mapping functions fail, it should use its cached value. The call
would follow its normal outbound call processing. would follow its normal outbound call processing.
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 access point they are connected to. obtain civic location from the access point to which they are
connected.
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
difficult. It is often difficult for the calling network to difficult. It is often difficult for the calling network to
accurately determine the endpoint's location. The endpoint may have accurately determine the endpoint's location. The endpoint may have
its own location, but would not normally include it on the call its own location, but would not normally include it on the call
signaling unless it knew it was an emergency call. There is no signaling unless it knew it was an emergency call. There is no
mechanism provided in [I-D.ietf-sip-location-conveyance] for a proxy mechanism provided in [RFC6442] for a proxy to request the endpoint
to request the endpoint supply its location, because that would open supply its location, because that would open the endpoint to an
the endpoint to an attack by any proxy on the path to get it to attack by any proxy on the path to get it to reveal location. The
reveal location. The proxy can attempt to redirect a call to the proxy can attempt to redirect a call to the service URN, which, if
service URN which, if the device recognizes the significance, would the device recognizes the significance, would include location in the
include location in the redirected call from the device. All redirected call from the device. All network elements should detect
networks elements should detect emergency calls and supply default emergency calls and supply default location and/or routing if it is
location and/or routing if it is not already present. not already present.
The LoST server would normally be provided by the local emergency The LoST server would normally be provided by the local emergency
authorities, although the access network or calling network might run authorities, although the access network or calling network might run
its own server using data provided by the emergency authorities. its own server using data provided by the emergency authorities.
Some enterprises may have local responders and call centers, and Some enterprises may have local responders and call centers, and
could operate their own LoST server, providing URIs to in-house could operate their own LoST server, providing URIs to in-house
"PSAPs". Local regulations might limit the ability of enterprises to "PSAPs". Local regulations might limit the ability of enterprises to
direct emergency calls to in-house services. direct emergency calls to in-house services.
The ESRP, which is a normal SIP proxy server in the signaling path of The ESRP, which is a normal SIP proxy server in the signaling path of
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 route onward 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 [RFC4103] should be handling of audio, video, and real-time text [RFC4103] should be
applied. As discussed above, location is carried in all emergency applied. As discussed above, location is carried in all emergency
calls in the call signaling. Since emergency calls carry privacy- calls in the call signaling. Since emergency calls carry privacy-
sensitive information, they are subject to the requirements for sensitive information, they are subject to the requirements for
geospatial protocols [RFC3693]. In particular, signaling information geospatial protocols [RFC3693]. In particular, signaling information
should be carried in TLS, i.e., in 'sips' mode with a ciphersuite should be carried in Transport Layer Security (TLS), i.e., in 'sips'
which includes strong encryption (e.g., AES). There are exceptions mode with a ciphersuite that includes strong encryption, such as AES.
in [RFC3693] for emergency calls. For example, local policy may There are exceptions in [RFC3693] for emergency calls. For example,
dictate that location is sent with an emergency call even if the local policy may dictate that location is sent with an emergency call
user's policy would otherwise prohibit that. Nevertheless, even if the user's policy would otherwise prohibit that.
protection from eavesdropping of location by encryption should be Nevertheless, protection from eavesdropping of location by encryption
provided. should be 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.
[RFC5630] recommends that to achieve this effect the target specifies [RFC5630] recommends that to achieve this effect, the target specify
a sip URI, but use TLS on the outbound connection. An element that a sip URI, but use TLS on the outbound connection. An element that
receives a request over a TLS connection should attempt to create a receives a request over a TLS connection should attempt to create a
TLS connection to the next hop. 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 [RFC5626]. In elements to minimize the time needed to establish them [RFC5626]. In
other circumstances, use of session resumption [RFC5077] is other circumstances, use of session resumption [RFC5077] is
recommended. IPsec [RFC4301] is an acceptable alternative to TLS recommended. IPsec [RFC4301] is an acceptable alternative to TLS
when used with an equivalent crypto suite. when used with an equivalent crypto 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 Secure/Multipurpose
signaling [RFC3261] cannot be used because they obscure location. Internet Mail Extensions (S/MIME) encryption of SIP signaling
Only hop-by-hop mechanisms such as TLS should be used. Implementing [RFC3261] cannot be used because they obscure location. Only hop-by-
location conveyance in SIP mandates inclusion of TLS support. hop mechanisms such as TLS should be used. Implementing 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
SIP UAs that recognize local dial strings, insert location, and SIP UAs that recognize local dial strings, insert location, and
perform emergency call routing will create SIP INVITE messages with perform emergency call routing will create SIP INVITE messages with
the Service URN in the Request URI, the LoST-determined URI for the the service URN in the Request-URI, the LoST-determined URI for the
PSAP in a Route header, and the location in a Geolocation header. PSAP in a Route header, and the location in a Geolocation header.
The INVITE request must also have appropriate call back identifiers The INVITE request must also have appropriate callback identifiers
(in Contact and From headers). To enable media sensitive routing, (in Contact and From headers). To enable media-sensitive routing,
the call should include an SDP offer. the call should include a Session Description Protocol (SDP) offer
[RFC3264].
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
At least one SIP proxy server in the path of an emergency call must At least one SIP proxy server in the path of an emergency call must
be able to assist UAs that are unable to provide any of the location be able to assist UAs that are unable to provide any of the location-
based routing steps and recognition of dial strings. A Proxy can based routing steps and recognition of dial strings. A proxy can
recognize the lack of location awareness by the lack of a Geolocation recognize the lack of location awareness by the lack of a Geolocation
header. They can recognize the lack of dial string recognition by header. It can recognize the lack of dial-string recognition by the
the presence of the local emergency call dial string in the From presence of the local emergency call dial string in the From header
header without the service URN being present. They should obtain the without the service URN being present. They should obtain the
location of the endpoint if possible, and use a default location if location of the endpoint if possible, and use a default location if
they can not, inserting it in a Geolocation header. They should they cannot, inserting it in a Geolocation header. They should query
query LoST with the location and put the resulting URI in a Route, LoST with the location and put the resulting URI in a route, with the
with the appropriate service URN in the Request URI. In any event, appropriate service URN in the Request-URI. In any event, they are
they are also expected to provide information for the caller using also expected to provide information for the caller using SIP
SIP Identity or P-Asserted-Identity. It is often a regulatory matter Identity or P-Asserted-Identity. It is often a regulatory matter
whether calls normally marked as anonymous are passed as anonymous whether calls normally marked as anonymous are passed as anonymous
when they are emergency calls. Proxies must conform to the local when they are emergency calls. Proxies must conform to the local
regulation or practice. 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 (AOR). In SIP systems, the caller must
include a Contact header field in an emergency call containing a include a Contact header field in an emergency call containing a
globally routable URI, possibly a GRUU [RFC5627]. This identifier globally routable URI, possibly a Globally Routable User Agent URI
would be used to initiate call-backs immediately by the call-taker (GRUU) [RFC5627]. This identifier would be used to initiate
if, for example, the call is prematurely dropped. A concern arises callbacks immediately by the call taker if, for example, the call is
with B2BUAs that manipulate Contact headers. Such B2BUAs should prematurely dropped. A concern arises with back-to-back user agents
always include a Contact header that routes to the same device. (B2BUAs) that manipulate Contact headers. Such B2BUAs should always
include a Contact header that routes to the same device.
In addition, a call-back identifier as an Address of Record (AoR) In addition, a callback identifier as an address of record (AoR) must
must be included either as the URI in the From header field [RFC3261] be included either as the URI in the From header field [RFC3261]
verified by SIP Identity [RFC4474] or as a network asserted URI verified by SIP Identity [RFC4474] or as a network-asserted URI
[RFC3325]. If the latter, the PSAP will need to establish a suitable [RFC3325]. If the latter, the PSAP will need to establish a suitable
spec(t) with the proxies that send it emergency calls. This 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 callback 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. It is often a regulatory matter whether calls normally marked rules. It is often a regulatory matter whether calls normally marked
as anonymous are passed as anonymous when they are emergency calls. as anonymous are passed as anonymous when they are emergency calls.
Proxies must conform to the local regulation or practice. 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 responders' 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 that 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 user
manipulation during such events may not be desirable. Relay services interface manipulation during such events may not be desirable.
for communication with people with disabilities may be included in Relay services for communication with people with disabilities may be
the call with the bridge. The UA should be prepared to have the call included in the call with the bridge. The UA should be prepared to
transferred (usually attended, but possibly blind) per [RFC5359]. have the call 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. A
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 calling, 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
determine a PSAP call back. A UA may be able to determine a PSAP determine a PSAP call back. A UA may be able to determine a PSAP
call back by examining the domain of incoming calls after placing an call back by examining the domain of incoming calls after placing an
emergency call and comparing that to the domain of the answering PSAP emergency call and comparing that to the domain of the answering PSAP
from the emergency call. Any call from the same domain and directed from the emergency call. Any call from the same domain and directed
to the supplied Contact header or AoR after an emergency call should to the supplied Contact header or AoR after an emergency call should
be accepted as a call-back from the PSAP if it occurs within a be accepted as a callback from the PSAP if it occurs within a
reasonable time after an emergency call was placed. reasonable time after an emergency call was placed.
14. Media 14. Media
PSAPs should always accept RTP media streams [RFC3550]. PSAPs should always accept RTP media streams [RFC3550].
Traditionally, voice has been the only media stream accepted by Traditionally, voice has been the only media stream accepted by
PSAPs. In some countries, text, in the form of Baudot codes or PSAPs. In some countries, text, in the form of Baudot codes or
similar tone encoded signaling within a voiceband is accepted ("TTY") similar tone encoded signaling within a voiceband is accepted ("TTY")
for persons who have hearing disabilities. Using SIP signaling for persons who have hearing disabilities. Using SIP signaling
includes the capability to negotiate media. Normal SIP offer/answer includes the capability to negotiate media. Normal SIP offer/answer
[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 media in emergency calling
Video Relay Service (sign language interpretation) as well as modern is required to support Video Relay Service (sign language
video phones. interpretation) as well as modern video phones.
It is desirable for media to be kept secure by the use of Secure RTP It is desirable for media to be kept secure by the use of Secure RTP
[RFC3711], using DTLS [RFC5764] for keying. [RFC3711], using DTLS [RFC5764] for keying.
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.
[I-D.ietf-ecrit-phonebcp]includes a description of an automated test [PHONEBCP] includes a description of an automated test procedure that
procedure that validates routing, signaling and media path validates routing, signaling, and media path continuity. This test
continuity. This test would be used within some random interval should be used within some random interval after boot time, and
after boot time, and whenever the device location changes enough that whenever the device location changes enough that a new PSAP mapping
a new PSAP mapping is returned by the LoST server. 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 [RFC6280]. [RFC5069] and [RFC6280].
This document suggests that security (TLS or IPsec) be used hop by This document suggests that security (TLS or IPsec) be used hop-by-
hop on a SIP call to protect location information, identity, etc. It hop on a SIP call to protect location information, identity, and
also suggests that if the attempt to create a security association other privacy-sensitive call data. It also suggests that if the
fails, the call be retried without the security. It's more important attempt to create a security association fails, the call be retried
to get an emergency call through than to protect the data; indeed, in without the security. It is more important to get an emergency call
many jurisdictions privacy is explicitly waived when making emergency through than to protect the data; indeed, in many jurisdictions
calls. Placing a call without security may reveal user information, privacy is explicitly waived when making emergency calls. Placing a
including location. The alternative - failing the call if security call without security may reveal user information, including
cannot be established, is considered unacceptable. location. The alternative, failing the call if security cannot be
established, is considered unacceptable.
17. IANA Considerations
This document has no actions for IANA.
18. Acknowledgments 17. Acknowledgments
This draft was created from a This document was created from "Emergency Services for Internet
draft-schulzrinne-sipping-emergency-arch-02 together with sections Telephony Systems" (Schulzrinne, 2004) together with sections from
from draft-polk-newton-ecrit-arch-considerations-02. "Emergency Context Routing of Internet Technologies Architecture
Considerations" (Polk, 2006).
Design Team members participating in this draft creation include Design Team members participating in this document 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.
19. Informative References 18. Informative References
[I-D.ietf-ecrit-phonebcp] [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control",
Rosen, B. and J. Polk, "Best Current Practice for December 2004.
Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-20 (work in progress),
September 2011.
[I-D.ietf-sip-location-conveyance] [LLDP-MED] ANSI/TIA, "Link Layer Discovery Protocol - Media
Polk, J. and B. Rosen, "Location Conveyance for the Endpoint Discovery", TIA Standard, TIA-1057, April 2006.
Session Initiation Protocol",
draft-ietf-sip-location-conveyance-13 (work in progress),
March 2009.
[LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", [NENAi3TRD] NENA, "08-751 v1 - i3 Technical Requirements (Long Term
Dec 2004. Definition)", 2006.
[LLDP-MED] [PHONEBCP] Rosen, B. and J. Polk, "Best Current Practice for
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media Communications Services in support of Emergency
Endpoint Discovery". Calling", Work in Progress, September 2011.
[NENAi3TRD] [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
NENA, "08-751 NENA i3 Technical Requirements for", 2006. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
A., Peterson, J., Sparks, R., Handley, M., and E. with Session Description Protocol (SDP)", RFC 3264,
Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
with Session Description Protocol (SDP)", RFC 3264, Extensions to the Session Initiation Protocol (SIP) for
June 2002. Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema,
Extensions to the Session Initiation Protocol (SIP) for C., and D. Gurle, "Session Initiation Protocol (SIP)
Asserted Identity within Trusted Networks", RFC 3325, Extension for Instant Messaging", RFC 3428,
November 2002. December 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
and D. Gurle, "Session Initiation Protocol (SIP) Extension Method", RFC 3515, April 2003.
for Instant Messaging", RFC 3428, December 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Method", RFC 3515, April 2003. Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
Jacobson, "RTP: A Transport Protocol for Real-Time and Video Conferences with Minimal Control", STD 65,
Applications", STD 64, RFC 3550, July 2003. RFC 3551, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
Video Conferences with Minimal Control", STD 65, RFC 3551, J. Polk, "Geopriv Requirements", RFC 3693,
July 2003. February 2004.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. K. Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3711, March 2004. RFC 3841, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Preferences for the Session Initiation Protocol (SIP)", Initiation Protocol (SIP)", RFC 3856, August 2004.
RFC 3841, August 2004.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Initiation Protocol (SIP)", RFC 3856, August 2004. Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Resource Identifier (URI): Generic Syntax", STD 66, Conversation", RFC 4103, June 2005.
RFC 3986, January 2005.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Conversation", RFC 4103, June 2005. Format", RFC 4119, December 2005.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
Format", RFC 4119, December 2005. Supporting Emergency Telecommunications Service (ETS) in
IP Telephony", RFC 4190, November 2005.
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Supporting Emergency Telecommunications Service (ETS) in Internet Protocol", RFC 4301, December 2005.
IP Telephony", RFC 4190, November 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Internet Protocol", RFC 4301, December 2005. Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP
Authenticated Identity Management in the Session Telephony Device Requirements and Configuration",
Initiation Protocol (SIP)", RFC 4474, August 2006. RFC 4504, May 2006.
[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
Device Requirements and Configuration", RFC 4504, (DHCPv4 and DHCPv6) Option for Civic Addresses
May 2006. Configuration Information", RFC 4776, November 2006.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4967] Rosen, B., "Dial String Parameter for the Session
(DHCPv4 and DHCPv6) Option for Civic Addresses Initiation Protocol Uniform Resource Identifier",
Configuration Information", RFC 4776, November 2006. RFC 4967, July 2007.
[RFC4967] Rosen, B., "Dial String Parameter for the Session [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Initiation Protocol Uniform Resource Identifier", Session Relay Protocol (MSRP)", RFC 4975,
RFC 4967, July 2007. September 2007.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Session Relay Protocol (MSRP)", RFC 4975, September 2007. Emergency Context Resolution with Internet
Technologies", RFC 5012, January 2008.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency Context Resolution with Internet Technologies", Emergency and Other Well-Known Services", RFC 5031,
RFC 5012, January 2008. January 2008.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
Emergency and Other Well-Known Services", RFC 5031, Shanmugam, "Security Threats and Requirements for
January 2008. Emergency Call Marking and Mapping", RFC 5069,
January 2008.
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
Shanmugam, "Security Threats and Requirements for "Transport Layer Security (TLS) Session Resumption
Emergency Call Marking and Mapping", RFC 5069, without Server-Side State", RFC 5077, January 2008.
January 2008.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
"Transport Layer Security (TLS) Session Resumption without Format for Presence Information Data Format Location
Server-Side State", RFC 5077, January 2008. Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Format for Presence Information Data Format Location Tschofenig, "LoST: A Location-to-Service Translation
Object (PIDF-LO)", RFC 5139, February 2008. Protocol", RFC 5222, August 2008.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig,
Tschofenig, "LoST: A Location-to-Service Translation "Discovering Location-to-Service Translation (LoST)
Protocol", RFC 5222, August 2008. Servers Using the Dynamic Host Configuration Protocol
(DHCP)", RFC 5223, August 2008.
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S.,
Location-to-Service Translation (LoST) Servers Using the and K. Summers, "Session Initiation Protocol Service
Dynamic Host Configuration Protocol (DHCP)", RFC 5223, Examples", BCP 144, RFC 5359, October 2008.
August 2008.
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig,
K. Summers, "Session Initiation Protocol Service "GEOPRIV Presence Information Data Format Location
Examples", BCP 144, RFC 5359, October 2008. Object (PIDF-LO) Usage Clarification, Considerations,
and Recommendations", RFC 5491, March 2009.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Presence Information Data Format Location Object (PIDF-LO) Initiated Connections in the Session Initiation Protocol
Usage Clarification, Considerations, and Recommendations", (SIP)", RFC 5626, October 2009.
RFC 5491, March 2009.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable
Initiated Connections in the Session Initiation Protocol User Agent URIs (GRUUs) in the Session Initiation
(SIP)", RFC 5626, October 2009. Protocol (SIP)", RFC 5627, October 2009.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the
Agent URIs (GRUUs) in the Session Initiation Protocol Session Initiation Protocol (SIP)", RFC 5630,
(SIP)", RFC 5627, October 2009. October 2009.
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Initiation Protocol (SIP)", RFC 5630, October 2009. Security (DTLS) Extension to Establish Keys for the
Secure Real-time Transport Protocol (SRTP)", RFC 5764,
May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
Security (DTLS) Extension to Establish Keys for the Secure RFC 5985, September 2010.
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
RFC 5985, September 2010. Location Information Server (LIS)", RFC 5986,
September 2010.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba,
Location Information Server (LIS)", RFC 5986, "Dynamic Host Configuration Protocol Options for
September 2010. Coordinate-Based Location Configuration Information",
RFC 6225, July 2011.
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Host Configuration Protocol Options for Coordinate-Based Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location Configuration Information", RFC 6225, July 2011. Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, July 2011.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location
Tschofenig, H., and H. Schulzrinne, "An Architecture for Conveyance for the Session Initiation Protocol",
Location and Location Privacy in Internet Applications", RFC 6442, December 2011.
BCP 160, RFC 6280, July 2011.
[WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of [WGS84] NIMA, "NGA: DoD World Geodetic System 1984, Its
Defense World Geodetic System 1984, Its Definition and Definition and Relationships with Local Geodetic
Relationships With Local Geodetic Systems, Third Edition", Systems", Technical Report TR8350.2, 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
USA 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
USA 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
USA 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
USA USA
Phone: +1 703 845 0656 Phone: +1 703 845 0656
Email: andy@hxr.us EMail: andy@hxr.us
 End of changes. 249 change blocks. 
712 lines changed or deleted 773 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/