draft-ietf-ecrit-phonebcp-19.txt   draft-ietf-ecrit-phonebcp-20.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: BCP J. Polk Intended status: BCP J. Polk
Expires: March 6, 2012 Cisco Systems Expires: March 10, 2012 Cisco Systems
September 3, 2011 September 7, 2011
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-19 draft-ietf-ecrit-phonebcp-20.txt
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 using IETF protocols should use such standards networks and services using IETF protocols should use such standards
to make emergency calls. to make emergency calls.
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 6, 2012. This Internet-Draft will expire on March 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . 7
6.2. Location Determination . . . . . . . . . . . . . . . . . . 7 6.2. Location Determination . . . . . . . . . . . . . . . . . . 7
6.2.1. User-entered location information . . . . . . . . . . 7 6.2.1. User-entered location information . . . . . . . . . . 7
6.2.2. Access network "wire database" location information . 7 6.2.2. Access network "wire database" location information . 7
6.2.3. End-system measured location information . . . . . . . 8 6.2.3. End-system measured location information . . . . . . . 8
6.2.4. Network-measured location information . . . . . . . . 8 6.2.4. Network-measured location information . . . . . . . . 8
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 8 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 9
6.4. Location and references to location . . . . . . . . . . . 9 6.4. Location and references to location . . . . . . . . . . . 9
6.5. End system location configuration . . . . . . . . . . . . 9 6.5. End system location configuration . . . . . . . . . . . . 9
6.6. When location should be configured . . . . . . . . . . . . 10 6.6. When location should be configured . . . . . . . . . . . . 10
6.7. Conveying location . . . . . . . . . . . . . . . . . . . . 11 6.7. Conveying location . . . . . . . . . . . . . . . . . . . . 11
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 12
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 12 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 12
6.10. Location validation . . . . . . . . . . . . . . . . . . . 13 6.10. Location validation . . . . . . . . . . . . . . . . . . . 13
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 13 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 13
6.12. Other location considerations . . . . . . . . . . . . . . 13 6.12. Other location considerations . . . . . . . . . . . . . . 13
7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 14 7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . 16 9.2. SIP signaling requirements for User Agents . . . . . . . . 16
9.3. SIP signaling requirements for proxy servers . . . . . . . 16 9.3. SIP signaling requirements for proxy servers . . . . . . . 17
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 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
17.1. test service urn . . . . . . . . . . . . . . . . . . . . . 21 17.1. test service urn . . . . . . . . . . . . . . . . . . . . . 21
17.2. 'test' Subregistry . . . . . . . . . . . . . . . . . . . . 21 17.2. 'test' Subregistry . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 5, line 20 skipping to change at page 5, line 20
Server (LIS). The location is conveyed (Section 6.7) in the SIP Server (LIS). The location is conveyed (Section 6.7) in the SIP
signaling with the call. The call is routed (Section 8) based on signaling with the call. The call is routed (Section 8) based on
location using the Location-to-Service Translation (LoST) protocol location using the Location-to-Service Translation (LoST) protocol
[RFC5222], which maps a location to a set of PSAP URIs. Each URI [RFC5222], which maps a location to a set of PSAP URIs. Each URI
resolves to a PSAP or an Emergency Services Routing Proxy (ESRP), resolves to a PSAP or an Emergency Services Routing Proxy (ESRP),
which serves a group of PSAPs. The call arrives at the PSAP with the which serves a group of PSAPs. The call arrives at the PSAP with the
location included in the SIP INVITE request. location included in the SIP INVITE request.
4. Which devices and services should support emergency calls 4. Which devices and services should support emergency calls
ED-1 A device or application SHOULD support emergency calling if a ED-1 A device or application that implements SIP calling SHOULD
user could reasonably expect to be able to place a call for help with support emergency calling. Some jurisdictions have regulations
the device. Some jurisdictions have regulations governing this. governing which devices need to support emergency calling and
developers are encouraged to ensure that devices they develop meet
relevant regulatory requirements. Unfortunately, the natural
variation in those regulations also makes it impossible to accurately
describe the cases when developers do or do not have to support
emergency calling.
SP-1 If a device or application expects to be able to place a call SP-1 If a device or application expects to be able to place a call
for help, the service provider that supports it MUST facilitate for help, the service provider that supports it MUST facilitate
emergency calling. Some jurisdictions have regulations governing emergency calling. Some jurisdictions have regulations governing
this. this.
ED-2 Devices that create media sessions and exchange real-time audio, ED-2 Devices that create media sessions and exchange real-time audio,
video and/or text, have the capability to establish sessions to a video and/or text, have the capability to establish sessions to a
wide variety of addresses, and communicate over private IP networks wide variety of addresses, and communicate over private IP networks
or the Internet, SHOULD support emergency calls. Some jurisdictions or the Internet, SHOULD support emergency calls. Some jurisdictions
skipping to change at page 9, line 30 skipping to change at page 9, line 36
6.4. Location and references to location 6.4. Location and references to location
ED-20/INT-12 Devices SHOULD be able to accept and forward location by ED-20/INT-12 Devices SHOULD be able to accept and forward location by
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
Obtaining location from the access network may be preferable even if
the device can measure its own location, especially indoors where
most measurement mechanisms are not accurate enough. This sections
requirements do not apply to devices that can accurately measure
their own location.
ED-21/INT-13 Devices MUST support both the Dynamic Host Configuration ED-21/INT-13 Devices MUST support both the Dynamic Host Configuration
Protocol (DHCP) location options [RFC4776], [RFC6225] and HTTP Protocol (DHCP) location options [RFC4776], [RFC6225] and HTTP
Enabled Location Delivery (HELD) [RFC5985]. When devices deploy a Enabled Location Delivery (HELD) [RFC5985]. When devices deploy a
specific access network interface for which location configuration specific access network interface for which location configuration
mechanisms such as Link Layer Discovery Protocol - Media Endpoint mechanisms such as Link Layer Discovery Protocol - Media Endpoint
Discovery (LLDP-MED) [LLDP-MED] or 802.11v are specified, the device Discovery (LLDP-MED) [LLDP-MED] or 802.11v are specified, the device
SHOULD support the additional respective access network specific SHOULD support the additional respective access network specific
location configuration mechanism. location configuration mechanism.
AN-13/INT-14 The access network MUST support either DHCP location AN-13/INT-14 The access network MUST support either DHCP location
skipping to change at page 21, line 34 skipping to change at page 21, line 43
17.1. test service urn 17.1. test service urn
A new entry in the URN Service Label registry is added. The new A new entry in the URN Service Label registry is added. The new
service is "test", the reference is this document, and the service is "test", the reference is this document, and the
description is "self test". description is "self test".
17.2. 'test' Subregistry 17.2. 'test' Subregistry
A new Subregistry is created, the "'test' Sub-Service. The A new Subregistry is created, the "'test' Sub-Service. The
registration process is Expert Review per [RFC5226]. The expert registration process is Expert Review per [RFC5226]. The expert
review should consider The Reference is this document. The initial review should consider that the entries in this registry nominally
content of the subregistry is: track the entries in the sos sub registry, although it is not
required that every entry in sos have an entry in test, and it is
possible that entries in the test sub-registry not necessarily be in
the sos sub registry. For example, testing of non-emergency URNs may
be allowed. The Reference is this document. The initial content of
the subregistry is:
Service Reference Description Service Reference Description
-------------------------------------------------------------------- --------------------------------------------------------------------
test.sos [this document] test for sos test.sos [this document] test for sos
test.sos.ambulance [this document] test for sos.ambulance test.sos.ambulance [this document] test for sos.ambulance
test.sos.animal-control [this document] test for sos.animal-control test.sos.animal-control [this document] test for sos.animal-control
test.sos.fire [this document] test for sos.fire test.sos.fire [this document] test for sos.fire
test.sos.gas [this document] test for sos.gas test.sos.gas [this document] test for sos.gas
test.sos.marine [this document] test for sos.marine test.sos.marine [this document] test for sos.marine
test.sos.mountain [this document] test for sos.mountain test.sos.mountain [this document] test for sos.mountain
skipping to change at page 22, line 26 skipping to change at page 22, line 39
[I-D.ietf-mmusic-media-loopback] [I-D.ietf-mmusic-media-loopback]
Sivachelvan, C., Venna, N., Jones, P., Stratton, N., Sivachelvan, C., Venna, N., Jones, P., Stratton, N.,
Roychowdhury, A., and K. Hedayat, "An Extension to the Roychowdhury, A., and K. Hedayat, "An Extension to the
Session Description Protocol (SDP) for Media Loopback", Session Description Protocol (SDP) for Media Loopback",
draft-ietf-mmusic-media-loopback-15 (work in progress), draft-ietf-mmusic-media-loopback-15 (work in progress),
March 2011. March 2011.
[I-D.ietf-sipcore-location-conveyance] [I-D.ietf-sipcore-location-conveyance]
Polk, J., Rosen, B., and J. Peterson, "Location Conveyance Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", for the Session Initiation Protocol",
draft-ietf-sipcore-location-conveyance-08 (work in draft-ietf-sipcore-location-conveyance-09 (work in
progress), May 2011. progress), September 2011.
[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.
 End of changes. 11 change blocks. 
15 lines changed or deleted 31 lines changed or added

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