draft-ietf-ecrit-phonebcp-10.txt   draft-ietf-ecrit-phonebcp-11.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: BCP J. Polk Intended status: BCP J. Polk
Expires: December 6, 2009 Cisco Systems Expires: December 6, 2009 Cisco Systems
June 4, 2009 June 4, 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-10 draft-ietf-ecrit-phonebcp-11
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 2, line 21 skipping to change at page 2, line 21
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
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 . . . . . . . 7
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 . . . . . . . . . . . 8
6.4. Location and references to location . . . . . . . . . . . 9 6.4. Location and references to location . . . . . . . . . . . 8
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 in SIP . . . . . . . . . . . . . . . . 11 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 11
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . 35 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 4, line 33 skipping to change at page 4, line 33
"AN-", service providers (requirements prefaced by "SP-") and PSAPs "AN-", service providers (requirements prefaced by "SP-") and PSAPs
to achieve globally interoperable 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-".
This document focuses on the case in which all three steps in the
emergency calling process -- location configuration, call routing,
and call placement - can be and are performed by the calling
endpoint, with the endpoint's Access Service Provider supporting the
process by providing location information. Calls in this case may be
routed via an application-layer Communications Service Provider
(e.g., a Voice Service Provider), but need not be. The underlying
protocols can also be used to support other models in which parts of
the process are delegated to the Communications Service Provider.
This document does not address in detail either these models or
interoperability issues between them and the model described here.
3. Overview of how emergency calls are placed 3. Overview of how emergency calls are placed
An emergency call can be distinguished (Section 5) from any other An emergency call can be distinguished (Section 5) from any other
call by a unique Service URN [RFC5031], which is placed in the call call by a unique Service URN [RFC5031], which is placed in the call
set-up signaling when a home or visited emergency dial string is set-up signaling when a home or visited emergency dial string is
detected. Because emergency services are local to specific detected. Because emergency services are local to specific
geographic regions, a caller must obtain his location (Section 6) geographic regions, a caller must obtain his location (Section 6)
prior to making emergency calls. To get this location, either a form prior to making emergency calls. To get this location, either a form
of measuring (e.g., GPS) (Section 6.2.3) device location in the of measuring (e.g., GPS) (Section 6.2.3) device location in the
endpoint is deployed, or the endpoint is configured (Section 6.5) endpoint is deployed, or the endpoint is configured (Section 6.5)
 End of changes. 8 change blocks. 
19 lines changed or deleted 7 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/