One document matched: draft-ietf-ecrit-framework-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2396 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2396.xml">
<!ENTITY rfc2401 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2401.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3263 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml">
<!ENTITY rfc3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY rfc3265 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml">
<!ENTITY rfc3311 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3311.xml">
<!ENTITY rfc3325 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml">
<!ENTITY rfc3428 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3428.xml">
<!ENTITY rfc3515 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3515.xml">
<!ENTITY rfc3693 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml">
<!ENTITY rfc3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3551 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY rfc3711 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY rfc3825 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3825.xml">
<!ENTITY rfc3840 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3840.xml">
<!ENTITY rfc3841 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3841.xml">
<!ENTITY rfc3856 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3856.xml">
<!ENTITY rfc3966 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3966.xml">
<!ENTITY rfc4119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml">
<!ENTITY rfc4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY rfc4103 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4103.xml">
<!ENTITY rfc4190 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4190.xml">
<!ENTITY rfc4474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml">
<!ENTITY rfc4507 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4507.xml">
<!ENTITY rfc4676 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4676.xml">
<!ENTITY rfc4967 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4967.xml">
<!ENTITY rfc4975 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4975.xml">
<!ENTITY rfc5012 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5012.xml">
<!ENTITY rfc5069 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5069.xml">
<!ENTITY rfc5139 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5139.xml">
<!ENTITY draft-ietf-ecrit-service-urn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-service-urn.xml">
<!ENTITY draft-ietf-sip-location-conveyance SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-location-conveyance.xml">
<!ENTITY draft-ietf-sipping-config-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-config-framework.xml">
<!ENTITY draft-ietf-sip-gruu SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-gruu.xml">
<!ENTITY draft-ietf-sip-outbound SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-outbound.xml">
<!ENTITY draft-ietf-sip-sips SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-sips.xml">
<!ENTITY draft-ietf-ecrit-lost SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-lost.xml">
<!ENTITY draft-ietf-ecrit-phonebcp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-phonebcp.xml">
<!ENTITY draft-ietf-sipping-service-examples SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-service-examples.xml">
<!ENTITY draft-ietf-geopriv-http-location-delivery SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery.xml">
<!ENTITY draft-barnes-geopriv-lo-sec SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.barnes-geopriv-lo-sec.xml">
<!ENTITY draft-ietf-ecrit-dhc-lost-discovery SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-dhc-lost-discovery.xml">
<!ENTITY draft-thomson-geopriv-lis-discovery SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-lis-discovery.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-ietf-ecrit-framework-05" ipr="full3978">
<front>
<title abbrev="Emergency Call Framework">Framework for Emergency Calling
using Internet Multimedia</title>
<author fullname="Brian Rosen" initials="B.R." surname="Rosen">
<organization abbrev="NeuStar">NeuStar, Inc.</organization>
<address>
<postal>
<street>470 Conrad Dr</street>
<city>Mars</city>
<region>PA</region>
<code>16046</code>
<country>US</country>
</postal>
<email>br@brianrosen.net</email>
</address>
</author>
<author fullname="Henning Schulzrinne" initials="H.S."
surname="Schulzrinne">
<organization abbrev="Columbia U.">Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7042</phone>
<email>hgs@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<author fullname="James Polk" initials="J.P" surname="Polk">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>3913 Treemont Circle</street>
<city>Colleyville</city>
<region>Texas</region>
<code>76034</code>
<country>US</country>
</postal>
<phone>+1-817-271-3552</phone>
<email>jmpolk@cisco.com</email>
</address>
</author>
<author fullname="Andrew Newton" initials="A.N." surname="Newton">
<organization>TranTech/MediaSolv</organization>
<address>
<postal>
<street>4900 Seminary Road</street>
<city>Alexandria</city>
<region>VA</region>
<code>22311</code>
<country>US</country>
</postal>
<phone>+1 703 845 0656</phone>
<email>andy@hxr.us</email>
</address>
</author>
<date day="25" month="February" year="2008" />
<area>rai</area>
<workgroup>ecrit</workgroup>
<abstract>
<t>The IETF has several efforts targeted at standardizing various aspects of placing emergency calls.
This document describes how all of those component parts are used to support emergency calls from citizens
and visitors to authorities.</t>
</abstract></front><middle>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"></xref>.</t>
<t>This document uses terms from <xref target="RFC3261"></xref> and <xref target="RFC5012"></xref>.
In addition the following terms are used:
<list style="hanging">
<t hangText="Access network:">
The access network supplies IP packet service to an endpoint. Examples of access networks include digital subscriber lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local area networks, or cellular data networks.</t>
<t hangText="(Emergency) Call taker:">
An emergency call taker answers an emergency call at the PSAP.</t>
<t hangText="Confidence:">
Confidence is an estimate indicating how sure the measuring system is that the actual location of the person is within the bounds defined by the uncertainty value, expressed as a percentage. For example, a value of 90% indicates that the actual location is within the uncertainty nine times out of ten.</t>
<t hangText="Dispatch Location:">The dispatch location is the location used for dispatching
responders to the person in need of assistance.
The dispatch location must be sufficiently precise to easily locate the callee;
it typically needs to be more accurate than the routing location.</t>
<t hangText="Emergency services routing proxy (ESRP):"> An emergency services routing proxy
provides routing services for a group of PSAPs.</t>
<t hangText="Location configuration:">
During location configuration, an endpoint learns its physical location.</t>
<t hangText="Location conveyance:">
Location conveyance delivers location information to another element.</t>
<t hangText="Location determination:">
Location determination finds where an endpoint is physically located.
For example, the endpoint may contain a GPS receiver used to measure its own
location or the location may be determined by a network administrator using a wiremap database.</t>
<t hangText="Location Information Server (LIS):"> A Location Information Server stores location information for retrieval by an authorized entity.</t>
<t hangText="Mobile device:">
A mobile device is a user agent that may change its physical location and
possibly its network attachment point during an emergency call.</t>
<t hangText="NENA (National Emergency Number Association):"> The National Emergency
Number Association is an organization of professionals to "foster the technological
advancement, availability and implementation of a universal emergency telephone number system."
It develops emergency calling specifications and procedures.</t>
<t hangText="Nomadic device (user):">
A nomadic user agent is connected to the network temporarily, for relatively short durations,
but does not move significantly during the lifetime of a network connection or during the
emergency call.
Examples include a laptop using an IEEE 802.11 hotspot or a desk IP phone that is moved
from one cubicle to another.</t>
<t hangText="Physical Location:">
A physical location describes where a person or device is located in physical space,
described by a coordinate system. It is distinguished from the network location,
described by a network address.
</t>
<t hangText="Routing Location:">
The routing location of a device is used for routing an emergency call and may
not be as precise as the Dispatch Location.</t>
<t hangText="Stationary device:">
An stationary device is not mobile and is connected to the network at a fixed,
long-term-stable physical location. Examples include home PCs or pay phones.</t>
<t hangText="Uncertainty:">
Uncertainty is an estimate, expressed in a unit of length, indicating the diameter
of a circle that contains the device with the probability indicated by the confidence
value.</t>
</list></t>
</section><section title="Introduction">
<t>Requesting help in an emergency using a communications device such as a telephone or mobile
is an accepted practice in most of the world. As communications devices increasingly utilize
the Internet to interconnect and communicate, users will continue to expect to use such devices
to request help, regardless of whether or not they communicate using IP. This document describes
establishment of a communications session by a user to a "Public Safety Answering Point" (PSAP)
that is a call center established by response agencies to accept emergency calls.
Such citizen/visitor-to-authority calls can be distinguished from those that are created by
responders (authority-to-authority) using public communications infrastructure often involving
some kind of priority access as defined in Emergency Telecommunications Service (ETS) in IP
Telephony <xref target="RFC4190"></xref>. They also can be distinguished from emergency warning
systems that are authority-to-citizen.</t>
<t>Supporting emergency calling requires cooperation by a number of elements, their vendors and
service providers. This document discusses how end device and applications create emergency calls, how access
networks supply location for some of these devices, how service providers assist the establishment
and routing, and how PSAPs receive calls from the Internet.</t>
<t>The emergency response community will have to upgrade their facilities to support a wider
range of communications services, but cannot be expected to handle wide variation in device and
service capability. New devices and services are being made available that could be used to
make a request for help that are not traditional telephones, and users are increasingly expecting
to use them to place emergency calls. However, many of the technical advantages of Internet
multimedia require re-thinking of the traditional emergency calling architecture. This challenge
also offers an opportunity to improve the operation of emergency calling technology, while potentially
lowering its cost and complexity.</t>
<t>It is beyond the scope of this document to enumerate and discuss all the differences between
traditional (Public Switched Telephone Network) and IP-based telephony, but calling on the Internet
is characterized by:
<list style="symbols">
<t>the interleaving over the same infrastructure of a wider variety of services; </t>
<t>the separation of the access provider from the application provider; </t>
<t>the plethora of different media that can be accommodated; </t>
<t>the potential mobility of all end systems, including endpoints nominally thought of as fixed systems
and not just those using radio access technology. For example, consider a wired phone connected to a router
using a mobile data network such as EV-DO as an uplink.</t>
</list></t>
<t>This document focuses on how devices using the Internet can place emergency calls and how PSAPs
can handle Internet multimedia emergency calls natively, rather than describing how circuit-switched
PSAPs can handle VoIP calls. In many cases, PSAPs making the transition from circuit-switched
interfaces to packet-switched interfaces may be able to use some of the mechanisms described here,
in combination with gateways that translate packet-switched calls into legacy interfaces, e.g.,
to continue to be able to use existing call taker equipment. There are many legacy telephone
networks that will persist long after most systems have been upgraded to IP origination and
termination of emergency calls. Many of these legacy systems use telephone number based routing.
Gateways and conversions between existing systems and newer systems defined by this document will be
required. Since existing systems are governed primarily by local government regulations and national
standards, the gateway and conversion details will be governed by national standards and thus are
out of scope for this document.</t>
<t>Existing emergency call systems are organized locally or nationally; there are currently no international
standards. However, the Internet crosses national boundaries, and thus international standards for
equipment and software are required. To further complicate matters, VoIP endpoints can be connected
through tunneling mechanisms such as virtual private networks (VPNs). Tunnels can obscure the identity
of the actual access network that knows the location. This significantly complicates emergency calling,
because the location of the caller and the first element that routes emergency calls can be on different
continents, with different conventions and processes for handling of emergency calls.</t>
<t>The IETF has historically refused to create national variants of its standards. Thus, this document
attempts to take into account best practices that have evolved for circuit switched PSAPs, but makes no
assumptions on particular operating practices currently in use, numbering schemes or organizational
structures.</t>
<t>This document discusses the use of the Session Initiation Protocol (SIP) <xref target="RFC3261"></xref>
by PSAPs and calling parties. While other inter-domain call signaling protocols may be used for emergency
calling, SIP is ubiquitous and possesses the proper support of this use case. Only protocols such as
H.323, XMPP/Jingle, ISUP and SIP are suitable for inter-domain communications, ruling out Media Gateway
Controller protocols
such as MGCP or H.248/Megaco. The latter protocols can be used by the enterprise or carrier
placing the call, but any such call would reach the PSAP through a media gateway controller, similar to
how inter-domain VoIP calls would be placed. Other signaling protocols may also use protocol translation
to communicate with a SIP-enabled PSAP.</t>
<t>Existing emergency services rely exclusively on voice and conventional text telephony ("TTY") media
streams. However, more choices of media offer additional ways to communicate and evaluate the situation
as well as to assist callers and call takers in handling emergency calls. For example, instant messaging
and video could improve the ability to communicate and evaluate the situation and to provide appropriate
instruction prior to arrival of emergency crews. Thus, the architecture described here supports the
creation of sessions of any media type, negotiated between the caller and PSAP using existing SIP protocol
mechanisms <xref target="RFC3264"></xref>.</t>
<t>Since this document is a framework document it does not include normative behavior. A companion document, <xref
target="I-D.ietf-ecrit-phonebcp"></xref> describes Best Current Practice for this subject and contains normative
language for devices, access and calling network elements.</t>
<t>Supporting emergency calling does not require any specialized SIP header fields, request methods,
status codes, message bodies, or event packages, but does require that existing mechanisms be used in
certain specific ways, as described below. User Agents (UAs) unaware of the recommendations in this draft may
be able to place emergency calls, but functionality may be impaired. For example, if the UA does not
implement the location mechanisms described, an emergency call may not be routed to the correct PSAP,
and if the caller is unable to supply his exact location, dispatch of emergency responders may be delayed.
Suggested behavior for both endpoints and servers is provided.</t>
<t>From the point of view of the PSAP, three essential elements characterize an emergency call:
<list style="symbols">
<t>The call is routed to the most appropriate PSAP, based primarily on the location of the
caller.</t>
<t>The PSAP must be able to automatically obtain the location of the caller with sufficient accuracy to
dispatch a responder to help the caller.</t>
<t>The PSAP must be able to re-establish a session to the caller if for any reason the original session
is disrupted.</t>
</list></t>
</section><section title="Overview of how emergency calls are placed">
<t>An emergency call can be distinguished (<xref target="Identifying"></xref>) from any other call
by a unique Service URN <xref target="I-D.ietf-ecrit-service-urn"></xref> that is placed in the call
set-up signaling when a home or visited emergency dial string is detected. Because emergency services
are local to specific geographic regions, a caller must obtain his location (
<xref target="Location"></xref>) prior to making emergency calls. To get this location, either a form of
measuring, for example, GPS (<xref target="EndSystemMeasuredLocation"></xref>) is deployed, or
the endpoint is configured (<xref target="LocationConfiguration"></xref>)
with its location from the access network's Location Information Server (LIS). The location is conveyed
(<xref target="Conveyance"></xref>) in the SIP signaling with the call. The call is routed
(<xref target="Routing"></xref>) based on location using the LoST protocol
<xref target="I-D.ietf-ecrit-lost"></xref>, which maps a location to a set of PSAP or URIs. Each URI
resolves to a PSAP or an Emergency Services Routing Proxy (ESRP) that serves an incoming proxy for group of PSAPs.
The call arrives at the PSAP with the location included in the INVITE request.</t>
<t>The following is a quick overview for a typical Ethernet connected telephone using SIP signaling.
It illustrates one set of choices for various options presented later in this document.
<list style="symbols">
<t>The phone "boots" and connects to its access network</t>
<t>The phone gets location from the DHCP server in civic <xref target="RFC4676"></xref> or geo
<xref target="RFC3825"></xref> forms, a HELD server <xref target="I-D.ietf-geopriv-http-location-delivery"></xref>
or the first level switch's LLDP server <xref target="LLDP"></xref>.</t>
<t>The phone obtains the local emergency dial string(s) from the <xref target="I-D.ietf-ecrit-lost"></xref>
server for its current location. It also receives and caches the PSAP URI obtained from LoST.</t>
<t>Some time later, the user places an emergency call. The phone recognizes an emergency call from the dial strings and uses "urn:service:sos"
<xref target="I-D.ietf-ecrit-service-urn"></xref> to mark an emergency call.</t>
<t>It determines the PSAP's URI by querying the LoST mapping server with its location.</t>
<t>It puts its location in the SIP INVITE in a Geolocation header
<xref target="I-D.ietf-sip-location-conveyance"></xref> and forwards the call using its normal
outbound call processing, which commonly involves an outgoing proxy.</t>
<t>The proxy recognizes the call as an emergency call and routes the call using normal SIP routing
mechanisms to the URI specified.</t>
<t>The call routing commonly traverses an incoming proxy server (ESRP) in the emergency services network.
That proxy would route the call to the PSAP.</t>
<t>The call is established with the PSAP and mutually agreed upon media streams are created.</t>
<t>The location of the caller is displayed to the call taker.</t>
</list></t>
<figure anchor="fig1" title="Emergency Call Component Topology">
<artwork>
Configuration Servers
. . . . . . . . . . . . . . . . .
. .
. +--------+ +----------+ .
. +--------+ | +----------+ | .
. | LIS | | | SIP | | .
. | |-+ | Registrar|-+ .
. +--------+ +----------+ .
. ^ ^ .
. . | . . . . . . . | . . . . . .
| |
|[M1][M4] |[M2]
| | +--------+
|+--------------+ +--------+ |
|| | LoST | |
||+-------------------->| Servers|-+
||| [M3][M5] +--------+ +-------+
||| | PSAP2 |
||| +-------+
|||
||| [M6] +-------+ [M7]+------+ [M8]+-------+
Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker
+-------+ +------+ +-------+
+-------+
| PSAP3 |
+-------+
</artwork></figure>
<figure anchor="fig2">
<artwork>
The typical message flow for this example using Alice as the caller:
[M1] Alice -> LIS LCP Request(s) (ask for location)
LIS -> Alice LCP Reply(s) (replies with location)
[M2] Alice -> Registrar SIP REGISTER
Registrar -> Alice SIP 200 OK (REGISTER)
[M3] Alice -> LoST Server Initial LoST Query (contains location)
Lost Server -> Alice Initial LoST Response (contains
PSAP-URI and dial string)
Some time later, Alice dials or otherwise initiates an emergency call
[M4] Alice -> LIS LCP Request (update location)
LIS -> ALICE LCP Reply (replies with location)
[M5] Alice -> LoST Server Update LoST Query (contains location)
Lost Server -> Alice LoST Response (contains PSAP-URI)
[M6] Alice to Outgoing Proxy INVITE (service URN,
Location and PSAP URI)
Outgoing Proxy to ESRP INVITE (service URN,
Location and PSAP URI)
ESRP to PSAP INVITE (service URN, Location and PSAP URI)
200 OK and ACK propogated back from PSAP to Alice
</artwork></figure>
<t>Figure 1 shows emergency call component topology and the text above shows call establishment.
These include the following components:
<list style="symbols">
<t>Alice - who makes the emergency call.</t>
<t>Configuration Servers - Servers providing Alice's UA its IP address and other configuration
information, perhaps including location by-value or by-reference. In this flow, DHCP is used as
an example location configuration protocol (LCP). Configuration servers also may include a SIP
registrar for Alice's UA. Most SIP UAs will register, so it will be a common scenario for UAs
that make emergency calls to be registered with such a server in the originating calling network.
Registration would be required for the PSAP to be able to call back after an emergency call is
completed. All the configuration messages are labeled M1 through M3, but could easily require
more than 3 messages to complete.</t>
<t>LoST server - Processes the LoST request for Location + Service URN to PSAP-URI Mapping function,
either for an initial request from a UA, or an in-call routing by the Proxy server in the
originating network, or possibly by an ESRP.</t>
<t>ESRP - The emergency services routing proxy server that is the incoming call proxy in the emergency
services domain. The ESRP makes further routing decisions (e.g. based on PSAP state and the location
of the caller) to choose the actual PSAP that handles the call. In some jurisdictions, this may
involve another LoST query.</t>
<t>PSAP - Call center where emergency calls are destined for.</t>
</list></t>
<t>Generally, Alice's UA either has location configured manually, has an integral location measurement
mechanism, or it runs a LCP [M1] to obtain location from the access (broadband) network.
For most devices, a LCP will be used, for example a DHCPREQUEST message or another location acquisition
mechanism. Alice's UA then will most 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 fails during an emergency call, or to use to test the emergency call
mechanism. The LoST response may contain the dial string for emergency calls appropriate for the
location provided.</t>
<t>At some time after her device has booted, Alice initiates an emergency call. She may do this
by dialing an emergency dial string valid for her current ("local") location, or for her "home"
location.</t>
<t>The UA recognizes the dial string. The UA attempts to refresh its location [M4], and with that
location, to refresh the LoST mapping [M5], in order to get the most accurate information to use
for routing the call. If the location request or the LoST request fails, or takes too long, the
UA uses values it has cached.</t>
<t>The UA creates a SIP INVITE [M6] request that includes the location.
<xref target="I-D.ietf-sip-location-conveyance"></xref> defines a SIP Geolocation header that
contains either a location-by-reference URI or a <xref target="RFC2396"></xref> "cid" URL
indicating where in the message body the location-by-value is.</t>
<t>The INVITE message is routed to the ESRP [M7], which is the first inbound proxy for the
emergency services domain. This message is then routed by the ESRP towards the most appropriate
PSAP for Alice's location [M8], as determined by the location and other information.</t>
<t>A proxy in the PSAP chooses an available call taker and extends the call to its UA.</t>
<t>The 200 OK response to the INVITE request traverses the path in reverse, from call taker
UA to PSAP proxy to ESRP to originating network proxy to Alice's UA. The ACK request completes the call
set-up and the emergency call is established, allowing the PSAP call-taker to talk to Alice
about Alice's emergency.</t>
</section><section anchor="WhichDevices" title="Which devices and services should support emergency calls">
<t>Current PSAPs support voice calls and real-time text calls placed through PSTN facilities or systems
connected to the PSTN. Future PSAPs will however support Internet
connectivity and a wider range of media types and provide higher functionality. In general,
if a user could reasonably expect to be able to place a call for help with the device, then the
device or service should support emergency calling. Certainly, any device or service that looks
like and works like a telephone (wired or mobile) should support emergency calling, but
increasingly, users have expectations that other devices and services should work.</t>
<t>Devices that create media sessions and exchange audio,
video and/or text, and have the capability to establish sessions to a wide variety of addresses,
and communicate over private IP networks or the Internet, should support emergency calls.</t>
</section><section anchor="Identifying" title="Identifying an emergency call">
<t>Using the PSTN, emergency help can often be summoned by dialing a nationally designated,
widely known number, regardless of where the telephone was purchased. The appropriate number
is determined by the infrastructure the telephone is connected to. However, this number 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. In some countries, there is a single digit sequence that is used
for all types of emergencies. In others, there are several sequences that are specific to the
type of responder needed, e.g., one for police, another for fire. For end systems, on the other
hand, it is desirable to have a universal identifier, independent of location, to allow the
automated inclusion of location information and to allow the device and other entities in the
call path to perform appropriate processing within the signaling protocol in an emergency call
set-up.</t>
<t>Since there is no such universal identifier, as part of the overall emergency calling
architecture, common emergency call URNs are defined in
<xref target="I-D.ietf-ecrit-service-urn"></xref>. For a single number environment the urn
is "urn:service:sos". Users are not expected to "dial" an emergency URN. Rather, appropriate
emergency dial strings are translated to corresponding service URNs, carried in the Request-URI
of the INVITE request. Such translation is best done by the endpoint, among other reasons,
because emergency calls convey
location in the signaling, but non emergency calls do not normally do that. If the device
recognizes the emergency call, it can include location. Dial string recognition could be
performed in a signaling intermediary (proxy server) if for some reason the endpoint does not
recognize it. </t>
<t>For devices that are mobile or nomadic, an issue arises of whether the home or
visited dialing strings should be used. Many users would prefer that their home dialing
sequences work no matter where they are. However, local laws and regulations may require the visited
dialing sequence(s) work. Therefore, the visited dial string must work while having the home dial
string work is optional.</t>
<t>The mechanism for obtaining the dialing sequences for a given location is provided by LoST
<xref target="I-D.ietf-ecrit-lost"></xref>. If the endpoint does not support the translation
of dial strings to telephone numbers, the dialing sequence is represented as a dial
string <xref target="RFC4967"></xref> and the outgoing proxy has to recognize the dial string
and translate to the service URN. To determine the local emergency dial string, the proxy needs the
location of the endpoint. This may be difficult in situations where the user can roam or be
nomadic. Endpoint recognition of emergency dial strings is therefore preferred. If
a service provider is unable to guarantee that it can correctly determine local emergency
dialstrings, wherever its subscribers may be, then it is required that the endpoint do the recognition.</t>
<t>Note: It is undesirable to have a single button emergency call user interface element.
These mechanisms tend to result in a very high rate of false or accidental emergency calls.
In order to minimize this rate, devices should only initiate emergency calls based on entry of
specific emergency call dial strings.</t>
</section><section anchor="Location" title="Location and its role in an emergency call">
<t>Location is central to the operation of emergency services. It is frequently the case that
the caller reporting an emergency is unable to provide a unique, valid location themselves. For this
reason, location provided by the endpoint or the access network is needed. For practical
reasons, each PSAP generally handles only calls for a certain geographic area, with overload
arrangements between PSAPs to handle each others calls. Other calls that reach it by accident must
be manually re-routed (transferred) to the most appropriate PSAP, increasing call handling delay
and the chance for errors. The area covered by each 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.</t>
<t>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 boundaries and may straddle more than one city.
Irregular boundaries are common, often for historical reasons. Routing must be done based on actual
PSAP service boundaries -- the closest PSAP, or the PSAP that serves the nominal city name provided
in the location, may not be the correct PSAP.</t>
<t>Accuracy of routing location is a complex subject. Calls must be routed quickly, but accurately,
and location determination is often a time/accuracy tradeoff, especially with mobile devices or
self measuring mechanisms. It is considered acceptable to base a routing decision on an accuracy
equal to the area of one sector of a mobile cell site if no more accurate routing location is
available.</t>
<t>Routing to the most appropriate PSAP is always calculated on the location of the caller,
despite the fact that some emergency calls are placed on behalf of someone else, and the location
of the incident is sometimes not the location of the caller. In some cases, there are other
factors that enter into the choice of the PSAP that gets the call, such as time of day, caller media
requests and language preference, call load, etc. However, location
of the caller is the primary input to the routing decision.</t>
<t>Routing is but one of two uses for location in an emergency call. The other is for dispatch of
a responder, which must be very precise. Many mechanisms used to locate a caller have a relatively long "cold start" time.
To get a location accurate enough for dispatch may take as much as 30 seconds. This is too long to
wait for emergencies. Accordingly, it is common, especially in mobile systems, to use a coarse
location, for example, the cell site and sector serving the call, for call routing purposes, and then
to update the location when a more precise value is known prior to dispatch. In this document we
use "routing location" and "dispatch location" when the distinction matters.</t>
<t>Accuracy of dispatch location is sometimes determined by local regulation, and is constrained
by available technology. The actual requirement exceeds available technology. It is required that
a device making an emergency call close to the "demising" or separation wall between two
apartments in a high rise apartment building report location with sufficient accuracy to
determine on what side of the wall it is on. This implies perhaps a 3 cm accuracy requirement.
As of the date of this memo, typical assisted GPS uncertainty with 95% confidence is 100 m. As
technology advances, the accuracy requirements for location will need to be increased. Wired systems
using wire tracing mechanisms can provide location to a wall jack in specific room on a floor in a building,
and may even specify a cubicle or even smaller resolution. As this discussion illustrates, emergency
call systems demand the most stringent location accuracy available.</t>
<t>Location usually involves several steps to process and multiple elements are involved. In
Internet emergency calling, where the endpoint is located is "determined" using a variety of
measurement or wire-tracing methods. Endpoints may be "configured" with their own location by
the access network. In some circumstances, a proxy server may insert location into the signaling
on behalf of the endpoint. The location is "mapped" to the URI to send the call to, and the
location is "conveyed" to the PSAP (and other elements) in the signaling. Likewise, we employ
Location Configuration Protocols, Location Mapping Protocols, and Location Conveyance Protocols
for these functions. </t>
<t>This document provides guidance for generic network configurations with respect to location. It is
recognized that unique issues may exist in some network deployments. The
IETF will continue to investigate these unique situations and provide
further guidance, if warranted, in future documents.</t>
<section anchor="LocationTypes" title="Types of location information">
<t>There are several ways location can be specified:
<list style="hanging">
<t hangText="Civic:">
Civic location information describes the location of a person or object by a street address
that corresponds to a building or other structure. Civic location may include more fine grained
location information such as floor, room and cubicle. Civic information comes in two forms:
<list style="hanging">
<t hangText="Jurisdictional">
this refers to a civic location using actual political subdivisions, especially for the
community name.</t>
<t hangText="Postal">
this refers to a civic location for mail delivery. The name of the post office
sometimes does not correspond to the community name and a postal address may contain
post office boxes or street addresses that do not correspond to an actual building.
Postal addresses are generally unsuitable for emergency call dispatch because the
post office conventions (for community name, for example) do not match those known
by the responders. The fact that they are unique can sometimes be exploited to
provide a mapping between a postal address and a civic address suitable to dispatch
a responder to. In IETF location protocols, there is an element (Postal Community Name)
that can be included in a location to provide the post office name as well as the
actual jurisdictional community name. There is no other accommodation for postal
addresses in these protocols.</t>
</list></t>
<t hangText="Geospatial (geo):">
Geospatial addresses contain longitude, latitude and altitude information based on an understood
datum and earth shape model. While there have been many datums developed over time, most modern
systems are using or moving towards the <xref target="WGS84"></xref> datum.</t>
<t hangText="Cell tower/sector:">
Cell tower/sector is often used for identifying the location of a mobile handset, especially for
routing of emergency calls. Cell tower and sectors identify the cell tower and the antenna sector
that a mobile device is currently using. Traditionally, the tower location is represented as a
point chosen to be within a certain PSAP service boundary who agrees to take calls originating
from that tower/sector, and routing decisions are made on that point. Cell/sector information
could also be represented as an irregularly shaped polygon of geospatial coordinates reflecting
the likely geospatial location of the mobile device. Whatever representation is used must route
correctly in the LoST database, where "correct" is determined by local PSAP management.</t>
</list></t>
<t>In IETF protocols, both civic and geospatial forms are supported. The civic forms include both
postal and jurisdictional fields. A cell tower/sector can be represented as a point (geo or civic)
or polygon. Other forms of location representation must be mapped into either a geo or civic for
use in emergency calls.</t>
<t>For emergency call purposes, conversion of location information from civic to geo or vice versa
prior to conveyance is not desirable. The location should be sent in the form it was determined.
Conversion between geo and civic requires a database. Where PSAPs need to convert from whatever form
they receive to another for responder purposes, they have a suitable database. However, if a
conversion is done before the PSAP's, and the database used is not exactly the same one the PSAP uses,
the double conversion has a high probability of introducing an error.</t>
</section><section anchor="LocationDetermination" title="Location determination">
<t>As noted above, location information can be entered by the user or installer of a device ("manual configuration"),
measured by the end system, can be delivered to the end system by some protocol or measured by a
third party and inserted into the call signaling. </t>
<t>In some cases, an entity may have multiple sources of location information, possibly partially
contradictory. This is particularly likely if the location information is determined both by the
end system and a third party. Although self measured location (e.g. GPS) is attractive, access
network provided location could be much more accurate, and more reliable in some environments such as
indoor
high rises in dense urban areas. In general, the closer an entity is to the source of location,
the more it is in the best position to determine which location is "best" for a particular purpose.
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.</t>
<section anchor="UserLocation" title="User-entered location information">
<t>Location information can be maintained by the end user or the installer of an endpoint in the
endpoint itself, or in a database.</t>
<t>Location information provided by end users is almost always less reliable than measured or wire
database information, as users may mistype location information or may enter civic address
information that does not correspond to a recognized (i.e., valid, see Section
<xref target="Validation"></xref>) address. Users can forget to change the data when the location of
a device changes during or after movement.</t>
<t>All that said, there are always a small number of cases where the automated mechanisms used by the
access network to determine location fail to accurately reflect the actual location of the endpoint.
For example, the user may deploy his own WAN behind an access network, effectively removing an endpoint
some distance from the access network's notion of its location. There must be some mechanism provided
to provision a location for an endpoint by the user or by the access network on behalf of a user.
The use of the mechanism introduces the possibility of users falsely declaring themselves to be
somewhere they are not. As an aside, normally, if an emergency caller insists that he is at a location
different from what any automatic location determination system reports he is, responders will always
be sent to the user's self-declared location. However, this is a matter of local policy and is outside
the scope of this document.</t>
</section><section anchor="WireDatabase" title='Access network "wire database" location information'>
<t>Location information can be maintained by the access network, relating some form of identifier for
the end subscriber or device to a location database ("wire database"). In enterprise LANs, wiremap
databases map Ethernet switch ports to building locations. In DSL installations, the local telephone
carrier maintains a mapping of wire-pairs to subscriber addresses.</t>
<t>Accuracy of location historically has been to a street address level. However, this is not sufficient
for larger structures. The PIDF-LO <xref target="RFC4119"></xref> with a recent extension
<xref target="RFC5139"></xref> permits interior building/floor/room
and even finer specification of location within a street address. When possible, interior
location should be supported.</t>
<t>The threshold for when interior location is needed is approximately 650 m2. This value is derived
from fire brigade recommendations of spacing of alarm pull stations. However, interior
space layout, construction materials and other factors should be considered. The ultimate goal
is to be able to find the person in need quickly if responders arrive at the location provided.</t>
<t>Even for IEEE 802.11 wireless access points, wire databases may provide sufficient location
resolution. The location of the access 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 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. The civic location of an IEEE 802.16 base station may be of
little use to emergency personnel, since the endpoint could be several kilometers away from the
base station.</t>
<t>Wire databases are likely to be the most promising solution for residential users
where a service provider knows the customer's service address. The service provider can then
perform address validation (see <xref target="Validation"></xref>), similar to the
current system in some jurisdictions.</t>
</section><section anchor="EndSystemMeasuredLocation" title="End-system measured location information">
<t>Global Positioning System (GPS) and similar satellite based (e.g., Galileo) receivers may be
embedded directly in the end device. GPS produces relatively high precision location fixes in
open-sky conditions, but the technology still faces several challenges in terms of performance
(time-to-fix and time-to-first-fix), as well as obtaining successful location fixes within
shielded structures, or underground. It also requires all devices to be equipped with the
appropriate GPS capability. GPS-derived locations are currently accurate to tens of meters.
Many mobile devices require using some kind of "assist", that may be operated by the access
network (A-GPS) or by a government (WAAS).</t>
<t>GPS systems may be always enabled and thus location will always be available accurately immediately
(assuming the device can "see" enough satellites). Mobile devices may not be able to sustain the
power levels required to keep the measuring system active. In such circumstances, when location is
needed, the device has to start up the measurement mechanism. This typically takes tens of seconds,
far too long to wait to be able to route an emergency call. For this reason, devices that
have end-system measured location mechanisms but need a "cold start period lasting more than a couple
seconds on need another way to get a routing location.
Typically this would be a location associated with a radio link (cell site/sector).</t>
</section><section anchor="NetworkMeasuredLocation" title="Network measured location information">
<t>The access network may locate end devices. Techniques include:
<list style="hanging">
<t hangText="Wireless triangulation:">
Elements in the network infrastructure triangulate end systems based on signal strength,
angle of arrival or time of arrival. Common mechanisms deployed include:
<list style="symbols">
<t>Time Difference Of Arrival - TDOA</t>
<t>Uplink Time Difference Of Arrival - U-TDOA</t>
<t>Angle of Arrival - AOA</t>
<t>RF fingerprinting</t>
<t>Advanced Forward Link Trilateration - AFLT</t>
<t>Enhanced Forward Link Trilateration - EFLT</t>
</list>
Sometimes multiple mechanisms are combined, for example A-GPS with AFLT</t>
<t hangText="Location beacons:">
A short range wireless beacon, e.g., using Bluetooth or infrared, announces its location
to mobile devices in the vicinity. This allows devices to get location from the beacon source's location.</t>
</list></t>
</section></section><section anchor="WhoAddsLocation" title="Who adds location, endpoint or proxy">
<t>The IETF emergency call architecture prefers endpoints to learn their location and supply it
on the call. Where devices do not support location, proxy servers may have to
add location to emergency calls. Some calling networks have relationships
with all access networks the device may be connected to, and that may allow the proxy to
accurately determine location of the endpoint. However, NATs and other middleboxes often make it
impossible to determine a reference identifier the access network could use with a LIS to determine the
location of the device. Systems designers are discouraged from relying on proxies to add location.
The technique
may be useful in some limited circumstances as devices are upgraded to meet the requirements of
this document, or where relationships between access networks and calling networks are feasible
and can be relied upon to get accurate location.</t>
<t>Proxy insertion of location complicates dial string recognition. As noted in
<xref target="Location"></xref>, local dial strings depend on the location of the caller.
If the device does not know its own location, it cannot use the LoST service to learn the
local emergency dial strings. 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 where the
dial string(s) change, or do the dial string determination itself.</t>
</section><section anchor="LocationReference" title="Location and references to location">
<t>Location information may be expressed as the actual civic or geospatial value but can be
transmitted as by value (wholly contained within the signaling message) or by reference
(i.e. as a URI pointing to the value residing on a remote node waiting to be dereferenced). Each form
is better suited to some applications than others.</t>
<t>When location is transmitted by value, the location information is available to each device;
on the other hand, location objects can be large, and only represent a single snapshot of the
device's location. Location references are small and can be used to represent a time-varying
location, but the added complexity of the dereference step introduces a risk that location
will not be available to parties that need it.</t>
</section><section anchor="LocationConfiguration" title="End system location configuration">
<t>Unless a user agent has access to provisioned or locally measured location information,
it must obtain it from the access network. There are several location configuration protocols
(LCPs) that can be used for this purpose including DHCP, HELD and LLDP:
<list style="hanging">
<t hangText="DHCP">
can deliver civic <xref target="RFC4676"></xref> or geospatial
<xref target="RFC3825"></xref> information. User agents need to support both formats. Note
that a user agent can use DHCP, via the DHCP REQUEST or INFORM messages, even if it uses
other means to acquire its IP address.</t>
<t hangText="HELD">
<xref target="I-D.ietf-geopriv-http-location-delivery"></xref> can deliver a civic or
geo, by value or by reference, as a layer 7 protocol. The query typically uses the IP address
of the requestor as an identifier and returns the location value or reference associated
with that identifier. HELD is typically carried in HTTP.</t>
<t hangText="Link-Layer Discovery Protocol">
<xref target="LLDP"></xref> with Media Endpoint Device extensions
<xref target="LLDP-MED"></xref> can be used to deliver location information directly from
the Layer 2 network infrastructure, and also supports both civic and geospatial formats
identical in format to DHCP methods.</t>
</list></t>
<t>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 mandatory-to-deploy LCP. For endpoints
with common network connections (such as an Ethernet jack or a WiFi connection) serious
incompatibilities would ensue unless every network supported every protocol, or
alternatively, every device supported every protocol. For this reason, a mandatory-to-implement
list of LCPs is
established in <xref target="I-D.ietf-ecrit-phonebcp"></xref>. Every endpoint that could
be used to place emergency calls must implement all of the protocols on the list. Every
access network must deploy at least one of them. It is recognized that this is an onerous
requirement that would be desirable to eliminate. However, since it is the
variability of the networks that prevent a single protocol from being acceptable, it
must be the endpoints that implement all of them, and to accommodate a wide range of
devices, networks must deploy at least one of them.</t>
<t>Often, network operators and device designers believe that they have a simpler
environment and some other network specific mechanism can be used to provide location.
Unfortunately, it is very rare to 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 support routers and LANs
behind a wireless data network WAN connection, with Ethernet connected phones
connected to that. It is possible that the access network could support a protocol not
on the list, and require every handset in that network to use that protocol for emergency
calls. However, the Ethernet-connected phone won't be able to acquire location, and the
user of the phone is unlikely to be dissuaded from placing an emergency call on that phone.
The widespread availability of gateways, routers and other network-broadening devices
means that indirectly connected endpoints are possible on nearly every network.
Network operators and vendors are cautioned that shortcuts to meeting this requirement
are seldom successful.</t>
<t>Location for non-mobile devices is normally expected to be acquired at network
attachment time and retained by the device. It should be refreshed when the cached value
expires. For example, if DHCP is the acquisition protocol, refresh of location
may occur when the IP address lease is renewed. At the time of an emergency call,
the location should be refreshed, with the retained location used if the location
acquisition does not immediately return a value. Mobile devices may determine location
at network attachment time and periodically thereafter as a backup in case location
determination at the time of call does not work. Mobile device location may be
refreshed when a TTL expires or the device moves beyond some boundaries (as provided by
<xref target="I-D.ietf-ecrit-lost"></xref>). Normally, mobile devices will acquire its
location at call time for use in an emergency call routing. See Section
<xref target="LocationUpdate"></xref> for a further discussion on location updates
for dispatch location.</t>
<t>There are many examples of end devices which are applications running on a more general
purpose device, such as a personal computer. In some circumstances, it is not possible for
application programs to access the network device at a level necessary to implement the LLDP-MED
protocol, and in other cases, obtaining location via DHCP may be impossible. In any case
it is desirable for an operating system which could be used for any application which
could make emergency calls to have an API which provides the location of the device for use
by any application.</t>
</section><section anchor="WhenConfigure" title="When location should be configured">
<t>Devices should get routing location immediately after obtaining local network
configuration information. The presence of NAT and VPN tunnels (that assign new IP
addresses to communications) can obscure identifiers used by LCPs to determine
location, especially for HELD. In some cases, such as residential NAT devices,
the NAT is placed before the access network demarcation point and thus the IP address
seen by the access network is the right identifier for location of the residence.
In many enterprise environments, VPN tunnels can obscure the actual IP address.
Some VPN mechanisms can be bypassed so that a query to the LCP can be designated to go
through the direct IP path, using the correct IP address, and not through the
tunnel. In other cases, no bypass is possible. Of course, LCPs that use Layer 2
mechanisms (DHCP Location options and LLDP-MED) are usually immune from such problems
because they do not use the IP address as the identifier for the device seeking
location.</t>
<t>It is desirable that routing location information be periodically refreshed.
A LIS supporting a million subscribers each refreshing once per day would need
to support a query rate of 1,000,00 / (24 * 60 * 60) = 12 queries per second.</t>
<t>It is desirable for routing location information to be requested immediately
before placing an emergency call. However, if there is any significant delay in
getting more recent location, the call should be placed with the most recent
location information the device has. In mobile handsets, routing is often
accomplished with the cell site and sector of the tower serving the call,
because it can take many seconds to start up the location determination mechanism
and obtain an accurate location.</t>
<t>There is a tradeoff between the time it takes to get a routing location and
the accuracy (technically, confidence and uncertainty) obtained. Routing an
emergency call quickly is required. However, 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 seconds, the current nominal time for a quick
fix, is a very long time to wait for help. Systems designers should attempt
to provide accurate routing location in much less time then that.</t>
<t>NENA recommends IP based systems complete calls in two seconds (i.e., last dial
press to ring at PSAP).</t>
</section><section anchor="Conveyance" title="Conveying location in SIP">
<t>When an emergency call is placed, the endpoint should put location in the
call signaling. This is referred to as "conveyance" to distinguish
it from "configuration". In SIP, the location information is conveyed following
the procedures in <xref target="I-D.ietf-sip-location-conveyance"></xref>.
Since the form of the location information obtained by the acquisition protocol may not
be the same as the conveyance protocol uses (PIDF-LO <xref target="RFC4119"></xref>),
mapping by the endpoint from the LCP form to PIDF may be required.</t>
</section><section anchor="LocationUpdate" title="Location updates">
<t>As discussed above, it make take some time for some measurement mechanisms
to get a location accurate enough for dispatch, and a routing location with less
accuracy may be provided to get the call established early. The PSAP needs the
dispatch location before it sends the call to the responder. This requires an
update of the location.</t>
<t>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.</t>
<t>A PSAP has no way to request an update of a location-by-value. If the UAC
gets new location, it must signal the PSAP using a reINVITE or UPDATE method
with a new Geolocation header to supply the new location.</t>
<t>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 <xref target=
"RFC3856"></xref> provides a suitable mechanism.</t>
<t>Generally, the PSAP can wait for an accurate location for dispatch. However,
there is no fixed limit known in advance; it depends on the
nature of the emergency. At some point the PSAP must dispatch. If the LIS is notifying
the PSAP with a SUBSCRIBE/NOTIFY mechanism, the PSAP could update the parameters in a filter
on the subscription.
(immediate response required).</t>
<t>When using a HELD dereference, the PSAP must specify the value "emergencyDispatch"
for the ResponseTime parameter. The LIS is should be aware of the needs of the PSAP
as they are local to one another.</t>
</section><section anchor="MultipleLocations" title="Multiple locations">
<t>Getting multiple locations all purported to describe the location of the caller
is confusing to all, and should be avoided. Handling multiple locations is discussed in . Conflicting location
information is particularly harmful if different routes (PSAPs) result from
LoST queries for the multiple locations. When they occur anyway, the general guidance
is that the entity earliest in the chain generally has more knowledge than later
elements to make an intelligent decision, especially about which location will be
used for routing. It is permissable to send multiple locations towards the PSAP,
but the element that choses the route must select one (and only one) location to use
with LoST.</t>
<t>Guidelines for dealing with multiple
locations are also given in <xref target="I-D.ietf-ecrit-lost"></xref>.
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 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 it has.</t>
<t>The UA or proxy should have the ability to understand how and from whom it learned
its location, and should include this information in the location objects
that are sent to the PSAP. That labeling provides the call-taker with many pieces of
information to make decisions upon, as well as guidance for what to ask the caller
and what to tell the responders.</t>
<t>The call must indicate the location information that has been used for routing,
so that the same location information is used for all call routing decisions.
The location conveyance mechanism
<xref target="I-D.ietf-sip-location-conveyance"></xref> contains a parameter
for this purpose.</t>
</section><section anchor="Validation" title="Location validation">
<t>It is recommended that location be validated prior to a device placing
an actual emergency call; some jurisdictions require that this be done.
Validation in this context means both that there is a mapping from the address
to a PSAP and that the PSAP understands how to direct responders to the location.
Determining the addresses that 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 city. In some countries, the current system provides validation.
For example, in the United States, the Master Street Address Guide (MSAG) records
all valid street addresses and is used to ensure that the service addresses in
phone billing records correspond to valid emergency service street addresses.
Validation is normally a concern for civic addresses, although there could be
a concern that a given geo is within at least one PSAP service boundary; that is,
a "valid" geo is one where there is a mapping.</t>
<t>LoST <xref target="I-D.ietf-ecrit-lost"></xref> includes a location validation
function. Validation is normally performed when a location is entered
into a Location Information Server. It should be confirmed periodically,
because the mapping database undergoes slow change; new streets are added or
removed, community names change, postal codes change, etc. Endpoints may wish
to validate locations they receive from the access network, and will need to
validate manually entered locations. Proxies that insert location may wish to
validate locations they receive from a LIS. Test functions
(<xref target="Testing"></xref>) should also re-validate.</t>
<t>When validation fails, the location given must not be used for an emergency call.
If validation is complete when location is first loaded into a LIS, any problems
can be found and fixed before devices could get the bad location. Failure of validation
arises because an error is made in determining the location, although occasionally
the LoST database is not up to date or has faulty information. In either case, the
problem must be identified and corrected before using the location.</t>
</section><section anchor="DefaultLocation" title="Default location">
<t>Occasionally, the access network cannot determine the actual location of
the caller. In these cases, it must supply a default location. The default location
should be as accurate as the network can determine. For example, in a cable network,
a default location for each Cable Modem Termination System (CMTS), with a
representative location for all cable modems served by that CMTS could be provided
if the network is unable to resolve the subscriber to anything more precise than the CMTS.
Default locations must be marked as such so that the PSAP knows that the
location is not accurate.</t>
</section><section anchor="OtherLocation" title="Location format conversion">
<t>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 return a PIDF.</t>
</section>
</section><section title="LIS and LoST Discovery">
<t>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
<xref target="I-D.thomson-geopriv-lis-discovery"></xref> and
<xref target="I-D.ietf-ecrit-dhc-lost-discovery"></xref></t>
<t>Until such DHCP records are widely available, it may be necessary for the service provider to provision a LoST server
address in the device.</t>
</section><section anchor="Routing" title="Routing the call to the PSAP">
<t>Emergency calls are routed based on one or more of the following criteria
expressed in the call setup request (INVITE):
<list style="hanging">
<t hangText="Location:">
Since each PSAP serves a limited geographic region and transferring existing
calls delays the emergency response, calls need to be routed to the most
appropriate PSAP. In this architecture, emergency call setup requests contain
location information, expressed in civic or geospatial coordinates, that allows
such routing. If there is no or imprecise (e.g., cell 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.</t>
<t hangText="Type of emergency service:">
In some jurisdictions, emergency calls for specific emergency services such as fire, police, ambulance or mountain
rescue are directed to just those emergency-specific PSAPs. This mechanism is
supported by marking emergency calls with the proper service identifier
<xref target="I-D.ietf-ecrit-service-urn"></xref>. Even in single number jurisdictions,
not all services are dispatched by PSAPs and may need alternate URNs to route calls
to the appropriate call center.</t>
<t hangText="Media capabilities of caller:">
In some cases, emergency call centers for specific caller media preferences,
such as typed text or video, are separate from PSAPs serving voice calls.
ESRPs are expected to be able to provide routing based on media. Also, even if media
capability does not affect the selection of the PSAP, there may be call takers
within the PSAP that are specifically trained, e.g., in interactive text or
sign language communications, where routing within the PSAP based on the media
offer would be provided.</t>
</list></t>
<t>Routing for calls by location and by service is the primary function LoST
<xref target="I-D.ietf-ecrit-lost"></xref> provides. LoST accepts a query with
location (by-value) in either civic or geospatial form, plus a service identifier,
and returns a URI (or set of URIs) to route the call to. Normal SIP
<xref target="RFC3261"></xref> routing functions are used to resolve the URI
to a next hop destination.</t>
<t>The endpoint can complete the LoST mapping from its location at boot time,
and periodically thereafter. It should attempt to obtain a "fresh" location,
and from that a current mapping when it places an emergency call.
If accessing either its location acquisition or mapping functions fail,
it should use this cached value. The call would follow its normal outbound
call processing.</t>
<t>Determining when the device leaves the area provided by the LoST service
can tax small mobile devices. For this reason, the LoST server should return
a simple (small number of points) polygon for geo reported location. This can be an enclosing
subset of the area when the reported point is not near an edge or a smaller
edge section when the reported location is near an edge. Civic location is
uncommon for mobile devices, but reporting that the same mapping is good
within a community name, or even a street, may be very helpful for WiFi
connected devices that roam and obtain civic location from the AP they are
connected to.</t>
<t>Networks that support devices that do not implement LoST mapping themselves
may need the outbound proxy do the mapping. If the endpoint recognized the call was
an emergency call, provided the correct service URN and/or included location on
the call in a Geolocation header, a proxy server could easily accomplish the mapping.</t>
<t>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 difficult. It is often difficult
for the calling network to accurately
determine the endpoint's location by itself. The endpoint may have its location,
but would not normally include
it on the call signaling unless it knew it was an emergency call.
There is no mechanism provided in
<xref target="I-D.ietf-sip-location-conveyance"></xref> to allow a proxy to
require the endpoint supply location, because that would open 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 service URN which, if the device
recognizes the significance, would include location in the redirected call from the device.
All networks should detect emergency calls and supply default location
and/or routing if it is not already performed.</t>
<t>Often, the SIP routing of an emergency call will first route to an incoming
call proxy in the domain operated by the emergency service. That proxy is
called an "Emergency Services Routing Proxy" (ESRP). The ESRP, which is a
normal SIP proxy server, may use a variety of PSAP state information, the
location of the caller, and other criteria to onward route the call to the PSAP.
In order for the ESRP to route on media choice, the initial INVITE request has to
supply an SDP offer.</t>
</section><section anchor="Signaling" title="Signaling of emergency calls">
<section anchor="TLS" title="Use of TLS">
<t>As discussed above, location is carried in all emergency calls in the call
signaling. Since emergency calls carry privacy-sensitive information, they
are subject to the requirements for geospatial protocols
<xref target="RFC3693"></xref>. In particular, signaling information should
be carried in TLS, i.e., in 'sips' mode with a ciphersuite which includes
strong encryption (e.g., AES). There are exceptions
in <xref target="RFC3693"></xref> for emergency calls. For example, local
policy may dictate that location is sent with an emergency call even if the
user's policy would otherwise prohibit that. Never the less, protection from eavesdropping
of location by encryption should be provided.</t>
<t>It is unacceptable to have
an emergency call fail to complete because a TLS connection was not created
for any reason. Thus, the call should be attempted with TLS, but if the TLS
session establishment fails, the call should be automatically retried without TLS.
<xref target="I-D.ietf-sip-sips"></xref> recommends that to achieve this effect
the target request a sip URI, but use TLS on the outbound connection. An element
that receives a request over a TLS connection should attempt to create a TLS connection
to the next hop.</t>
<t>In many cases, persistent TLS connections can be maintained between elements
to minimize the time needed to establish them <xref target="I-D.ietf-sip-outbound"></xref>.
In other circumstances, use of session resumption <xref target="RFC4507"></xref> is
recommended. IPSEC <xref target="RFC2401"></xref> is an acceptable alternative to TLS when
used with an equivalent crypto suite.</t>
<t>Location may be used for routing by
multiple proxy servers on the path. Confidentiality mechanisms such as S/MIME encryption of SIP signaling <xref
target="RFC3261"></xref> cannot be used because they obscure location.
Only hop-by-hop mechanisms such as TLS
should be used. Many SIP devices do not support TLS. Implementing
location conveyance in SIP mandates inclusion of TLS support.</t>
</section><section anchor="UAsignaling" title="SIP signaling requirements for User Agents">
<t>SIP UAs that do local dial string interpretation, location, and emergency
call route will create SIP INVITE messages with 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. The INVITE request must also have appropriate
call back identifiers. To enable media sensitive routing, the call should
include an SDP offer.</t>
</section><section anchor="ProxySignaling" title="SIP signaling requirements for proxy servers">
<t>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 routing steps and
recognition of dial strings. They are also expected to provide identity
information for the caller.</t>
</section></section><section anchor="Callbacks" title="Call backs">
<t>The call-taker must be able to reach the emergency caller if the original
call is disconnected. In traditional emergency calls, wireline and wireless
emergency calls include a callback identifier for this purpose. In SIP systems,
the caller must include a Contact header field indicating its device URI,
if globally routable, or possibly a GRUU <xref target="I-D.ietf-sip-gruu"></xref>
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 <xref target="RFC3261"></xref>
where the Contact: header is optional.</t>
<t>In addition, a call-back identifier must be included either as the URI in
the From header field <xref target="RFC3261"></xref> verified by SIP Identity
<xref target="RFC4474"></xref> or as a network asserted URI
<xref target="RFC3325"></xref>. This identifier would be used to initiate a
call-back at a later time and may reach the caller, not necessarily on the
same device (and at the same location) as the original emergency call as per
normal SIP rules.</t>
</section><section anchor="MidCall" title="Mid-call behavior">
<t>PSAPs often include
dispatchers, responders or specialists on a 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 REFER <xref target="RFC3515"></xref>
a call to a bridge
for conferencing. Relay services for communication
with people with disabilities may be included in the call in this way.</t>
<t>The UA should also be prepared to have the call
transferred (usually attended, but possibly blind) as per
<xref target="I-D.ietf-sipping-service-examples"></xref>.</t>
<t>SIP Caller Preferences <xref target="RFC3841"></xref> 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.</t>
</section><section anchor="Termination" title="Call termination">
<t>It is undesirable for the caller to terminate an emergency call.
PSAP terminates a call using the normal SIP call termination
procedures.</t>
</section><section anchor="DisableFeatures" title="Disabling of features">
<t>Certain features that can be invoked while a normal call is active are
not permitted when the call is an emergency call. Services such as call waiting,
call transfer, three way call and flash Hold should be disabled.</t>
<t>Certain features such as call forwarding can interfere with calls from a PSAP and should be disabled.
A UA can 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 from the emergency call.
A time limit after an emergency call should be established during which any call
from the same domain and directed to the supplied Contact: or AoR should be
accepted as a call-back from the PSAP.</t>
</section><section anchor="Media" title="Media">
<t>PSAPs should always accept RTP media streams <xref target="RFC3550"></xref>.
Traditionally, voice has been the only media stream accepted by PSAPs. In some
countries, text, in the form of Baudot codes or similar tone encoded signaling
within a voiceband is accepted ("TTY") for persons who have hearing disabilities.
With the Internet comes a wider array of potential media that a PSAP should accept.
Using SIP signaling includes the capability to negotiate media. Normal SIP
offer/answer <xref target="RFC3264"></xref> negotiations should be used to agree
on the media streams to be used. PSAPs should accept real-time text
<xref target="RFC4103"></xref>. All PSAPs should accept G.711 A-law (and mu-Law
in North America) encoded voice as described in <xref target="RFC3551"></xref>.
Newer text forms are rapidly appearing, with Instant Messaging now very common,
PSAPs should accept IM with at least "pager-mode" MESSAGE <xref target="RFC3428"></xref>
as well as Message Session Relay Protocol
<xref target="RFC4975"></xref>. Video may be important to support Video Relay
Service (Sign language interpretation) as well as modern video phones.</t>
<t>While it is desirable for media to be kept secure, preferably by use of Secure RTP
<xref target="RFC3711"></xref>, there is not yet consensus on how best to signal
keying material for SRTP. As a consequence, no recommendation to support SRTP can
be made yet for emergency calls. </t>
</section><section anchor="Testing" title="Testing">
<t>Since the emergency calling architecture consists of a number of pieces operated
by independent entities, it is important to be able to test whether an emergency
call is likely to succeed without actually occupying the human resources at a PSAP.
Both signaling and media paths need to be tested since NATs and firewalls may
allow the session setup request to reach the PSAP, while preventing the exchange
of media.</t>
<t><xref target="I-D.ietf-ecrit-phonebcp"></xref> includes a description of an
automated test procedure that validates routing, signaling and media path continuity.
This test would be used within some random interval after boot time, and whenever the device location changes
enough that a new PSAP mapping is returned from LoST. A manual operation for the
test should also be possible.</t>
<t>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 permanently suspend its
operation.</t>
<t>There is a concern associated with testing during a so-called
"avalanche-restart" event where, for example a large power outage affects a large
number of endpoints, that, when power is restored, all attempt to reboot and,
possibly, test. Devices need to randomize their initiation of a boot time test
to avoid the problem.</t>
</section><section anchor="Security" title="Security Considerations">
<t>Security considerations for emergency calling have been documented in
<xref target="RFC5069"></xref>,
and <xref target="I-D.barnes-geopriv-lo-sec"></xref>. </t>
<t>Ed. Note: go through that doc and make sure any actions needed are captured
in the BCP text.</t>
</section><section title="Acknowledgements">
<t>This draft was created from a draft-schulzrinne-sipping-emergency-arch-02
together with sections from draft-polk-newton-ecrit-arch-considerations-02.</t>
<t>Design Team members participating in this draft creation include Hannes Tschofenig,
Ted Hardie, Martin Dolly, Marc Linsner, Roger Marshall, Stu Goldman, Shida Schubert
and Tom Taylor. Further comments and input were provided by Richard Barnes, Barbara
Stark and James Winterbottom.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2396;
&rfc2401;
&rfc3261;
&rfc3263;
&rfc3264;
&rfc3265;
&rfc3311;
&rfc3325;
&rfc3428;
&rfc3515;
&rfc3693;
&rfc3550;
&rfc3551;
&rfc3711;
&rfc3825;
&rfc3841;
&rfc3856;
&rfc4119;
&rfc4103;
&rfc4190;
&rfc4474;
&rfc4507;
&rfc4676;
&rfc4967;
&rfc4975;
&rfc5069;
&rfc5012;
&rfc5139;
&draft-ietf-ecrit-service-urn;
&draft-ietf-sip-location-conveyance;
&draft-ietf-sip-gruu;
&draft-ietf-sip-outbound;
&draft-ietf-sip-sips;
&draft-ietf-ecrit-lost;
&draft-ietf-ecrit-phonebcp;
&draft-ietf-geopriv-http-location-delivery;
&draft-barnes-geopriv-lo-sec;
&draft-ietf-ecrit-dhc-lost-discovery;
&draft-thomson-geopriv-lis-discovery;
<reference anchor="LLDP">
<front>
<title>IEEE802.1ab Station and Media Access Control</title>
<author fullname="">
<organization>IEEE</organization>
</author>
<date day="01" month="Dec" year="2004" />
</front>
</reference>
<reference anchor="LLDP-MED">
<front>
<title>ANSI/TIA-1057 Link Layer Discovery Protocol - Media Endpoint
Discovery</title>
<author fullname="">
<organization>TIA</organization>
</author>
<date year="" />
</front>
</reference>
</references>
<references title="Informative References">
&draft-ietf-sipping-service-examples;
<reference anchor="WGS84">
<front>
<title>NIMA Technical Report TR8350.2, Department of Defense World
Geodetic System 1984, Its Definition and Relationships With Local
Geodetic Systems, Third Edition</title>
<author fullname="">
<organization>NIMA</organization>
</author>
<date day="4" month="July" year="1997" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 20:11:28 |