draft-ietf-ecrit-framework-07.txt   draft-ietf-ecrit-framework-08.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track H. Schulzrinne Intended status: Informational H. Schulzrinne
Expires: July 31, 2009 Columbia U. Expires: August 31, 2009 Columbia U.
J. Polk J. Polk
Cisco Systems Cisco Systems
A. Newton A. Newton
TranTech/MediaSolv TranTech/MediaSolv
January 27, 2009 February 27, 2009
Framework for Emergency Calling using Internet Multimedia Framework for Emergency Calling using Internet Multimedia
draft-ietf-ecrit-framework-07 draft-ietf-ecrit-framework-08
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 31, 2009. This Internet-Draft will expire on August 31, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
The IETF has several efforts targeted at standardizing various The IETF has standardized various aspects of placing emergency calls.
aspects of placing emergency calls. This document describes how all This document describes how all of those component parts are used to
of those component parts are used to support emergency calls from support emergency calls from citizens and visitors to authorities.
citizens and visitors to authorities.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of how emergency calls are placed . . . . . . . . . . 8 3. Overview of how emergency calls are placed . . . . . . . . . . 7
4. Which devices and services should support emergency calls . . 11 4. Which devices and services should support emergency calls . . 10
5. Identifying an emergency call . . . . . . . . . . . . . . . . 12 5. Identifying an emergency call . . . . . . . . . . . . . . . . 11
6. Location and its role in an emergency call . . . . . . . . . . 13 6. Location and its role in an emergency call . . . . . . . . . . 12
6.1. Types of location information . . . . . . . . . . . . . . 15 6.1. Types of location information . . . . . . . . . . . . . . 14
6.2. Location determination . . . . . . . . . . . . . . . . . . 16 6.2. Location determination . . . . . . . . . . . . . . . . . . 15
6.2.1. User-entered location information . . . . . . . . . . 17 6.2.1. User-entered location information . . . . . . . . . . 16
6.2.2. Access network "wire database" location information . 17 6.2.2. Access network "wire database" location information . 16
6.2.3. End-system measured location information . . . . . . . 18 6.2.3. End-system measured location information . . . . . . . 17
6.2.4. Network measured location information . . . . . . . . 19 6.2.4. Network measured location information . . . . . . . . 18
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 19 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 18
6.4. Location and references to location . . . . . . . . . . . 20 6.4. Location and references to location . . . . . . . . . . . 19
6.5. End system location configuration . . . . . . . . . . . . 20 6.5. End system location configuration . . . . . . . . . . . . 19
6.6. When location should be configured . . . . . . . . . . . . 22 6.6. When location should be configured . . . . . . . . . . . . 21
6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 22 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 22
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 23 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 22
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 24 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 22
6.10. Location validation . . . . . . . . . . . . . . . . . . . 25 6.10. Location validation . . . . . . . . . . . . . . . . . . . 24
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 25 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 24
6.12. Location format conversion . . . . . . . . . . . . . . . . 26 6.12. Location format conversion . . . . . . . . . . . . . . . . 25
7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 26 7. LIS and LoST discovery . . . . . . . . . . . . . . . . . . . . 25
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 26 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 25
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 28 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 27
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. SIP signaling requirements for User Agents . . . . . . . . 29 9.2. SIP signaling requirements for User Agents . . . . . . . . 28
9.3. SIP signaling requirements for proxy servers . . . . . . . 29 9.3. SIP signaling requirements for proxy servers . . . . . . . 28
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 30 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 29
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 30 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 30
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 30 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 30
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 16. Security Considerations . . . . . . . . . . . . . . . . . . . 31
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
19. Informative References . . . . . . . . . . . . . . . . . . . . 32 19. Informative References . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Terminology 1. Terminology
This document uses terms from [RFC3261] and [RFC5012]. In addition This document uses terms from [RFC3261] and [RFC5012]. In addition
the following terms are used: the following terms are used:
Access network: The access network supplies IP packet service to an Access network: The access network supplies IP packet service to an
endpoint. Examples of access networks include digital subscriber endpoint. Examples of access networks include digital subscriber
lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local
area networks, or cellular data networks. area networks and cellular data networks.
(Emergency) Call taker: An emergency call taker answers an emergency (Emergency) Call taker: An emergency call taker answers an emergency
call at the PSAP. call at the PSAP.
Confidence: Confidence is an estimate indicating how sure the Confidence: Confidence is an estimate indicating how sure the
measuring system is that the actual location of the person is measuring system is that the actual location of the endpoint is
within the bounds defined by the uncertainty value, expressed as a within the bounds defined by the uncertainty value, expressed as a
percentage. For example, a value of 90% indicates that the actual percentage. For example, a value of 90% indicates that the actual
location is within the uncertainty nine times out of ten. location is within the uncertainty nine times out of ten.
Dispatch Location: The dispatch location is the location used for Dispatch Location: The dispatch location is the location used for
dispatching responders to the person in need of assistance. The dispatching responders to the person in need of assistance. The
dispatch location must be sufficiently precise to easily locate dispatch location must be sufficiently precise to easily locate
the caller; it typically needs to be more accurate than the the caller; it typically needs to be more accurate than the
routing location. routing location.
Emergency services routing proxy (ESRP): An emergency services Emergency services routing proxy (ESRP): An emergency services
routing proxy provides routing services for a group of PSAPs. routing proxy provides routing services for a group of PSAPs.
Location configuration: During location configuration, an endpoint Location configuration: During location configuration, an endpoint
learns its physical location. learns its physical location.
Location Configuration Protocol (LCP): A protocol used by an
endpoint to learn its location.
Location conveyance: Location conveyance delivers location Location conveyance: Location conveyance delivers location
information to another element. information to another element.
Location determination: Location determination finds where an Location determination: Location determination finds where an
endpoint is physically located. For example, the endpoint may endpoint is physically located. For example, the endpoint may
contain a GPS receiver used to measure its own location or the contain a GPS receiver used to measure its own location or the
location may be determined by a network administrator using a location may be determined by a network administrator using a
wiremap database. wiremap database.
Location Information Server (LIS): A Location Information Server Location Information Server (LIS): A Location Information Server
stores location information for retrieval by an authorized entity. stores location information for retrieval by an authorized entity.
Mobile device: A mobile device is a user agent that may change its Mobile device: A mobile device is a user agent that may change its
physical location and possibly its network attachment point during physical location and possibly its network attachment point during
an emergency call. an emergency call.
NENA (National Emergency Number Association): The National Emergency NENA (National Emergency Number Association): The National Emergency
Number Association is an organization of professionals to "foster Number Association is an organization of professionals to "foster
the technological advancement, availability and implementation of the technological advancement, availability and implementation of
a universal emergency telephone number system." It develops a universal emergency telephone number system." It develops
emergency calling specifications and procedures. emergency calling specifications and procedures.
Nomadic device (user): A nomadic user agent is connected to the Nomadic device (user): A nomadic user agent is connected to the
network temporarily, for relatively short durations, but does not network temporarily, for relatively short durations, but does not
move significantly during the lifetime of a network connection or move significantly during the during the emergency call. Examples
during the emergency call. Examples include a laptop using an include a laptop using an IEEE 802.11 hotspot or a desk IP phone
IEEE 802.11 hotspot or a desk IP phone that is moved from one that is moved occasionally from one cubicle to another.
cubicle to another.
Physical Location: A physical location describes where a person or Physical location: A physical location describes where a person or
device is located in physical space, described by a coordinate device is located in physical space, described by a coordinate
system. It is distinguished from the network location, described system. It is distinguished from the network location, described
by a network address. by a network address.
Routing Location: The routing location of a device is used for RoutinglLocation: The routing location of a device is used for
routing an emergency call and may not be as precise as the routing an emergency call and may not be as precise as the
Dispatch Location. Dispatch Location.
Stationary device: An stationary device is not mobile and is Stationary device: An stationary device is not mobile and is
connected to the network at a fixed, long-term-stable physical connected to the network at a fixed, long-term-stable physical
location. Examples include home PCs or pay phones. location. Examples include home PCs or pay phones.
Uncertainty: Uncertainty is an estimate, expressed in a unit of Uncertainty: Uncertainty is an estimate, expressed in a unit of
length, indicating the diameter of a circle that contains the length, indicating the diameter of a circle that contains the
device with the probability indicated by the confidence value. endpoint with the probability indicated by the confidence value.
2. Introduction 2. 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 is an accepted practice in most of the world. a telephone or mobile phone is an accepted practice in many parts of
As communications devices increasingly utilize the Internet to the world. As communications devices increasingly utilize the
interconnect and communicate, users will continue to expect to use Internet to interconnect and communicate, users will expect to use
such devices to request help, regardless of whether or not they such devices to request help. This document describes establishment
communicate using IP. This document describes establishment of a of a communications session by a user to a "Public Safety Answering
communications session by a user to a "Public Safety Answering Point" Point" (PSAP), that is, a call center established by response
(PSAP) that is a call center established by response agencies to agencies to accept emergency calls. Such citizen/
accept emergency calls. Such citizen/visitor-to-authority calls can visitor-to-authority calls can be distinguished from those that are
be distinguished from those that are created by responders created by responders (authority-to-authority) using public
(authority-to-authority) using public communications infrastructure communications infrastructure often involving some kind of priority
often involving some kind of priority access as defined in Emergency access as defined in Emergency Telecommunications Service (ETS) in IP
Telecommunications Service (ETS) in IP Telephony [RFC4190]. They Telephony [RFC4190]. They also can be distinguished from emergency
also can be distinguished from emergency warning systems that are warning systems that are authority-to-citizen.
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 device and applications create emergency calls, how
access networks supply location for some of these devices, 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 variation 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 of 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 o the interleaving over the same infrastructure of a wider variety
of services; of services;
o the separation of the access provider from the application o the separation of the access provider from the application
provider; provider;
o the plethora of different media that can be accommodated; o media other than voice (e.g. video and text in several forms);
o the potential mobility of all end systems, including endpoints o the potential mobility of all end systems, including endpoints
nominally thought of as fixed systems and not just those using nominally thought of as fixed systems and not just those using
radio access technology. For example, consider a wired phone radio access technology. For example, consider a wired phone
connected to a router using a mobile data network such as EV-DO as connected to a router using a mobile data network such as EV-DO as
an uplink. an uplink.
This document focuses on how devices using the Internet can place This document focuses on how devices using the Internet can place
emergency calls and how PSAPs can handle Internet multimedia emergency calls and how PSAPs can handle Internet multimedia
emergency calls natively, rather than describing how circuit-switched emergency calls natively, rather than describing how circuit-switched
PSAPs can handle VoIP calls. In many cases, PSAPs making the PSAPs can handle VoIP calls. In many cases, PSAPs making the
transition from circuit-switched interfaces to packet-switched transition from circuit-switched interfaces to packet-switched
interfaces may be able to use some of the mechanisms described here, interfaces may be able to use some of the mechanisms described here,
in combination with gateways that translate packet-switched calls in combination with gateways that translate packet-switched calls
into legacy interfaces, e.g., to continue to be able to use existing into legacy interfaces, e.g., to continue to be able to use existing
call taker equipment. There are many legacy telephone networks that call taker equipment. There are many legacy telephone networks that
will persist long after most systems have been upgraded to IP will persist long after most systems have been upgraded to IP
origination and termination of emergency calls. Many of these legacy origination and termination of emergency calls. Many of these legacy
systems use telephone number based routing. Gateways and conversions systems route calls based on telephone numbers. Gateways and
between existing systems and newer systems defined by this document conversions between existing systems and newer systems defined by
will be required. Since existing systems are governed primarily by this document will be required. Since existing systems are governed
local government regulations and national standards, the gateway and primarily by local government regulations and national standards, the
conversion details will be governed by national standards and thus gateway and conversion details will be governed by national standards
are out of scope for this document. and thus are out of scope for this document.
Existing emergency call systems are organized locally or nationally; Existing emergency call systems are organized locally or nationally;
there are currently no international standards. However, the there are currently no international standards. However, the
Internet crosses national boundaries, and thus international Internet crosses national boundaries, and thus international
standards for equipment and software are required. To further standards for equipment and software are required. To further
complicate matters, VoIP endpoints can be connected through tunneling complicate matters, VoIP endpoints can be connected through tunneling
mechanisms such as virtual private networks (VPNs). Tunnels can mechanisms such as virtual private networks (VPNs). Tunnels can
obscure the identity of the actual access network that knows the obscure the identity of the actual access network that knows the
location. This significantly complicates emergency calling, because location. This significantly complicates emergency calling, because
the location of the caller and the first element that routes the location of the caller and the first element that routes
skipping to change at page 7, line 35 skipping to change at page 6, line 35
conventional text telephony ("TTY") media streams. However, more conventional text telephony ("TTY") media streams. However, more
choices of media offer additional ways to communicate and evaluate choices of media offer additional ways to communicate and evaluate
the situation as well as to assist callers and call takers in the situation as well as to assist callers and call takers in
handling emergency calls. For example, instant messaging and video handling emergency calls. For example, instant messaging and video
could improve the ability to communicate and evaluate the situation could improve the ability to communicate and evaluate the situation
and to provide appropriate instruction prior to arrival of emergency and to provide appropriate instruction prior to arrival of emergency
crews. Thus, the architecture described here supports the creation crews. Thus, the architecture described here supports the creation
of sessions of any media type, negotiated between the caller and PSAP of sessions of any media type, negotiated between the caller and PSAP
using existing SIP protocol mechanisms [RFC3264]. using existing SIP protocol mechanisms [RFC3264].
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. A companion document, [I-D.ietf-ecrit-phonebcp],
describes Best Current Practice for this subject and contains describes Best Current Practice for this subject and contains
normative language for devices, access and calling network elements. normative language for devices, 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 does require that existing mechanisms be used in
certain specific ways, as described below. User Agents (UAs) unaware certain specific ways, as described below. User Agents (UAs) unaware
of the recommendations in this draft may be able to place emergency of the recommendations in this draft may be able to place emergency
calls, but functionality may be impaired. For example, if the UA calls, but functionality may be impaired. For example, if the UA
does not implement the location mechanisms described, an emergency does not implement the location mechanisms described, an emergency
skipping to change at page 8, line 23 skipping to change at page 7, line 23
3. Overview of how emergency calls are placed 3. Overview of how emergency calls are placed
An emergency call can be distinguished (Section 5) from any other An emergency call can be distinguished (Section 5) from any other
call by a unique Service URN [RFC5031] that is placed in the call call by a unique Service URN [RFC5031] that is placed in the call
set-up signaling when a home or visited emergency dial string is set-up signaling when a home or visited emergency dial string is
detected. Because emergency services are local to specific detected. Because emergency services are local to specific
geographic regions, a caller must obtain his location ( Section 6) geographic regions, a caller must obtain his location ( Section 6)
prior to making emergency calls. To get this location, either a form prior to making emergency calls. To get this location, either a form
of measuring, for example, GPS (Section 6.2.3) is deployed, or the of measuring, for example, GPS (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). The location is access network's Location Information Server (LIS) using a Location
conveyed (Section 6.7) in the SIP signaling with the call. The call Configuration Protocol (LCP). The location is conveyed (Section 6.7)
is routed (Section 8) based on location using the LoST protocol in the SIP signaling with the call. The call is routed (Section 8)
[RFC5222], which maps a location to a set of PSAP URIs. Each URI based on location using the LoST protocol [RFC5222], which maps a
resolves to a PSAP or an Emergency Services Routing Proxy (ESRP) that location to a set of PSAP URIs. Each URI resolves to a PSAP or an
serves as an incoming proxy for a group of PSAPs. The call arrives Emergency Services Routing Proxy (ESRP) that serves as an incoming
at the PSAP with the location included in the INVITE request. proxy for a group of PSAPs. The call arrives at the PSAP with the
location included in the INVITE request.
The following is a quick overview for a typical Ethernet connected 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 from the DHCP server in civic [RFC4776] o The phone gets location via a Location Configuration Protocol
and/or geo [RFC3825] forms, a HELD server (LCP), for example from the DHCP server in civic [RFC4776] and/or
geo [RFC3825] forms, a HELD server
[I-D.ietf-geopriv-http-location-delivery] or the first level [I-D.ietf-geopriv-http-location-delivery] or the first level
switch's LLDP server [LLDP]. switch's LLDP server [LLDP].
o The phone obtains the local emergency dial string(s) from the 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 LoST. 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 recognizes an emergency call from the dial strings and uses the
"urn:service:sos" [RFC5031] 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 in a Geolocation header
[I-D.ietf-sip-location-conveyance] and forwards the call using its
normal outbound call processing, which commonly involves an
outgoing proxy.
o It puts its location in the SIP INVITE request in a Geolocation
header [I-D.ietf-sip-location-conveyance] and forwards the call
using its normal outbound call processing, which commonly involves
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 would route
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
skipping to change at page 10, line 5 skipping to change at page 9, line 5
||| [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:
[M4] Alice -> LIS LCP Request (update location) [M4] Alice -> LIS: LCP Request (update location)
LIS -> ALICE LCP Reply (replies with location) LIS -> AliceE: 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 to Outgoing Proxy INVITE (service URN, [M6] Alice -> Outgoing Proxy: INVITE (service URN,
Location and PSAP URI) Location and PSAP URI)
Outgoing Proxy to ESRP INVITE (service URN, Outgoing Proxy -> ESRP: INVITE (service URN,
Location and PSAP URI) Location and PSAP URI)
ESRP to PSAP INVITE (service URN, Location and PSAP URI) ESRP -> PSAP: INVITE (service URN, Location and PSAP URI)
200 OK and ACK propogated back from PSAP to Alice The 200 OK response is propagated back from the PSAP to Alice and the
ACK response is propagated from Alice to the PSAP.
Figure 2 Figure 2
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 makes the emergency call. o Alice - who places the emergency call.
o Configuration Servers - Servers providing Alice's UA its IP o Configuration Servers - Servers providing Alice's UA its IP
address and other configuration information, perhaps including address and other configuration information, perhaps including
location by-value or by-reference. Configuration servers also may location by-value or by-reference. Configuration servers also may
include a SIP registrar for Alice's UA. Most SIP UAs will include a SIP registrar for Alice's UA. Most SIP UAs will
register, so it will be a common scenario for UAs that make register, so it will be a common scenario for UAs that make
emergency calls to be registered with such a server in the emergency calls to be registered with such a server in the
originating calling network. Registration would be required for originating calling network. Registration would be required for
the PSAP to be able to call back after an emergency call is the PSAP to be able to call back after an emergency call is
completed. All the configuration messages are labeled M1 through completed. All the configuration messages are labeled M1 through
M3, but could easily require more than 3 messages to complete. M3, but could easily require more than 3 messages to complete.
o LoST server - Processes the LoST request for Location + Service o LoST server - Processes the LoST request for location plus a
URN to PSAP-URI Mapping function, either for an initial request Service URN to a PSAP-URI, either for an initial request from a
from a UA, or an in-call routing by the Proxy server in the UA, or an in-call routing by the proxy server in the originating
originating network, or possibly by an ESRP. network, or possibly by an ESRP.
o ESRP - The emergency services routing proxy server that is the o ESRP - Emergency Services Routing Proxy, a sip proxy server that
incoming call proxy in the emergency services domain. The ESRP is the incoming call proxy in the emergency services domain. The
makes further routing decisions (e.g. based on PSAP state and the ESRP makes further routing decisions (e.g. based on PSAP state and
location of the caller) to choose the actual PSAP that handles the the location of the caller) to choose the actual PSAP that handles
call. In some jurisdictions, this may involve another LoST query. the call. In some jurisdictions, this may involve another LoST
query.
o PSAP - Call center where emergency calls are destined for. o PSAP - Emergency calls are answered at a Public Safety Answering
Point, a call center.
Generally, Alice's UA either has location configured manually, has an Generally, Alice's UA either has location configured manually, has an
integral location measurement mechanism, or it runs a LCP [M1] to integral location measurement mechanism, or it runs a LCP [M1] to
obtain location from the access (broadband) network. For most obtain location from the access (broadband) network. Alice's UA then
devices, a LCP will be used, for example a DHCPREQUEST message or will most likely register [M2] with a SIP registrar. This allows her
another location acquisition mechanism. Alice's UA then will most to be contacted by other SIP entities. Next, her UA will perform an
likely register [M2] with a SIP domain. This allows her to be
contacted by other SIP entities. Next, her UA will perform an
initial LoST query [M3] to learn a URI for use if the LoST query 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 the dial string. The UA attempts to refresh its
skipping to change at page 12, line 18 skipping to change at page 11, line 18
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 have the capability to establish sessions to a wide variety
of addresses, and communicate over private IP networks or the 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
the telephony service provider to the enterprise. In some more
recent systems, the enterprise PBX assists emergency calling by
providing more fine grained location in larger enterprises. In the
future, the enterprise may provide the 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 the telephone is connected to. However, this number
differs between localities, even though it is often the same for a differs between localities, even though it is often the same for a
country or region, as it is in many countries in the European Union. country or region, as it is in many countries in the European Union.
In some countries, there is a single digit sequence that is used for In some countries, there is only one uniform digit sequence that is
all types of emergencies. In others, there are several sequences used for all types of emergencies. In others, there are several
that are specific to the type of responder needed, e.g., one for sequences that are specific to the type of responder needed, e.g.,
police, another for fire. For end systems, on the other hand, it is one for police, another for fire. For end systems, on the other
desirable to have a universal identifier, independent of location, to hand, it is desirable to have a universal identifier, independent of
allow the automated inclusion of location information and to allow location, to allow the automated inclusion of location information
the device and other entities in the call path to perform appropriate and to allow the device and other entities in the call path to
processing within the signaling protocol in an emergency call set-up. perform appropriate processing within the signaling protocol in an
emergency call set-up.
Since there is no such universal identifier, as part of the overall Since there is no such universal identifier, as part of the overall
emergency calling architecture, common emergency call URNs are emergency calling architecture, common emergency call URNs are
defined in [RFC5031]. For a single number environment the urn is defined in [RFC5031]. For a single number environment the urn is
"urn:service:sos". Users are not expected to "dial" an emergency "urn:service:sos". Users are not expected to "dial" an emergency
URN. Rather, appropriate emergency dial strings are translated to URN. Rather, appropriate emergency dial strings are translated to
corresponding service URNs, carried in the Request-URI of the INVITE corresponding service URNs, carried in the Request-URI of the INVITE
request. Such translation is best done by the endpoint, among other request. Such translation is best done by the endpoint, because,
reasons, because emergency calls convey location in the signaling, among other reasons, emergency calls convey location in the
but non emergency calls do not normally do that. If the device signaling, but non-emergency calls do not normally do that. If the
recognizes the emergency call, it can include location. Dial string device recognizes the emergency call, it can include location. A
recognition could be performed in a signaling intermediary (proxy signaling intermediary (proxy server) can also recognize emergency
server) if for some reason the endpoint does not recognize it. 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 the visited are. However, local laws and regulations may require that the
dialing sequence(s) work. Therefore, the visited dial string must visited dialing sequence(s) work. Therefore, the visited dial string
work. Devices must allow at least the configuration of the home must work. Devices may have a way to be configured or learn home
country, from which a home dial string can be determined. dial strings.
The mechanism for obtaining the dialing sequences for a given LoST [RFC5222] provides the mechanism for obtaining the dialing
location is provided by LoST [RFC5222]. Lost servers must return sequences for a given location. LoST servers must return dial
dial strings for emergency services. If the endpoint does not strings for emergency services. If the endpoint does not support the
support the translation of dial strings to telephone numbers, the translation of dial strings to service URNs, the dialing sequence
dialing sequence is represented as a dial string [RFC4967] and the from the endpoint to its proxy is represented as a dial string
outgoing proxy has to recognize the dial string and translate to the [RFC4967] and the outgoing proxy must recognize the dial string and
service URN. To determine the local emergency dial string, the proxy translate it to the equivalent service URN. To determine the local
needs the location of the endpoint. This may be difficult in emergency dial string, the proxy needs the location of the endpoint.
situations where the user can roam or be nomadic. Endpoint This may be difficult in situations where the user can roam or be
recognition of emergency dial strings is therefore preferred. If a nomadic. Endpoint recognition of emergency dial strings is therefore
service provider is unable to guarantee that it can correctly preferred. If a service provider is unable to guarantee that it can
determine local emergency dialstrings, wherever its subscribers may correctly determine local emergency dialstrings, wherever its
be, then it is required that the endpoint do the recognition. subscribers may be, then it is required that the endpoint do the
recognition.
Note: It is undesirable to have a single button emergency call user Note: It is undesirable to have a single button emergency call user
interface element. These mechanisms tend to result in a very high interface element. These mechanisms tend to result in a very high
rate of false or accidental emergency calls. In order to minimize rate of false or accidental emergency calls. In order to minimize
this rate, devices should only initiate emergency calls based on this rate, 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
should not be permitted. should 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. It is Location is central to the operation of emergency services. Location
frequently the case that the caller reporting an emergency is unable is used for two purposes in emergency call handling: routing of the
to provide a unique, valid location themselves. For this reason, call and dispatch of responders. It is frequently the case that the
location provided by the endpoint or the access network is needed. caller reporting an emergency is unable to provide a unique, valid
For practical reasons, each PSAP generally handles only calls for a location themselves. For this reason, location provided by the
certain geographic area, with overload arrangements between PSAPs to endpoint or the access network is needed. For practical reasons,
handle each others calls. Other calls that reach it by accident must each PSAP generally handles only calls for a certain geographic area,
be manually re-routed (transferred) to the most appropriate PSAP, with overload arrangements between PSAPs to handle each others'
increasing call handling delay and the chance for errors. The area calls. Other calls that reach it by accident must be manually re-
covered by each PSAP differs by jurisdiction, where some countries routed (transferred) to the most appropriate PSAP, increasing call
have only a small number of PSAPs, while others decentralize PSAP handling delay and the chance for errors. The area covered by each
responsibilities to the level of counties or municipalities. PSAP differs by jurisdiction, where some countries have only a small
number of PSAPs, while others decentralize PSAP responsibilities to
the level of counties or municipalities.
In most cases, PSAPs cover at least a city or town, but there are In most cases, PSAPs cover at least a city or town, but there are
some areas where PSAP coverage areas follow old telephone rate center some areas where PSAP coverage areas follow old telephone rate center
boundaries and may straddle more than one city. Irregular boundaries boundaries and may straddle more than one city. Irregular boundaries
are common, often for historical reasons. Routing must be done based are common, often for historical reasons. Routing must be done based
on actual PSAP service boundaries -- the closest PSAP, or the PSAP on actual PSAP service boundaries -- the closest PSAP, or the PSAP
that serves the nominal city name provided in the location, may not that serves the nominal city name provided in the location, may not
be the correct PSAP. 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 tradeoff, especially with mobile devices or self
measuring mechanisms. It is considered acceptable to base a routing measuring mechanisms. if more accurate routing location is not
decision on an accuracy equal to the area of one sector of a mobile available it is considered acceptable to base a routing decision on
cell site if no more accurate routing location is available. an accuracy equal to the area of one sector of a mobile cell site.
Routing to the most appropriate PSAP is always calculated on the Routing to the most appropriate PSAP is always based on the location
location of the caller, despite the fact that some emergency calls of the caller, despite the fact that some emergency calls are placed
are placed on behalf of someone else, and the location of the on behalf of someone else, and the location of the incident is
incident is sometimes not the location of the caller. In some cases, sometimes not the location of the caller. In some cases, there are
there are other factors that enter into the choice of the PSAP that other factors that enter into the choice of the PSAP that gets the
gets the call, such as time of day, caller media requests and call, such as time of day, caller media requests and language
language preference, call load, etc. However, location of the caller preference and call load. However, location of the caller is the
is the primary input to the routing decision. primary input to the routing decision.
Location is used for two purposes in emergency call handling: routing Many mechanisms used to locate a caller have a relatively long "cold
of the call and dispatch of responders. Many mechanisms used to start" time. To get a location accurate enough for dispatch may take
locate a caller have a relatively long "cold start" time. To get a as much as 30 seconds. This is too long to wait for emergencies.
location accurate enough for dispatch may take as much as 30 seconds. Accordingly, it is common, especially in mobile systems, to use a
This is too long to wait for emergencies. Accordingly, it is common, coarse location, for example, the cell site and sector serving the
especially in mobile systems, to use a coarse location, for example, call, for call routing purposes, and then to update the location when
the cell site and sector serving the call, for call routing purposes, a more precise value is known prior to dispatch. In this document we
and then to update the location when a more precise value is known use "routing location" and "dispatch location" when the distinction
prior to dispatch. In this document we use "routing location" and matters.
"dispatch location" when the 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 exceeds available technology. It is required that a requirement is more stringent than available technology can deliver:
device making an emergency call close to the "demising" or separation It is required that a device making an emergency call close to the
wall between two apartments in a high rise apartment building report "demising" or separation wall between two apartments in a high rise
location with sufficient accuracy to determine on what side of the apartment building report location with sufficient accuracy to
wall it is on. This implies perhaps a 3 cm accuracy requirement. As determine on what side of the wall it is on. This implies perhaps a
of the date of this memo, typical assisted GPS uncertainty with 95% 3 cm accuracy requirement. As of the date of this memo, typical
confidence is 100 m. As technology advances, the accuracy assisted GPS uncertainty in mobile phones with 95% confidence is 100
requirements for location will need to be increased. Wired systems m. As technology advances, the accuracy requirements for location
using wire tracing mechanisms can provide location to a wall jack in will need to be tightened. Wired systems using wire tracing
specific room on a floor in a building, and may even specify a mechanisms can provide location to a wall jack in specific room on a
cubicle or even smaller resolution. As this discussion illustrates, floor in a building, and may even specify a cubicle or even smaller
emergency call systems demand the most stringent location accuracy resolution. As this discussion illustrates, emergency call systems
available. demand the most stringent location accuracy available.
Location usually involves several steps to process and multiple In Internet emergency calling, where the endpoint is located is
elements are involved. In Internet emergency calling, where the determined using a variety of measurement or wire-tracing methods.
endpoint is located is "determined" using a variety of measurement or Endpoints may be configured with their own location by the access
wire-tracing methods. Endpoints may be "configured" with their own network. In some circumstances, a proxy server may insert location
location by the access network. In some circumstances, a proxy into the signaling on behalf of the endpoint. The location is mapped
server may insert location into the signaling on behalf of the to the URI to send the call to, and the location is conveyed to the
endpoint. The location is "mapped" to the URI to send the call to, PSAP (and other elements) in the signaling. The terms
and the location is "conveyed" to the PSAP (and other elements) in 'determination', 'configuration', 'mapping', and 'conveyance' are
the signaling. Likewise, we employ Location Configuration Protocols, used for specific aspects of location handling in IETF protocols.
Location Mapping Protocols, and Location Conveyance Protocols for Likewise, we employ Location Configuration Protocols, Location
these functions. Mapping Protocols, and Location Conveyance Protocols for these
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
There are several ways location can be specified: Location can be specified in several ways:
Civic: Civic location information describes the location of a person Civic: Civic location information describes the location of a person
or object by a street address that corresponds to a building or or object by a street address that corresponds to a building or
other structure. Civic location may include more fine grained other structure. Civic location may include more fine grained
location information such as floor, room and cubicle. Civic location information such as floor, room and cubicle. Civic
information comes in two forms: information comes in two forms:
Jurisdictional refers to a civic location using actual political Jurisdictional refers to a civic location using actual political
subdivisions, especially for the community name. subdivisions, especially for the community name.
Postal refers to a civic location for mail delivery. The name of Postal refers to a civic location for mail delivery. The name of
the post office sometimes does not correspond to the community the post office sometimes does not correspond to the community
name and a postal address may contain post office boxes or name and a postal address may contain post office boxes or
skipping to change at page 15, line 48 skipping to change at page 15, line 11
provide a mapping between a postal address and a civic address provide a mapping between a postal address and a civic address
suitable to dispatch a responder to. In IETF location suitable to dispatch a responder to. In IETF location
protocols, there is an element (Postal Community Name) that can protocols, there is an element (Postal Community Name) that can
be included in a location to provide the post office name as be included in a location to provide the post office name as
well as the actual jurisdictional community name. There is well as the actual jurisdictional community name. There is
also an element for a postal code. There is no other also an element for a postal code. There is no other
accommodation for postal addresses in these protocols. accommodation for postal addresses in these protocols.
Geospatial (geo): Geospatial addresses contain longitude, latitude Geospatial (geo): Geospatial addresses contain longitude, latitude
and altitude information based on an understood datum and earth and altitude information based on an understood datum and earth
shape model. While there have been many datums developed over shape model. While there have been many datums developed over
time, most modern systems are using or moving towards the [WGS84] time, most modern systems are using or moving towards the WGS84
datum. [WGS84] datum.
Cell tower/sector: Cell tower/sector is often used for identifying Cell tower/sector: Cell tower/sector is often used for identifying
the location of a mobile handset, especially for routing of the location of a mobile handset, especially for routing of
emergency calls. Cell tower and sectors identify the cell tower emergency calls. Cell tower and sectors identify the cell tower
and the antenna sector that a mobile device is currently using. and the antenna sector that a mobile device is currently using.
Traditionally, the tower location is represented as a point chosen Traditionally, the tower location is represented as a point chosen
to be within a certain PSAP service boundary who agrees to take to be within a certain PSAP service boundary who agrees to take
calls originating from that tower/sector, and routing decisions calls originating from that tower/sector, and routing decisions
are made on that point. Cell/sector information could also be are made on that point. Cell/sector information could also be
represented as an irregularly shaped polygon of geospatial represented as an irregularly shaped polygon of geospatial
coordinates reflecting the likely geospatial location of the coordinates reflecting the likely geospatial location of the
skipping to change at page 16, line 46 skipping to change at page 16, line 6
As noted above, location information can be entered by the user or As noted above, location information can be entered by the user or
installer of a device ("manual configuration"), measured by the end installer of a device ("manual configuration"), measured by the end
system, can be delivered to the end system by some protocol or system, can be delivered to the end system by some protocol or
measured by a third party and inserted into the call signaling. measured by a third party and inserted into the call signaling.
In some cases, an entity may have multiple sources of location In some cases, an entity may have multiple sources of location
information, possibly partially contradictory. This is particularly information, possibly partially contradictory. This is particularly
likely if the location information is determined both by the end likely if the location information is determined both by the end
system and a third party. Although self measured location (e.g. system and a third party. Although self measured location (e.g.
GPS) is attractive, access network provided location could be much GPS) is attractive, location information provided by the access
more accurate, and more reliable in some environments such as indoor network could be much more accurate, and more reliable in some
high rises in dense urban areas. In general, the closer an entity is environments such as high rise buildings in dense urban areas.
to the source of location, the more it is in the best position to
determine which location is "best" for a particular purpose. In The closer an entity is to the source of location, the more likely it
emergency calling, the PSAP is the least likely to be able to is able to determine which location is most appropriate for a
appropriately choose which location to use when multiple conflicting particular purpose when there are more than one location
locations are presented to it. determinations for a given endpoint. In emergency calling, the PSAP
is the least likely to be able to appropriately choose which location
to use when multiple conflicting locations are presented to it.
While all available locations can be sent towards the PSAP, the order
of the locations should be the sender's best attempt to guide the
recipient of which one(s) to use.
6.2.1. User-entered location information 6.2.1. User-entered location information
Location information can be maintained by the end user or the Location information can be maintained by the end user or the
installer of an endpoint in the endpoint itself, or in a database. installer of an endpoint in the endpoint itself, or in a database.
Location information provided by end users is almost always less Location information provided by end users is almost always less
reliable than measured or wire database information, as users may reliable than measured or wire database information, as users may
mistype location information or may enter civic address information mistype location information or may enter civic address information
that does not correspond to a recognized (i.e., valid, see Section that does not correspond to a recognized (i.e., valid, see Section
skipping to change at page 17, line 44 skipping to change at page 17, line 10
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-LO However, this is not sufficient for larger structures. The PIDF
[RFC4119] with a recent extension [RFC5139] permits interior Location Object [RFC4119] with a recent extension [RFC5139] permits
building/floor/room and even finer specification of location within a interior building/floor/room and even finer specification of location
street address. When possible, interior location should be within a street address. When possible, interior location should be
supported. supported.
The threshold for when interior location is needed is approximately The threshold for when interior location is needed is approximately
650 m2. This value is derived from fire brigade recommendations of 650 square meters. This value is derived from fire brigade
spacing of alarm pull stations. However, interior space layout, recommendations of spacing of alarm pull stations. However, interior
construction materials and other factors should be considered. The space layout, construction materials and other factors should be
ultimate goal is to be able to find the person in need quickly if considered.
responders arrive at the location provided.
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.
skipping to change at page 18, line 34 skipping to change at page 17, line 47
6.2.3. End-system measured location information 6.2.3. End-system measured location information
Global Positioning System (GPS) and similar satellite based (e.g., Global Positioning System (GPS) and similar satellite based (e.g.,
Galileo) receivers may be embedded directly in the end device. GPS Galileo) receivers may be embedded directly in the end device. GPS
produces relatively high precision location fixes in open-sky produces relatively high precision location fixes in open-sky
conditions, but the technology still faces several challenges in conditions, but the technology still faces several challenges in
terms of performance (time-to-fix and time-to-first-fix), as well as terms of performance (time-to-fix and time-to-first-fix), as well as
obtaining successful location fixes within shielded structures, or obtaining successful location fixes within shielded structures, or
underground. It also requires all devices to be equipped with the underground. It also requires all devices to be equipped with the
appropriate GPS capability. GPS-derived locations are currently appropriate GPS capability. Many mobile devices require using some
accurate to tens of meters. Many mobile devices require using some
kind of "assist", that may be operated by the access network (A-GPS) kind of "assist", that may be operated by the access network (A-GPS)
or by a government (WAAS). or by a government (WAAS). A device may be able to use multiple
sources of assist data.
GPS systems may be always enabled and thus location will always be GPS systems may be always enabled and thus location will always be
available accurately immediately (assuming the device can "see" available accurately immediately (assuming the device can "see"
enough satellites). Mobile devices may not be able to sustain the enough satellites). Mobile devices may not be able to sustain the
power levels required to keep the measuring system active. In such power levels required to keep the measuring system active. In such
circumstances, when location is needed, the device has to start up circumstances, when location is needed, the device has to start up
the measurement mechanism. This typically takes tens of seconds, far the measurement mechanism. This typically takes tens of seconds, far
too long to wait to be able to route an emergency call. For this too long to wait to be able to route an emergency call. For this
reason, devices that have end-system measured location mechanisms but reason, devices that have end-system measured location mechanisms but
need a cold start period lasting more than a couple seconds need need a cold start period lasting more than a couple seconds need
skipping to change at page 19, line 18 skipping to change at page 18, line 30
Wireless triangulation: Elements in the network infrastructure Wireless triangulation: Elements in the network infrastructure
triangulate end systems based on signal strength, angle of arrival triangulate end systems based on signal strength, angle of arrival
or time of arrival. Common mechanisms deployed include: or time of arrival. Common mechanisms deployed include:
* Time Difference Of Arrival - TDOA * Time Difference Of Arrival - TDOA
* Uplink Time Difference Of Arrival - U-TDOA * Uplink Time Difference Of Arrival - U-TDOA
* Angle of Arrival - AOA * Angle of Arrival - AOA
* RF fingerprinting * RF fingerprinting
* Advanced Forward Link Trilateration - AFLT * Advanced Forward Link Trilateration - AFLT
* Enhanced Forward Link Trilateration - EFLT * Enhanced Forward Link Trilateration - EFLT
Sometimes multiple mechanisms are combined, for example A-GPS with Sometimes multiple mechanisms are combined, for example A-GPS with
AFLT AFLT.
Location beacons: A short range wireless beacon, e.g., using Location beacons: A short range wireless beacon, e.g., using
Bluetooth or infrared, announces its location to mobile devices in Bluetooth or infrared, announces its location to mobile devices in
the vicinity. This allows devices to get location from the beacon the vicinity. This allows devices to get location from the beacon
source's location. source's location.
6.3. Who adds location, endpoint or proxy 6.3. Who adds location, endpoint or proxy
The IETF emergency call architecture prefers endpoints to learn their The IETF emergency call architecture prefers endpoints to learn their
location and supply it on the call. Where devices do not support location and supply it on the call. Where devices do not support
location, proxy servers may have to add location to emergency calls. location, proxy servers may have to add location to emergency calls.
Some calling networks have relationships with all access networks the Some calling networks have relationships with all access networks the
device may be connected to, and that may allow the proxy to device may be connected to, and that may allow the proxy to
accurately determine 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 use with 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. Systems 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 (wholly contained
within the signaling message) or by reference (i.e. as a URI pointing within the signaling message) or by reference (i.e., as a URI
to the value residing on a remote node waiting to be dereferenced). pointing to the value residing on a remote node waiting to be
Each form is better suited to some applications than others. dereferenced).
When location is transmitted by value, the location information is When location is transmitted by value, the location information is
available to each device; on the other hand, location objects can be available to entity in the call path. On the other hand, location
large, and only represent a single snapshot of the device's location. objects can be large, and only represent a single snapshot of the
Location references are small and can be used to represent a time- device's location. Location references are small and can be used to
varying location, but the added complexity of the dereference step represent a time-varying location, but the added complexity of the
introduces a risk that location will not be available to parties that dereference step introduces a risk that location will not be
need it. available to parties that need it.
6.5. End system location configuration 6.5. End system location configuration
Unless a user agent has access to provisioned or locally measured Unless a user agent has access to provisioned or locally measured
location information, it must obtain it from the access network. location information, it must obtain it from the access network.
There are several location configuration protocols (LCPs) that can be There are several location configuration protocols (LCPs) that can be
used for this purpose including DHCP, HELD and LLDP: used for this purpose including DHCP, HELD and LLDP:
DHCP can deliver civic [RFC4776] or geospatial [RFC3825] DHCP can deliver civic [RFC4776] or geospatial [RFC3825]
information. User agents need to support both formats. Note that information. User agents need to support both formats. Note that
a user agent can use DHCP, via the DHCP REQUEST or INFORM a user agent can use DHCP, via the DHCP REQUEST or INFORM
messages, even if it uses other means to acquire its IP address. messages, even if it uses other means to acquire its IP address.
HELD [I-D.ietf-geopriv-http-location-delivery] can deliver a civic HELD [I-D.ietf-geopriv-http-location-delivery] can deliver a civic
or geo, by value or by reference, as a layer 7 protocol. The or geo location object, by value or by reference, via a layer 7
query typically uses the IP address of the requestor as an protocol. The query typically uses the IP address of the
identifier and returns the location value or reference associated requestor as an identifier and returns the location value or
with that identifier. HELD is typically carried in HTTP. reference associated with that identifier. HELD is typically
carried in HTTP.
Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device
extensions [LLDP-MED] can be used to deliver location information extensions [LLDP-MED] can be used to deliver location information
directly from the Layer 2 network infrastructure, and also directly from the Layer 2 network infrastructure, and also
supports both civic and geospatial formats identical in format to supports both civic and geo formats identical in format to DHCP
DHCP methods. methods.
Each LCP has limitations in the kinds of networks that can reasonably Each LCP has limitations in the kinds of networks that can reasonably
support it. For this reason, it is not possible to choose a single support it. For this reason, it is not possible to choose a single
mandatory-to-deploy LCP. For endpoints with common network mandatory-to-deploy LCP. For endpoints with common network
connections (such as an Ethernet jack or a WiFi connection) serious connections (such as an Ethernet jack or a WiFi connection) serious
incompatibilities would ensue unless every network supported every incompatibilities would ensue 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 [I-D.ietf-ecrit-phonebcp]. Every endpoint that could be used to
place emergency calls must implement all of the protocols on the place emergency calls must implement all of the protocols on the
list. Every access network must deploy at least one of them. It is list. Every access network must deploy at least one of them. Since
recognized that this is an onerous requirement that would be it is the variability of the networks that prevent a single protocol
desirable to eliminate. However, since it is the variability of the from being acceptable, it must be the endpoints that implement all of
networks that prevent a single protocol from being acceptable, it them, and to accommodate a wide range of devices, networks must
must be the endpoints that implement all of them, and to accommodate deploy at least one of them.
a wide range of devices, networks must deploy at least 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 a wireless data network WAN
connection, with Ethernet connected phones connected to that. It is connection, with Ethernet connected phones connected to that. It is
possible that the access network could support a protocol not on the possible that the access network could support a protocol not on the
list, and require every handset in that network to use that protocol list, and require every handset in that network to use that protocol
skipping to change at page 21, line 43 skipping to change at page 21, line 5
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 TTL expires or the device moves beyond some
boundaries (as provided by [RFC5222]). Normally, mobile devices will boundaries (as provided by [RFC5222]). Normally, mobile devices will
acquire its location at call time for use in an emergency call acquire its location at call time for use in an emergency call
routing. See Section 6.8 for a further discussion on location routing. See Section 6.8 for a further discussion on location
updates for dispatch location. updates for dispatch location.
There are many examples of end devices which are applications running There are many examples of endpoints which are user agent
on a more general purpose device, such as a personal computer. In applications running on a more general purpose device, such as a
some circumstances, it is not possible for application programs to personal computer. On some systems, layer 2 protocols like DHCP and
access the network device at a level necessary to implement the LLDP- LLDP may not be directly accessible to applications. It is desirable
MED protocol, and in other cases, obtaining location via DHCP may be for an operating system to have an API which provides the location of
impossible. In any case it is desirable for an operating system the device for use by any application, especially those supporting
which could be used for any application which could make emergency emergency calls.
calls to have an API which provides the location of the device for
use by any application.
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
before the access network demarcation point and thus the IP address between the endpoint and the access network demarcation point and
seen by the access network is the right identifier for location of thus the IP address seen by the access network is the right
the residence. In many enterprise environments, VPN tunnels can identifier for location of the residence. However, in many
obscure the actual IP address. Some VPN mechanisms can be bypassed enterprise environments, VPN tunnels can obscure the actual IP
so that a query to the LCP can be designated to go through the direct address. Some VPN mechanisms can be bypassed so that a query to the
IP path, using the correct IP address, and not through the tunnel. LCP can be designated to go through the direct IP path, using the
In other cases, no bypass is possible. Of course, LCPs that use correct IP address, and not through the tunnel. In other cases, no
Layer 2 mechanisms (DHCP Location options and LLDP-MED) are usually bypass is possible. Of course, LCPs that use layer 2 mechanisms
immune from such problems because they do not use the IP address as (DHCP Location options and LLDP-MED) are usually immune from such
the identifier for the device seeking location. problems because they do not use the IP address as the identifier for
the device seeking location.
It is desirable that routing location information be periodically It is desirable that routing location information be periodically
refreshed. A LIS supporting a million subscribers each refreshing refreshed. A LIS supporting a million subscribers each refreshing
once per day would need to support a query rate of 1,000,000 / (24 * once per day would need to support a query rate of 1,000,000 / (24 *
60 * 60) = 12 queries per second. 60 * 60) = 12 queries per second.
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
skipping to change at page 22, line 43 skipping to change at page 21, line 52
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 tradeoff 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 fix"), it's preferable to wait. Three
seconds, the current nominal time for a quick fix, is a very long seconds, the current nominal time for a quick fix, is a very long
time to wait for help. Systems designers should attempt to provide time add to post dial delay.
accurate routing location in much less time then that.
NENA recommends [NENAi3TRD]IP based systems complete calls in two NENA recommends [NENAi3TRD] that IP based systems complete calls in
seconds (i.e., last dial press to ring at PSAP). two seconds from last dial press to ring at PSAP.
6.7. Conveying location in SIP 6.7. Conveying location in SIP
When an emergency call is placed, the endpoint should put location in When an emergency call is placed, the endpoint should include
the call signaling. This is referred to as "conveyance" to location in the call signaling. This is referred to as "conveyance"
distinguish it from "configuration". In SIP, the location to distinguish it from "configuration". In SIP, the location
information is conveyed following the procedures in information is conveyed following the procedures in
[I-D.ietf-sip-location-conveyance]. Since the form of the location [I-D.ietf-sip-location-conveyance]. Since the form of the location
information obtained by the acquisition protocol may not be the same information obtained by the acquisition protocol may not be the same
as the conveyance protocol uses (PIDF-LO [RFC4119]), mapping by the as the conveyance protocol uses (PIDF-LO [RFC4119]), mapping by the
endpoint from the LCP form to PIDF may be required. endpoint from the LCP form to PIDF may be required.
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 early. 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. location. In addition, the location of some mobile callers, e.g., in
a vehicle or aircraft, can change significantly during the emergency
In addition, the location of some mobile callers, e.g., in a vehicle
or aircraft, can change significantly during the emergency call.
While most often this change is not significant, the PSAP must be
able to get updated location information while it is processing the
call. call.
A PSAP has no way to request an update of a location-by-value. If A PSAP has no way to request an update of a location provided by
the UAC gets new location, it must signal the PSAP using a reINVITE value. If the UAC gets new location, it must signal the PSAP using a
or UPDATE method with a new Geolocation header to supply the new new INVITE or an UPDATE transaction with a new Geolocation header to
location. supply the new location.
With the wide variation in determination mechanisms, the PSAP doesn't
know when accurate location may be available to it. Therefore, the
preferred mechanism is that the LIS notifies the PSAP when accurate
location is updated rather than requiring a poll operation from the
PSAP to the LIS. The SIP Presence subscription [RFC3856] provides a
suitable mechanism.
Generally, the PSAP can wait for an accurate location for dispatch. With the wide variation in determination mechanisms, the PSAP does
However, there is no fixed limit known in advance; it depends on the not know when accurate location may be available. The preferred
nature of the emergency. At some point the PSAP must dispatch. If mechanism is that the LIS notifies the PSAP when an accurate location
the LIS is notifying the PSAP with a SUBSCRIBE/NOTIFY mechanism, the is available rather than requiring a poll operation from the PSAP to
PSAP could update the parameters in a filter on the subscription. the LIS. The SIP Presence subscription [RFC3856] provides a suitable
(immediate response required). 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. The LIS should "emergencyDispatch" for the ResponseTime parameter. Since typically
be aware of the needs of the PSAP as they are local to one another. the LIS is local relative to the PSAP, the LIS can be 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 [I-D.ietf-geopriv-pdif-lo-profile] . Conflicting location in [I-D.ietf-geopriv-pdif-lo-profile] . Conflicting location
information is particularly harmful if different routes (PSAPs) information is particularly harmful if different routes (PSAPs)
result from LoST queries for the multiple locations. When they occur result from LoST queries for the multiple locations. When they occur
anyway, the general guidance is that the entity earliest in the chain anyway, the general guidance is that the entity earliest in the chain
generally has more knowledge than later elements to make an generally has more knowledge than later elements to make an
intelligent decision, especially about which location will be used intelligent decision, especially about which location will be used
for routing. It is permissible to send multiple locations towards for routing. It is permissible to send multiple locations towards
the PSAP, but the element that chooses the route must select one (and the PSAP, but the element that chooses the route must select exactly
only one) location to use with LoST. 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 the one to use to route and send any others locations, it must choose exactly one to use for routing, marking it
it has. as such (per [I-D.ietf-sip-location-conveyance], and send it as well
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 many pieces of information to make provides the call-taker with information to make decisions upon, as
decisions upon, as well as guidance for what to ask the caller and well as guidance for what to ask the caller and what to tell the
what to tell the responders. responders.
The call must indicate the location information that has been used The call must indicate the location information that has been used
for routing, so that the same location information is used for all for routing, so that the same location information is used for all
call routing decisions. The location conveyance mechanism call routing decisions. The location conveyance mechanism
[I-D.ietf-sip-location-conveyance] contains a parameter for this [I-D.ietf-sip-location-conveyance] contains a parameter for this
purpose. purpose.
An entity may also recieve multiple versions of the same location. Endpoints or proxies may be tempted to send multiple versions of the
For example a database may be used to "geocode" or "reverse geocode", same location. For example a database may be used to "geocode" or
that is, convert from civic to geo or vice versa. It is very "reverse geocode", that is, convert from civic to geo or vice versa.
problematic to use derived locations in emergency calls. The PSAP It is very problematic to use derived locations in emergency calls.
and the responders have very accurate databases which they use to The PSAP and the responders have very accurate databases which they
convert, most commonly from a reported geo to a civic suitable for use to convert, most commonly from a reported geo to a civic suitable
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. "Off by
one" errors are serious when responders go to the wrong location. one" errors are serious when responders go to the wrong location.
Derived locations should be marked with a "derived" method token Derived locations should be marked with a "derived" method token
[RFC4119]. If an entity gets a location which has a measured or [RFC4119]. If an entity gets a location which has a measured or
other original method, and another with a derived method, it must use other original method, and another with a derived method, it must use
the original value for the emergency call. the original value for the emergency call.
6.10. Location validation 6.10. Location validation
It is recommended that location be validated prior to a device Validation in this context means both that there is a mapping from
placing an actual emergency call; some jurisdictions require that the address to a PSAP and that the PSAP understands how to direct
this be done. Validation in this context means both that there is a responders to the location. It is recommended that location be
mapping from the address to a PSAP and that the PSAP understands how validated prior to a device placing an actual emergency call; some
to direct responders to the location. Determining the addresses that jurisdictions require that this be done.
are valid can be difficult. There are, for example, many cases of
two names for the same street, or two streets with the same name in a Determining the addresses that are valid can be difficult. There
city. In some countries, the current system provides validation. are, for example, many cases of two names for the same street, or two
For example, in the United States, the Master Street Address Guide streets with the same name, but different "suffixes" (Avenue, Street,
(MSAG) records all valid street addresses and is used to ensure that Circle) in a city. In some countries, the current system provides
the service addresses in phone billing records correspond to valid validation. For example, in the United States, the Master Street
emergency service street addresses. Validation is normally a concern Address Guide (MSAG) records all valid street addresses and is used
for civic addresses, although there could be a concern that a given to ensure that the service addresses in phone billing records
geo is within at least one PSAP service boundary; that is, a "valid" correspond to valid emergency service street addresses. Validation
geo is one where there is a mapping. is normally only a concern for civic addresses, although there could
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
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; new streets are added or mapping database undergoes slow change and locations which previously
removed, community names change, postal codes change, etc. Endpoints validated may eventually fail validation. Endpoints may wish to
may wish to validate locations they receive from the access network, validate locations they receive from the access network, and will
and will need to validate manually entered locations. Proxies that need to validate manually entered locations. Proxies that insert
insert location may wish to validate locations they receive from a location may wish to validate locations they receive from a LIS.
LIS. When the Test functions (Section 15) are invoked, the location When the test functions (Section 15) are invoked, the location used
used should be re-validated. should be validated.
When validation fails, the location given must not be used for an When validation fails, the location given must not be used for an
emergency call. If validation is complete when location is first emergency call. If validation is completed when location is first
loaded into a LIS, any problems can be found and fixed before devices loaded into a LIS, any problems can be found and fixed before devices
could get the bad location. Failure of validation arises because an could get the bad location. Failure of validation arises because an
error is made in determining the location, although occasionally the error is made in determining the location, although occasionally the
LoST database is not up to date or has faulty information. In either LoST database is not up to date or has faulty information. In either
case, the problem must be identified and corrected before using the case, the problem must be identified and corrected before using the
location. 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
skipping to change at page 26, line 12 skipping to change at page 25, line 13
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. 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,
[I-D.ietf-geopriv-lis-discovery] and [RFC5223] namely [I-D.ietf-geopriv-lis-discovery] 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 an SRV query within its SIP domain device. The endpoint can also do a DNS SRV query to find a LoST
to find a LoST server. In any environment, more than one of these server. In any environment, more than one of these mechanisms may
mechanisms may yield a LoST server, and they may be differernt. The yield a LoST server, and they may be different. The recommended
recommended priority is DHCP first, provisioned value second, and SRV priority is DHCP first, provisioned value second, and DNS SRV query
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. If there is no or imprecise (e.g., cell allows such routing.
tower and sector) information at call setup time, an on-going
emergency call may also be transferred to another PSAP based on
location information that becomes available in mid-call.
Type of emergency service: In some jurisdictions, emergency calls Type of emergency service: In some jurisdictions, emergency calls
for specific emergency services such as fire, police, ambulance or for specific emergency services such as fire, police, ambulance or
mountain rescue are directed to just those emergency-specific 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 interactive text or sign language
communications, where routing within the PSAP based on the media communications, where routing within the PSAP based on the media
offer would be provided. offer would be provided.
Routing for calls by location and by service is the primary function Providing a URL to route emergency calls by location and by type of
LoST [RFC5222] provides. LoST accepts a query with location (by- service is the primary function LoST [RFC5222] provides. LoST
value) in either civic or geospatial form, plus a service identifier, accepts a query with location (by-value) in either civic or geo form,
and returns a URI (or set of URIs) to route the call to. Normal SIP plus a service identifier, and returns a URI (or set of URIs) to
[RFC3261] routing functions are used to resolve the URI to a next hop route the call to. Normal SIP [RFC3261] routing functions are used
destination. 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
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
geo reported location. This can be an enclosing subset of the area geospatial location. This can be a simple enclosing rectangle of the
when the reported point is not near an edge or a smaller edge section PSAP service area when the reported point is not near an edge, or a
when the reported location is near an edge. Civic location is smaller polygonal edge section when the reported location is near an
uncommon for mobile devices, but reporting that the same mapping is edge. Civic location is uncommon for mobile devices, but reporting
good within a community name, or even a street, may be very helpful that the same mapping is good within a community name, or even a
for WiFi connected devices that roam and obtain civic location from street, may be very helpful for WiFi connected devices that roam and
the AP they are connected to. obtain civic location from the AP they are connected to.
Networks that support devices that do not implement LoST mapping Networks that support devices that do not implement LoST mapping
themselves may need the outbound proxy do the mapping. If the themselves may need the outbound proxy do the mapping. If the
endpoint recognized the call was an emergency call, provided the endpoint recognized the call was an emergency call, provided the
correct service URN and/or included location on the call in a correct service URN and/or included location on the call in a
Geolocation header, a proxy server could easily accomplish the Geolocation header, a proxy server could easily accomplish the
mapping. mapping.
However, if the endpoint did not recognize the call was an emergency However, if the endpoint did not recognize the call was an emergency
call, and thus did not include location, the proxy's task is more call, and thus did not include location, the proxy's task is more
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 by itself. The endpoint accurately determine the endpoint's location. The endpoint may have
may have its 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] to allow a mechanism provided in [I-D.ietf-sip-location-conveyance] for a proxy
proxy to require the endpoint supply location, because that would to request the endpoint supply its location, because that would open
open the endpoint to an attack by any proxy on the path to get it to the endpoint to an attack by any proxy on the path to get it to
reveal location. The proxy can attempt to redirect a call to the reveal location. The proxy can attempt to redirect a call to the
service URN which, if the device recognizes the significance, would service URN which, if the device recognizes the significance, would
include location in the redirected call from the device. All include location in the redirected call from the device. All
networks should detect emergency calls and supply default location networks elements should detect emergency calls and supply default
and/or routing if it is not already performed. location and/or routing if it is not already present.
Often, the SIP routing of an emergency call will first route to an The LoST server would normally be provided by the local emergency
incoming call proxy in the domain operated by the emergency service. authorities, although the access network or calling network might run
That proxy is called an "Emergency Services Routing Proxy" (ESRP). its own server using data provided by the emergency authorities.
The ESRP, which is a normal SIP proxy server, may use a variety of Some enterprises may have local responders and call centers, and
PSAP state information, the location of the caller, and other could operate their own LoST server, providing URIs to in-house
criteria to onward route the call to the PSAP. In order for the ESRP "PSAPs". Local regulations might limit the ability of enterprises to
to route on media choice, the initial INVITE request has to supply an direct emergency calls to in-house services.
SDP offer.
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
of the caller, and other criteria to onward route the call to the
PSAP. In order for the ESRP to route on media choice, the initial
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
As discussed above, location is carried in all emergency calls in the Best Current Practice for SIP user agents [RFC4504] including
call signaling. Since emergency calls carry privacy-sensitive handling of audio, video and real-time text xref target="RFC4103"/>
information, they are subject to the requirements for geospatial should be applied. As discussed above, location is carried in all
protocols [RFC3693]. In particular, signaling information should be emergency calls in the call signaling. Since emergency calls carry
carried in TLS, i.e., in 'sips' mode with a ciphersuite which privacy-sensitive information, they are subject to the requirements
includes strong encryption (e.g., AES). There are exceptions in for geospatial protocols [RFC3693]. In particular, signaling
[RFC3693] for emergency calls. For example, local policy may dictate information should be carried in TLS, i.e., in 'sips' mode with a
that location is sent with an emergency call even if the user's ciphersuite which includes strong encryption (e.g., AES). There are
policy would otherwise prohibit that. Never the less, protection exceptions in [RFC3693] for emergency calls. For example, local
from eavesdropping of location by encryption should be provided. policy may dictate that location is sent with an emergency call even
if the user's policy would otherwise prohibit that. Nevertheless,
protection from eavesdropping of location by encryption 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.
[I-D.ietf-sip-sips] recommends that to achieve this effect the target [I-D.ietf-sip-sips] recommends that to achieve this effect the target
request a sip URI, but use TLS on the outbound connection. An specifies a sip URI, but use TLS on the outbound connection. An
element that receives a request over a TLS connection should attempt element that receives a request over a TLS connection should attempt
to create a TLS connection to the next hop. to create a TLS connection to the next hop.
In many cases, persistent TLS connections can be maintained between In many cases, persistent TLS connections can be maintained between
elements to minimize the time needed to establish them elements to minimize the time needed to establish them
[I-D.ietf-sip-outbound]. In other circumstances, use of session [I-D.ietf-sip-outbound]. In other circumstances, use of session
resumption [RFC5077] is recommended. IPSEC [RFC4301] is an resumption [RFC5077] is recommended. IPSEC [RFC4301] is an
acceptable alternative to TLS when used with an equivalent crypto acceptable alternative to TLS when used with an equivalent crypto
suite. suite.
Location may be used for routing by multiple proxy servers on the Location may be used for routing by multiple proxy servers on the
path. Confidentiality mechanisms such as S/MIME encryption of SIP path. Confidentiality mechanisms such as S/MIME encryption of SIP
signaling [RFC3261] cannot be used because they obscure location. signaling [RFC3261] cannot be used because they obscure location.
Only hop-by-hop mechanisms such as TLS should be used. Many SIP Only hop-by-hop mechanisms such as TLS should be used. Implementing
devices do not support TLS. Implementing location conveyance in SIP location conveyance in SIP mandates inclusion of TLS support.
mandates inclusion of TLS support.
9.2. SIP signaling requirements for User Agents 9.2. SIP signaling requirements for User Agents
SIP UAs that do local dial string interpretation, location, and SIP UAs that recognize local dial strings, insert location, and
emergency call route will create SIP INVITE messages with the Service perform emergency call routing will create SIP INVITE messages with
URN in the Request URI and To header, 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 call back identifiers
To enable media sensitive routing, the call should include an SDP (in Contact and From headers). To enable media sensitive routing,
offer. the call should include an SDP offer.
SIP caller preferences [RFC3841] can be used to signal how the PSAP
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
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
a relay service for communication with people with disabilities in
the call.
9.3. SIP signaling requirements for proxy servers 9.3. SIP signaling requirements for proxy servers
SIP proxy servers in the path of an emergency call must be able to SIP proxy servers in the path of an emergency call must be able to
assist UAs that are unable to provide any of the location based assist UAs that are unable to provide any of the location based
routing steps and recognition of dial strings. They are also routing steps and recognition of dial strings. They should recognize
expected to provide identity information for the caller. emergency dial strings, inserting the Route header with the
appropriate service URN. They should obtain the location of the
endpoint if possible, and use a default location if they can not,
inserting it in a Geolocation header. They should query LoST with
the location and put the resulting URI in the Request URI. They are
also expected to provide identity information for the caller using
SIP Identity or P-Asserted-Identity.
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. In SIP systems, the caller must include a Contact for this purpose. There are two kinds of call backs. When a call is
header field indicating its device URI, if globally routable, or dropped, or the call taker realizes that some important information
possibly a GRUU [I-D.ietf-sip-gruu] if calls need to be routed via a is needed that it doesn't have, it must call back the device that
proxy. This identifier would be used to initiate call-backs placed the emergency call. The PSAP, or a responder, may need to
immediately by the call-taker if, for example, the call is call back the caller much later, and for that purpose, it wants a
normal SIP Address of Record. In SIP systems, the caller must
include a Contact header field indicating its device URI, if globally
routable, or possibly a GRUU [I-D.ietf-sip-gruu] if calls need to be
routed via a proxy. This identifier would be used to initiate call-
backs immediately by the call-taker if, for example, the call is
prematurely dropped. This is a change from [RFC3261] where the prematurely dropped. This is a change from [RFC3261] where the
Contact: header is optional. Contact: header is optional. A concern arises with B2BUAs that
manipulate Contact headers. Such manipulation should always result
in the Contact header being available for call backs.
In addition, a call-back identifier must be included either as the In addition, a call-back identifier as an AoR must be included either
URI in the From header field [RFC3261] verified by SIP Identity as the URI in the From header field [RFC3261] verified by SIP
[RFC4474] or as a network asserted URI [RFC3325]. This identifier Identity [RFC4474] or as a network asserted URI [RFC3325]. This
would be used to initiate a call-back at a later time and may reach identifier would be used to initiate a call-back at a later time and
the caller, not necessarily on the same device (and at the same may reach the caller, not necessarily on the same device (and at the
location) as the original emergency call as per normal SIP rules. same location) as the original emergency call as per normal SIP
rules.
11. Mid-call behavior 11. Mid-call behavior
PSAPs often include dispatchers, responders or specialists on a call. Some features often provided in telephony services, such as call
Some responder's dispatchers are not located in the primary PSAP. waiting, 3 way call, and the like, need to be disabled during
The call may have to be transferred to another PSAP. Most often this emergency calls. In [I-D.ietf-ecrit-phonebcp], reference is made to
will be an attended transfer, or a bridged transfer. Therefore a "flash hold". This is a service in some PSTN systems where a short
PSAP may need to REFER [RFC3515] a call to a bridge for conferencing. duration "on hook" signals the network to put the call on hold,
Relay services for communication with people with disabilities may be provide dial tone, and await DTMF signaling. That form of hold, as
included in the call in this way. well as ISDN signaled hold is undesirable in emergency calls.
The UA should also be prepared to have the call transferred (usually Some PSAPs often include dispatchers, responders or specialists on a
attended, but possibly blind) as per call. Some responder's dispatchers are not located in the primary
PSAP, the call may have to be transferred to another PSAP. Most
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
bridge for conferencing. Devices which normally involve the user in
transfer operations should consider the effect of such interactions
when a stressed user places an emergency call. Requiring UI
manipulation during such events may not be desirable. Relay services
for communication with people with disabilities may be included in
the call with the bridge. The UA should be prepared to have the call
transferred (usually attended, but possibly blind) per
[I-D.ietf-sipping-service-examples]. [I-D.ietf-sipping-service-examples].
SIP Caller Preferences [RFC3841] can be used to signal how the PSAP
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
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
a relay service for communication with people with disabilities in
the call.
12. Call termination 12. Call termination
It is undesirable for the caller to terminate an emergency call. It is undesirable for the caller to terminate an emergency call.
PSAP terminates a call using the normal SIP call termination PSAP terminates a call using the normal SIP call termination
procedures. 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 flash Hold should as call waiting, call transfer, three way call and flash Hold should
be disabled. be 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. A UA can determine a PSAP call from a PSAP and should be disabled. There is no way to reliably
back by examining the domain of incoming calls after placing an 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
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. A time limit after an emergency call should from the emergency call. Any call from the same domain and directed
be established during which any call from the same domain and to the supplied Contact header or AoR after an emergency call should
directed to the supplied Contact: or AoR should be accepted as a be accepted as a call-back from the PSAP if it occurs within a
call-back from the PSAP. 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. With the Internet comes a for persons who have hearing disabilities. Using SIP signaling
wider array of potential media that a PSAP should accept. Using SIP includes the capability to negotiate media. Normal SIP offer/answer
signaling includes the capability to negotiate media. Normal SIP [RFC3264] negotiations should be used to agree on the media streams
offer/answer [RFC3264] negotiations should be used to agree on the to be used. PSAPs should accept real-time text [RFC4103]. All PSAPs
media streams to be used. PSAPs should accept real-time text should accept G.711 A-law (and mu-law in North America) encoded voice
[RFC4103]. All PSAPs should accept G.711 A-law (and mu-Law in North as described in [RFC3551]. Newer text forms are rapidly appearing,
America) encoded voice as described in [RFC3551]. Newer text forms with instant messaging now very common, PSAPs should accept IM with
are rapidly appearing, with Instant Messaging now very common, PSAPs at least "pager-mode" MESSAGE request [RFC3428] as well as Message
should accept IM with at least "pager-mode" MESSAGE [RFC3428] as well Session Relay Protocol [RFC4975]. Video may be important to support
as Message Session Relay Protocol [RFC4975]. Video may be important Video Relay Service (sign language interpretation) as well as modern
to support Video Relay Service (Sign language interpretation) as well video phones.
as modern video phones.
While it is desirable for media to be kept secure, preferably by use While it is desirable for media to be kept secure, preferably by use
of Secure RTP [RFC3711], there is not yet consensus on how best to of Secure RTP [RFC3711], there is not yet consensus on how best to
signal keying material for SRTP. As a consequence, no recommendation signal keying material for SRTP. As a consequence, no recommendation
to support SRTP can be made yet for emergency calls. to support SRTP can be made yet for emergency calls.
15. Testing 15. Testing
Since the emergency calling architecture consists of a number of Since the emergency calling architecture consists of a number of
pieces operated by independent entities, it is important to be able pieces operated by independent entities, it is important to be able
to test whether an emergency call is likely to succeed without to test whether an emergency call is likely to succeed without
actually occupying the human resources at a PSAP. Both signaling and actually occupying the human resources at a PSAP. Both signaling and
media paths need to be tested since NATs and firewalls may allow the media paths need to be tested since NATs and firewalls may allow the
session setup request to reach the PSAP, while preventing the session setup request to reach the PSAP, while preventing the
exchange of media. exchange of media.
[I-D.ietf-ecrit-phonebcp] includes a description of an automated test <> 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 would 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 from LoST. A manual operation for the is returned by the LoST server.
test should also be possible.
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 overused, it may temporarily or test, and since the process could be abused, it may temporarily or
permanently suspend its operation. permanently suspend its operation.
There is a concern associated with testing during a so-called There is a concern associated with testing during a so-called
"avalanche-restart" event where, for example a large power outage "avalanche-restart" event where, for example a large power outage
affects a large number of endpoints, that, when power is restored, affects a large number of endpoints, that, when power is restored,
all attempt to reboot and, possibly, test. Devices need to randomize all attempt to reboot and, possibly, test. Devices need to randomize
their initiation of a boot time test to avoid the problem. their initiation of a boot time test to avoid the problem.
16. Security Considerations 16. Security Considerations
Security considerations for emergency calling have been documented in Security considerations for emergency calling have been documented in
[RFC5069], and [I-D.barnes-geopriv-lo-sec]. [RFC5069] and [I-D.barnes-geopriv-lo-sec].
17. IANA Considerations 17. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
18. Acknowledgements 18. Acknowledgements
This draft was created from a This draft was created from a
draft-schulzrinne-sipping-emergency-arch-02 together with sections draft-schulzrinne-sipping-emergency-arch-02 together with sections
from draft-polk-newton-ecrit-arch-considerations-02. from draft-polk-newton-ecrit-arch-considerations-02.
Design Team members participating in this draft creation include Design Team members participating in this draft creation include
Hannes Tschofenig, Ted Hardie, Martin Dolly, Marc Linsner, Roger Martin Dolly, Stu Goldman, Ted Hardie, Marc Linsner, Roger Marshall,
Marshall, Stu Goldman, Shida Schubert and Tom Taylor. Further Shida Schubert, Tom Taylor and Hannes Tschofenig,. Further comments
comments and input were provided by Richard Barnes, Barbara Stark and and input were provided by Richard Barnes, Barbara Stark and James
James Winterbottom. Winterbottom.
19. Informative References 19. Informative References
[I-D.barnes-geopriv-lo-sec] [I-D.barnes-geopriv-lo-sec]
Barnes, R., Lepinski, M., Tschofenig, H., and H. Barnes, R., Lepinski, M., Tschofenig, H., and H.
Schulzrinne, "Additional Location Privacy Considerations", Schulzrinne, "Additional Location Privacy Considerations",
draft-barnes-geopriv-lo-sec-03 (work in progress), draft-barnes-geopriv-lo-sec-04 (work in progress),
July 2008. January 2009.
[I-D.ietf-ecrit-phonebcp] [I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-06 (work in progress), draft-ietf-ecrit-phonebcp-07 (work in progress),
November 2008. January 2009.
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-11 (work in draft-ietf-geopriv-http-location-delivery-13 (work in
progress), December 2008. progress), February 2009.
[I-D.ietf-geopriv-lis-discovery] [I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-05 (work in progress), draft-ietf-geopriv-lis-discovery-07 (work in progress),
December 2008. February 2009.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
(work in progress), November 2008. (work in progress), November 2008.
[I-D.ietf-sip-gruu] [I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
skipping to change at page 35, line 27 skipping to change at page 35, line 9
Supporting Emergency Telecommunications Service (ETS) in Supporting Emergency Telecommunications Service (ETS) in
IP Telephony", RFC 4190, November 2005. IP Telephony", RFC 4190, November 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony
Device Requirements and Configuration", RFC 4504,
May 2006.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006. Configuration Information", RFC 4776, November 2006.
[RFC4967] Rosen, B., "Dial String Parameter for the Session [RFC4967] Rosen, B., "Dial String Parameter for the Session
Initiation Protocol Uniform Resource Identifier", Initiation Protocol Uniform Resource Identifier",
RFC 4967, July 2007. RFC 4967, July 2007.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007. Session Relay Protocol (MSRP)", RFC 4975, September 2007.
 End of changes. 118 change blocks. 
486 lines changed or deleted 523 lines changed or added

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