draft-ietf-ecrit-framework-03.txt   draft-ietf-ecrit-framework-04.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: March 22, 2008 Columbia U. Expires: May 22, 2008 Columbia U.
J. Polk J. Polk
Cisco Systems Cisco Systems
A. Newton A. Newton
TranTech/MediaSolv TranTech/MediaSolv
September 19, 2007 November 19, 2007
Framework for Emergency Calling using Internet Multimedia Framework for Emergency Calling using Internet Multimedia
draft-ietf-ecrit-framework-03 draft-ietf-ecrit-framework-04
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 March 22, 2008. This Internet-Draft will expire on May 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 . . 11 4. Which devices and services should support emergency calls . . 10
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 . . . . . . . . . . 13
6.1. Types of location information . . . . . . . . . . . . . . 14 6.1. Types of location information . . . . . . . . . . . . . . 14
6.2. Location Determination . . . . . . . . . . . . . . . . . . 16 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 . 17
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 . . . . . . . . . . . . . . . . 22
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. Other location considerations . . . . . . . . . . . . . . 24
6.13. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . 24
7. Uninitialized devices . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 26 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 27
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . 27
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 28 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 28
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 28 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 29
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 28 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 29
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
16. Security Considerations . . . . . . . . . . . . . . . . . . . 29 16. Security Considerations . . . . . . . . . . . . . . . . . . . 30
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
18.1. Normative References . . . . . . . . . . . . . . . . . . . 30 18.1. Normative References . . . . . . . . . . . . . . . . . . . 31
18.2. Informative References . . . . . . . . . . . . . . . . . . 34 18.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 36 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
[I-D.ietf-ecrit-requirements]. In addition the following terms are [I-D.ietf-ecrit-requirements]. In addition the following terms are
used: used:
skipping to change at page 6, line 32 skipping to change at page 6, line 32
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.
A companion document, [I-D.ietf-ecrit-phonebcp] describes Best
Current Practice for this subject and contains 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 unaware of
the recommendations in this draft may be able to place emergency 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
skipping to change at page 7, line 24 skipping to change at page 7, line 29
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 Section 6) prior to making emergency calls. To get this
location, either a form of measuring (e.g., GPS) (Section 6.2.3) location, either a form of measuring (e.g., GPS) (Section 6.2.3)
device location in the endpoint is deployed, or the endpoint is device location in the endpoint is deployed, or the endpoint is
configured (Section 6.5) with its location from the access network's configured (Section 6.5) with its location from the access network's
Location Information Server (LIS). The location is conveyed Location Information Server (LIS). The location is conveyed
(Section 6.7) in the SIP signaling with the call. The call is routed (Section 6.7) in the SIP signaling with the call. The call is routed
(Section 8) based on location using the LoST protocol (Section 8) based on location using the LoST protocol
[I-D.ietf-ecrit-lost], that maps a location to a set of PSAP or URIs. [I-D.ietf-ecrit-lost], that maps a location to a set of PSAP or URIs.
Each URI resolves to a PSAP or an Emergency Services Routing Proxy Each URI resolves to a PSAP or an Emergency Services Routing Proxy
(ESRP) that serves a group of PSAPs. The call arrives at the PSAP (ESRP) that serves an incoming proxy for group of PSAPs. The call
with the location included in the INVITE request. arrives at the PSAP with the location included in the INVITE request.
The following is a quick overview for a typical Ethernet connected The following is a quick overview for a typical Ethernet connected
telephone using SIP signaling. It illustrates one set of choices for telephone using SIP signaling. It illustrates one set of choices for
various options presented later in this document. various options presented later in this document.
o The phone "boots" and connects to its access network o The phone "boots" and connects to its access network
o The phone gets location from the DHCP server [RFC4676] or o The phone gets location from the DHCP server [RFC4676] or
[RFC3825], a HELD server [I-D.ietf-geopriv-http-location-delivery] [RFC3825], a HELD server [I-D.ietf-geopriv-http-location-delivery]
or the first level switch's LLDP server [LLDP]. 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
skipping to change at page 7, line 46 skipping to change at page 8, line 4
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 It 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, that 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 in o The call routing commonly traverses an incoming proxy server
the emergency services network. That proxy would route to the (ESRP) in the emergency services network. That proxy would route
PSAP. 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 common media streams are
created. 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 | | .
skipping to change at page 9, line 4 skipping to change at page 9, line 4
||| |||
||| [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
Configuration LoST The typical message flow would be:
Alice Servers ESRP Server PSAP [M1] Alice -> LIS LCP Request(s) (ask for location)
LIS -> ALICE LCP Reply(s) (replies with location)
[M1] LCP Request(s) (ask for location) [M2] Alice -> Registrar SIP REGISTER
----------> Registrar -> Alice SIP 200 OK (REGISTER)
LCP Reply(s) (replies with location) [M3] Alice -> LoST Server Initial LoST Query (contains location)
<--------- Lost Server -> Alice Initial LoST Response (contains
[M2] SIP REGISTER PSAP-URI and dial string)
---------->
SIP 200 OK (REGISTER)
<---------
[M3] Initial LoST Protocol Query (contains location)
---------------------------------------->
Initial LoST Protocol Response (contains PSAP-URI and dial
string)
<----------------------------------------
*** Some time later, Alice dials/initiates emergency call *** *** Some time later, Alice dials/initiates emergency call ***
[M4] LCP Request (update location) [M4] Alice -> LIS LCP Request (update location)
----------> LIS -> ALICE LCP Reply (replies with location)
LCP Reply (replies with location) [M5] Alice -> LoST Server Update LoST Query (contains location)
<--------- Lost Server -> Alice LoST Response (contains PSAP-URI)
[M5] Update LoST Protocol Query (contains location) [M6] Alice to Outgoing Proxy INVITE (service URN,
----------------------------------------> Location and PSAP URI)
LoST Protocol Response (contains PSAP-URI) Outgoing Proxy to ESRP INVITE (service URN,
<---------------------------------------- Location and PSAP URI)
[M6/7] INVITE (service URN, Location & PSAP URI) ESRP to PSAP INVITE (service URN, Location and PSAP URI)
--------------------->
[M8] INVITE (urm:service:sos, Location & PSAP-URI) *** 200 OK and ACK propogated back from PSAP to Alice ***
-------------------------------------->
200 OK
<--------------------------------------------------------------
ACK
-------------------------------------------------------------->
Emergency Session Established
<=============================================================>
Figure 2: General Flow of an Emergency Call Establishment Figure 2: Emergency Call Message Flow
Figure 1 shows emergency call component topology and Figure 2 shows Figure 1 shows emergency call component topology and the text above
call establishment. These include the following: shows call establishment. These include the following:
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
skipping to change at page 12, line 38 skipping to change at page 12, line 21
Having the home dial string work is optional. 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 would be represented as a dial string
[RFC4967] and the outgoing proxy would recognize the dial string and [RFC4967] and the outgoing proxy would 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 dial string,
the proxy needs the location of the endpoint. This may be difficult the proxy needs the location of the endpoint. This may be difficult
in situations where the user can roam or be nomadic. Endpoint in situations where the user can roam or be nomadic. Endpoint
recognition of emergency dial strings is therefore preferred. recognition of emergency dial strings is therefore preferred, and in
fact if a service provider is unable to guarantee that it can
correctly determine local emergency dialstrings 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 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 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 countries there are several 3 digit numbers used for different types
skipping to change at page 14, line 27 skipping to change at page 14, line 14
"dispatch location" when the distinction matters. "dispatch location" when the distinction matters.
Accuracy of dispatch location is sometimes determined by local Accuracy of dispatch location is sometimes determined by local
regulation, and is constrained by available technology. The actual regulation, and is constrained by available technology. The actual
requirement exceeds available technology. It is required that a requirement 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. confidence is 100 m. As technology advances, the accuracy
requirements for location will need to be increased. Wired systems
using wire tracing mechanisms can provide location to a wall jack in
specific room on a floor in a building, and may even specify a
cubicle or even smaller resolution. As this discussion illustrates,
emergency call systems demand the most stringent location accuracy
available.
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,
skipping to change at page 16, line 23 skipping to change at page 16, line 15
party and inserted into the call signaling. Choice of location party and inserted into the call signaling. Choice of location
determination mechanisms and their properties are out of scope for determination mechanisms and their properties are out of scope for
this document. 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 (indoor high
rise in dense urban areas for example). rise in dense urban areas for example). In general, the closer an
entity is to the source of location, the more it is in the best
position to determine which location is "best" for a particular
purpose. In emergency calling, the PSAP is the least likely to be
able to appropriately choose which location when multiple conflicting
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
skipping to change at page 21, line 14 skipping to change at page 21, line 14
the location acquisition does not immediately return a value. Mobile the 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, the device moves beyond some boundaries
(as provided by [I-D.ietf-ecrit-lost]). Normally, mobile devices (as provided by [I-D.ietf-ecrit-lost]). Normally, mobile devices
will acquire its location at call time for use in an emergency call will acquire its location at call time for use in an emergency call
routing. See Section Section 6.8 for a further discussion on routing. See Section Section 6.8 for a further discussion on
location updates for dispatch location. location updates for dispatch location.
There are many examples of end devices which are applications running
on a more general purpose device, such as a personal computer. In
some circumstances, it is not possible for application programs to
access the network device at a level necessary to implement the LLDP-
MED protocol, and in other cases, obtaining location via DHCP may be
impossible. In any case it is desirable for an operating system
which could be used for any application which could make emergency
calls to have an API which provides the location of the device for
use by any application.
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 using
HELD. In some cases, such as residential NAT devices, the NAT is HELD. In some cases, such as residential NAT devices, the NAT is
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
skipping to change at page 24, line 26 skipping to change at page 24, line 35
if the network is unable to resolve the subscriber to any unit less if the network is unable to resolve the subscriber to any unit less
than the CMTS. Default locations must be marked as such so that the than the CMTS. Default locations must be marked as such so that the
PSAP knows that the location is not accurate. PSAP knows that the location is not accurate.
6.12. Other location considerations 6.12. Other location considerations
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.
To prevent against spoofing of the DHCP server, devices implementing 6.13. LIS and LoST Discovery
DHCP for location configuration should use DHCP security mechanisms
[RFC3118].
Location may be used for routing by multiple proxy servers on the If endpoints are to get their location and determine the routing of
path. Mechanism such as S/MIME in SIP signaling [RFC3261] cannot be emergency calls, they must be able to discover a LIS (if the HELD
used because they obscure location. Only hop-by-hop mechanisms such protocol is used), and a LoST server. DHCP options are defined for
as TLS should be used. Location information is sensitive and must be this purpose: [I-D.thomson-geopriv-lis-discovery] and
protected [RFC3693]. Although support of TLS is mandatory in [I-D.thomson-geopriv-lis-discovery]
[RFC3261], many devices do not support it. Implementing location
conveyance in SIP mandates inclusion of TLS support. In some cases, it may be necessary for the service provider to
provision a LoST server address in the device.
7. Uninitialized devices 7. Uninitialized devices
Support of devices that are not registered, or that don't have valid Support of devices that are not registered, or that don't have valid
call back identifiers is complex. In some jurisdictions, for some call back identifiers is complex. In some jurisdictions, for some
services, support of emergency calls from so-called "uninitialized" services, support of emergency calls from so-called "uninitialized"
devices is required. For example, cellular providers in the United devices is required. For example, cellular providers in the United
States must support calls to 9-1-1 from a mobile phone that does not 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 have an active service contract. It is attractive for such devices
to be able to be used in an emergency. However, the requirement to to be able to be used in an emergency. However, the requirement to
skipping to change at page 27, line 4 skipping to change at page 27, line 13
Offer. 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. However, it is unacceptable to carried in TLS, i.e., in 'sips' mode. Although there are exceptions
in [RFC3693] for emergency calls (for example, local policy may
dictate that location is sent with an emergency call even if the
user's policy would otherwise prohibit that), it is unacceptable to
have an emergency call fail to complete because a TLS connection was have an emergency call fail to complete because a TLS connection was
not created, for any reason. Thus the call should be attempted with not created for any reason. Thus the call should be attempted with
TLS, but if the TLS session establishment fails, the call should be TLS, but if the TLS session establishment fails, the call should be
automatically retried without TLS. In many cases, persistent TLS automatically retried without TLS. [I-D.ietf-sip-sips] recommends
connections can be maintained between elements to minimize the time that to achieve this effect the target request a sip URI, but use TLS
needed to establish them [I-D.ietf-sip-outbound]. In other on the outbound connection. An element that recieves a request over
circumstances, use of session resumption [RFC4507] is recommended. a TLS connection should attempt to create a TLS connection to the
IPSEC [RFC2401] is an acceptable alternative to TLS. next hop.
Location may be used for routing by multiple proxy servers on the
path. Confidentiality mechanisms such as S/MIME encryption of SIP
signaling [RFC3261] cannot be used because they obscure location.
Only hop-by-hop mechanisms such as TLS should be used. Many SIP
devices do not support TLS. Implementing location conveyance in SIP
mandates inclusion of TLS support.
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 must also have appropriate call back identifiers To enable media
sensitive routing, the call should include an SDP offer. sensitive routing, the call should include an SDP offer.
skipping to change at page 28, line 15 skipping to change at page 28, line 38
emergency call, some kind of call back URI must be provided (e.g. a 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 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 device back some time later as well by including some form of URI in
a network asserted identity. 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 A PSAP may need to REFER [RFC3515] a call to a bridge for
conferencing. The caller should also be prepared to have the call conferencing. The caller should also be prepared to have the call
transferred (usually attended, but possibly blind) as per transferred (usually attended, but possibly blind) as per
[I-D.ietf-sipping-service-examples]. [I-D.ietf-sipping-service-examples]. PSAPs often include
dispatchers, responders or specialists on a call. Some responder's
dispatchers are not located in the primary PSAP. The call may have
to be transferred to another PSAP. Most often this will be an
attended transfer, or a bridged transfer. Relay services for
communication with people with disabilities may be included in the
call in this way.
SIP Caller Preferences [RFC3841] can be used to signal how the PSAP
should handle the call. For example, a language preference expressed
in an Accept-Language header may be used as a hint to cause the PSAP
to route the call to a call taker who speaks the requested language.
SIP Caller Preferences may also be used to indicate a need to invoke
a relay service for communication with people with disabilities in
the call.
12. Call termination 12. Call termination
It is undesirable for the caller to terminate an emergency call. It is undesirable for the caller to terminate an emergency call.
PSAP call termination is accomplished with normal SIP call PSAP call termination is accomplished with normal SIP call
termination procedures. termination 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
skipping to change at page 29, line 11 skipping to change at page 29, line 47
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 [RFC3428] as well as [RFC3920]. Video
may be important to support Video Relay Service (Sign language may be important to support Video Relay Service (Sign language
interpretation) as well as modern video phones. interpretation) as well as modern video phones.
Media should be kept secure, preferably by use of Secure RTP While it is desirable for media to be kept secure, preferably by use
[RFC3711]. of Secure RTP [RFC3711], there is not yet consensus on how best to
signal keying material for SRTP. As a consequence, no recommendation
to support SRTP can yet be made 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.
skipping to change at page 30, line 26 skipping to change at page 31, line 16
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., "Threats to GEOPRIV Location Objects",
draft-barnes-geopriv-lo-sec-00 (work in progress), draft-barnes-geopriv-lo-sec-00 (work in progress),
July 2007. July 2007.
[I-D.ietf-ecrit-dhc-lost-discovery]
Schulzrinne, H., "A Dynamic Host Configuration Protocol
(DHCP) based Location-to-Service Translation Protocol
(LoST) Discovery Procedure",
draft-ietf-ecrit-dhc-lost-discovery-02 (work in progress),
July 2007.
[I-D.ietf-ecrit-lost] [I-D.ietf-ecrit-lost]
Hardie, T., "LoST: A Location-to-Service Translation Hardie, T., "LoST: A Location-to-Service Translation
Protocol", draft-ietf-ecrit-lost-06 (work in progress), Protocol", draft-ietf-ecrit-lost-06 (work in progress),
August 2007. August 2007.
[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-01 (work in progress), draft-ietf-ecrit-phonebcp-02 (work in progress),
March 2007. September 2007.
[I-D.ietf-ecrit-requirements] [I-D.ietf-ecrit-requirements]
Schulzrinne, H. and R. Marshall, "Requirements for Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress), draft-ietf-ecrit-requirements-13 (work in progress),
March 2007. March 2007.
[I-D.ietf-ecrit-security-threats] [I-D.ietf-ecrit-security-threats]
Taylor, T., "Security Threats and Requirements for Taylor, T., "Security Threats and Requirements for
Emergency Call Marking and Mapping", Emergency Call Marking and Mapping",
draft-ietf-ecrit-security-threats-05 (work in progress), draft-ietf-ecrit-security-threats-05 (work in progress),
August 2007. 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., "HTTP Enabled Location Delivery (HELD)", Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
draft-ietf-geopriv-http-location-delivery-01 (work in "HTTP Enabled Location Delivery (HELD)",
progress), July 2007. draft-ietf-geopriv-http-location-delivery-03 (work in
progress), November 2007.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-geopriv-pdif-lo-profile]
Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Considerations and Recommendations", PIDF-LO Usage Clarification, Considerations and
draft-ietf-geopriv-pdif-lo-profile-08 (work in progress), Recommendations", draft-ietf-geopriv-pdif-lo-profile-10
July 2007. (work in progress), October 2007.
[I-D.ietf-geopriv-revised-civic-lo] [I-D.ietf-geopriv-revised-civic-lo]
Thomson, M. and J. Winterbottom, "Revised Civic Location Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for PIDF-LO", Format for PIDF-LO",
draft-ietf-geopriv-revised-civic-lo-05 (work in progress), draft-ietf-geopriv-revised-civic-lo-06 (work in progress),
February 2007. 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-14 (work in progress), (SIP)", draft-ietf-sip-gruu-15 (work in progress),
June 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-08 (work in progress),
July 2007. July 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-10 (work in progress), July 2007.
[I-D.ietf-sip-sips]
Audet, F., "The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", draft-ietf-sip-sips-07 (work
in progress), November 2007.
[I-D.ietf-sipping-config-framework] [I-D.ietf-sipping-config-framework]
Petrie, D. and S. Channabasappa, "A Framework for Session Channabasappa, S., "A Framework for Session Initiation
Initiation Protocol User Agent Profile Delivery", Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-12 (work in progress), draft-ietf-sipping-config-framework-14 (work in progress),
June 2007. November 2007.
[I-D.thomson-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)",
draft-thomson-geopriv-lis-discovery-03 (work in progress),
September 2007.
[LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control",
Dec 2004. Dec 2004.
[LLDP-MED] [LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery". Endpoint Discovery".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
 End of changes. 40 change blocks. 
105 lines changed or deleted 167 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/