draft-ietf-ecrit-phonebcp-07.txt   draft-ietf-ecrit-phonebcp-08.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track J. Polk Intended status: BCP J. Polk
Expires: July 31, 2009 Cisco Systems Expires: August 30, 2009 Cisco Systems
January 27, 2009 February 26, 2009
Best Current Practice for Communications Services in support of Best Current Practice for Communications Services in support of
Emergency Calling Emergency Calling
draft-ietf-ecrit-phonebcp-07 draft-ietf-ecrit-phonebcp-08
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 31, 2009. This Internet-Draft will expire on August 30, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
The IETF and other standards organization have efforts targeted at The IETF and other standards organization have efforts targeted at
standardizing various aspects of placing emergency calls on IP standardizing various aspects of placing emergency calls on IP
networks. This memo describes best current practice on how devices, networks. This memo describes best current practice on how devices,
networks and services should use such standards to make emergency networks and services should use such standards to make emergency
calls. calls.
Table of Contents Table of Contents
skipping to change at page 2, line 48 skipping to change at page 2, line 44
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 14 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 14
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 15 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 15
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. SIP signaling requirements for User Agents . . . . . . . . 15 9.2. SIP signaling requirements for User Agents . . . . . . . . 15
9.3. SIP signaling requirements for proxy servers . . . . . . . 17 9.3. SIP signaling requirements for proxy servers . . . . . . . 17
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 18 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 18
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 18 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 18
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 18 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 18
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
16. Security Considerations . . . . . . . . . . . . . . . . . . . 20 16. Security Considerations . . . . . . . . . . . . . . . . . . . 21
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
19.1. Normative References . . . . . . . . . . . . . . . . . . . 21 19.1. Normative References . . . . . . . . . . . . . . . . . . . 21
19.2. Informative References . . . . . . . . . . . . . . . . . . 24 19.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. BCP Requirements Sorted by Responsible Party . . . . 25 Appendix A. BCP Requirements Sorted by Responsible Party . . . . 25
A.1. Requirements of End Devices . . . . . . . . . . . . . . . 25 A.1. Requirements of End Devices . . . . . . . . . . . . . . . 25
A.2. Requirements of Service Providers . . . . . . . . . . . . 34 A.2. Requirements of Service Providers . . . . . . . . . . . . 34
A.3. Requirements of Access Network . . . . . . . . . . . . . . 39 A.3. Requirements of Access Network . . . . . . . . . . . . . . 39
A.4. Requirements of Intermediate Devices . . . . . . . . . . . 42 A.4. Requirements of Intermediate Devices . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
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], [RFC5012] and This document uses terms from [RFC3261], [RFC5012] and
[I-D.ietf-ecrit-framework]. [I-D.ietf-ecrit-framework].
2. Introduction 2. Introduction
This document describes how access networks, SIP user agents, proxy This document describes how access networks, SIP user agents, proxy
servers and PSAPs support emergency calling, as outlined in servers and PSAPs support emergency calling, as outlined in
[I-D.ietf-ecrit-framework], which is designed to complement the [I-D.ietf-ecrit-framework], which is designed to complement the
present document in section headings, numbering and content. This present document in section headings, numbering and content. This
BCP succinctly describes the requirements of end devices and BCP succinctly describes the requirements of end devices and
applications (requirements prefaced by "ED-"), access networks applications (requirements prefaced by "ED-"), access networks
(requirements prefaced by "AN-", service providers (requirements (including enterprise access networks) (requirements prefaced by
prefaced by "SP-") and PSAPs to achieve globally interoperable "AN-", service providers (requirements prefaced by "SP-") and PSAPs
emergency calling on the Internet. to achieve globally interoperable emergency calling on the Internet.
This document also defines requirements for "Intermediate" devices This document also defines requirements for "Intermediate" devices
which exist between end devices or applications and the access which exist between end devices or applications and the access
network. For example, a home router is an "Intermediate" device. network. For example, a home router is an "Intermediate" device.
Reporting location on an emergency call (see Section 6) may depend on Reporting location on an emergency call (see Section 6) may depend on
the ability of such intermediate devices to meet the requirements the ability of such intermediate devices to meet the requirements
prefaced by "INT-". prefaced by "INT-".
3. Overview of how emergency calls are placed 3. Overview of how emergency calls are placed
skipping to change at page 5, line 38 skipping to change at page 5, line 38
SP-2 Proxy servers SHOULD recognize emergency dial strings if for SP-2 Proxy servers SHOULD recognize emergency dial strings if for
some reason the endpoint does not recognize them. This cannot be some reason the endpoint does not recognize them. This cannot be
relied upon by the device if the service provider cannot always relied upon by the device if the service provider cannot always
determine the location of the device. determine the location of the device.
ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the
Request-URI of the INVITE. Request-URI of the INVITE.
ED-5/SP-4 Local dial strings MUST be recognized. ED-5/SP-4 Local dial strings MUST be recognized.
ED-6/SP-5 Devices MUST be able to be configured with the home country ED-6/SP-5 deleted
from which the home dial string(s) can be determined.
ED-7/SP-6 Emergency dial strings SHOULD be determined from LoST ED-7/SP-6 Emergency dial strings SHOULD be determined from LoST
[RFC5222]. Dial Strings MAY be configured directly in the device. [RFC5222]. Dial Strings MAY be configured directly in the device.
AN-1 LoST servers MUST return dial strings for emergency services AN-1 LoST servers MUST return dial strings for emergency services
ED-8 Endpoints which do not recognize emergency dial strings SHOULD ED-8 Endpoints which do not recognize emergency dial strings SHOULD
send dial strings as per [RFC4967]. send dial strings as per [RFC4967].
SP-7 If a proxy server recognizes dial strings on behalf of its SP-7 If a proxy server recognizes dial strings on behalf of its
clients it MUST recognize emergency dial strings represented by clients it MUST recognize emergency dial strings represented by
[RFC4967] and SHOULD recognize emergency dial strings represented by [RFC4967] and SHOULD recognize emergency dial strings represented by
a tel URI [RFC3966]. a tel URI [RFC3966].
SP-8 Service providers MAY provide home dial strings by ED-9 Endpoints SHOULD be able to have home dial strings provisioned.
configuration.
ED-9 Endpoints SHOULD be able to have home dial strings provisioned SP-8 Service providers MAY provision home dial strings in devices.
by configuration.
ED-10 Devices SHOULD NOT have one button emergency calling ED-10 Devices SHOULD NOT have one button emergency calling
initiation. initiation.
ED-11/SP-9 All emergency services specified in [RFC5031] MUST be ED-11/SP-9 All emergency services specified in [RFC5031] MUST be
recognized. recognized.
6. Location and its role in an emergency call 6. Location and its role in an emergency call
Handling location for emergency calling usually involves several Handling location for emergency calling usually involves several
skipping to change at page 8, line 24 skipping to change at page 8, line 24
have at least a coarse location (typically <1km when not location have at least a coarse location (typically <1km when not location
hiding) capability at all times for routing of calls. hiding) capability at all times for routing of calls.
AN-11 Access networks with range of <10 meters (e.g. personal area AN-11 Access networks with range of <10 meters (e.g. personal area
networks such as Bluetooth MUST provide a location to mobile devices networks such as Bluetooth MUST provide a location to mobile devices
connected to them. The location provided SHOULD be that of the connected to them. The location provided SHOULD be that of the
access point location unless a more accurate mechanism is provided. access point location unless a more accurate mechanism is provided.
6.3. Who adds location, endpoint or proxy 6.3. Who adds location, endpoint or proxy
ED-18/INT-9 Endpoints SHOULD attempt to configure their own location. ED-18/INT-9 Endpoints SHOULD attempt to configure their own location
using the LCPs listed in ED-21.
SP-12 Proxies MAY provide location on behalf of devices if: SP-12 Proxies MAY provide location on behalf of devices if:
o The proxy has a relationship with all access networks the device o The proxy has a relationship with all access networks the device
could connect to, and the relationship allows it to obtain could connect to, and the relationship allows it to obtain
location. location.
o The proxy has an identifier, such as an IP address, that can be o The proxy has an identifier, such as an IP address, that can be
used by the access network to determine the location of the used by the access network to determine the location of the
endpoint, even in the presence of NAT and VPN tunnels that may endpoint, even in the presence of NAT and VPN tunnels that may
obscure the identifier between the access network and the service obscure the identifier between the access network and the service
provider. provider.
skipping to change at page 9, line 11 skipping to change at page 9, line 11
value or by reference. An end device that receives location by value or by reference. An end device that receives location by
reference (and does not also get the corresponding value) MUST be reference (and does not also get the corresponding value) MUST be
able to perform a dereference operation to obtain a value. able to perform a dereference operation to obtain a value.
6.5. End system location configuration 6.5. End system location configuration
ED-21/INT-12 Devices MUST support both the DHCP location options ED-21/INT-12 Devices MUST support both the DHCP location options
[RFC4776], [RFC3825] and HELD [RFC4776], [RFC3825] and HELD
[I-D.ietf-geopriv-http-location-delivery]. When devices deploy a [I-D.ietf-geopriv-http-location-delivery]. When devices deploy a
specific access network interface in which that access network specific access network interface in which that access network
supports location discovery such as LLDP-MED or 802.11, the device supports location discovery such as LLDP-MED or 802.11v, the device
SHOULD support the additional respective access network specific SHOULD support the additional respective access network specific
location discovery mechanism. location discovery mechanism.
AN-12/INT-13 The access network MUST support either DHCP location AN-12/INT-13 The access network MUST support either DHCP location
options or HELD. The access network SHOULD support other location options or HELD. The access network SHOULD support other location
technologies that are specific to the type of access network. technologies that are specific to the type of access network.
AN-13/INT-14 Where a router is employed between a LAN and WAN in a AN-13/INT-14 Where a router is employed between a LAN and WAN in a
small (less than approximately 650 square meters) area, the router small (less than approximately 650 square meters) area, the router
MUST be transparent to the location provided by the WAN to the LAN. MUST be transparent to the location provided by the WAN to the LAN.
skipping to change at page 15, line 19 skipping to change at page 15, line 19
would be the mapping obtained previously for the default location would be the mapping obtained previously for the default location
appropriate for the caller. appropriate for the caller.
ED-57/SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route ED-57/SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route
an emergency call towards the PSAP's URI. an emergency call towards the PSAP's URI.
ED-58 Initial INVITES MUST provide an Offer [RFC3264]. ED-58 Initial INVITES MUST provide an Offer [RFC3264].
9. Signaling of emergency calls 9. Signaling of emergency calls
ED-59 Best Current Practice for SIP user agents [RFC4504] including ED-59 deleted
handling of audio, video and real-time text [RFC4103] SHOULD be
applied. This memo can be considered as an addition to [RFC4504] for
endpoints.
9.1. Use of TLS 9.1. Use of TLS
ED-60/SP-31 TLS MUST be specified when attempting to signal an ED-60/SP-31 TLS MUST be specified when attempting to signal an
emergency call with SIP per [I-D.ietf-sip-sips]. IPSEC [RFC3986] is emergency call with SIP per Section 3.1 of [I-D.ietf-sip-sips].
an acceptable alternative. IPSEC [RFC3986] is an acceptable alternative.
ED-61/SP-32 If TLS session establishment fails, the call MUST be ED-61/SP-32 If TLS session establishment fails, the call MUST be
retried without TLS. retried without TLS.
ED-62/SP-33 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain ED-62/SP-33 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain
persistent TLS connections between elements. persistent TLS connections between elements.
ED-63/AN-28 TLS MUST be specified when attempting to retrieve ED-63/AN-28 TLS MUST be specified when attempting to retrieve
location (configuration or dereferencing) with HELD. The use of location (configuration or dereferencing) with HELD. The use of
[RFC5077] is RECOMMENDED to minimize the time to establish TLS [RFC5077] is RECOMMENDED to minimize the time to establish TLS
skipping to change at page 16, line 36 skipping to change at page 16, line 33
location available, it MUST include location either by-value, location available, it MUST include location either by-value,
by-reference or both. by-reference or both.
10. If a device understands the SIP Location Conveyance extension 10. If a device understands the SIP Location Conveyance extension
and has its location unavailable or unknown to that device, it and has its location unavailable or unknown to that device, it
MUST include a Supported header with a "geolocation" option tag, MUST include a Supported header with a "geolocation" option tag,
and MUST NOT include a Geolocation header, and not include a and MUST NOT include a Geolocation header, and not include a
PIDF-LO message body. PIDF-LO message body.
11. If a device understands the SIP Location Conveyance extension 11. If a device understands the SIP Location Conveyance extension
and supports LoST [RFC5222], the Geolocation "used-for-routing" and supports LoST [RFC5222], the Geolocation "used-for-routing"
header parameter MUST be added to the corresponding URI in the header parameter MUST be added to the corresponding URI in the
Geolocation header. Geolocation header. If the device is unable to obtain a PSAP
12. A normal SDP offer SHOULD be included in the INVITE. If voice URI for any reason it MUST NOT include "used-for-routing" on a
is supported the offer MUST include the G.711 codec, see Geolocation URI, so that downstream entities know that LoST
routing has not been completed.
12. A SDP offer MUST be included in the INVITE. If voice is
supported the offer MUST include the G.711 codec, see
Section 14. Section 14.
13. If the device includes location-by-value, the UA MUST support 13. If the device includes location-by-value, the UA MUST support
multipart message bodies, since SDP will likely be also in the multipart message bodies, since SDP will likely be also in the
INVITE. INVITE.
14. A UAC SHOULD include a "inserted-by=endpoint" header parameter 14. A UAC SHOULD include a "inserted-by=endpoint" header parameter
on all Geolocation headers. This informs downstream elements on all Geolocation headers. This informs downstream elements
which device entered the location at this URI (either cid-URL or which device entered the location at this URI (either cid-URL or
location-by-reference URI). location-by-reference URI).
15. SIP Caller Preferences [RFC3841] MAY be used to signal how the 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the
PSAP should handle the call. For example, a language preference PSAP should handle the call. For example, a language preference
skipping to change at page 17, line 43 skipping to change at page 17, line 43
the signaling, obtained from a LIS, or default) MUST be used in a the signaling, obtained from a LIS, or default) MUST be used in a
query to LoST with the service URN received with the call. The query to LoST with the service URN received with the call. The
resulting URI MUST be placed in a Route header added to the call. resulting URI MUST be placed in a Route header added to the call.
3. The "inserted-by=" parameter in any Geolocation: header received 3. The "inserted-by=" parameter in any Geolocation: header received
on the call MUST NOT be modified or deleted in transit. on the call MUST NOT be modified or deleted in transit.
4. The proxy SHOULD NOT modify any parameters in Geolocation headers 4. The proxy SHOULD NOT modify any parameters in Geolocation headers
received in the call. It MAY add a Geolocation header. Such an received in the call. It MAY add a Geolocation header. Such an
additional location SHOULD NOT be used for routing; the location additional location SHOULD NOT be used for routing; the location
provided by the UA should be used. provided by the UA should be used.
5. Either a P-Asserted-Identity [RFC3325] or an Identity header 5. Either a P-Asserted-Identity [RFC3325] or an Identity header
[RFC4474], or both, MUST be included to identify the sender. [RFC4474], or both, SHOULD be included to identify the sender.
For services which must support emergency calls from
unauthenticated devices, valid identity may not be available.
10. Call backs 10. Call backs
ED-66/SP-35 Devices device MUST have a globally routable URI in a ED-66/SP-35 Devices device SHOULD have a globally routable URI in a
Contact: header which remains valid for 30 minutes past the time the Contact: header which remains valid for 30 minutes past the time the
original call containing the URI completes. original call containing the URI completes unless the device
registration expires and is not renewed.
SP-36 Call backs to the Contact: header URI recieved within 30 SP-36 Call backs to the Contact: header URI recieved within 30
minutes of an emergency call must reach the device regardless of call minutes of an emergency call must reach the device regardless of call
features or services that would normally cause the call to be routed features or services that would normally cause the call to be routed
to some other entity. to some other entity.
SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted- SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted-
Identity: header or From: protected by an Identity header suitable Identity: header or From: protected by an Identity header suitable
for returning a call some time after the original call. Such a call for returning a call some time after the original call. Such a call
back would not necessarily reach the device that originally placed back would not necessarily reach the device that originally placed
skipping to change at page 18, line 44 skipping to change at page 18, line 46
reliable, and could be spoofed. Dropping an active call by a new reliable, and could be spoofed. Dropping an active call by a new
call with a spoofed From: would be a DoS attack. call with a spoofed From: would be a DoS attack.
13. Disabling of features 13. Disabling of features
ED-70/SP-39 User Agents and proxies MUST disable outgoing call ED-70/SP-39 User Agents and proxies MUST disable outgoing call
features such as features such as
o Call Waiting o Call Waiting
o Call Transfer o Call Transfer
o Three Way Call o Three Way Call
o Flash hold o Hold, including Flash hold
o Outbound Call Blocking o Outbound Call Blocking
when an emergency call is established. Also see ED-77 in Section 14. when an emergency call is established. Also see ED-77 in Section 14.
ED-71/SP-40 The emergency dial strings SHOULD NOT be permitted in ED-71/SP-40 The emergency dial strings SHOULD NOT be permitted in
Call Forward numbers or speed dial lists. Call Forward numbers or speed dial lists.
ED-72/SP-41 The User Agent and Proxies SHOULD disable the following ED-72/SP-41 The User Agent and Proxies SHOULD disable the following
incoming call features on call backs from the PSAP: incoming call features on call backs from the PSAP:
o Call Waiting o Call Waiting
o Do Not Disturb o Do Not Disturb
skipping to change at page 20, line 4 skipping to change at page 20, line 12
ED-80 Endpoints supporting video MUST support H.264 per [RFC3984]. ED-80 Endpoints supporting video MUST support H.264 per [RFC3984].
15. Testing 15. Testing
ED-81 INVITE requests to a service URN ending in ".test" indicates a ED-81 INVITE requests to a service URN ending in ".test" indicates a
request for an automated test. For example, request for an automated test. For example,
"urn:service.sos.fire.test". As in standard SIP, a 200 (OK) response "urn:service.sos.fire.test". As in standard SIP, a 200 (OK) response
indicates that the address was recognized and a 404 (Not found) that indicates that the address was recognized and a 404 (Not found) that
it was not. A 486 (Busy Here) MUST be returned if the test service it was not. A 486 (Busy Here) MUST be returned if the test service
is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP is busy, and a 404 (Not found) MUST be returned if the PSAP does not
does not support the test mechanism. support the test mechanism.
ED-82 In its response to the test, the PSAP MAY include a text body ED-82 In its response to the test, the PSAP MAY include a text body
(text/plain) indicating the identity of the PSAP, the requested (text/plain) indicating the identity of the PSAP, the requested
service, and the location reported with the call. For the latter, service, and the location reported with the call. For the latter,
the PSAP SHOULD return location-by-value even if the original the PSAP SHOULD return location-by-value even if the original
location delivered with the test was by-reference. If the location- location delivered with the test was by-reference. If the location-
by-reference was supplied, and the dereference requires credentials, by-reference was supplied, and the dereference requires credentials,
the PSAP SHOULD use credentials supplied by the LIS for test the PSAP SHOULD use credentials supplied by the LIS for test
purposes. This alerts the LIS that the dereference is not for an purposes. This alerts the LIS that the dereference is not for an
actual emergency call and location hiding techniques, if they are actual emergency call and location hiding techniques, if they are
being used, may be employed for this dereference. The response MAY being used, may be employed for this dereference. The test response
include the connected identity of the PSAP per [RFC4916]. SHOULD be protected with TLS. If the body cannot be protected, the
location SHOULD NOT be included in the response..
ED-83 A PSAP accepting a test call SHOULD accept a media loopback ED-83 A PSAP accepting a test call SHOULD accept a media loopback
test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-
pkt-loopback" and "rtp-start-loopback" options. The user agent would pkt-loopback" and "rtp-start-loopback" options. The user agent would
specify a loopback attribute of "loopback-source", the PSAP being the specify a loopback attribute of "loopback-source", the PSAP being the
mirror. User Agents should expect the PSAP to loop back no more than mirror. User Agents should expect the PSAP to loop back no more than
3 packets of each media type accepted (which limits the duration of 3 packets of each media type accepted (which limits the duration of
the test), after which the PSAP would normally send BYE. the test), after which the PSAP would normally send BYE.
ED-84 User agents SHOULD perform a full call test, including media ED-84 User agents SHOULD perform a full call test, including media
skipping to change at page 21, line 19 skipping to change at page 21, line 28
Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom, Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom,
Barbara Stark, Richard Barnes and Peter Blatherwick. Barbara Stark, Richard Barnes and Peter Blatherwick.
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-11 (work in draft-ietf-geopriv-http-location-delivery-13 (work in
progress), December 2008. progress), February 2009.
[I-D.ietf-geopriv-lis-discovery] [I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-05 (work in progress), draft-ietf-geopriv-lis-discovery-07 (work in progress),
December 2008. February 2009.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
(work in progress), November 2008. (work in progress), November 2008.
[I-D.ietf-mmusic-media-loopback] [I-D.ietf-mmusic-media-loopback]
Hedayat, K., "An Extension to the Session Description Hedayat, K., "An Extension to the Session Description
Protocol (SDP) for Media Loopback", Protocol (SDP) for Media Loopback",
skipping to change at page 22, line 11 skipping to change at page 22, line 21
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-12 (work in progress), draft-ietf-sip-location-conveyance-12 (work in progress),
November 2008. November 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-16 (work in progress), draft-ietf-sip-outbound-16 (work in progress),
October 2008. October 2008.
[I-D.ietf-sip-sips]
Audet, F., "The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", draft-ietf-sip-sips-09 (work
in progress), November 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 [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.
skipping to change at page 23, line 52 skipping to change at page 24, line 10
Format", RFC 4119, December 2005. Format", RFC 4119, 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.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006. Configuration Information", RFC 4776, November 2006.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007.
[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.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031, Emergency and Other Well-Known Services", RFC 5031,
January 2008. January 2008.
skipping to change at page 24, line 35 skipping to change at page 24, line 39
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
Location-to-Service Translation (LoST) Servers Using the Location-to-Service Translation (LoST) Servers Using the
Dynamic Host Configuration Protocol (DHCP)", RFC 5223, Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
August 2008. August 2008.
19.2. Informative References 19.2. Informative References
[I-D.barnes-geopriv-lo-sec] [I-D.barnes-geopriv-lo-sec]
Barnes, R., Lepinski, M., Tschofenig, H., and H. Barnes, R., Lepinski, M., Tschofenig, H., and H.
Schulzrinne, "Additional Location Privacy Considerations", Schulzrinne, "Additional Location Privacy Considerations",
draft-barnes-geopriv-lo-sec-03 (work in progress), draft-barnes-geopriv-lo-sec-04 (work in progress),
July 2008. January 2009.
[I-D.ietf-ecrit-framework] [I-D.ietf-ecrit-framework]
Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling using Internet "Framework for Emergency Calling using Internet
Multimedia", draft-ietf-ecrit-framework-06 (work in Multimedia", draft-ietf-ecrit-framework-07 (work in
progress), July 2008. progress), January 2009.
[I-D.ietf-sip-sips]
Audet, F., "The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", draft-ietf-sip-sips-09 (work
in progress), November 2008.
[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.
[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony
Device Requirements and Configuration", RFC 4504,
May 2006.
[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.
[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, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
skipping to change at page 25, line 45 skipping to change at page 25, line 50
ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If ED-3 Endpoints SHOULD recognize dial strings of emergency calls. If
the service provider always knows the location of the device, then the service provider always knows the location of the device, then
the service provider could recognize them. the service provider could recognize them.
ED-4 Emergency calls MUST be marked with a Service URN in the ED-4 Emergency calls MUST be marked with a Service URN in the
Request-URI of the INVITE. Request-URI of the INVITE.
ED-5 Local dial strings MUST be recognized. ED-5 Local dial strings MUST be recognized.
ED-6 Devices MUST be able to be configured with the home country from
which the home dial string(s) can be determined.
ED-7 Emergency dial strings SHOULD be determined from LoST [RFC5222]. ED-7 Emergency dial strings SHOULD be determined from LoST [RFC5222].
Dial Strings MAY be configured directly in the device. Dial Strings MAY be configured directly in the device.
ED-8 Endpoints which do not recognize emergency dial strings SHOULD ED-8 Endpoints which do not recognize emergency dial strings SHOULD
send dial strings as per [RFC4967]. send dial strings as per [RFC4967].
ED-9 Endpoints SHOULD be able to have home dial strings provisioned ED-9 Endpoints SHOULD be able to have home dial strings provisioned
by configuration. by configuration.
ED-10 Devices SHOULD NOT have one button emergency calling ED-10 Devices SHOULD NOT have one button emergency calling
skipping to change at page 26, line 37 skipping to change at page 26, line 39
ED-16 Devices MAY support end-system measured location. Uncertainty ED-16 Devices MAY support end-system measured location. Uncertainty
of less than 100 m with 95% confidence SHOULD be available for of less than 100 m with 95% confidence SHOULD be available for
dispatch. dispatch.
ED-17 Devices that support endpoint measuring of location MUST have ED-17 Devices that support endpoint measuring of location MUST have
at least a coarse location capability (typically <1km accuracy when at least a coarse location capability (typically <1km accuracy when
not location hiding) for routing of calls. The location mechanism not location hiding) for routing of calls. The location mechanism
MAY be a service provided by the access network. MAY be a service provided by the access network.
ED-18 Endpoints SHOULD attempt to configure their own location. ED-18 Endpoints SHOULD attempt to configure their own location using
the LCPs listed in ED-21.
ED-19 Where proxies provide location on behalf of endpoints, the ED-19 Where proxies provide location on behalf of endpoints, the
service provider MUST ensure that either the end device is provided service provider MUST ensure that either the end device is provided
with the local dial strings for its current location (where the end with the local dial strings for its current location (where the end
device recognizes dial strings), or the service provider proxy MUST device recognizes dial strings), or the service provider proxy MUST
detect the appropriate local dial strings at the time of the call. detect the appropriate local dial strings at the time of the call.
ED-20 Devices SHOULD be able to accept and forward location by value ED-20 Devices SHOULD be able to accept and forward location by value
or by reference. An end device that receives location by reference or by reference. An end device that receives location by reference
(and does not also get the corresponding value) MUST be able to (and does not also get the corresponding value) MUST be able to
perform a dereference operation to obtain a value. perform a dereference operation to obtain a value.
ED-21 Devices MUST support both the DHCP location options [RFC4776], ED-21 Devices MUST support both the DHCP location options [RFC4776],
[RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. When [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. When
devices deploy a specific access network interface in which that devices deploy a specific access network interface in which that
access network supports location discovery such as LLDP-MED or access network supports location discovery such as LLDP-MED or
802.11, the device SHOULD support the additional respective access 802.11v, the device SHOULD support the additional respective access
network specific location discovery mechanism. network specific location discovery mechanism.
ED-22 Endpoints SHOULD try all LCPs supported by the device in any ED-22 Endpoints SHOULD try all LCPs supported by the device in any
order or in parallel. The first one that succeeds in supplying order or in parallel. The first one that succeeds in supplying
location can be used. location can be used.
ED-23 When HELD is the LCP, the request MUST specify a value of ED-23 When HELD is the LCP, the request MUST specify a value of
"emergencyRouting" for the "responseTime" parameter and use the "emergencyRouting" for the "responseTime" parameter and use the
resulting location for routing. If a value for dispatch location resulting location for routing. If a value for dispatch location
will be sent, another request with the "responseTime" parameter set will be sent, another request with the "responseTime" parameter set
skipping to change at page 30, line 39 skipping to change at page 30, line 41
time of an emergency call. If it cannot obtain a new mapping time of an emergency call. If it cannot obtain a new mapping
quickly, it MUST use the cached value. If the device cannot update quickly, it MUST use the cached value. If the device cannot update
the LoST mapping and does not have a cached value, it MUST signal an the LoST mapping and does not have a cached value, it MUST signal an
emergency call without a Route header containing a PSAP URI. emergency call without a Route header containing a PSAP URI.
ED-57 [RFC3261] and [RFC3263] procedures MUST be used to route an ED-57 [RFC3261] and [RFC3263] procedures MUST be used to route an
emergency call towards the PSAP's URI. emergency call towards the PSAP's URI.
ED-58 Initial INVITES MUST provide an Offer [RFC3264]. ED-58 Initial INVITES MUST provide an Offer [RFC3264].
ED-59 Best Current Practice for SIP user agents [RFC4504] including ED-59 deleted
handling of audio, video and real-time text [RFC4103] SHOULD be
applied. This memo can be considered as an addition to [RFC4504] for
endpoints.
ED-60 TLS MUST be specified when attempting to signal an emergency ED-60 TLS MUST be specified when attempting to signal an emergency
call with SIP per [I-D.ietf-sip-sips]. IPSEC [RFC3986] is an call with SIP per Section 3.1 of [I-D.ietf-sip-sips]. IPSEC
acceptable alternative. [RFC3986] is an acceptable alternative.
ED-61 If TLS session establishment fails, the call MUST be retried ED-61 If TLS session establishment fails, the call MUST be retried
without TLS. without TLS.
ED-62 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent ED-62 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent
TLS connections between elements. TLS connections between elements.
ED-63 TLS MUST be specified when attempting to retrieve location ED-63 TLS MUST be specified when attempting to retrieve location
(configuration or dereferencing) with HELD. The use of [RFC5077] is (configuration or dereferencing) with HELD. The use of [RFC5077] is
RECOMMENDED to minimize the time to establish TLS sessions without RECOMMENDED to minimize the time to establish TLS sessions without
skipping to change at page 31, line 48 skipping to change at page 31, line 48
location available, it MUST include location either by-value, location available, it MUST include location either by-value,
by-reference or both. by-reference or both.
10. If a device understands the SIP Location Conveyance extension 10. If a device understands the SIP Location Conveyance extension
and has its location unavailable or unknown to that device, it and has its location unavailable or unknown to that device, it
MUST include a Supported header with a "geolocation" option tag, MUST include a Supported header with a "geolocation" option tag,
and MUST NOT include a Geolocation header, and not include a and MUST NOT include a Geolocation header, and not include a
PIDF-LO message body. PIDF-LO message body.
11. If a device understands the SIP Location Conveyance extension 11. If a device understands the SIP Location Conveyance extension
and supports LoST [RFC5222], the Geolocation "used-for-routing" and supports LoST [RFC5222], the Geolocation "used-for-routing"
header parameter MUST be added to the corresponding URI in the header parameter MUST be added to the corresponding URI in the
Geolocation header. Geolocation header. If the device is unable to obtain a PSAP
12. A normal SDP offer SHOULD be included in the INVITE. If voice URI for any reason it MUST NOT include "used-for-routing" on a
is supported the offer MUST include the G.711 codec, see Geolocation URI, so that downstream entities know that LoST
Section 14. routing has not been completed.
12. A SDP offer MUST be included in the INVITE. If voice is
supported the offer MUST include the G.711 codec, see
Section 14.
13. If the device includes location-by-value, the UA MUST support 13. If the device includes location-by-value, the UA MUST support
multipart message bodies, since SDP will likely be also in the multipart message bodies, since SDP will likely be also in the
INVITE. INVITE.
14. A UAC SHOULD include a "inserted-by=endpoint" header parameter 14. A UAC SHOULD include a "inserted-by=endpoint" header parameter
on all Geolocation headers. This informs downstream elements on all Geolocation headers. This informs downstream elements
which device entered the location at this URI (either cid-URL or which device entered the location at this URI (either cid-URL or
location-by-reference URI). location-by-reference URI).
15. SIP Caller Preferences [RFC3841] MAY be used to signal how the 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the
PSAP should handle the call. For example, a language preference PSAP should handle the call. For example, a language preference
expressed in an Accept-Language header may be used as a hint to 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 cause the PSAP to route the call to a call taker who speaks the
requested language. SIP Caller Preferences may also be used to requested language. SIP Caller Preferences may also be used to
indicate a need to invoke a relay service for communication with indicate a need to invoke a relay service for communication with
people with disabilities in the call. people with disabilities in the call.
ED-66/ Devices device MUST have a globally routable URI in a Contact: ED-66 Devices device SHOULD have a globally routable URI in a
header which remains valid for 30 minutes past the time the original Contact: header which remains valid for 30 minutes past the time the
call containing the URI completes. original call containing the URI completes unless the device
registration expires and is not renewed.
ED-67 During the course of an emergency call, devices and proxies ED-67 During the course of an emergency call, devices and proxies
MUST support REFER transactions and the Referred-by: header MUST support REFER transactions and the Referred-by: header
[RFC3515]. [RFC3515].
ED-68 deleted ED-68 deleted
ED-69 There can be a case where the session signaling path is lost, ED-69 There can be a case where the session signaling path is lost,
and the user agent does not receive the BYE. If the call is hung up, and the user agent does not receive the BYE. If the call is hung up,
and the session timer (if implemented) expires, the call MAY be and the session timer (if implemented) expires, the call MAY be
skipping to change at page 33, line 47 skipping to change at page 34, line 4
expectations for emergency service support for the real-time text expectations for emergency service support for the real-time text
medium, described in [RFC5194], Section 7.1 SHOULD be fulfilled. medium, described in [RFC5194], Section 7.1 SHOULD be fulfilled.
ED-80 Endpoints supporting video MUST support H.264 per [RFC3984]. ED-80 Endpoints supporting video MUST support H.264 per [RFC3984].
ED-81 INVITE requests to a service URN ending in ".test" indicates a ED-81 INVITE requests to a service URN ending in ".test" indicates a
request for an automated test. For example, request for an automated test. For example,
"urn:service.sos.fire.test". As in standard SIP, a 200 (OK) response "urn:service.sos.fire.test". As in standard SIP, a 200 (OK) response
indicates that the address was recognized and a 404 (Not found) that indicates that the address was recognized and a 404 (Not found) that
it was not. A 486 (Busy Here) MUST be returned if the test service it was not. A 486 (Busy Here) MUST be returned if the test service
is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP is busy, and a 404 (Not Found) MUST be returned if the PSAP does not
does not support the test mechanism. support the test mechanism.
ED-82 In its response to the test, the PSAP MAY include a text body ED-82 In its response to the test, the PSAP MAY include a text body
(text/plain) indicating the identity of the PSAP, the requested (text/plain) indicating the identity of the PSAP, the requested
service, and the location reported with the call. For the latter, service, and the location reported with the call. For the latter,
the PSAP SHOULD return location-by-value even if the original the PSAP SHOULD return location-by-value even if the original
location delivered with the test was by-reference. If the location- location delivered with the test was by-reference. If the location-
by-reference was supplied, and the dereference requires credentials, by-reference was supplied, and the dereference requires credentials,
the PSAP SHOULD use credentials supplied by the LIS for test the PSAP SHOULD use credentials supplied by the LIS for test
purposes. This alerts the LIS that the dereference is not for an purposes. This alerts the LIS that the dereference is not for an
actual emergency call and location hiding techniques, if they are actual emergency call and location hiding techniques, if they are
being used, may be employed for this dereference. The response MAY being used, may be employed for this dereference. The test response
include the connected identity of the PSAP per [RFC4916]. SHOULD be protected with TLS. If the body cannot be protected, the
location SHOULD NOT be included in the response.
ED-83 A PSAP accepting a test call SHOULD accept a media loopback ED-83 A PSAP accepting a test call SHOULD accept a media loopback
test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp- test [I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-
pkt-loopback" and "rtp-start-loopback" options. The user agent would pkt-loopback" and "rtp-start-loopback" options. The user agent would
specify a loopback attribute of "loopback-source", the PSAP being the specify a loopback attribute of "loopback-source", the PSAP being the
mirror. User Agents should expect the PSAP to loop back no more than mirror. User Agents should expect the PSAP to loop back no more than
3 packets of each media type accepted (which limits the duration of 3 packets of each media type accepted (which limits the duration of
the test), after which the PSAP would normally send BYE. the test), after which the PSAP would normally send BYE.
ED-84 User agents SHOULD perform a full call test, including media ED-84 User agents SHOULD perform a full call test, including media
skipping to change at page 35, line 5 skipping to change at page 35, line 11
SP-2 Proxy servers SHOULD recognize emergency dial strings if for SP-2 Proxy servers SHOULD recognize emergency dial strings if for
some reason the endpoint does not recognize them. This cannot be some reason the endpoint does not recognize them. This cannot be
relied upon by the device if the service provider cannot always relied upon by the device if the service provider cannot always
determine the location of the device. determine the location of the device.
SP-3 Emergency calls MUST be marked with a Service URN in the SP-3 Emergency calls MUST be marked with a Service URN in the
Request-URI of the INVITE. Request-URI of the INVITE.
SP-4 Local dial strings MUST be recognized. SP-4 Local dial strings MUST be recognized.
SP-5 Devices MUST be able to be configured with the home country from
which the home dial string(s) can be determined.
SP-6 Emergency dial strings SHOULD be determined from LoST [RFC5222]. SP-6 Emergency dial strings SHOULD be determined from LoST [RFC5222].
Dial Strings MAY be configured directly in the device. Dial Strings MAY be configured directly in the device.
SP-7 If a proxy server recognizes dial strings on behalf of its SP-7 If a proxy server recognizes dial strings on behalf of its
clients it MUST recognize emergency dial strings represented by clients it MUST recognize emergency dial strings represented by
[RFC4967] and SHOULD recognize emergency dial strings represented by [RFC4967] and SHOULD recognize emergency dial strings represented by
a tel URI [RFC3966]. a tel URI [RFC3966].
SP-8 Service providers MAY provide home dial strings by SP-8 Service providers MAY provide home dial strings by
configuration. configuration.
skipping to change at page 37, line 24 skipping to change at page 37, line 30
SP-29 A proxy server which attempts mapping and fails to get a SP-29 A proxy server which attempts mapping and fails to get a
mapping MUST provide a default mapping. A suitable default mapping mapping MUST provide a default mapping. A suitable default mapping
would be the mapping obtained previously for the default location would be the mapping obtained previously for the default location
appropriate for the caller. appropriate for the caller.
SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route an SP-30 [RFC3261] and [RFC3263] procedures MUST be used to route an
emergency call towards the PSAP's URI. emergency call towards the PSAP's URI.
SP-31 TLS MUST be specified when attempting to signal an emergency SP-31 TLS MUST be specified when attempting to signal an emergency
call with SIP per [I-D.ietf-sip-sips]. IPSEC [RFC3986] is an call with SIP per Section 3.1 of [I-D.ietf-sip-sips]. IPSEC
acceptable alternative. [RFC3986] is an acceptable alternative.
SP-32 If TLS session establishment fails, the call MUST be retried SP-32 If TLS session establishment fails, the call MUST be retried
without TLS. without TLS.
SP-33 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent SP-33 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent
TLS connections between elements. TLS connections between elements.
SP-34 SIP Proxy servers processing emergency calls: SP-34 SIP Proxy servers processing emergency calls:
1. If the proxy interprets dial plans on behalf of user agents, the 1. If the proxy interprets dial plans on behalf of user agents, the
proxy MUST look for the local emergency dial string at the proxy MUST look for the local emergency dial string at the
skipping to change at page 38, line 20 skipping to change at page 38, line 27
the signaling, obtained from a LIS, or default) MUST be used in a the signaling, obtained from a LIS, or default) MUST be used in a
query to LoST with the service URN received with the call. The query to LoST with the service URN received with the call. The
resulting URI MUST be placed in a Route header added to the call. resulting URI MUST be placed in a Route header added to the call.
3. The "inserted-by=" parameter in any Geolocation: header received 3. The "inserted-by=" parameter in any Geolocation: header received
on the call MUST NOT be modified or deleted in transit. on the call MUST NOT be modified or deleted in transit.
4. The proxy SHOULD NOT modify any parameters in Geolocation headers 4. The proxy SHOULD NOT modify any parameters in Geolocation headers
received in the call. It MAY add a Geolocation header. Such an received in the call. It MAY add a Geolocation header. Such an
additional location SHOULD NOT be used for routing; the location additional location SHOULD NOT be used for routing; the location
provided by the UA should be used. provided by the UA should be used.
5. Either a P-Asserted-Identity [RFC3325] or an Identity header 5. Either a P-Asserted-Identity [RFC3325] or an Identity header
[RFC4474], or both, MUST be included to identify the sender. [RFC4474], or both, SHOULD be included to identify the sender.
For services which must support emergency calls from
unauthenticated devices, valid identity may not be available.
SP-35 Devices device MUST have a globally routable URI in a Contact: SP-35 Devices device SHOULD have a globally routable URI in a
header which remains valid for 30 minutes past the time the original Contact: header which remains valid for 30 minutes past the time the
call containing the URI completes. original call containing the URI completes unless the device
registration expires and is not renewed.
SP-36 Call backs to the Contact: header URI recieved within 30 SP-36 Call backs to the Contact: header URI recieved within 30
minutes of an emergency call must reach the device regardless of call minutes of an emergency call must reach the device regardless of call
features or services that would normally cause the call to be routed features or services that would normally cause the call to be routed
to some other entity. to some other entity.
SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted- SP-37 Devices MUST have a persistent AOR URI either in a P-Asserted-
Identity: header or From: protected by an Identity header suitable Identity: header or From: protected by an Identity header suitable
for returning a call some time after the original call. Such a call for returning a call some time after the original call. Such a call
back would not necessarily reach the device that originally placed back would not necessarily reach the device that originally placed
skipping to change at page 42, line 47 skipping to change at page 43, line 10
INT-7 Devices MAY support end-system measured location. Uncertainty INT-7 Devices MAY support end-system measured location. Uncertainty
of less than 100 m with 95% confidence SHOULD be available for of less than 100 m with 95% confidence SHOULD be available for
dispatch. dispatch.
INT-8 Devices that support endpoint measuring of location MUST have INT-8 Devices that support endpoint measuring of location MUST have
at least a coarse location capability (typically <1km accuracy when at least a coarse location capability (typically <1km accuracy when
not location hiding) for routing of calls. The location mechanism not location hiding) for routing of calls. The location mechanism
MAY be a service provided by the access network. MAY be a service provided by the access network.
INT-9 Endpoints SHOULD attempt to configure their own location. INT-9 Endpoints SHOULD attempt to configure their own location using
the LCPs listed in ED-21.
INT-10 Where proxies provide location on behalf of endpoints, the INT-10 Where proxies provide location on behalf of endpoints, the
service provider MUST ensure that either the end device is provided service provider MUST ensure that either the end device is provided
with the local dial strings for its current location (where the end with the local dial strings for its current location (where the end
device recognizes dial strings), or the service provider proxy MUST device recognizes dial strings), or the service provider proxy MUST
detect the appropriate local dial strings at the time of the call. detect the appropriate local dial strings at the time of the call.
INT-11 Devices SHOULD be able to accept and forward location by value INT-11 Devices SHOULD be able to accept and forward location by value
or by reference. An end device that receives location by reference or by reference. An end device that receives location by reference
(and does not also get the corresponding value) MUST be able to (and does not also get the corresponding value) MUST be able to
perform a dereference operation to obtain a value. perform a dereference operation to obtain a value.
INT-12 Devices MUST support both the DHCP location options [RFC4776], INT-12 Devices MUST support both the DHCP location options [RFC4776],
[RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. When [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. When
devices deploy a specific access network interface in which that devices deploy a specific access network interface in which that
access network supports location discovery such as LLDP-MED or access network supports location discovery such as LLDP-MED or
802.11, the device SHOULD support the additional respective access 802.11v, the device SHOULD support the additional respective access
network specific location discovery mechanism. network specific location discovery mechanism.
INT-13 The access network MUST support either DHCP location options INT-13 The access network MUST support either DHCP location options
or HELD. The access network SHOULD support other location or HELD. The access network SHOULD support other location
technologies that are specific to the type of access network. technologies that are specific to the type of access network.
INT-14 Where a router is employed between a LAN and WAN in a small INT-14 Where a router is employed between a LAN and WAN in a small
(less than approximately 650 square meters) area, the router MUST be (less than approximately 650 square meters) area, the router MUST be
transparent to the location provided by the WAN to the LAN. This may transparent to the location provided by the WAN to the LAN. This may
mean the router must obtain location as a client from the WAN, and mean the router must obtain location as a client from the WAN, and
 End of changes. 44 change blocks. 
95 lines changed or deleted 90 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/