draft-ietf-ecrit-framework-04.txt   draft-ietf-ecrit-framework-05.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track H. Schulzrinne Intended status: Standards Track H. Schulzrinne
Expires: May 22, 2008 Columbia U. Expires: August 28, 2008 Columbia U.
J. Polk J. Polk
Cisco Systems Cisco Systems
A. Newton A. Newton
TranTech/MediaSolv TranTech/MediaSolv
November 19, 2007 February 25, 2008
Framework for Emergency Calling using Internet Multimedia Framework for Emergency Calling using Internet Multimedia
draft-ietf-ecrit-framework-04 draft-ietf-ecrit-framework-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 May 22, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The IETF has several efforts targeted at standardizing various The IETF has several efforts targeted at standardizing various
aspects of placing emergency calls. This document describes how all aspects of placing emergency calls. This document describes how all
of those component parts are used to support emergency calls from of those component parts are used to support emergency calls from
citizens and visitors to authorities. citizens and visitors to authorities.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of how emergency calls are placed . . . . . . . . . . 7 3. Overview of how emergency calls are placed . . . . . . . . . . 7
4. Which devices and services should support emergency calls . . 10 4. Which devices and services should support emergency calls . . 11
5. Identifying an emergency call . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . 14 6.1. Types of location information . . . . . . . . . . . . . . 14
6.2. Location Determination . . . . . . . . . . . . . . . . . . 15 6.2. Location determination . . . . . . . . . . . . . . . . . . 15
6.2.1. User-entered location information . . . . . . . . . . 16 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 . . . . . . . 17 6.2.3. End-system measured location information . . . . . . . 17
6.2.4. Network measured location information . . . . . . . . 18 6.2.4. Network measured location information . . . . . . . . 18
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 18 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 18
6.4. Location and references to location . . . . . . . . . . . 19 6.4. Location and references to location . . . . . . . . . . . 19
6.5. End system location configuration . . . . . . . . . . . . 19 6.5. End system location configuration . . . . . . . . . . . . 19
6.6. When location should be configured . . . . . . . . . . . . 21 6.6. When location should be configured . . . . . . . . . . . . 21
6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 22 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 21
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 22 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 22
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 23 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 23
6.10. Location validation . . . . . . . . . . . . . . . . . . . 23 6.10. Location validation . . . . . . . . . . . . . . . . . . . 23
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 24 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 24
6.12. Other location considerations . . . . . . . . . . . . . . 24 6.12. Location format conversion . . . . . . . . . . . . . . . . 24
6.13. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . 24 7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 24
7. Uninitialized devices . . . . . . . . . . . . . . . . . . . . 24
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 25 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 25
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 27 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 27
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. SIP signaling requirements for User Agents . . . . . . . 27 9.2. SIP signaling requirements for User Agents . . . . . . . . 27
9.3. SIP signaling requirements for proxy servers . . . . . . . 27 9.3. SIP signaling requirements for proxy servers . . . . . . . 28
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 28 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 28
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 29 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 29
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 29 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 29
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
16. Security Considerations . . . . . . . . . . . . . . . . . . . 30 16. Security Considerations . . . . . . . . . . . . . . . . . . . 30
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
18.1. Normative References . . . . . . . . . . . . . . . . . . . 31 18.1. Normative References . . . . . . . . . . . . . . . . . . . 31
18.2. Informative References . . . . . . . . . . . . . . . . . . 35 18.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses terms from [RFC3261] and This document uses terms from [RFC3261] and [RFC5012]. In addition
[I-D.ietf-ecrit-requirements]. In addition the following terms are the following terms are used:
used: Access network: The access network supplies IP packet service to an
Access network: The network that supplies IP packet service to an endpoint. Examples of access networks include digital subscriber
endpoint. In a residential or small business environment, this lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local
might be a DSL or cable modem or WiMax service. In a large area networks, or cellular data networks.
enterprise environment, this would be the enterprise network. In (Emergency) Call taker: An emergency call taker answers an emergency
a mobile environment, this might be a mobile (cellular) data call at the PSAP.
network or a WiFi network Confidence: Confidence is an estimate indicating how sure the
(Emergency) Call taker: The person who answers an emergency call at measuring system is that the actual location of the person is
the PSAP within the bounds defined by the uncertainty value, expressed as a
Confidence The mathematically derived statistical estimate percentage. For example, a value of 90% indicates that the actual
indicating how sure the measuring system is that the location data location is within the uncertainty nine times out of ten.
estimate is accurate, within the bounds defined by the Uncertainty Dispatch Location: The dispatch location is the location used for
value. This is expressed as a percentage, such as 90%, or 45% dispatching responders to the person in need of assistance. The
etc. dispatch location must be sufficiently precise to easily locate
Dispatch Location Location used for dispatching responders to the the callee; it typically needs to be more accurate than the
person in need of assistance. Must be precise as opposed to that routing location.
needed for Routing Location. Emergency services routing proxy (ESRP): An emergency services
Emergency services routing proxy (ESRP): A proxy server that routing proxy provides routing services for a group of PSAPs.
provides routing services for a group of PSAPs Location configuration: During location configuration, an endpoint
Location configuration: The process where an endpoint learns its learns its physical location.
physical location Location conveyance: Location conveyance delivers location
Location conveyance: The process of sending location to another information to another element.
element Location determination: Location determination finds where an
Location determination: The process of finding where an endpoint is endpoint is physically located. For example, the endpoint may
physically. For example, the endpoint may contain a GPS receiver contain a GPS receiver used to measure its own location or the
used to measure its own location or location may be determined by location may be determined by a network administrator using a
administration using a wiremap database or similar wiremap database.
Location Information Server (LIS): An element that stores location Location Information Server (LIS): A Location Information Server
information for retrieval by an authorized entity stores location information for retrieval by an authorized entity.
Mobile device: User agent that changes geographic location and Mobile device: A mobile device is a user agent that may change its
possibly its network attachment point during an emergency call physical location and possibly its network attachment point during
NENA (National Emergency Number Association): A North American an emergency call.
organization of public safety focused individuals defining NENA (National Emergency Number Association): The National Emergency
emergency calling specifications and procedures Number Association is an organization of professionals to "foster
Nomadic device (user): User agent that is connected to the network the technological advancement, availability and implementation of
temporarily, for relatively short durations, but does not move a universal emergency telephone number system." It develops
significantly during the lifetime of a network connection or emergency calling specifications and procedures.
Nomadic device (user): A nomadic user agent is connected to the
network temporarily, for relatively short durations, but does not
move significantly during the lifetime of a network connection or
during the emergency call. Examples include a laptop using an during the emergency call. Examples include a laptop using an
IEEE 802.11 hotspot or a desk IP phone that is moved from one IEEE 802.11 hotspot or a desk IP phone that is moved from one
cubicle to another cubicle to another.
Routing Location: The location of an endpoint that is used for Physical Location: A physical location describes where a person or
routing an emergency call. May not be as precise as the Dispatch device is located in physical space, described by a coordinate
Location. system. It is distinguished from the network location, described
Stationary device: An immobile user agent that is connected to the by a network address.
network at a fixed, long-term-stable geographic location. Routing Location: The routing location of a device is used for
Examples include a home PC or a pay phone routing an emergency call and may not be as precise as the
Uncertainty The mathematically derived statistical estimate, Dispatch Location.
expressed in meters, indicating the size of the area used in the Stationary device: An stationary device is not mobile and is
calculation of Confidence. connected to the network at a fixed, long-term-stable physical
location. Examples include home PCs or pay phones.
Uncertainty: Uncertainty is an estimate, expressed in a unit of
length, indicating the diameter of a circle that contains the
device 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 is an accepted practice in most of the world.
As communications devices increasingly utilize the Internet to As communications devices increasingly utilize the Internet to
interconnect and communicate, users will continue to expect to use interconnect and communicate, users will continue to expect to use
such devices to request help, regardless of whether or not they such devices to request help, regardless of whether or not they
communicate using IP. This document describes establishment of a communicate using IP. This document describes establishment of a
communications session by a user to a "Public Safety Answering Point" communications session by a user to a "Public Safety Answering Point"
(PSAP) that is a call center established by response agencies to (PSAP) that is a call center established by response agencies to
accept emergency calls. Such citizen/visitor-to-authority calls can accept emergency calls. Such citizen/visitor-to-authority calls can
be distinguished from those that are created by responders be distinguished from those that are created by responders
(authority-to-authority) using public communications infrastructure (authority-to-authority) using public communications infrastructure
often involving some kind of priority access as defined in Emergency often involving some kind of priority access as defined in Emergency
Telecommunications Service (ETS) in IP Telephony [RFC4190]. They Telecommunications Service (ETS) in IP Telephony [RFC4190]. They
also can be distinguished from emergency warning systems that are also can be distinguished from emergency 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. It discusses how end elements, their vendors and service providers. This document
device and applications create emergency calls, how access networks discusses how end device and applications create emergency calls, how
supply location for some of these devices, how service providers access networks supply location for some of these devices, how
assist the establishment and routing, and how PSAPs receive calls service providers assist the establishment and routing, and how PSAPs
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 the 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 variation 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 them to be used to telephones, and users are increasingly expecting to use them to place
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 the plethora of different media that can be accommodated;
o 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, a wired phone connected to radio access technology. For example, consider a wired phone
a router using a mobile data network such as EV-DO as an uplink. connected to a router using a mobile data network such as EV-DO as
an uplink.
This document focuses on how devices using the Internet can place This document focuses on how devices using the Internet can place
emergency calls and how PSAPs can handle Internet multimedia emergency calls and how PSAPs can handle Internet multimedia
emergency calls natively, rather than describing how circuit-switched emergency calls natively, rather than describing how circuit-switched
PSAPs can handle VoIP calls. In many cases, PSAPs making the PSAPs can handle 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. There will be PSAPs origination and termination of emergency calls. Many of these legacy
that require new systems to terminate to existing mechanisms for some systems use telephone number based routing. Gateways and conversions
time. Many of these legacy systems use telephone number based between existing systems and newer systems defined by this document
routing. Gateways and conversions between existing systems and newer will be required. Since existing systems are governed primarily by
systems defined by this document will be required. Since existing local government regulations and national standards, the gateway and
systems are governed primarily by local government regulations and conversion details will be governed by national standards and thus
national standards, the gateway and conversion details will be are out of scope for this document.
governed by national standards and thus are out of scope for this
document.
Existing emergency call systems are organized locally or nationally; Existing emergency call systems are organized locally or nationally;
there are currently 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 6, line 13 skipping to change at page 6, line 22
standards. Thus, this document attempts to take into account best standards. Thus, this document attempts to take into account best
practices that have evolved for circuit switched PSAPs, but makes no practices that have evolved for circuit switched PSAPs, but makes no
assumptions on particular operating practices currently in use, assumptions on particular operating practices currently in use,
numbering schemes or organizational structures. numbering schemes or organizational structures.
This document discusses the use of the Session Initiation Protocol This document discusses the use of the Session Initiation Protocol
(SIP) [RFC3261] by PSAPs and calling parties. While other inter- (SIP) [RFC3261] by PSAPs and calling parties. While other inter-
domain call signaling protocols may be used for emergency calling, domain call signaling protocols may be used for emergency calling,
SIP is ubiquitous and possesses the proper support of this use case. SIP is ubiquitous and possesses the proper support of this use case.
Only protocols such as H.323, XMPP/Jingle, ISUP and SIP are suitable Only protocols such as H.323, XMPP/Jingle, ISUP and SIP are suitable
for inter-domain communications, ruling out MGC protocols such as for inter-domain communications, ruling out Media Gateway Controller
MGCP or H.248/Megaco. The latter protocols can naturally be used by protocols such as MGCP or H.248/Megaco. The latter protocols can be
the enterprise or carrier placing the call, but any such call would used by the enterprise or carrier placing the call, but any such call
reach the PSAP through a media gateway controller, similar to how would reach the PSAP through a media gateway controller, similar to
inter-domain VoIP calls would be placed. Other signaling protocols how inter-domain VoIP calls would be placed. Other signaling
may also use protocol translation to communicate with a SIP-enabled protocols may also use protocol translation to communicate with a
PSAP. SIP-enabled PSAP.
Existing emergency services rely exclusively on voice and Existing emergency services rely exclusively on voice and
conventional text telephony ("TTY") media streams. However, more conventional text telephony ("TTY") media streams. However, more
choices of media offer additional ways to communicate and evaluate choices of media offer additional ways to communicate and evaluate
the situation as well as to assist callers and call takers in the situation as well as to assist callers and call takers in
handling emergency calls. For example, instant messaging and video handling emergency calls. For example, instant messaging and video
could improve the ability to communicate and evaluate the situation could improve the ability to communicate and evaluate the situation
and to provide appropriate instruction prior to arrival of emergency and to provide appropriate instruction prior to arrival of emergency
crews. Thus, the architecture described here supports the creation crews. Thus, the architecture described here supports the creation
of sessions of any media type, negotiated between the caller and PSAP of sessions of any media type, negotiated between the caller and PSAP
using existing SIP protocol mechanisms [RFC3264]. using existing SIP protocol mechanisms [RFC3264].
As a framework document, no normative behavior is contained herein. Since this document is a framework document it does not include
A companion document, [I-D.ietf-ecrit-phonebcp] describes Best normative behavior. A companion document, [I-D.ietf-ecrit-phonebcp]
Current Practice for this subject and contains normative language for describes Best Current Practice for this subject and contains
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 unaware of certain specific ways, as described below. User Agents (UAs) unaware
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
call may not be routed to the correct PSAP, and if the caller is call may not be routed to the correct PSAP, and if the caller is
unable to supply his exact location, dispatch of emergency responders unable to supply his exact location, dispatch of emergency responders
may be delayed. Suggested behavior for both endpoints and servers is may be delayed. Suggested behavior for both endpoints and servers is
provided. provided.
From the point of view of the PSAP three essential elements From the point of view of the PSAP, three essential elements
characterize an emergency call: characterize an emergency call:
o The call is routed to the most appropriate PSAP, based primarily
o The call is routed to the most appropriate PSAP, selected on the location of the caller.
principally by the location of the caller.
o The PSAP must be able to automatically obtain the location of the o The PSAP must be able to automatically obtain the location of the
caller sufficiently accurate to dispatch a responder to help the caller with sufficient accuracy to dispatch a responder to help
caller. the caller.
o The PSAP must be able to re-establish a session to the caller if o The PSAP must be able to re-establish a session to the caller if
for any reason the original session is lost. for any reason the original session is disrupted.
3. Overview of how emergency calls are placed 3. Overview of how emergency calls are placed
An emergency call can be distinguished (Section 5) from any other An emergency call can be distinguished (Section 5) from any other
call by a unique Service URN [I-D.ietf-ecrit-service-urn], that is call by a unique Service URN [I-D.ietf-ecrit-service-urn] that is
placed in the call set-up signaling when a home or visited emergency placed in the call set-up signaling when a home or visited emergency
dial string is detected. Because emergency services are local to dial string is detected. Because emergency services are local to
specific geographic regions, a caller must obtain his location specific geographic regions, a caller must obtain his location (
(Section Section 6) prior to making emergency calls. To get this Section 6) prior to making emergency calls. To get this location,
location, either a form of measuring (e.g., GPS) (Section 6.2.3) either a form of measuring, for example, GPS (Section 6.2.3) is
device location in the endpoint is deployed, or the endpoint is deployed, or the endpoint is configured (Section 6.5) with its
configured (Section 6.5) with its location from the access network's location from the access network's Location Information Server (LIS).
Location Information Server (LIS). The location is conveyed The location is conveyed (Section 6.7) in the SIP signaling with the
(Section 6.7) in the SIP signaling with the call. The call is routed call. The call is routed (Section 8) based on location using the
(Section 8) based on location using the LoST protocol LoST protocol [I-D.ietf-ecrit-lost], which maps a location to a set
[I-D.ietf-ecrit-lost], that maps a location to a set of PSAP or URIs. of PSAP or URIs. Each URI resolves to a PSAP or an Emergency
Each URI resolves to a PSAP or an Emergency Services Routing Proxy Services Routing Proxy (ESRP) that serves an incoming proxy for group
(ESRP) that serves an incoming proxy for group of PSAPs. The call of PSAPs. The call arrives at the PSAP with the location included in
arrives at the PSAP with the location included in the INVITE request. 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 [RFC4676] or o The phone gets location from the DHCP server in civic [RFC4676] or
[RFC3825], a HELD server [I-D.ietf-geopriv-http-location-delivery] geo [RFC3825] forms, a HELD server
or the first level switch's LLDP server [LLDP]. [I-D.ietf-geopriv-http-location-delivery] or the first level
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
[I-D.ietf-ecrit-lost] server for its current location. It also [I-D.ietf-ecrit-lost] server for its current location. It also
receives and caches the PSAP URI obtained from LoST. receives and caches the PSAP URI obtained from LoST.
o It recognizes an emergency call from the dial strings and uses
o Some time later, the user places an emergency call. The phone
recognizes an emergency call from the dial strings and uses
"urn:service:sos" [I-D.ietf-ecrit-service-urn] to mark an "urn:service:sos" [I-D.ietf-ecrit-service-urn] to mark an
emergency call. emergency call.
o It determines the PSAP's URI by querying the LoST mapping server o It determines the PSAP's URI by querying the LoST mapping server
with its location. with its location.
o It puts its location in the SIP INVITE in a Geolocation header 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 [I-D.ietf-sip-location-conveyance] and forwards the call using its
normal outbound call processing, that commonly involves an normal outbound call processing, which commonly involves an
outgoing proxy. outgoing 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
to the PSAP. the call to the PSAP.
o The call is established with the PSAP and common media streams are o The call is established with the PSAP and mutually agreed upon
created. media streams are created.
o The location of the caller is displayed to the call taker. o The location of the caller is displayed to the call taker.
Configuration Servers Configuration Servers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. +--------+ +----------+ . . +--------+ +----------+ .
. +--------+ | +----------+ | . . +--------+ | +----------+ | .
. | LIS | | | SIP | | . . | LIS | | | SIP | | .
. | |-+ | Registrar|-+ . . | |-+ | Registrar|-+ .
. +--------+ +----------+ . . +--------+ +----------+ .
skipping to change at page 8, line 41 skipping to change at page 9, line 4
||| | PSAP2 | ||| | PSAP2 |
||| +-------+ ||| +-------+
||| |||
||| [M6] +-------+ [M7]+------+ [M8]+-------+ ||| [M6] +-------+ [M7]+------+ [M8]+-------+
Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker
+-------+ +------+ +-------+ +-------+ +------+ +-------+
+-------+ +-------+
| PSAP3 | | PSAP3 |
+-------+ +-------+
Figure 1: Emergency Call Component Topology Figure 1: Emergency Call Component Topology
The typical message flow would be:
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/initiates 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 -> ALICE LCP Reply (replies with location)
[M5] Alice -> LoST Server Update LoST Query (contains location) [M5] Alice -> LoST Server Update LoST Query (contains location)
Lost Server -> Alice LoST Response (contains PSAP-URI) Lost Server -> Alice LoST Response (contains PSAP-URI)
[M6] Alice to Outgoing Proxy INVITE (service URN, [M6] Alice to Outgoing Proxy INVITE (service URN,
Location and PSAP URI) Location and PSAP URI)
Outgoing Proxy to ESRP INVITE (service URN, Outgoing Proxy to ESRP INVITE (service URN,
Location and PSAP URI) Location and PSAP URI)
ESRP to PSAP 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 *** 200 OK and ACK propogated back from PSAP to Alice
Figure 2: Emergency Call Message Flow 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: shows call establishment. These include the following components:
o Alice - who makes the emergency call. o Alice - who makes 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. In this flow, DHCP is used as location by-value or by-reference. In this flow, DHCP is used as
an example location configuration protocol (LCP). Configuration an example location configuration protocol (LCP). Configuration
servers also may include a SIP registrar for Alice's UA. Most SIP 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 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 make 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 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.
o LoST server - Processes the LoST request for Location + Service o LoST server - Processes the LoST request for Location + Service
URN to PSAP-URI Mapping function, either for an initial request 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 from a UA, or an in-call routing by the Proxy server in the
originating network, or possibly by an ESRP. originating network, or possibly by an ESRP.
o 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.
o PSAP - Call center where emergency calls are destined for. o PSAP - Call center where emergency calls are destined for.
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. For most
devices, a LCP will be used, for example a DHCPREQUEST message or devices, a LCP will be used, for example a DHCPREQUEST message or
another location acquisition mechanism. Alice's UA then will most another location acquisition mechanism. Alice's UA then will most
likely register [M2] with a SIP domain. This allows her to be likely register [M2] with a SIP domain. This allows her to be
contacted by other SIP entities. Next, her UA will perform an 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
skipping to change at page 10, line 34 skipping to change at page 10, line 39
location [M4], and with that location, to refresh the LoST mapping location [M4], and with that location, to refresh the LoST mapping
[M5], in order to get the most accurate information to use for [M5], in order to get the most accurate information to use for
routing the call. If the location request or the LoST request fails, routing the call. If the location request or the LoST request fails,
or takes too long, the UA uses values it has cached. or takes too long, the UA uses values it has cached.
The UA creates a SIP INVITE [M6] request that includes the location. The UA creates a SIP INVITE [M6] request that includes the location.
[I-D.ietf-sip-location-conveyance] defines a SIP Geolocation header [I-D.ietf-sip-location-conveyance] defines a SIP Geolocation header
that contains either a location-by-reference URI or a [RFC2396] "cid" that contains either a location-by-reference URI or a [RFC2396] "cid"
URL indicating where in the message body the location-by-value is. URL indicating where in the message body the location-by-value is.
The INVITE message is routed to the ESRP [M7], that is the first The INVITE message is routed to the ESRP [M7], which is the first
inbound proxy for the emergency services domain. This message is inbound proxy for the emergency services domain. This message is
then routed by the ESRP towards the most appropriate PSAP for Alice's then routed by the ESRP towards the most appropriate PSAP for Alice's
location [M8], as determined by PSAP state, location and other location [M8], as determined by the location and other information.
information.
A proxy in the PSAP chooses an available call taker and extends the A proxy in the PSAP chooses an available call taker and extends the
call to its UA. call to its UA.
The 200 OK response to the INVITE request traverses the path in The 200 OK response to the INVITE request traverses the path in
reverse, from call taker UA to PSAP proxy to ESRP to originating reverse, from call taker UA to PSAP proxy to ESRP to originating
network proxy to Alice's UA. The ACK completes the call set-up and network proxy to Alice's UA. The ACK request completes the call
the emergency call is established, allowing the PSAP call-taker to set-up and the emergency call is established, allowing the PSAP call-
talk to Alice about Alice's emergency. taker to talk to Alice about Alice's emergency.
4. Which devices and services should support emergency calls 4. Which devices and services should support emergency calls
Support for voice calls and real-time text calls placed through PSTN Current PSAPs support voice calls and real-time text calls placed
facilities or systems connected to the PSTN is found in present through PSTN facilities or systems connected to the PSTN. Future
PSAPs. Future PSAPs will however support Internet connectivity and a PSAPs will however support Internet connectivity and a wider range of
wider range of media types and provide higher functionality. In media types and provide higher functionality. In general, if a user
general, if a user could reasonably expect to be able to place a call could reasonably expect to be able to place a call for help with the
for help with the device, then the device or service should support device, then the device or service should support emergency calling.
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.
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.
Using current (evolving) standards, devices that create media Devices that create media sessions and exchange audio, video and/or
sessions and exchange audio, video and/or text, and have the text, and have the capability to establish sessions to a wide variety
capability to establish sessions to a wide variety of addresses, and of addresses, and communicate over private IP networks or the
communicate over private IP networks or the Internet, should support Internet, should support emergency calls.
emergency calls.
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 a single digit sequence that is used for
all types of emergencies. In others, there are several sequences all types of emergencies. In others, there are several sequences
that are specific to the type of responder needed, e.g., one for 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 police, another for fire. For end systems, on the other hand, it is
desirable to have a universal identifier, independent of location, to desirable to have a universal identifier, independent of location, to
allow the automated inclusion of location information and to allow allow the automated inclusion of location information and to allow
the device and other entities in the call path to perform appropriate the device and other entities in the call path to perform appropriate
processing within the signaling protocol in an emergency call set-up. 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 [I-D.ietf-ecrit-service-urn]. An example, for a single defined in [I-D.ietf-ecrit-service-urn]. For a single number
number environment is "urn:service:sos". Users are not expected to environment the urn is "urn:service:sos". Users are not expected to
"dial" an emergency URN. Rather, appropriate emergency dial strings "dial" an emergency URN. Rather, appropriate emergency dial strings
is translated to corresponding service URNs, carried in the Request- are translated to corresponding service URNs, carried in the Request-
URI of the INVITE. Such translation is best done by the endpoint, URI of the INVITE request. Such translation is best done by the
because emergency calls convey location in the signaling, but non endpoint, among other reasons, because emergency calls convey
emergency calls do not normally do that. If the device recognizes location in the signaling, but non emergency calls do not normally do
the emergency call, it can include location. Dial string recognition that. If the device recognizes the emergency call, it can include
could be performed in a signaling intermediary (proxy server) if for location. Dial string recognition could be performed in a signaling
some reason, the endpoint does not recognize it. For devices that intermediary (proxy server) if for some reason the endpoint does not
are mobile or nomadic, an issue arises of whether the home or visited recognize it.
dialing strings should be used. Many users would prefer that their
home dialing sequences work no matter where they are. Local laws and For devices that are mobile or nomadic, an issue arises of whether
regulations may require the visited dialing sequence(s) always work. the home or visited dialing strings should be used. Many users would
Having the home dial string work is optional. 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.
The mechanism for obtaining the dialing sequences for a given The mechanism for obtaining the dialing sequences for a given
location is provided by LoST [I-D.ietf-ecrit-lost]. If the endpoint location is provided by LoST [I-D.ietf-ecrit-lost]. If the endpoint
does not support the translation of dial strings to telephone does not support the translation of dial strings to telephone
numbers, the dialing sequence would be represented as a dial string numbers, the dialing sequence is represented as a dial string
[RFC4967] and the outgoing proxy would recognize the dial string and [RFC4967] and the outgoing proxy has to recognize the dial string and
translate to the service URN. To determine the local dial string, translate to the service URN. To determine the local emergency dial
the proxy needs the location of the endpoint. This may be difficult string, the proxy needs the location of the endpoint. This may be
in situations where the user can roam or be nomadic. Endpoint difficult in situations where the user can roam or be nomadic.
recognition of emergency dial strings is therefore preferred, and in Endpoint recognition of emergency dial strings is therefore
fact if a service provider is unable to guarantee that it can preferred. If a service provider is unable to guarantee that it can
correctly determine local emergency dialstrings then it is required correctly determine local emergency dialstrings, wherever its
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. entry of specific emergency call dial strings.
While in some countries there is a single 3 digit dial string that is
used for all emergency calls (i.e. 9-1-1 in North America), in some
countries there are several 3 digit numbers used for different types
of calls. For example, in Switzerland, 1-1-7 is used to call police,
1-1-8 is used to call the fire brigade, and 1-4-4 is used for
emergency medical assistance. In other countries, there are no
"short codes" or "service codes" for 3 digit dialing of emergency
services and local (PSTN) numbers are used.
[I-D.ietf-ecrit-service-urn] introduces a universal emergency service
URN scheme. On the wire, emergency calls include this type of URI in
the Request-URI [RFC3261]. The scheme includes a single emergency
URN (urn:service:sos) for use in countries with a single emergency
dial string, and responder-specific ones (urn:service:sos.police) for
countries where the user dials each service with separate numbers.
Using the service:sos URN scheme, emergency calls can be recognized
as such throughout the Internet.
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. It is
frequently the case that the user in an emergency is unable to frequently the case that the caller reporting an emergency is unable
provide a unique, valid location themselves. For this reason, to provide a unique, valid location themselves. For this reason,
location provided by the endpoint or the access network is needed. location provided by the endpoint or the access network is needed.
For practical reasons, each PSAP generally handles only calls for a For practical reasons, each PSAP generally handles only calls for a
certain geographic area, with overload arrangements between PSAPs to certain geographic area, with overload arrangements between PSAPs to
handle each others calls. Other calls that reach it by accident must handle each others calls. Other calls that reach it by accident must
be manually re-routed (transferred) to the most appropriate PSAP, be manually re-routed (transferred) to the most appropriate PSAP,
increasing call handling delay and the chance for errors. The area increasing call handling delay and the chance for errors. The area
covered by each PSAP differs by jurisdiction, where some countries covered by each PSAP differs by jurisdiction, where some countries
have only a small number of PSAPs, while others decentralize PSAP have only a small number of PSAPs, while others decentralize PSAP
responsibilities to the level of counties or municipalities. 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 PSAP service boundaries, the closest PSAP, or the PSAP that serves on actual PSAP service boundaries -- the closest PSAP, or the PSAP
the nominal city name provided in the location may not be the correct that serves the nominal city name provided in the location, may not
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. It is considered acceptable to base a routing
decision on an accuracy equal to the area of one sector of a mobile decision on an accuracy equal to the area of one sector of a mobile
cell site if no more accurate routing location is available. cell site if no more accurate routing location is available.
Routing to the most appropriate PSAP is always calculated on the Routing to the most appropriate PSAP is always calculated on the
location of the caller, despite the fact that some emergency calls location of the caller, despite the fact that some emergency calls
are placed on behalf of someone else, and the location of the are placed on behalf of someone else, and the location of the
incident is sometimes not the location of the caller. In some cases, 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 there are other factors that enter into the choice of the PSAP that
gets the call, which may include factors other than location (such as gets the call, such as time of day, caller media requests and
caller media and language preference, PSAP state, etc.). However, language preference, call load, etc. However, location of the caller
location of the caller is the primary input to the routing decision. is the primary input to the routing decision.
Routing is but one of two uses for location in an emergency call. Routing is but one of two uses for location in an emergency call.
The other is for dispatch of a responder. Many mechanisms used to The other is for dispatch of a responder, which must be very precise.
locate a caller have a relatively long "cold start" time. To get a Many mechanisms used to locate a caller have a relatively long "cold
location accurate enough for dispatch may take as much as 30 seconds. start" time. To get a location accurate enough for dispatch may take
This is too long to wait for emergencies. Accordingly, it is common, as much as 30 seconds. This is too long to wait for emergencies.
especially in mobile systems to use a coarse location, for example, Accordingly, it is common, especially in mobile systems, to use a
the cell site and sector serving the call, for routing purposes, and coarse location, for example, the cell site and sector serving the
then to update the location when a more precise value is known prior call, for call routing purposes, and then to update the location when
to dispatch. In this document we use "routing location" and a more precise value is known prior to dispatch. In this document we
"dispatch location" when the distinction matters. use "routing location" and "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 exceeds available technology. It is required that a
device making an emergency call close to the "demising" or separation device making an emergency call close to the "demising" or separation
wall between two apartments in a high rise apartment building report wall between two apartments in a high rise apartment building report
location with sufficient accuracy to determine on what side of the location with sufficient accuracy to determine on what side of the
wall it is on. This implies perhaps a 3 cm accuracy requirement. As 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% of the date of this memo, typical assisted GPS uncertainty with 95%
confidence is 100 m. As technology advances, the accuracy confidence is 100 m. As technology advances, the accuracy
requirements for location will need to be increased. Wired systems requirements for location will need to be increased. Wired systems
using wire tracing mechanisms can provide location to a wall jack in 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 specific room on a floor in a building, and may even specify a
cubicle or even smaller resolution. As this discussion illustrates, cubicle or even smaller resolution. As this discussion illustrates,
emergency call systems demand the most stringent location accuracy emergency call systems demand the most stringent location accuracy
available. available.
Location usually involves several steps to process and multiple Location usually involves several steps to process and multiple
elements are involved. In Internet emergency calling, where the elements are involved. In Internet emergency calling, where the
endpoint is located is "Determined" using a variety of measurement or endpoint is located is "determined" using a variety of measurement or
wire-tracing methods. Endpoints may be "Configured" with their own wire-tracing methods. Endpoints may be "configured" with their own
location by the access network. In some circumstances, a proxy location by the access network. In some circumstances, a proxy
server may insert location into the signaling on behalf of the server may insert location into the signaling on behalf of the
endpoint. The location is "Mapped" to the URI to send the call to, 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 and the location is "conveyed" to the PSAP (and other elements) in
the signaling. Likewise, we employ Location Configuration Protocols, the signaling. Likewise, we employ Location Configuration Protocols,
Location Mapping Protocols, and Location Conveyance Protocols for Location Mapping Protocols, and Location Conveyance Protocols for
these functions. The Location-to-Service Translation protocol these functions.
[I-D.ietf-ecrit-lost] is the Location Mapping Protocol defined by the
IETF. 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.
6.1. Types of location information 6.1. Types of location information
There are several ways location can be specified: There are several ways location can be specified:
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 finely 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 This refers to a civic location using actual Jurisdictional this refers to a civic location using actual
political subdivisions, especially for the community name. political subdivisions, especially for the community name.
Postal This refers to a civic location for mail delivery. The Postal this refers to a civic location for mail delivery. The
name of the post office sometimes does not correspond to the name of the post office sometimes does not correspond to the
community name and a postal address may contain post office community name and a postal address may contain post office
boxes or street addresses that do not correspond to an actual boxes or street addresses that do not correspond to an actual
building. Postal addresses are generally unsuitable for building. Postal addresses are generally unsuitable for
emergency call dispatch because the post office conventions emergency call dispatch because the post office conventions
(for community name, for example) do not match those known by (for community name, for example) do not match those known by
the responders. The fact that they are unique can sometimes be the responders. The fact that they are unique can sometimes be
exploited to provide a mapping between a postal address and a exploited to provide a mapping between a postal address and a
civic address suitable to dispatch a responder to. In IETF civic address suitable to dispatch a responder to. In IETF
location protocols, there is a element (Postal Community Name) location protocols, there is an element (Postal Community Name)
that can be included in a location to provide the post office that can be included in a location to provide the post office
name as well as the actual jurisdictional community name. name as well as the actual jurisdictional community name.
There is no other accommodation for postal addresses in these There is no other accommodation for postal addresses in these
protocols. 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 time, most modern systems are using or moving towards the [WGS84]
WGS84[WGS84] datum. 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
mobile device. Whatever representation is used must route mobile device. Whatever representation is used must route
correctly in the LoST database, where "correct" is determined by correctly in the LoST database, where "correct" is determined by
local PSAP management. local PSAP management.
In IETF protocols, civic and geospatial forms are both supported. In IETF protocols, both civic and geospatial forms are supported.
The civic forms include both postal and jurisdictional fields. A The civic forms include both postal and jurisdictional fields. A
cell tower/sector can be represented as a point (geo or civic) or cell tower/sector can be represented as a point (geo or civic) or
polygon. Other forms of location representation must be mapped into polygon. Other forms of location representation must be mapped into
either a geo or civic for use in emergency calls. either a geo or civic for use in emergency calls.
For emergency call purposes, conversion of location information from For emergency call purposes, conversion of location information from
civic to geo or vice versa prior to conveyance is not desirable. The civic to geo or vice versa prior to conveyance is not desirable. The
location should be sent in the form it was determined. Conversion location should be sent in the form it was determined. Conversion
between geo and civic requires a database. PSAPs may need to convert between geo and civic requires a database. Where PSAPs need to
from whatever form they receive to another for responder purposes. convert from whatever form they receive to another for responder
They have a suitable database. However, if a conversion is done purposes, they have a suitable database. However, if a conversion is
before the PSAP, and the database used is not exactly the one the done before the PSAP's, and the database used is not exactly the same
PSAP uses, the double conversion has a high probability of one the PSAP uses, the double conversion has a high probability of
introducing an error. introducing an error.
6.2. Location Determination 6.2. Location determination
Location information can be entered by the user or installer of a As noted above, location information can be entered by the user or
device ("manual configuration"), measured by the end system, can be installer of a device ("manual configuration"), measured by the end
delivered to the end system by some protocol or measured by a third system, can be delivered to the end system by some protocol or
party and inserted into the call signaling. Choice of location measured by a third party and inserted into the call signaling.
determination mechanisms and their properties are out of scope for
this document.
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, access network provided location could be much
more accurate, and more reliable in some environments (indoor high more accurate, and more reliable in some environments such as indoor
rise in dense urban areas for example). In general, the closer an high rises in dense urban areas. In general, the closer an entity is
entity is to the source of location, the more it is in the best to the source of location, the more it is in the best position to
position to determine which location is "best" for a particular determine which location is "best" for a particular purpose. In
purpose. In emergency calling, the PSAP is the least likely to be emergency calling, the PSAP is the least likely to be able to
able to appropriately choose which location when multiple conflicting appropriately choose which location to use when multiple conflicting
locations are presented to it. locations are presented to it.
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
Section 6.10) address. Users can neglect to change the data when the Section 6.10) address. Users can forget to change the data when the
location of a device changes during or after movement. location of a device changes during or after movement.
All that said, there are always a small number of cases where the All that said, there are always a small number of cases where the
automated mechanisms used by the access network to determine location automated mechanisms used by the access network to determine location
fail to accurately reflect the actual location of the endpoint. For fail to accurately reflect the actual location of the endpoint. For
example, the user may deploy his own WAN behind an access network, example, the user may deploy his own WAN behind an access network,
effectively removing an endpoint some distance from the access effectively removing an endpoint some distance from the access
network's notion of its location. There must be some mechanism network's notion of its location. There must be some mechanism
provided to provision a location for an endpoint by the user or by 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 the access network on behalf of a user. The use of the mechanism
introduces the possibility of users falsely declaring themselves to introduces the possibility of users falsely declaring themselves to
be somewhere they are not. As an aside, normally, if an emergency be somewhere they are not. As an aside, normally, if an emergency
caller insists that he is at a location different from what any caller insists that he is at a location different from what any
automatic location determination system reports he is, responders automatic location determination system reports he is, responders
will always be sent to the user's self-declared location. However 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 this is a matter of local policy and is outside the scope of this
document. document.
6.2.2. Access network "wire database" location information 6.2.2. Access network "wire database" location information
Location information can be maintained by the access network, Location information can be maintained by the access network,
relating some form of identifier for the end subscriber or device to relating some form of identifier for the end subscriber or device to
a location database ("wire database"). In enterprise LANs, wiremap a location database ("wire database"). In enterprise LANs, wiremap
databases map Ethernet switch ports to building locations. In DSL databases map Ethernet switch ports to building locations. In DSL
installations, the local telephone carrier maintains a mapping of installations, the local telephone carrier maintains a mapping of
wire-pairs to subscriber addresses. wire-pairs to subscriber addresses.
Accuracy of location historically has been to a street address level. Accuracy of location historically has been to a street address level.
However, this is not sufficient for larger structures. The PIDF-LO However, this is not sufficient for larger structures. The PIDF-LO
[RFC4119] with a recent extension [I-D.ietf-geopriv-revised-civic-lo] [RFC4119] with a recent extension [RFC5139] permits interior
permits interior building/floor/room and even finer specification of building/floor/room and even finer specification of location within a
location within a street address. When possible, interior location street address. When possible, interior location should be
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 (that is derived from fire brigade recommendations of spacing 650 m2. This value is derived from fire brigade recommendations of
of alarm pull stations) should have, but interior space layout, spacing of alarm pull stations. However, interior space layout,
construction materials and other factors should be considered. The construction materials and other factors should be considered. The
ultimate goal is to be able to find the person in need quickly if ultimate goal is to be able to find the person in need quickly if
responders arrive at the location given. 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.
Wire databases to the home are likely to be the most promising Wire databases are likely to be the most promising solution for
solution for residential users where a service provider knows the residential users where a service provider knows the customer's
customer's service address. The service provider can then perform service address. The service provider can then perform address
address validation (see Section 6.10), similar to the current system validation (see Section 6.10), similar to the current system in some
in some jurisdictions. jurisdictions.
6.2.3. End-system measured location information 6.2.3. End-system measured location information
Global Positioning System (GPS) and similar satellite based (e.g. Global Positioning System (GPS) and similar 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. GPS-derived locations are currently
accurate to tens of meters. 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).
GPS systems may be always on; where location will always be available GPS systems may be always enabled and thus location will always be
accurately (assuming the device can "see" enough satellites). Mobile available accurately immediately (assuming the device can "see"
devices may not be able to sustain the power levels required to keep enough satellites). Mobile devices may not be able to sustain the
the measuring system active. This means that when location is power levels required to keep the measuring system active. In such
needed, the device has to start up the measurement mechanism. This circumstances, when location is needed, the device has to start up
typically takes tens of seconds, far too long to wait to be able to the measurement mechanism. This typically takes tens of seconds, far
route an emergency call. For this reason, devices that don't have too long to wait to be able to route an emergency call. For this
end-system measured location mechanisms always on need another way to reason, devices that have end-system measured location mechanisms but
get a routing location. Typically this would be a location need a "cold start period lasting more than a couple seconds on need
associated with a radio link (cell site/sector). another way to get a routing location. Typically this would be a
location associated with a radio link (cell site/sector).
6.2.4. Network measured location information 6.2.4. Network measured location information
The access network may locate end devices. Techniques include: The access network may locate end devices. Techniques include:
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:
1. Time Difference Of Arrival - TDOA * Time Difference Of Arrival - TDOA
2. Uplink Time Difference Of Arrival - U-TDOA * Uplink Time Difference Of Arrival - U-TDOA
3. Angle of Arrival - AOA * Angle of Arrival - AOA
4. RF-Fingerprinting * RF fingerprinting
5. Advanced Forward Link Trilateration - AFLT * Advanced Forward Link Trilateration - AFLT
6. 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. Outbound proxies that support location and supply it on the call. Where devices do not support
devices that do not support location may have to add location to location, proxy servers may have to add location to emergency calls.
emergency calls at a proxy server. Some calling networks have Some calling networks have relationships with all access networks the
relationships with all access networks the device may be connected device may be connected to, and that may allow the proxy to
to, and that may allow the proxy to accurately determine location of accurately determine location of the endpoint. However, NATs and
the endpoint. However NATs and other middleboxes often make it other middleboxes often make it impossible to determine a reference
impossible to determine a reference identifier the access network identifier the access network could use with a LIS to determine the
could use to determine the location. Systems designers are location of the device. Systems designers are discouraged from
discouraged from relying on proxies to add location. The technique relying on proxies to add location. The technique may be useful in
may be useful in some limited circumstances as devices are upgraded some limited circumstances as devices are upgraded to meet the
to meet the requirements of this document, or where relationships requirements of this document, or where relationships between access
between access networks and calling networks are feasible and can be networks and calling networks are feasible and can be relied upon to
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 Section 6, local dial strings depend on the location noted in Section 6, local dial strings depend on the location of the
of the caller. If the device does not know its own location, it caller. If the device does not know its own location, it cannot use
cannot use the LoST service to learn the local emergency dial the LoST service to learn the local emergency dial strings. The
strings. The calling network must provide another way for the device calling network must provide another way for the device to learn the
to learn the local dial string (and update it when the user moves to local dial string, and update it when the user moves to a location
a location where the dial string(s) change) or do the dial string where the dial string(s) change, or do the dial string determination
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 (a URI pointing to the within the signaling message) or by reference (i.e. as a URI pointing
value residing on a remote node waiting to be dereferenced). Each to the value residing on a remote node waiting to be dereferenced).
form is better suited to some applications than others. Each form is better suited to some applications than others.
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 each device; on the other hand, location objects can be
large, and only represent a single snapshot of the device's location. large, and only represent a single snapshot of the device's location.
Location references are small and can be used to represent a time- Location references are small and can be used to represent a time-
varying location, but the added complexity of the dereference step varying location, but the added complexity of the dereference step
introduces a risk that location will not be available to parties that introduces a risk that location will not be available to parties that
need it. 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 such as: used for this purpose including DHCP, HELD and LLDP:
DHCP DHCP can deliver civic [RFC4676] or geospatial [RFC3825] DHCP can deliver civic [RFC4676] 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 HELD [I-D.ietf-geopriv-http-location-delivery] can deliver a HELD [I-D.ietf-geopriv-http-location-delivery] can deliver a civic
civic or geo, by value or by reference, as a layer 7 protocol. or geo, by value or by reference, as a layer 7 protocol. The
The query typically uses the IP address of the requestor as an query typically uses the IP address of the requestor as an
identifier and returns the location value or reference associated identifier and returns the location value or reference associated
with that identifier. HELD is typically transported on HTTP. with that identifier. HELD is typically carried in HTTP.
Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device
Link-Layer Discovery Protocol Layer Discovery Protocol [LLDP] with extensions [LLDP-MED] can be used to deliver location information
Media Endpoint Device extensions [LLDP-MED] can be used to deliver directly from the Layer 2 network infrastructure, and also
location information directly from the Layer 2 network supports both civic and geospatial formats identical in format to
infrastructure, and also supports both civic and geospatial DHCP methods.
formats identical in format to DHCP methods.
Each LCP has limitations in the kinds of networks that can reasonably Each LCP has limitations in the kinds of networks that can reasonably
support it. For this reason, it is not possible to choose a single support it. For this reason, it is not possible to choose a single
mandatory-to-deploy LCP. For endpoints with common network mandatory-to-deploy LCP. For endpoints with common network
connections (such as an Ethernet jack or a WiFi connection) serious connections (such as an Ethernet jack or a WiFi connection) 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 list of LCPs is established in For this reason, a mandatory-to-implement list of LCPs is established
[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. It is
recognized that this is an onerous requirement, that it would be recognized that this is an onerous requirement that would be
desirable to eliminate. However, since it is the variability of the desirable to eliminate. However, since it is the variability of the
networks that prevent a single protocol from being acceptable, it networks that prevent a single protocol from being acceptable, it
must be the endpoints that implement all of them, and to accommodate 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. 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. to a network. For example, existing mobile networks are being used
to support routers and LANs behind a wireless data network WAN
For example, existing mobile networks are being used to support connection, with Ethernet connected phones connected to that. It is
routers and LANs behind a wireless data network WAN connection, with possible that the access network could support a protocol not on the
Ethernet connected phones connected to that. It is possible that the list, and require every handset in that network to use that protocol
access network could support a protocol not on the list, and require for emergency calls. However, the Ethernet-connected phone won't be
every handset in that network to use that protocol for emergency able to acquire location, and the user of the phone is unlikely to be
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 dissuaded from placing an emergency call on that phone. The
widespread availability of gateways, routers and other network- widespread availability of gateways, routers and other network-
broadening devices means that indirectly connected endpoints are broadening devices means that indirectly connected endpoints are
possible on nearly every network. Network operators and vendors are possible on nearly every network. Network operators and vendors are
cautioned that shortcuts to meeting this requirement are seldom cautioned that shortcuts to meeting this requirement are seldom
successful. successful.
Location for non-mobile devices is normally expected to be acquired Location for non-mobile devices is normally expected to be acquired
at network attachment time and retained by the device. It should be at network attachment time and retained by the device. It should be
refreshed when the cached value becomes invalid. For example, if refreshed when the cached value expires. For example, if DHCP is the
DHCP is the acquisition protocol, refresh of location may occur when acquisition protocol, refresh of location may occur when the IP
the IP address lease is renewed. At the time of an emergency call, address lease is renewed. At the time of an emergency call, the
the location should be refreshed, with the retained location used if location should be refreshed, with the retained location used if the
the location acquisition does not immediately return a value. Mobile location acquisition does not immediately return a value. Mobile
devices may determine location at network attachment time and devices may determine location at network attachment time and
periodically thereafter as a backup in case location determination at periodically thereafter as a backup in case location determination at
the time of call does not work. Mobile device location may be the time of call does not work. Mobile device location may be
refreshed when a TTL expires, the device moves beyond some boundaries refreshed when a TTL expires or the device moves beyond some
(as provided by [I-D.ietf-ecrit-lost]). Normally, mobile devices boundaries (as provided by [I-D.ietf-ecrit-lost]). Normally, mobile
will acquire its location at call time for use in an emergency call devices will acquire its location at call time for use in an
routing. See Section Section 6.8 for a further discussion on emergency call routing. See Section Section 6.8 for a further
location updates for dispatch location. discussion on location updates for dispatch location.
There are many examples of end devices which are applications running There are many examples of end devices which are applications running
on a more general purpose device, such as a personal computer. In on a more general purpose device, such as a personal computer. In
some circumstances, it is not possible for application programs to some circumstances, it is not possible for application programs to
access the network device at a level necessary to implement the LLDP- access the network device at a level necessary to implement the LLDP-
MED protocol, and in other cases, obtaining location via DHCP may be MED protocol, and in other cases, obtaining location via DHCP may be
impossible. In any case it is desirable for an operating system impossible. In any case it is desirable for an operating system
which could be used for any application which could make emergency which could be used for any application which could make emergency
calls to have an API which provides the location of the device for calls to have an API which provides the location of the device for
use by any application. 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 using identifiers used by LCPs to determine location, especially for HELD.
HELD. In some cases, such as residential NAT devices, the NAT is In some cases, such as residential NAT devices, the NAT is placed
before the access network demarcation point and thus the IP address before the access network demarcation point and thus the IP address
seen by the access network is the right identifier for location of seen by the access network is the right identifier for location of
the residence. In many enterprise environments, VPN tunnels can the residence. In many enterprise environments, VPN tunnels can
obscure the actual IP address. Some VPN mechanisms can be bypassed obscure the actual IP address. Some VPN mechanisms can be bypassed
(a query to the LCP can be designated to go through the direct IP so that a query to the LCP can be designated to go through the direct
path, using the correct IP address, and not through the tunnel). In IP path, using the correct IP address, and not through the tunnel.
other cases, no bypass is possible. Of course, LCPs that use Layer 2 In other cases, no bypass is possible. Of course, LCPs that use
mechanisms (DHCP Location options and LLDP-MED) are usually immune Layer 2 mechanisms (DHCP Location options and LLDP-MED) are usually
from such problems because they do not use the IP address as the immune from such problems because they do not use the IP address as
identifier for the device seeking location. 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,00 / (24 * once per day would need to support a query rate of 1,000,00 / (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
has. In mobile handsets, routing is often accomplished with the cell has. In mobile handsets, routing is often accomplished with the cell
site and sector of the tower serving the call, because it can take site and sector of the tower serving the call, because it can take
many seconds to start up the location determination mechanism and many seconds to start up the location determination mechanism and
obtain an accurate location. obtain an accurate location.
There is a tradeoff between the time it takes to get a routing There is a 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. 3 (e.g., for some sort of "quick fix"), it's preferable to wait. Three
seconds, that is the current nominal time for a quick fix, is a very seconds, the current nominal time for a quick fix, is a very long
long time to wait for help, and systems designers should attempt to time to wait for help. Systems designers should attempt to provide
provide accurate routing location in much less time. accurate routing location in much less time then that.
NENA recommends IP based systems complete calls in two seconds (last NENA recommends IP based systems complete calls in two seconds (i.e.,
dial press to ring at PSAP). 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 put location in
the signaling with the call. That is referred to as "conveyance" to the call signaling. This is referred to as "conveyance" to
distinguish it from "configuration". In SIP, the location 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]. 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 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 make take some time for some measurement As discussed above, it make 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 early. 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 a mobile caller, e.g., in a vehicle or In addition, the location of some mobile callers, e.g., in a vehicle
aircraft, can change significantly during the emergency call. While or aircraft, can change significantly during the emergency call.
most often this change is not significant, the PSAP must be able to While most often this change is not significant, the PSAP must be
get updated location information while it is processing the call. able to get updated location information while it is processing the
call.
Subscription is preferred so that the LIS notifies the PSAP when
accurate location is updated rather than requiring a poll operation
from the PSAP to the LIS.
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-by-value. If
the UAC gets new location, it must reINVITE or UPDATE to supply the the UAC gets new location, it must signal the PSAP using a reINVITE
new location. or UPDATE method with a new Geolocation header to 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. Generally, the PSAP can wait for an accurate location for dispatch.
However, there is no fixed limit known in advance; it depends on the However, there is no fixed limit known in advance; it depends on the
nature of the emergency. At some point the PSAP must dispatch. In a nature of the emergency. At some point the PSAP must dispatch. If
subscription environment, the PSAP could update the parameters in the the LIS is notifying the PSAP with a SUBSCRIBE/NOTIFY mechanism, the
filter (immediate response required). In a HELD dereference, there PSAP could update the parameters in a filter on the subscription.
is no way to cancel and the PSAP will have to choose a ResponseTime (immediate response required).
that it will wait for even if it wants to dispatch sooner than that.
(Change as the discussion on ResponseTime evolves). 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.
6.9. Multiple locations 6.9. Multiple locations
Handling multiple locations is discussed in Getting multiple locations all purported to describe the location of
[I-D.ietf-geopriv-pdif-lo-profile]. Conflicting location information the caller is confusing to all, and should be avoided. Handling
is particularly harmful if different routes (PSAPs) result from LoST multiple locations is discussed in . Conflicting location
queries for the multiple locations. Guidelines for dealing with information is particularly harmful if different routes (PSAPs)
multiple locations are also given in [I-D.ietf-ecrit-lost]. result from LoST queries for the multiple locations. When they occur
Generally, if a UA gets multiple locations, it must choose the one to anyway, the general guidance is that the entity earliest in the chain
use. If a proxy is inserting location and has multiple locations, it generally has more knowledge than later elements to make an
must choose the one to use. 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.
The ability of the UA or proxy to understand how and from whom it Guidelines for dealing with multiple locations are also given in
learned its location, and include this information element in the [I-D.ietf-ecrit-lost]. If a UA gets multiple locations, it must
location object that is sent to the PSAP, provides the call-taker choose the one to use for routing, but it may send all of the
with many pieces of information to make decisions upon, and guidance locations it has in the signaling. If a proxy is inserting location
for what to ask the caller and what to tell the responders. and has multiple locations, it must choose the one to use to route
and send any others it has.
The call should indicate the location information that has been used 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.
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.
6.10. Location validation 6.10. Location validation
It is recommended that location must be validated prior to a device It is recommended that location be validated prior to a device
placing an actual emergency call; some jurisdictions require that placing an actual emergency call; some jurisdictions require that
this be done. Validation in this context means both that there is a 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 mapping from the address to a PSAP and that the PSAP understands how
to direct responders to the location. Determining the addresses that to direct responders to the location. Determining the addresses that
are valid can be difficult. There are, for example, many cases of 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 two names for the same street, or two streets with the same name in a
city. In some countries, the current system provides validation. city. In some countries, the current system provides validation.
For example, in the United States, the Master Street Address Guide For example, in the United States, the Master Street Address Guide
(MSAG) records all valid street addresses and is used to ensure that (MSAG) records all valid street addresses and is used to ensure that
the service addresses in phone billing records correspond to valid the service addresses in phone billing records correspond to valid
emergency service street addresses. Validation is normally a concern emergency service street addresses. Validation is normally a concern
for civic addresses, although there could be a concern that a given 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 within at least one PSAP service boundary; that is, a "valid"
geo is one where there is a mapping. geo is one where there is a mapping.
LoST [I-D.ietf-ecrit-lost] includes a location validation function. LoST [I-D.ietf-ecrit-lost] includes a location validation function.
Validation should ideally be performed when a location is entered Validation is normally performed when a location is entered into a
into a Location Information Server. It should be confirmed Location Information Server. It should be confirmed periodically,
periodically, because the mapping database undergoes slow change; new because the mapping database undergoes slow change; new streets are
streets are added or removed, community names change, postal codes added or removed, community names change, postal codes change, etc.
change, etc. Endpoints may wish to validate locations they receive Endpoints may wish to validate locations they receive from the access
from the access network, and will need to validate manually entered network, and will need to validate manually entered locations.
locations. Proxies that insert location may wish to validate Proxies that insert location may wish to validate locations they
locations they receive from a LIS. Test functions (Section 15) receive from a LIS. Test functions (Section 15) should also re-
should also re-validate. validate.
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.
6.11. Default location 6.11. Default location
Occasionally, the access network cannot determine the actual location Occasionally, the access network cannot determine the actual location
of the caller. In these cases, it must supply a default location. of the caller. In these cases, it must supply a default location.
The default location should be as accurate as the network can The default location should be as accurate as the network can
determine. For example, in a cable network, a default location for determine. For example, in a cable network, a default location for
each Cable Modem Termination System (CMTS), with a representative each Cable Modem Termination System (CMTS), with a representative
location for all cable modems served by that CMTS could be provided location for all cable modems served by that CMTS could be provided
if the network is unable to resolve the subscriber to any unit less if the network is unable to resolve the subscriber to anything more
than the CMTS. Default locations must be marked as such so that the precise than the CMTS. Default locations must be marked as such so
PSAP knows that the location is not accurate. that the PSAP knows that the location is not accurate.
6.12. Other location considerations 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.
6.13. LIS and LoST Discovery 7. LIS and LoST Discovery
If endpoints are to get their location and determine the routing of
emergency calls, they must be able to discover a LIS (if the HELD
protocol is used), and a LoST server. DHCP options are defined for
this purpose: [I-D.thomson-geopriv-lis-discovery] and
[I-D.thomson-geopriv-lis-discovery]
In some cases, it may be necessary for the service provider to
provision a LoST server address in the device.
7. Uninitialized devices
Support of devices that are not registered, or that don't have valid Endpoints must be able to discover a LIS (if the HELD protocol is
call back identifiers is complex. In some jurisdictions, for some used), and a LoST server. DHCP options are defined for this purpose
services, support of emergency calls from so-called "uninitialized" [I-D.thomson-geopriv-lis-discovery] and
devices is required. For example, cellular providers in the United [I-D.ietf-ecrit-dhc-lost-discovery]
States must support calls to 9-1-1 from a mobile phone that does not
have an active service contract. It is attractive for such devices
to be able to be used in an emergency. However, the requirement to
do so has caused a huge number of prank calls to the emergency
service. In some countries, it is common to attempt to place an
emergency call from an unitialized device in the local bazaars to
prove to a would-be purchaser that the phone works. For this reason,
PSAP authorities discourage support for unititialized devices.
An unitialized device that can place an emergency call must supply Until such DHCP records are widely available, it may be necessary for
location the same as a fully enabled device, must carry a call back the service provider to provision a LoST server address in the
URI that can be used to call the device back, and should have device.
identifiers in the signaling that can be used to identify the device.
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. If there is no or imprecise (e.g., cell
tower and sector) information at call setup time, an on-going tower and sector) information at call setup time, an on-going
emergency call may also be transferred to another PSAP based on emergency call may also be transferred to another PSAP based on
location information that becomes available in mid-call. 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 fire, police, ambulance or mountain rescue are directed to for specific emergency services such as fire, police, ambulance or
just those emergency-specific PSAPs. This mechanism is supported mountain rescue are directed to just those emergency-specific
by marking emergency calls with the proper service identifier PSAPs. This mechanism is supported by marking emergency calls
[I-D.ietf-ecrit-service-urn]. with the proper service identifier [I-D.ietf-ecrit-service-urn].
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.
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. Routing based video, are separate from PSAPs serving voice calls. ESRPs are
on media would be accomplished at an ESRP. Also, even if media expected to be able to provide routing based on media. Also, even
capability does not affect the selection of the PSAP, there may be if media capability does not affect the selection of the PSAP,
call takers within the PSAP that are specifically trained, e.g., there may be call takers within the PSAP that are specifically
in interactive text or sign language communications, where routing trained, e.g., in interactive text or sign language
within the PSAP based on the media offer would be provided. communications, where routing within the PSAP based on the media
offer would be provided.
Routing for calls by location and by service is the primary function Routing for calls by location and by service is the primary function
LoST [I-D.ietf-ecrit-lost] provides. LoST accepts a query with LoST [I-D.ietf-ecrit-lost] provides. LoST accepts a query with
location (by-value) in either civic or geospatial form, plus a location (by-value) in either civic or geospatial form, plus a
service identifier, and returns a URI (or set of URIs) to route the service identifier, and returns a URI (or set of URIs) to route the
call to. Normal SIP [RFC3261] routing functions are used to resolve call to. Normal SIP [RFC3261] routing functions are used to resolve
the URI to a next hop destination. 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 this cached value. The call mapping functions fail, it should use this 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 [I-D.ietf-geopriv-pdif-lo-profile]. This can geo reported location. This can be an enclosing subset of the area
be an enclosing subset of the area when the reported point is not when the reported point is not near an edge or a smaller edge section
near an edge or a smaller edge section when the reported location is when the reported location is near an edge. Civic location is
near an edge. Civic location is uncommon for mobile devices, but uncommon for mobile devices, but reporting that the same mapping is
reporting that the same mapping is good within a community name, or good within a community name, or even a street, may be very helpful
even a street, may be very helpful for WiFi connected devices that for WiFi connected devices that roam and obtain civic location from
roam and obtain civic location from the AP they are connected to. 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 would have the outbound proxy do the mapping. The proxy themselves may need the outbound proxy do the mapping. If the
must have the location of the endpoint, that is often difficult for endpoint recognized the call was an emergency call, provided the
the calling network to accurately determine. The endpoint may have correct service URN and/or included location on the call in a
its location, but would not normally include it on the call Geolocation header, a proxy server could easily accomplish the
signaling. There is no mechanism provided in mapping.
[I-D.ietf-sip-location-conveyance] 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 redirect a call to the service URN that, if the device
recognized the significance, would include location in the redirected
call. All networks should detect emergency calls and supply default
location and/or routing if it is not already performed.
With the URI obtained from mapping, whether by the endpoint or the However, if the endpoint did not recognize the call was an emergency
proxy, the proxy routes the call. Normal SIP [RFC3261] and [RFC3263] call, and thus did not include location, the proxy's task is more
mechanisms are used to route calls to the URI obtained from the LoST difficult. It is often difficult for the calling network to
query. 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 [I-D.ietf-sip-location-conveyance] 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.
Often, the SIP routing of an emergency call will first route to an Often, the SIP routing of an emergency call will first route to an
incoming call proxy in the domain operated by the emergency service. incoming call proxy in the domain operated by the emergency service.
That proxy is called an "Emergency Services Routing Proxy" (ESRP). That proxy is called an "Emergency Services Routing Proxy" (ESRP).
The ESRP, which is a normal SIP proxy server, may use a variety of The ESRP, which is a normal SIP proxy server, may use a variety of
PSAP state information, the location of the caller, and other PSAP state information, the location of the caller, and other
criteria to onward route the call to the PSAP. In order for the ESRP criteria to onward route the call to the PSAP. In order for the ESRP
to route on media choice, the initial INVITE has to supply an SDP to route on media choice, the initial INVITE request has to supply an
Offer. 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 As discussed above, location is carried in all emergency calls in the
call signaling. Since emergency calls carry privacy-sensitive call signaling. Since emergency calls carry privacy-sensitive
information, they are subject to the requirements for geospatial information, they are subject to the requirements for geospatial
protocols [RFC3693]. In particular, signaling information should be protocols [RFC3693]. In particular, signaling information should be
carried in TLS, i.e., in 'sips' mode. Although there are exceptions carried in TLS, i.e., in 'sips' mode with a ciphersuite which
in [RFC3693] for emergency calls (for example, local policy may includes strong encryption (e.g., AES). There are exceptions in
dictate that location is sent with an emergency call even if the [RFC3693] for emergency calls. For example, local policy may dictate
user's policy would otherwise prohibit that), it is unacceptable to that location is sent with an emergency call even if the user's
have an emergency call fail to complete because a TLS connection was policy would otherwise prohibit that. Never the less, protection
not created for any reason. Thus the call should be attempted with from eavesdropping of location by encryption should be provided.
TLS, but if the TLS session establishment fails, the call should be
automatically retried without TLS. [I-D.ietf-sip-sips] recommends It is unacceptable to have an emergency call fail to complete because
that to achieve this effect the target request a sip URI, but use TLS a TLS connection was not created for any reason. Thus, the call
on the outbound connection. An element that recieves a request over should be attempted with TLS, but if the TLS session establishment
a TLS connection should attempt to create a TLS connection to the fails, the call should be automatically retried without TLS.
next hop. [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
element that receives a request over a TLS connection should attempt
to create a TLS connection to the next hop.
In many cases, persistent TLS connections can be maintained between
elements to minimize the time needed to establish them
[I-D.ietf-sip-outbound]. In other circumstances, use of session
resumption [RFC4507] is recommended. IPSEC [RFC2401] is an
acceptable alternative to TLS when used with an equivalent crypto
suite.
Location may be used for routing by multiple proxy servers on the Location may be used for routing by multiple proxy servers on the
path. Confidentiality mechanisms such as S/MIME encryption of SIP path. Confidentiality mechanisms such as 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. Many SIP
devices do not support TLS. Implementing location conveyance in SIP devices do not support TLS. Implementing location conveyance in SIP
mandates inclusion of TLS support. mandates inclusion of TLS support.
In many cases, persistent TLS connections can be maintained between
elements to minimize the time needed to establish them
[I-D.ietf-sip-outbound]. In other circumstances, use of session
resumption [RFC4507] is recommended. IPSEC [RFC2401] is an
acceptable alternative to TLS.
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 do local dial string interpretation, location, and
emergency call route will create SIP INVITE messages with the Service 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 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 Route header, and the location in a Geolocation header. The INVITE
must also have appropriate call back identifiers To enable media request must also have appropriate call back identifiers. To enable
sensitive routing, the call should include an SDP offer. media sensitive routing, the call should include an SDP offer.
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 are also
expected to provide identity information for the caller. expected to provide identity information for the caller.
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. In SIP systems, the caller must include a Contact
header field indicating its device URI, if globally routable, or 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 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 proxy. This identifier would be used to initiate call-backs
immediately by the call-taker if, for example, the call is immediately by the call-taker if, for example, the call is
prematurely dropped. This is a change from [RFC3261] where Contact: prematurely dropped. This is a change from [RFC3261] where the
is optional. Contact: header is optional.
In addition, a call-back identifier must be included either as the In addition, a call-back identifier must be included either as the
URI in the From header field [RFC3261] verified by SIP Identity URI in the From header field [RFC3261] verified by SIP Identity
[RFC4474] , or as a network asserted URI [RFC3325]. This identifier [RFC4474] or as a network asserted URI [RFC3325]. This identifier
would be used to initiate a call-back at a later time and may reach 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 the caller, not necessarily on the same device (and at the same
location) as the original emergency call as per normal SIP rules. location) as the original emergency call as per normal SIP rules.
Emergency authorities generally discourage support of unitialized
devices (see Section 7. If an uninitialized device does place an
emergency call, some kind of call back URI must be provided (e.g. a
GRUU) in the Contact: header. It is useful to be able to call the
device back some time later as well by including some form of URI in
a network asserted identity.
11. Mid-call behavior 11. Mid-call behavior
A PSAP may need to REFER [RFC3515] a call to a bridge for PSAPs often include dispatchers, responders or specialists on a call.
conferencing. The caller should also be prepared to have the call Some responder's dispatchers are not located in the primary PSAP.
transferred (usually attended, but possibly blind) as per The call may have to be transferred to another PSAP. Most often this
[I-D.ietf-sipping-service-examples]. PSAPs often include will be an attended transfer, or a bridged transfer. Therefore a
dispatchers, responders or specialists on a call. Some responder's PSAP may need to REFER [RFC3515] a call to a bridge for conferencing.
dispatchers are not located in the primary PSAP. The call may have Relay services for communication with people with disabilities may be
to be transferred to another PSAP. Most often this will be an included in the call in this way.
attended transfer, or a bridged transfer. Relay services for
communication with people with disabilities may be included in the The UA should also be prepared to have the call transferred (usually
call in this way. attended, but possibly blind) as per
[I-D.ietf-sipping-service-examples].
SIP Caller Preferences [RFC3841] can be used to signal how the PSAP SIP Caller Preferences [RFC3841] can be used to signal how the PSAP
should handle the call. For example, a language preference expressed should handle the call. For example, a language preference expressed
in an Accept-Language header may be used as a hint to cause the PSAP in an Accept-Language header may be used as a hint to cause the PSAP
to route the call to a call taker who speaks the requested language. to route the call to a call taker who speaks the requested language.
SIP Caller Preferences may also be used to indicate a need to invoke SIP Caller Preferences may also be used to indicate a need to invoke
a relay service for communication with people with disabilities in a relay service for communication with people with disabilities in
the call. the call.
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 call termination is accomplished with normal SIP call PSAP terminates a call using the normal SIP call termination
termination procedures. procedures.
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 can interfere with calls from a PSAP and should be Certain features such as call forwarding can interfere with calls
disabled. The domain of a PSAP can be determined from the domain from a PSAP and should be disabled. A UA can determine a PSAP call
answering an emergency call. A time limit after an emergency call back by examining the domain of incoming calls after placing an
should be established during which any call from the same domain and 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 directed to the supplied Contact: or AoR should be accepted as a
call-back from the PSAP. call-back from the PSAP.
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. With the Internet comes a
wider array of potential media that a PSAP should accept. Using SIP wider array of potential media that a PSAP should accept. Using SIP
signaling includes the capability to negotiate media. Normal SIP signaling includes the capability to negotiate media. Normal SIP
offer/answer [RFC3264] negotiations should be used to agree on the offer/answer [RFC3264] negotiations should be used to agree on the
media streams to be used. PSAPs should accept real-time text media streams to be used. PSAPs should accept real-time text
[RFC4103]. All PSAPs should accept G.711 A law (and mu Law in North [RFC4103]. All PSAPs should accept G.711 A-law (and mu-Law in North
America) encoded voice as described in [RFC3551]. Newer text forms America) encoded voice as described in [RFC3551]. Newer text forms
are rapidly appearing, with Instant Messaging now very common, PSAPs are rapidly appearing, with Instant Messaging now very common, PSAPs
should accept IM with at least [RFC3428] as well as [RFC3920]. Video should accept IM with at least "pager-mode" MESSAGE [RFC3428] as well
may be important to support Video Relay Service (Sign language as Message Session Relay Protocol [RFC4975]. Video may be important
interpretation) as well as modern video phones. to support Video Relay Service (Sign language interpretation) as well
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 yet be made 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 [I-D.ietf-ecrit-phonebcp] includes a description of an automated test
procedure that validates routing, signaling and media path procedure that validates routing, signaling and media path
continuity. This test would be used at boot time, and whenever the continuity. This test would be used within some random interval
device location changes enough that a new PSAP mapping is returned after boot time, and whenever the device location changes enough that
from LoST. A manual operation for the test should also be possible. a new PSAP mapping is returned from LoST. A manual operation for the
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 overused, 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
[I-D.ietf-ecrit-security-threats], and [I-D.barnes-geopriv-lo-sec]. [RFC5069], and [I-D.barnes-geopriv-lo-sec].
Ed. Note: go through that doc and make sure any actions needed are Ed. Note: go through that doc and make sure any actions needed are
captured in the BCP text. captured in the BCP text.
17. Acknowledgements 17. 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 Hannes Tschofenig, Ted Hardie, Martin Dolly, Marc Linsner, Roger
Marshall, Stu Goldman, Shida Schubert and Tom Taylor. Further Marshall, Stu Goldman, Shida Schubert and Tom Taylor. Further
comments and input was provided by Richard Barnes, Barbara Stark and comments and input were provided by Richard Barnes, Barbara Stark and
James Winterbottom. James Winterbottom.
18. References 18. References
18.1. Normative References 18.1. Normative References
[I-D.barnes-geopriv-lo-sec] [I-D.barnes-geopriv-lo-sec]
Barnes, R., "Threats to GEOPRIV Location Objects", Barnes, R., Lepinski, M., Tschofenig, H., and H.
draft-barnes-geopriv-lo-sec-00 (work in progress), Schulzrinne, "Security Requirements for the Geopriv
July 2007. Location System", draft-barnes-geopriv-lo-sec-02 (work in
progress), February 2008.
[I-D.ietf-ecrit-dhc-lost-discovery] [I-D.ietf-ecrit-dhc-lost-discovery]
Schulzrinne, H., "A Dynamic Host Configuration Protocol Schulzrinne, H., "A Dynamic Host Configuration Protocol
(DHCP) based Location-to-Service Translation Protocol (DHCP) based Location-to-Service Translation Protocol
(LoST) Discovery Procedure", (LoST) Discovery Procedure",
draft-ietf-ecrit-dhc-lost-discovery-02 (work in progress), draft-ietf-ecrit-dhc-lost-discovery-02 (work in progress),
July 2007. July 2007.
[I-D.ietf-ecrit-lost] [I-D.ietf-ecrit-lost]
Hardie, T., "LoST: A Location-to-Service Translation Hardie, T., Newton, A., Schulzrinne, H., and H.
Protocol", draft-ietf-ecrit-lost-06 (work in progress), Tschofenig, "LoST: A Location-to-Service Translation
August 2007. Protocol", draft-ietf-ecrit-lost-07 (work in progress),
February 2008.
[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-02 (work in progress), draft-ietf-ecrit-phonebcp-03 (work in progress),
September 2007. November 2007.
[I-D.ietf-ecrit-requirements]
Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress),
March 2007.
[I-D.ietf-ecrit-security-threats]
Taylor, T., "Security Threats and Requirements for
Emergency Call Marking and Mapping",
draft-ietf-ecrit-security-threats-05 (work in progress),
August 2007.
[I-D.ietf-ecrit-service-urn] [I-D.ietf-ecrit-service-urn]
Schulzrinne, H., "A Uniform Resource Name (URN) for Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", Emergency and Other Well-Known Services",
draft-ietf-ecrit-service-urn-07 (work in progress), draft-ietf-ecrit-service-urn-07 (work in progress),
August 2007. August 2007.
[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-03 (work in draft-ietf-geopriv-http-location-delivery-05 (work in
progress), November 2007. progress), February 2008.
[I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-10
(work in progress), October 2007.
[I-D.ietf-geopriv-revised-civic-lo]
Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for PIDF-LO",
draft-ietf-geopriv-revised-civic-lo-06 (work in progress),
October 2007.
[I-D.ietf-sip-gruu] [I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress), (SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007. October 2007.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-08 (work in progress), draft-ietf-sip-location-conveyance-09 (work in progress),
July 2007. November 2007.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-10 (work in progress), July 2007. draft-ietf-sip-outbound-11 (work in progress),
November 2007.
[I-D.ietf-sip-sips] [I-D.ietf-sip-sips]
Audet, F., "The use of the SIPS URI Scheme in the Session Audet, F., "The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", draft-ietf-sip-sips-07 (work Initiation Protocol (SIP)", draft-ietf-sip-sips-08 (work
in progress), November 2007. in progress), February 2008.
[I-D.ietf-sipping-config-framework]
Channabasappa, S., "A Framework for Session Initiation
Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-14 (work in progress),
November 2007.
[I-D.thomson-geopriv-lis-discovery] [I-D.thomson-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-thomson-geopriv-lis-discovery-03 (work in progress), draft-thomson-geopriv-lis-discovery-03 (work in progress),
September 2007. September 2007.
[LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control",
Dec 2004. Dec 2004.
skipping to change at page 34, line 27 skipping to change at page 34, line 5
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004. Location Configuration Information", RFC 3825, July 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005. Conversation", RFC 4103, June 2005.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
Supporting Emergency Telecommunications Service (ETS) in Supporting Emergency Telecommunications Service (ETS) in
IP Telephony", RFC 4190, November 2005. IP Telephony", RFC 4190, November 2005.
skipping to change at page 35, line 22 skipping to change at page 34, line 38
Server-Side State", RFC 4507, May 2006. Server-Side State", RFC 4507, May 2006.
[RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4676, October 2006. Configuration Information", RFC 4676, October 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
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008.
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
Shanmugam, "Security Threats and Requirements for
Emergency Call Marking and Mapping", RFC 5069,
January 2008.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008.
18.2. Informative References 18.2. Informative References
[I-D.ietf-sipping-service-examples] [I-D.ietf-sipping-service-examples]
Johnston, A., "Session Initiation Protocol Service Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
Examples", draft-ietf-sipping-service-examples-13 (work in K. Summers, "Session Initiation Protocol Service
progress), July 2007. Examples", draft-ietf-sipping-service-examples-14 (work in
progress), February 2008.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of [WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of
Defense World Geodetic System 1984, Its Definition and Defense World Geodetic System 1984, Its Definition and
Relationships With Local Geodetic Systems, Third Edition", Relationships With Local Geodetic Systems, Third Edition",
July 1997. July 1997.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar, Inc. NeuStar, Inc.
skipping to change at page 37, line 7 skipping to change at page 37, line 7
TranTech/MediaSolv TranTech/MediaSolv
4900 Seminary Road 4900 Seminary Road
Alexandria, VA 22311 Alexandria, VA 22311
US US
Phone: +1 703 845 0656 Phone: +1 703 845 0656
Email: andy@hxr.us Email: andy@hxr.us
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 150 change blocks. 
591 lines changed or deleted 571 lines changed or added

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