draft-ietf-ecrit-framework-05.txt   draft-ietf-ecrit-framework-06.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: August 28, 2008 Columbia U. Expires: January 11, 2009 Columbia U.
J. Polk J. Polk
Cisco Systems Cisco Systems
A. Newton A. Newton
TranTech/MediaSolv TranTech/MediaSolv
February 25, 2008 July 10, 2008
Framework for Emergency Calling using Internet Multimedia Framework for Emergency Calling using Internet Multimedia
draft-ietf-ecrit-framework-05 draft-ietf-ecrit-framework-06
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 August 28, 2008. This Internet-Draft will expire on January 11, 2009.
Copyright Notice
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 . . 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 . . . . . . . . . . 12 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 . 16 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
skipping to change at page 2, line 43 skipping to change at page 2, line 42
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 . . . . . . . 28 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
18.1. Normative References . . . . . . . . . . . . . . . . . . . 31 19. Informative References . . . . . . . . . . . . . . . . . . . . 31
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document uses terms from [RFC3261] and [RFC5012]. In addition This document uses terms from [RFC3261] and [RFC5012]. In addition
the following terms are used: the following terms are used:
Access network: The access network supplies IP packet service to an Access network: The access network supplies IP packet service to an
endpoint. Examples of access networks include digital subscriber endpoint. Examples of access networks include digital subscriber
lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local
area networks, or cellular data networks. area networks, or cellular data networks.
(Emergency) Call taker: An emergency call taker answers an emergency (Emergency) Call taker: An emergency call taker answers an emergency
call at the PSAP. call at the PSAP.
Confidence: Confidence is an estimate indicating how sure the Confidence: Confidence is an estimate indicating how sure the
measuring system is that the actual location of the person is measuring system is that the actual location of the person is
skipping to change at page 7, line 23 skipping to change at page 7, line 16
on the location of the caller. on the location of the caller.
o The PSAP must be able to automatically obtain the location of the o The PSAP must be able to automatically obtain the location of the
caller with sufficient accuracy to dispatch a responder to help caller with sufficient accuracy to dispatch a responder to help
the caller. the caller.
o The PSAP must be able to re-establish a session to the caller if o The PSAP must be able to re-establish a session to the caller if
for any reason the original session is disrupted. for any reason the original session is disrupted.
3. Overview of how emergency calls are placed 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 [RFC5031] that is placed in the call
placed in the call set-up signaling when a home or visited emergency set-up signaling when a home or visited emergency dial string is
dial string is detected. Because emergency services are local to detected. Because emergency services are local to specific
specific geographic regions, a caller must obtain his location ( geographic regions, a caller must obtain his location ( Section 6)
Section 6) prior to making emergency calls. To get this location, prior to making emergency calls. To get this location, either a form
either a form of measuring, for example, GPS (Section 6.2.3) is of measuring, for example, GPS (Section 6.2.3) is deployed, or the
deployed, or the endpoint is configured (Section 6.5) with its endpoint is configured (Section 6.5) with its location from the
location from the access network's Location Information Server (LIS). access network's Location Information Server (LIS). The location is
The location is conveyed (Section 6.7) in the SIP signaling with the conveyed (Section 6.7) in the SIP signaling with the call. The call
call. The call is routed (Section 8) based on location using the is routed (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], which maps a location to a set of PSAP 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 as an incoming proxy for a group of PSAPs. The
of PSAPs. The call arrives at the PSAP with the location included in call arrives at the PSAP with the location included in the INVITE
the INVITE request. request.
The following is a quick overview for a typical Ethernet connected The following is a quick overview for a typical Ethernet connected
telephone using SIP signaling. It illustrates one set of choices for telephone using SIP signaling. It illustrates one set of choices for
various options presented later in this document. various options presented later in this document.
o The phone "boots" and connects to its access network o The phone "boots" and connects to its access network
o The phone gets location from the DHCP server in civic [RFC4676] or o The phone gets location from the DHCP server in civic [RFC4776] or
geo [RFC3825] forms, a HELD server geo [RFC3825] forms, a HELD server
[I-D.ietf-geopriv-http-location-delivery] or the first level [I-D.ietf-geopriv-http-location-delivery] or the first level
switch's LLDP server [LLDP]. switch's LLDP server [LLDP].
o The phone obtains the local emergency dial string(s) from the o The phone obtains the local emergency dial string(s) from the
[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 Some time later, the user places an emergency call. The phone o Some time later, the user places an emergency call. The phone
recognizes an emergency call from the dial strings and uses recognizes an emergency call from the dial strings and uses
"urn:service:sos" [I-D.ietf-ecrit-service-urn] to mark an "urn:service:sos" [RFC5031] 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, which 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
skipping to change at page 9, line 4 skipping to change at page 8, line 41
||| | PSAP2 | ||| | PSAP2 |
||| +-------+ ||| +-------+
||| |||
||| [M6] +-------+ [M7]+------+ [M8]+-------+ ||| [M6] +-------+ [M7]+------+ [M8]+-------+
Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker Alice ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker
+-------+ +------+ +-------+ +-------+ +------+ +-------+
+-------+ +-------+
| PSAP3 | | PSAP3 |
+-------+ +-------+
Figure 1: Emergency Call Component Topology
Figure 1: Emergency Call Component Topology
The typical message flow for this example using Alice as the caller: The typical message flow for this example using Alice as the caller:
[M1] Alice -> LIS LCP Request(s) (ask for location) [M1] Alice -> LIS LCP Request(s) (ask for location)
LIS -> Alice LCP Reply(s) (replies with location) LIS -> Alice LCP Reply(s) (replies with location)
[M2] Alice -> Registrar SIP REGISTER [M2] Alice -> Registrar SIP REGISTER
Registrar -> Alice SIP 200 OK (REGISTER) Registrar -> Alice SIP 200 OK (REGISTER)
[M3] Alice -> LoST Server Initial LoST Query (contains location) [M3] Alice -> LoST Server Initial LoST Query (contains location)
Lost Server -> Alice Initial LoST Response (contains Lost Server -> Alice Initial LoST Response (contains
PSAP-URI and dial string) PSAP-URI and dial string)
Some time later, Alice dials or otherwise initiates an emergency call Some time later, Alice dials or otherwise initiates an emergency call
skipping to change at page 10, line 36 skipping to change at page 10, line 31
valid for her current ("local") location, or for her "home" location. valid for her current ("local") location, or for her "home" location.
The UA recognizes the dial string. The UA attempts to refresh its The UA recognizes the dial string. The UA attempts to refresh its
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 [RFC3986] "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], which is the first The INVITE message is routed to the ESRP [M7], which is the first
inbound proxy for the emergency services domain. This message is inbound proxy for the emergency services domain. This message is
then routed by the ESRP towards the most appropriate PSAP for Alice's then routed by the ESRP towards the most appropriate PSAP for Alice's
location [M8], as determined by the location and other information. location [M8], as determined by the location and other information.
A proxy in the PSAP chooses an available call taker and extends the A proxy in the PSAP chooses an available call taker and extends the
call to its UA. call to its UA.
skipping to change at page 11, line 42 skipping to change at page 11, line 37
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]. For a single number defined in [RFC5031]. For a single number environment the urn is
environment the urn is "urn:service:sos". Users are not expected to "urn:service:sos". Users are not expected to "dial" an emergency
"dial" an emergency URN. Rather, appropriate emergency dial strings URN. Rather, appropriate emergency dial strings are translated to
are translated to corresponding service URNs, carried in the Request- corresponding service URNs, carried in the Request-URI of the INVITE
URI of the INVITE request. Such translation is best done by the request. Such translation is best done by the endpoint, among other
endpoint, among other reasons, because emergency calls convey reasons, because emergency calls convey location in the signaling,
location in the signaling, but non emergency calls do not normally do but non emergency calls do not normally do that. If the device
that. If the device recognizes the emergency call, it can include recognizes the emergency call, it can include location. Dial string
location. Dial string recognition could be performed in a signaling recognition could be performed in a signaling intermediary (proxy
intermediary (proxy server) if for some reason the endpoint does not server) if for some reason the endpoint does not recognize it.
recognize it.
For devices that are mobile or nomadic, an issue arises of whether For devices that are mobile or nomadic, an issue arises of whether
the home or visited dialing strings should be used. Many users would the home or visited dial strings should be used. Many users would
prefer that their home dialing sequences work no matter where they prefer that their home dialing sequences work no matter where they
are. However, local laws and regulations may require the visited are. However, local laws and regulations may require the visited
dialing sequence(s) work. Therefore, the visited dial string must dialing sequence(s) work. Therefore, the visited dial string must
work while having the home dial string work is optional. work. Devices must allow at least the configuration of the home
country, from which a home dial string can be determined.
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]. Lost servers
must return dial strings for emergency services. 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 is represented as a dial string numbers, the dialing sequence is represented as a dial string
[RFC4967] and the outgoing proxy has to 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 emergency dial translate to the service URN. To determine the local emergency dial
string, the proxy needs the location of the endpoint. This may be string, the proxy needs the location of the endpoint. This may be
difficult in situations where the user can roam or be nomadic. difficult in situations where the user can roam or be nomadic.
Endpoint recognition of emergency dial strings is therefore Endpoint recognition of emergency dial strings is therefore
preferred. If a service provider is unable to guarantee that it can preferred. If a service provider is unable to guarantee that it can
correctly determine local emergency dialstrings, wherever its correctly determine local emergency dialstrings, wherever its
subscribers may be, then it is required that the endpoint do the subscribers may be, then it is required that the endpoint do the
recognition. recognition.
Note: 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. Speed dial mechanisms
may effectively create single button emergency call invocation and
should not be permitted.
6. Location and its role in an emergency call 6. Location and its role in an emergency call
Location is central to the operation of emergency services. It is Location is central to the operation of emergency services. It is
frequently the case that the caller reporting an emergency is unable frequently the case that the caller reporting an emergency is unable
to 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
skipping to change at page 14, line 31 skipping to change at page 14, line 31
warranted, in future documents. warranted, in future documents.
6.1. Types of location information 6.1. Types of location information
There are several ways location can be specified: 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 fine grained other structure. Civic location may include more fine grained
location information such as floor, room and cubicle. Civic location information such as floor, room and cubicle. Civic
information comes in two forms: information comes in two forms:
Jurisdictional this refers to a civic location using actual Jurisdictional refers to a civic location using actual political
political subdivisions, especially for the community name. subdivisions, especially for the community name.
Postal this refers to a civic location for mail delivery. The Postal refers to a civic location for mail delivery. The name of
name of the post office sometimes does not correspond to the the post office sometimes does not correspond to the community
community name and a postal address may contain post office name and a postal address may contain post office boxes or
boxes or street addresses that do not correspond to an actual street addresses that do not correspond to an actual building.
building. Postal addresses are generally unsuitable for Postal addresses are generally unsuitable for emergency call
emergency call dispatch because the post office conventions dispatch because the post office conventions (for community
(for community name, for example) do not match those known by name, for example) do not match those known by the responders.
the responders. The fact that they are unique can sometimes be The fact that they are unique can sometimes be exploited to
exploited to provide a mapping between a postal address and a provide a mapping between a postal address and a civic address
civic address suitable to dispatch a responder to. In IETF suitable to dispatch a responder to. In IETF location
location protocols, there is an element (Postal Community Name) protocols, there is an element (Postal Community Name) that can
that can be included in a location to provide the post office be included in a location to provide the post office name as
name as well as the actual jurisdictional community name. well as the actual jurisdictional community name. There is
There is no other accommodation for postal addresses in these also an element for a postal code. There is no other
protocols. accommodation for postal addresses in these protocols.
Geospatial (geo): Geospatial addresses contain longitude, latitude Geospatial (geo): Geospatial addresses contain longitude, latitude
and altitude information based on an understood datum and earth and altitude information based on an understood datum and earth
shape model. While there have been many datums developed over shape model. While there have been many datums developed over
time, most modern systems are using or moving towards the [WGS84] time, most modern systems are using or moving towards the [WGS84]
datum. 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.
skipping to change at page 17, line 47 skipping to change at page 17, line 47
or by a government (WAAS). or by a government (WAAS).
GPS systems may be always enabled and thus location will always be GPS systems may be always enabled and thus location will always be
available accurately immediately (assuming the device can "see" available accurately immediately (assuming the device can "see"
enough satellites). Mobile devices may not be able to sustain the enough satellites). Mobile devices may not be able to sustain the
power levels required to keep the measuring system active. In such power levels required to keep the measuring system active. In such
circumstances, when location is needed, the device has to start up circumstances, when location is needed, the device has to start up
the measurement mechanism. This typically takes tens of seconds, far the measurement mechanism. This typically takes tens of seconds, far
too long to wait to be able to route an emergency call. For this too long to wait to be able to route an emergency call. For this
reason, devices that have end-system measured location mechanisms but reason, devices that have end-system measured location mechanisms but
need a "cold start period lasting more than a couple seconds on need need a cold start period lasting more than a couple seconds need
another way to get a routing location. Typically this would be a another way to get a routing location. Typically this would be a
location associated with a radio link (cell site/sector). location associated with a radio link (cell 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:
* Time Difference Of Arrival - TDOA * Time Difference Of Arrival - TDOA
skipping to change at page 19, line 27 skipping to change at page 19, line 27
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 including DHCP, HELD and LLDP: used for this purpose including DHCP, HELD and LLDP:
DHCP can deliver civic [RFC4676] or geospatial [RFC3825] DHCP can deliver civic [RFC4776] or geospatial [RFC3825]
information. User agents need to support both formats. Note that information. User agents need to support both formats. Note that
a user agent can use DHCP, via the DHCP REQUEST or INFORM a user agent can use DHCP, via the DHCP REQUEST or INFORM
messages, even if it uses other means to acquire its IP address. messages, even if it uses other means to acquire its IP address.
HELD [I-D.ietf-geopriv-http-location-delivery] can deliver a civic HELD [I-D.ietf-geopriv-http-location-delivery] can deliver a civic
or geo, by value or by reference, as a layer 7 protocol. The or geo, by value or by reference, as a layer 7 protocol. 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 carried in HTTP. with that identifier. HELD is typically carried in HTTP.
Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device Link-Layer Discovery Protocol [LLDP] with Media Endpoint Device
extensions [LLDP-MED] can be used to deliver location information extensions [LLDP-MED] can be used to deliver location information
skipping to change at page 20, line 40 skipping to change at page 20, line 40
acquisition protocol, refresh of location may occur when the IP acquisition protocol, refresh of location may occur when the IP
address lease is renewed. At the time of an emergency call, the address lease is renewed. At the time of an emergency call, the
location should be refreshed, with the retained location used if the location should be refreshed, with the retained location used if the
location acquisition does not immediately return a value. Mobile location acquisition does not immediately return a value. Mobile
devices may determine location at network attachment time and devices may determine location at network attachment time and
periodically thereafter as a backup in case location determination at periodically thereafter as a backup in case location determination at
the time of call does not work. Mobile device location may be the time of call does not work. Mobile device location may be
refreshed when a TTL expires or the device moves beyond some refreshed when a TTL expires or the device moves beyond some
boundaries (as provided by [I-D.ietf-ecrit-lost]). Normally, mobile boundaries (as provided by [I-D.ietf-ecrit-lost]). Normally, mobile
devices will acquire its location at call time for use in an devices will acquire its location at call time for use in an
emergency call routing. See Section Section 6.8 for a further emergency call routing. See Section 6.8 for a further discussion on
discussion on location updates for dispatch location. 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.
skipping to change at page 21, line 25 skipping to change at page 21, line 25
obscure the actual IP address. Some VPN mechanisms can be bypassed obscure the actual IP address. Some VPN mechanisms can be bypassed
so that a query to the LCP can be designated to go through the direct so that a query to the LCP can be designated to go through the direct
IP path, using the correct IP address, and not through the tunnel. IP path, using the correct IP address, and not through the tunnel.
In other cases, no bypass is possible. Of course, LCPs that use In other cases, no bypass is possible. Of course, LCPs that use
Layer 2 mechanisms (DHCP Location options and LLDP-MED) are usually Layer 2 mechanisms (DHCP Location options and LLDP-MED) are usually
immune from such problems because they do not use the IP address as immune from such problems because they do not use the IP address as
the 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,000 / (24 *
60 * 60) = 12 queries per second. 60 * 60) = 12 queries per second.
It is desirable for routing location information to be requested It is desirable for routing location information to be requested
immediately before placing an emergency call. However, if there is immediately before placing an emergency call. However, if there is
any significant delay in getting more recent location, the call any significant delay in getting more recent location, the call
should be placed with the most recent location information the device should be placed with the most recent location information the device
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. Three (e.g., for some sort of "quick fix"), it's preferable to wait. Three
seconds, the current nominal time for a quick fix, is a very long seconds, the current nominal time for a quick fix, is a very long
time to wait for help. Systems designers should attempt to provide time to wait for help. Systems designers should attempt to provide
accurate routing location in much less time then that. accurate routing location in much less time then that.
NENA recommends IP based systems complete calls in two seconds (i.e., NENA recommends [NENAi3TRD]IP based systems complete calls in two
last dial press to ring at PSAP). seconds (i.e., 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 call signaling. This 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]. Since the form of the location [I-D.ietf-sip-location-conveyance]. Since the form of the location
information obtained by the acquisition protocol may not be the same information obtained by the acquisition protocol may not be the same
as the conveyance protocol uses (PIDF-LO [RFC4119]), mapping by the as the conveyance protocol uses (PIDF-LO [RFC4119]), mapping by the
endpoint from the LCP form to PIDF may be required. endpoint from the LCP form to PIDF may be required.
6.8. Location updates 6.8. Location updates
As discussed above, it make take some time for some measurement As discussed above, it may take some time for some measurement
mechanisms to get a location accurate enough for dispatch, and a mechanisms to get a location accurate enough for dispatch, and a
routing location with less accuracy may be provided to get the call routing location with less accuracy may be provided to get the call
established early. The PSAP needs the dispatch location before it established 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 some mobile callers, e.g., in a vehicle In addition, the location of some mobile callers, e.g., in a vehicle
or aircraft, can change significantly during the emergency call. or aircraft, can change significantly during the emergency call.
While most often this change is not significant, the PSAP must be While most often this change is not significant, the PSAP must be
able to get updated location information while it is processing the able to get updated location information while it is processing the
skipping to change at page 22, line 46 skipping to change at page 22, line 46
suitable mechanism. 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. If nature of the emergency. At some point the PSAP must dispatch. If
the LIS is notifying the PSAP with a SUBSCRIBE/NOTIFY mechanism, the the LIS is notifying the PSAP with a SUBSCRIBE/NOTIFY mechanism, the
PSAP could update the parameters in a filter on the subscription. PSAP could update the parameters in a filter on the subscription.
(immediate response required). (immediate response required).
When using a HELD dereference, the PSAP must specify the value When using a HELD dereference, the PSAP must specify the value
"emergencyDispatch" for the ResponseTime parameter. The LIS is "emergencyDispatch" for the ResponseTime parameter. The LIS should
should be aware of the needs of the PSAP as they are local to one be aware of the needs of the PSAP as they are local to one another.
another.
6.9. Multiple locations 6.9. Multiple locations
Getting multiple locations all purported to describe the location of Getting multiple locations all purported to describe the location of
the caller is confusing to all, and should be avoided. Handling the caller is confusing to all, and should be avoided. Handling
multiple locations is discussed in . Conflicting location multiple locations at the point where a PIDF is created is discussed
in [I-D.ietf-geopriv-pdif-lo-profile] . Conflicting location
information is particularly harmful if different routes (PSAPs) information is particularly harmful if different routes (PSAPs)
result from LoST queries for the multiple locations. When they occur result from LoST queries for the multiple locations. When they occur
anyway, the general guidance is that the entity earliest in the chain anyway, the general guidance is that the entity earliest in the chain
generally has more knowledge than later elements to make an generally has more knowledge than later elements to make an
intelligent decision, especially about which location will be used intelligent decision, especially about which location will be used
for routing. It is permissable to send multiple locations towards for routing. It is permissible to send multiple locations towards
the PSAP, but the element that choses the route must select one (and the PSAP, but the element that chooses the route must select one (and
only one) location to use with LoST. only one) location to use with LoST.
Guidelines for dealing with multiple locations are also given in Guidelines for dealing with multiple locations are also given in
[I-D.ietf-ecrit-lost]. If a UA gets multiple locations, it must [I-D.ietf-ecrit-lost]. If a UA gets multiple locations, it must
choose the one to use for routing, but it may send all of the choose the one to use for routing, but it may send all of the
locations it has in the signaling. If a proxy is inserting location locations it has in the signaling. If a proxy is inserting location
and has multiple locations, it must choose the one to use to route and has multiple locations, it must choose the one to use to route
and send any others it has. and send any others it has.
The UA or proxy should have the ability to understand how and from The UA or proxy should have the ability to understand how and from
skipping to change at page 24, line 16 skipping to change at page 24, line 17
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 is normally performed when a location is entered into a Validation is normally performed when a location is entered into a
Location Information Server. It should be confirmed periodically, Location Information Server. It should be confirmed periodically,
because the mapping database undergoes slow change; new streets are because the mapping database undergoes slow change; new streets are
added or removed, community names change, postal codes change, etc. added or removed, community names change, postal codes change, etc.
Endpoints may wish to validate locations they receive from the access Endpoints may wish to validate locations they receive from the access
network, and will need to validate manually entered locations. network, and will need to validate manually entered locations.
Proxies that insert location may wish to validate locations they Proxies that insert location may wish to validate locations they
receive from a LIS. Test functions (Section 15) should also re- receive from a LIS. When the Test functions (Section 15) are
validate. invoked, the location used should be re-validated.
When validation fails, the location given must not be used for an When validation fails, the location given must not be used for an
emergency call. If validation is complete when location is first emergency call. If validation is complete when location is first
loaded into a LIS, any problems can be found and fixed before devices loaded into a LIS, any problems can be found and fixed before devices
could get the bad location. Failure of validation arises because an could get the bad location. Failure of validation arises because an
error is made in determining the location, although occasionally the error is made in determining the location, although occasionally the
LoST database is not up to date or has faulty information. In either LoST database is not up to date or has faulty information. In either
case, the problem must be identified and corrected before using the case, the problem must be identified and corrected before using the
location. location.
skipping to change at page 24, line 50 skipping to change at page 25, line 4
6.12. Location format conversion 6.12. Location format conversion
The endpoint is responsible for mapping any form of location it The endpoint is responsible for mapping any form of location it
receives from an LCP into PIDF-LO form if the LCP did not directly receives from an LCP into PIDF-LO form if the LCP did not directly
return a PIDF. return a PIDF.
7. LIS and LoST Discovery 7. LIS and LoST Discovery
Endpoints must be able to discover a LIS (if the HELD protocol is Endpoints must be able to discover a LIS (if the HELD protocol is
used), and a LoST server. DHCP options are defined for this purpose used), and a LoST server. DHCP options are defined for this purpose
[I-D.thomson-geopriv-lis-discovery] and [I-D.ietf-geopriv-lis-discovery] and
[I-D.ietf-ecrit-dhc-lost-discovery] [I-D.ietf-ecrit-dhc-lost-discovery]
Until such DHCP records are widely available, it may be necessary for Until such DHCP records are widely available, it may be necessary for
the service provider to provision a LoST server address in the the service provider to provision a LoST server address in the
device. device. The endpoint can also do an SRV query within its SIP domain
to find a LoST server. In any environment, more than one of these
mechanisms may yield a LoST server, and they may be differernt. The
recommended priority is DHCP first, provisioned value second, and SRV
query in the SIP domain third.
8. Routing the call to the PSAP 8. Routing the call to the PSAP
Emergency calls are routed based on one or more of the following Emergency calls are routed based on one or more of the following
criteria expressed in the call setup request (INVITE): criteria expressed in the call setup request (INVITE):
Location: Since each PSAP serves a limited geographic region and Location: Since each PSAP serves a limited geographic region and
transferring existing calls delays the emergency response, calls transferring existing calls delays the emergency response, calls
need to be routed to the most appropriate PSAP. In this need to be routed to the most appropriate PSAP. In this
architecture, emergency call setup requests contain location architecture, emergency call setup requests contain location
information, expressed in civic or geospatial coordinates, that information, expressed in civic or geospatial coordinates, that
allows such routing. If there is no or imprecise (e.g., cell allows such routing. 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 specific emergency services such as fire, police, ambulance or for specific emergency services such as fire, police, ambulance or
mountain rescue are directed to just those emergency-specific mountain rescue are directed to just those emergency-specific
PSAPs. This mechanism is supported by marking emergency calls PSAPs. This mechanism is supported by marking emergency calls
with the proper service identifier [I-D.ietf-ecrit-service-urn]. with the proper service identifier [RFC5031]. Even in single
Even in single number jurisdictions, not all services are number jurisdictions, not all services are dispatched by PSAPs and
dispatched by PSAPs and may need alternate URNs to route calls to may need alternate URNs to route calls to the appropriate call
the appropriate call center. center.
Media capabilities of caller: In some cases, emergency call centers Media capabilities of caller: In some cases, emergency call centers
for specific caller media preferences, such as typed text or for specific caller media preferences, such as typed text or
video, are separate from PSAPs serving voice calls. ESRPs are video, are separate from PSAPs serving voice calls. ESRPs are
expected to be able to provide routing based on media. Also, even expected to be able to provide routing based on media. Also, even
if media capability does not affect the selection of the PSAP, if media capability does not affect the selection of the PSAP,
there may be call takers within the PSAP that are specifically there may be call takers within the PSAP that are specifically
trained, e.g., in interactive text or sign language trained, e.g., in interactive text or sign language
communications, where routing within the PSAP based on the media communications, where routing within the PSAP based on the media
offer would be provided. offer would be provided.
skipping to change at page 26, line 5 skipping to change at page 26, line 10
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 its cached value. The call
would follow its normal outbound call processing. would follow its normal outbound call processing.
Determining when the device leaves the area provided by the LoST Determining when the device leaves the area provided by the LoST
service can tax small mobile devices. For this reason, the LoST service can tax small mobile devices. For this reason, the LoST
server should return a simple (small number of points) polygon for server should return a simple (small number of points) polygon for
geo reported location. This can be an enclosing subset of the area geo reported location. This can be an enclosing subset of the area
when the reported point is not near an edge or a smaller edge section when the reported point is not near an edge or a smaller edge section
when the reported location is near an edge. Civic location is when the reported location is near an edge. Civic location is
uncommon for mobile devices, but reporting that the same mapping is uncommon for mobile devices, but reporting that the same mapping is
good within a community name, or even a street, may be very helpful good within a community name, or even a street, may be very helpful
skipping to change at page 27, line 32 skipping to change at page 27, line 34
should be attempted with TLS, but if the TLS session establishment should be attempted with TLS, but if the TLS session establishment
fails, the call should be automatically retried without TLS. fails, the call should be automatically retried without TLS.
[I-D.ietf-sip-sips] recommends that to achieve this effect the target [I-D.ietf-sip-sips] recommends that to achieve this effect the target
request a sip URI, but use TLS on the outbound connection. An request a sip URI, but use TLS on the outbound connection. An
element that receives a request over a TLS connection should attempt element that receives a request over a TLS connection should attempt
to create a TLS connection to the next hop. to create a TLS connection to the next hop.
In many cases, persistent TLS connections can be maintained between In many cases, persistent TLS connections can be maintained between
elements to minimize the time needed to establish them elements to minimize the time needed to establish them
[I-D.ietf-sip-outbound]. In other circumstances, use of session [I-D.ietf-sip-outbound]. In other circumstances, use of session
resumption [RFC4507] is recommended. IPSEC [RFC2401] is an resumption [RFC5077] is recommended. IPSEC [RFC4301] is an
acceptable alternative to TLS when used with an equivalent crypto acceptable alternative to TLS when used with an equivalent crypto
suite. suite.
Location may be used for routing by multiple proxy servers on the Location may be used for routing by multiple proxy servers on the
path. Confidentiality mechanisms such as S/MIME encryption of SIP path. Confidentiality mechanisms such as S/MIME encryption of SIP
signaling [RFC3261] cannot be used because they obscure location. signaling [RFC3261] cannot be used because they obscure location.
Only hop-by-hop mechanisms such as TLS should be used. Many SIP Only hop-by-hop mechanisms such as TLS should be used. 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.
skipping to change at page 30, line 40 skipping to change at page 30, line 43
"avalanche-restart" event where, for example a large power outage "avalanche-restart" event where, for example a large power outage
affects a large number of endpoints, that, when power is restored, affects a large number of endpoints, that, when power is restored,
all attempt to reboot and, possibly, test. Devices need to randomize all attempt to reboot and, possibly, test. Devices need to randomize
their initiation of a boot time test to avoid the problem. their initiation of a boot time test to avoid the problem.
16. Security Considerations 16. Security Considerations
Security considerations for emergency calling have been documented in Security considerations for emergency calling have been documented in
[RFC5069], and [I-D.barnes-geopriv-lo-sec]. [RFC5069], and [I-D.barnes-geopriv-lo-sec].
Ed. Note: go through that doc and make sure any actions needed are 17. IANA Considerations
captured in the BCP text.
17. Acknowledgements This document has no actions for IANA.
18. Acknowledgements
This draft was created from a This draft was created from a
draft-schulzrinne-sipping-emergency-arch-02 together with sections draft-schulzrinne-sipping-emergency-arch-02 together with sections
from draft-polk-newton-ecrit-arch-considerations-02. from draft-polk-newton-ecrit-arch-considerations-02.
Design Team members participating in this draft creation include Design Team members participating in this draft creation include
Hannes Tschofenig, Ted Hardie, Martin Dolly, Marc Linsner, Roger 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 were provided by Richard Barnes, Barbara Stark and comments and input were provided by Richard Barnes, Barbara Stark and
James Winterbottom. James Winterbottom.
18. References 19. Informative References
18.1. Normative References
[I-D.barnes-geopriv-lo-sec] [I-D.barnes-geopriv-lo-sec]
Barnes, R., Lepinski, M., Tschofenig, H., and H. Barnes, R., Lepinski, M., Tschofenig, H., and H.
Schulzrinne, "Security Requirements for the Geopriv Schulzrinne, "Security Requirements for the Geopriv
Location System", draft-barnes-geopriv-lo-sec-02 (work in Location System", draft-barnes-geopriv-lo-sec-02 (work in
progress), February 2008. 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., Polk, J., and H. Tschofenig, "A Dynamic
(DHCP) based Location-to-Service Translation Protocol Host Configuration Protocol (DHCP) based Location-to-
(LoST) Discovery Procedure", Service Translation Protocol (LoST) Discovery Procedure",
draft-ietf-ecrit-dhc-lost-discovery-02 (work in progress), draft-ietf-ecrit-dhc-lost-discovery-03 (work in progress),
July 2007. May 2008.
[I-D.ietf-ecrit-lost] [I-D.ietf-ecrit-lost]
Hardie, T., Newton, A., Schulzrinne, H., and H. Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
Protocol", draft-ietf-ecrit-lost-07 (work in progress), Protocol", draft-ietf-ecrit-lost-10 (work in progress),
February 2008. May 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-03 (work in progress), draft-ietf-ecrit-phonebcp-04 (work in progress),
November 2007. February 2008.
[I-D.ietf-ecrit-service-urn]
Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services",
draft-ietf-ecrit-service-urn-07 (work in progress),
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-05 (work in draft-ietf-geopriv-http-location-delivery-08 (work in
progress), February 2008. progress), July 2008.
[I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-01 (work in progress),
June 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-11
(work in progress), February 2008.
[I-D.ietf-sip-gruu] [I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(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-09 (work in progress), draft-ietf-sip-location-conveyance-10 (work in progress),
November 2007. February 2008.
[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-11 (work in progress), draft-ietf-sip-outbound-15 (work in progress), June 2008.
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-08 (work Initiation Protocol (SIP)", draft-ietf-sip-sips-08 (work
in progress), February 2008. in progress), February 2008.
[I-D.thomson-geopriv-lis-discovery] [I-D.ietf-sipping-service-examples]
Thomson, M. and J. Winterbottom, "Discovering the Local Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
Location Information Server (LIS)", K. Summers, "Session Initiation Protocol Service
draft-thomson-geopriv-lis-discovery-03 (work in progress), Examples", draft-ietf-sipping-service-examples-14 (work in
September 2007. progress), February 2008.
[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 [NENAi3TRD]
Requirement Levels", BCP 14, RFC 2119, March 1997. NENA, "08-751 NENA i3 Technical Requirements for", 2006.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[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
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. November 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002. for Instant Messaging", RFC 3428, December 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
skipping to change at page 34, line 12 skipping to change at page 33, line 52
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.
[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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 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.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 4507, May 2006.
[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 4776, November 2006.
[RFC4967] Rosen, B., "Dial String Parameter for the Session [RFC4967] Rosen, B., "Dial String Parameter for the Session
Initiation Protocol Uniform Resource Identifier", Initiation Protocol Uniform Resource Identifier",
RFC 4967, July 2007. RFC 4967, July 2007.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007. Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008. RFC 5012, January 2008.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031,
January 2008.
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
Shanmugam, "Security Threats and Requirements for Shanmugam, "Security Threats and Requirements for
Emergency Call Marking and Mapping", RFC 5069, Emergency Call Marking and Mapping", RFC 5069,
January 2008. January 2008.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008. Object (PIDF-LO)", RFC 5139, February 2008.
18.2. Informative References
[I-D.ietf-sipping-service-examples]
Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service
Examples", draft-ietf-sipping-service-examples-14 (work in
progress), February 2008.
[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.
470 Conrad Dr 470 Conrad Dr
skipping to change at page 37, line 44 skipping to change at line 1681
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 57 change blocks. 
160 lines changed or deleted 145 lines changed or added

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