< draft-ietf-ecrit-phonebcp-13.txt   draft-ietf-ecrit-phonebcp-14.txt >
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: BCP J. Polk Intended status: BCP J. Polk
Expires: January 30, 2010 Cisco Systems Expires: July 23, 2010 Cisco Systems
July 29, 2009 January 19, 2010
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-13 draft-ietf-ecrit-phonebcp-14
Abstract
The IETF and other standards organization have efforts targeted at
standardizing various aspects of placing emergency calls on IP
networks. This memo describes best current practice on how devices,
networks and services should use such standards to make emergency
calls.
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 42
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 January 30, 2010. This Internet-Draft will expire on July 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The IETF and other standards organization have efforts targeted at described in the BSD License.
standardizing various aspects of placing emergency calls on IP
networks. This memo describes best current practice on how devices,
networks and services should use such standards to make emergency
calls.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of how emergency calls are placed . . . . . . . . . . 4 3. Overview of how emergency calls are placed . . . . . . . . . . 4
4. Which devices and services should support emergency calls . . 5 4. Which devices and services should support emergency calls . . 5
5. Identifying an emergency call . . . . . . . . . . . . . . . . 5 5. Identifying an emergency call . . . . . . . . . . . . . . . . 5
6. Location and its role in an emergency call . . . . . . . . . . 6 6. Location and its role in an emergency call . . . . . . . . . . 6
6.1. Types of location information . . . . . . . . . . . . . . 6 6.1. Types of location information . . . . . . . . . . . . . . 6
skipping to change at page 2, line 39 skipping to change at page 2, line 43
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 11 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 11
6.10. Location validation . . . . . . . . . . . . . . . . . . . 12 6.10. Location validation . . . . . . . . . . . . . . . . . . . 12
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 12 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 12
6.12. Other location considerations . . . . . . . . . . . . . . 13 6.12. Other location considerations . . . . . . . . . . . . . . 13
7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 13 7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
16. Security Considerations . . . . . . . . . . . . . . . . . . . 21 16. Security Considerations . . . . . . . . . . . . . . . . . . . 21
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 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
skipping to change at page 3, line 4 skipping to change at page 3, line 8
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
16. Security Considerations . . . . . . . . . . . . . . . . . . . 21 16. Security Considerations . . . . . . . . . . . . . . . . . . . 21
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . 35
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 . . . . . . . . . . . . . . . . . . . . . . . . 45 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].
skipping to change at page 9, line 45 skipping to change at page 9, line 45
ED-23/INT-17/SP-14 When HELD is the LCP, the request MUST specify a ED-23/INT-17/SP-14 When HELD is the LCP, the request MUST specify a
value of "emergencyRouting" for the "responseTime" parameter and use value of "emergencyRouting" for the "responseTime" parameter and use
the resulting location for routing. If a value for dispatch location the 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
to "emergencyDispatch" must be completed, with the result sent for to "emergencyDispatch" must be completed, with the result sent for
dispatch purposes. dispatch purposes.
ED-24 Where the operating system supporting application programs ED-24 Where the operating system supporting application programs
which need location for emergency calls does not allow access to which need location for emergency calls does not allow access to
Layer 2 and Layer 3 functions necessary for a client application to Layer 2 and Layer 3 functions necessary for a client application to
use DHCP location options and/or LLDP-MED, the operating system MUST use DHCP location options and/or other location technologies that are
specific to the type of access network, the operating system MUST
provide a published API conforming to ED-12 through ED-21 and ED-21 provide a published API conforming to ED-12 through ED-21 and ED-21
through ED-31. It is RECOMMENDED that all operating systems provide through ED-31. It is RECOMMENDED that all operating systems provide
such an API. such an API.
6.6. When location should be configured 6.6. When location should be configured
ED-25/INT-18 Endpoints SHOULD obtain location immediately after ED-25/INT-18 Endpoints SHOULD obtain location immediately after
obtaining local network configuration information. When HELD is the obtaining local network configuration information. When HELD is the
LCP the client MUST support a random back-off period (between 30 LCP the client MUST support a random back-off period (between 30
seconds and 300 seconds) for re-trying the HELD query, when no seconds and 300 seconds) for re-trying the HELD query, when no
skipping to change at page 15, line 13 skipping to change at page 15, line 13
available, a default location (see Section 6.11) MUST be supplied. available, a default location (see Section 6.11) MUST be supplied.
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.
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 MAY provide an Offer [RFC3264].
9. Signaling of emergency calls 9. Signaling of emergency calls
ED-59 deleted ED-59 deleted
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. IPSEC [RFC3986] is an acceptable alternative. emergency call. IPSEC [RFC3986] is an acceptable alternative.
ED-61/SP-32 If TLS session establishment is not available, or fails, ED-61/SP-32 If TLS session establishment is not available, or fails,
the call MUST be retried without TLS. the call MUST be retried without TLS.
ED-62/SP-33 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain ED-62/SP-33 [RFC5626] is RECOMMENDED to maintain persistent TLS
persistent TLS connections between elements. 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
sessions without keeping server-side state. sessions without keeping server-side state.
ED-64/AN-29 If TLS session establishment fails, the location ED-64/AN-29 If TLS session establishment fails, the location
retrieval MUST be retried without TLS. retrieval MUST be retried without TLS.
9.2. SIP signaling requirements for User Agents 9.2. SIP signaling requirements for User Agents
skipping to change at page 16, line 10 skipping to change at page 16, line 10
dial string URI with the dialed digits. dial string URI with the dialed digits.
3. The From header MUST be present and SHOULD be the AoR of the 3. The From header MUST be present and SHOULD be the AoR of the
caller. caller.
4. A Via header MUST be present. 4. A Via header MUST be present.
5. A Route header SHOULD be present with a PSAP URI obtained from 5. A Route header SHOULD be present with a PSAP URI obtained from
LoST (see Section 8) and the loose route parameter. If the LoST (see Section 8) and the loose route parameter. If the
device does not interpret dial plans, or was unable to obtain a device does not interpret dial plans, or was unable to obtain a
route from a LoST server, no Route header will be present. route from a LoST server, no Route header will be present.
6. A Contact header MUST be present which MUST be globally 6. A Contact header MUST be present which MUST be globally
routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid routable, for example a GRUU [RFC5627], and be valid for several
for several minutes following the termination of the call, minutes following the termination of the call, provided that the
provided that the UAC remains registered with the same UAC remains registered with the same registrar, to permit an
registrar, to permit an immediate call-back to the specific immediate call-back to the specific device which placed the
device which placed the emergency call. It is acceptable if the emergency call. It is acceptable if the UAC inserts a locally
UAC inserts a locally routable URI and a subsequent B2BUA maps routable URI and a subsequent B2BUA maps that to a globally
that to a globally routable URI. routable URI.
7. Other headers MAY be included as per normal SIP behavior. 7. Other headers MAY be included as per normal SIP behavior.
8. A Supported header MUST be included with the 'geolocation' 8. A Supported header MUST be included with the 'geolocation'
option tag [I-D.ietf-sip-location-conveyance], unless the device option tag [I-D.ietf-sip-location-conveyance], unless the device
does not understand the concept of SIP location. does not understand the concept of SIP location.
9. If a device understands the SIP location conveyance 9. If a device understands the SIP location conveyance
[I-D.ietf-sip-location-conveyance] extension and has its [I-D.ietf-sip-location-conveyance] extension and has its
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. If the device is unable to obtain a PSAP Geolocation header. If the device is unable to obtain a PSAP
URI for any reason it MUST NOT include "used-for-routing" on a URI for any reason it MUST NOT include "used-for-routing" on a
Geolocation URI, so that downstream entities know that LoST Geolocation URI, so that downstream entities know that LoST
routing has not been completed. routing has not been completed.
12. A SDP offer MUST be included in the INVITE. If voice is 12. A SDP offer SHOULD be included in the INVITE. If voice is
supported the offer MUST include the G.711 codec, see supported the offer MUST include the G.711 codec, see
Section 14. Section 14. As PSAPs may support a wide range of media types
and codecs, sending an offerless INVITE may result in a lengthy
return offer, but is permitted. Cautions in [RFC3261] on
offerless INVITEs should be considered before such use.
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" header parameter with its 14. A UAC SHOULD include a "inserted-by" header parameter with its
own hostname on all Geolocation headers. This informs own hostname on all Geolocation headers. This informs
downstream elements which device entered the location at this downstream elements which device entered the location at this
URI (either cid-URL or location-by-reference URI). URI (either cid-URL or 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
skipping to change at page 21, line 8 skipping to change at page 21, line 12
a random amount of time (in perhaps a 30 minute period, sufficient a random amount of time (in perhaps a 30 minute period, sufficient
for any avalanche restart to complete) and then test. for any avalanche restart to complete) and then test.
ED-86 PSAPs MAY refuse repeated requests for test from the same ED-86 PSAPs MAY refuse repeated requests for test from the same
device in a short period of time. Any refusal is signaled with a 486 device in a short period of time. Any refusal is signaled with a 486
or 488 response. or 488 response.
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.ietf-geopriv-arch].
17. IANA Considerations 17. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
18. Acknowledgements 18. Acknowledgements
Work group members participating in the creation and review of this Work group members participating in the creation and review of this
document include include Hannes Tschofenig, Ted Hardie, Marc Linsner, document include include Hannes Tschofenig, Ted Hardie, Marc Linsner,
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-15 (work in draft-ietf-geopriv-http-location-delivery-16 (work in
progress), June 2009. progress), August 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-11 (work in progress), draft-ietf-geopriv-lis-discovery-13 (work in progress),
May 2009. December 2009.
[I-D.ietf-mmusic-media-loopback] [I-D.ietf-mmusic-media-loopback]
Venna, N., Jones, P., Roychowdhury, A., and K. Hedayat, Sivachelvan, C., Venna, N., Jones, P., Stratton, N.,
"An Extension to the Session Description Protocol (SDP) Roychowdhury, A., and K. Hedayat, "An Extension to the
for Media Loopback", draft-ietf-mmusic-media-loopback-10 Session Description Protocol (SDP) for Media Loopback",
(work in progress), February 2009. draft-ietf-mmusic-media-loopback-11 (work in progress),
October 2009.
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress),
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-13 (work in progress), draft-ietf-sip-location-conveyance-13 (work in progress),
March 2009. March 2009.
[I-D.ietf-sip-outbound]
Jennings, C., "Managing Client Initiated Connections in
the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-20 (work in progress), June 2009.
[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.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
skipping to change at page 24, line 31 skipping to change at page 24, line 27
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
19.2. Informative References [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
[I-D.barnes-geopriv-lo-sec] [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Agent URIs (GRUUs) in the Session Initiation Protocol
Tschofenig, H., and H. Schulzrinne, "An Architecture for (SIP)", RFC 5627, October 2009.
Location and Location Privacy in Internet Applications",
draft-barnes-geopriv-lo-sec-05 (work in progress), 19.2. Informative References
March 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-09 (work in Multimedia", draft-ietf-ecrit-framework-10 (work in
progress), March 2009. progress), July 2009.
[I-D.ietf-geopriv-arch]
Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-01 (work in progress),
October 2009.
[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.
[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.
skipping to change at page 27, line 22 skipping to change at page 27, line 26
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
to "emergencyDispatch" must be completed, with the result sent for to "emergencyDispatch" must be completed, with the result sent for
dispatch purposes. dispatch purposes.
ED-24 Where the operating system supporting application programs ED-24 Where the operating system supporting application programs
which need location for emergency calls does not allow access to which need location for emergency calls does not allow access to
Layer 2 and Layer 3 functions necessary for a client application to Layer 2 and Layer 3 functions necessary for a client application to
use DHCP location options and/or LLDP-MED, the operating system MUST use DHCP location options and/or other location technologies that are
specific to the type of access network, the operating system MUST
provide a published API conforming to ED-12 through ED-21 and ED-21 provide a published API conforming to ED-12 through ED-21 and ED-21
through ED-31. It is RECOMMENDED that all operating systems provide through ED-31. It is RECOMMENDED that all operating systems provide
such an API. such an API.
ED-25 Endpoints SHOULD obtain location immediately after obtaining ED-25 Endpoints SHOULD obtain location immediately after obtaining
local network configuration information. When HELD is the LCP the local network configuration information. When HELD is the LCP the
client MUST support a random back-off period (between 30 seconds and client MUST support a random back-off period (between 30 seconds and
300 seconds) for re-trying the HELD query, when no response is 300 seconds) for re-trying the HELD query, when no response is
received, and no other LCP provided location information. received, and no other LCP provided location information.
skipping to change at page 30, line 34 skipping to change at page 30, line 38
ED-56 The endpoint SHOULD attempt to update the LoST mapping at the ED-56 The endpoint SHOULD attempt to update the LoST mapping at the
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 MAY provide an Offer [RFC3264].
ED-59 deleted ED-59 deleted
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. IPSEC [RFC3986] is an acceptable alternative. call with SIP. IPSEC [RFC3986] is an acceptable alternative.
ED-61 If TLS session establishment is not available, or fails, the ED-61 If TLS session establishment is not available, or fails, the
call MUST be retried without TLS. call MUST be retried without TLS.
ED-62 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent ED-62 [RFC5626] is RECOMMENDED to maintain persistent TLS connections
TLS connections between elements. 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
keeping server-side state. keeping server-side state.
ED-64 If TLS session establishment fails, the location retrieval MUST ED-64 If TLS session establishment fails, the location retrieval MUST
be retried without TLS. be retried without TLS.
ED-65 The initial SIP signaling method is an INVITE request: ED-65 The initial SIP signaling method is an INVITE request:
skipping to change at page 31, line 23 skipping to change at page 31, line 26
device cannot interpret local dial strings, the To: SHOULD be a device cannot interpret local dial strings, the To: SHOULD be a
dial string URI with the dialed digits. dial string URI with the dialed digits.
3. The From header MUST be present and SHOULD be the AoR of the 3. The From header MUST be present and SHOULD be the AoR of the
caller. caller.
4. A Via header MUST be present. 4. A Via header MUST be present.
5. A Route header SHOULD be present with a PSAP URI obtained from 5. A Route header SHOULD be present with a PSAP URI obtained from
LoST (see Section 8) and the loose route parameter. If the LoST (see Section 8) and the loose route parameter. If the
device does not interpret dial plans, or was unable to obtain a device does not interpret dial plans, or was unable to obtain a
route from a LoST server, no Route header will be present. route from a LoST server, no Route header will be present.
6. A Contact header MUST be present which MUST be globally 6. A Contact header MUST be present which MUST be globally
routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid routable, for example a GRUU [RFC5627], and be valid for several
for several minutes following the termination of the call, minutes following the termination of the call, provided that the
provided that the UAC remains registered with the same UAC remains registered with the same registrar, to permit an
registrar, to permit an immediate call-back to the specific immediate call-back to the specific device which placed the
device which placed the emergency call. It is acceptable if the emergency call. It is acceptable if the UAC inserts a locally
UAC inserts a locally routable URI and a subsequent B2BUA maps routable URI and a subsequent B2BUA maps that to a globally
that to a globally routable URI. routable URI.
7. Other headers MAY be included as per normal SIP behavior. 7. Other headers MAY be included as per normal SIP behavior.
8. A Supported header MUST be included with the 'geolocation' 8. A Supported header MUST be included with the 'geolocation'
option tag [I-D.ietf-sip-location-conveyance], unless the device option tag [I-D.ietf-sip-location-conveyance], unless the device
does not understand the concept of SIP location. does not understand the concept of SIP location.
9. If a device understands the SIP location conveyance 9. If a device understands the SIP location conveyance
[I-D.ietf-sip-location-conveyance] extension and has its [I-D.ietf-sip-location-conveyance] extension and has its
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. If the device is unable to obtain a PSAP Geolocation header. If the device is unable to obtain a PSAP
URI for any reason it MUST NOT include "used-for-routing" on a URI for any reason it MUST NOT include "used-for-routing" on a
Geolocation URI, so that downstream entities know that LoST Geolocation URI, so that downstream entities know that LoST
routing has not been completed. routing has not been completed.
12. A SDP offer MUST be included in the INVITE. If voice is 12. A SDP offer SHOULD be included in the INVITE. If voice is
supported the offer MUST include the G.711 codec, see supported the offer MUST include the G.711 codec, see
Section 14. Section 14. As PSAPs may support a wide range of media types
and codecs, sending an offerless INVITE may result in a lengthy
return offer, but is permitted. Cautions in [RFC3261] on
offerless INVITEs should be considered before such use.
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" header parameter with its 14. A UAC SHOULD include a "inserted-by" header parameter with its
own hostname on all Geolocation headers. This informs own hostname on all Geolocation headers. This informs
downstream elements which device entered the location at this downstream elements which device entered the location at this
URI (either cid-URL or location-by-reference URI). URI (either cid-URL or 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
skipping to change at page 37, line 35 skipping to change at page 37, line 47
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. IPSEC [RFC3986] is an acceptable alternative. call with SIP. IPSEC [RFC3986] is an acceptable alternative.
SP-32 If TLS session establishment is not available, or fails, the SP-32 If TLS session establishment is not available, or fails, the
call MUST be retried without TLS. call MUST be retried without TLS.
SP-33 [I-D.ietf-sip-outbound] is RECOMMENDED to maintain persistent SP-33 [RFC5626] is RECOMMENDED to maintain persistent TLS connections
TLS connections between elements. 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
location of the end device and MAY look for the home dial string. location of the end device and MAY look for the home dial string.
If it finds it, the proxy MUST: If it finds it, the proxy MUST:
* Insert a Geolocation header as above. Location-by-reference * Insert a Geolocation header as above. Location-by-reference
MUST be used because proxies must not insert bodies. MUST be used because proxies must not insert bodies.
* Include the Geolocation "inserted-by" and "used-for-routing" * Include the Geolocation "inserted-by" and "used-for-routing"
parameters with its own hostname (which should match the Via parameters with its own hostname (which should match the Via
it inserts) on the inserted-by. it inserts) on the inserted-by.
* Map the location to a PSAP URI using LoST. * Map the location to a PSAP URI using LoST.
 End of changes. 30 change blocks. 
78 lines changed or deleted 87 lines changed or added

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