draft-ietf-ecrit-framework-08.txt   draft-ietf-ecrit-framework-09.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Informational H. Schulzrinne Intended status: Informational H. Schulzrinne
Expires: August 31, 2009 Columbia U. Expires: September 28, 2009 Columbia U.
J. Polk J. Polk
Cisco Systems Cisco Systems
A. Newton A. Newton
TranTech/MediaSolv TranTech/MediaSolv
February 27, 2009 March 27, 2009
Framework for Emergency Calling using Internet Multimedia Framework for Emergency Calling using Internet Multimedia
draft-ietf-ecrit-framework-08 draft-ietf-ecrit-framework-09
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 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 31, 2009. This Internet-Draft will expire on September 28, 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 16 skipping to change at page 2, line 16
The IETF has standardized various aspects of placing emergency calls. The IETF has standardized various aspects of placing emergency calls.
This document describes how all of those component parts are used to This document describes how all of those component parts are used to
support emergency calls from citizens and visitors to authorities. support emergency calls from citizens and visitors to authorities.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of how emergency calls are placed . . . . . . . . . . 7 3. Overview of how emergency calls are placed . . . . . . . . . . 7
4. Which devices and services should support emergency calls . . 10 4. Which devices and services should support emergency calls . . 11
5. Identifying an emergency call . . . . . . . . . . . . . . . . 11 5. Identifying an emergency call . . . . . . . . . . . . . . . . 12
6. Location and its role in an emergency call . . . . . . . . . . 12 6. Location and its role in an emergency call . . . . . . . . . . 13
6.1. Types of location information . . . . . . . . . . . . . . 14 6.1. Types of location information . . . . . . . . . . . . . . 15
6.2. Location determination . . . . . . . . . . . . . . . . . . 15 6.2. Location determination . . . . . . . . . . . . . . . . . . 16
6.2.1. User-entered location information . . . . . . . . . . 16 6.2.1. User-entered location information . . . . . . . . . . 17
6.2.2. Access network "wire database" location information . 16 6.2.2. Access network "wire database" location information . 17
6.2.3. End-system measured location information . . . . . . . 17 6.2.3. End-system measured location information . . . . . . . 18
6.2.4. Network measured location information . . . . . . . . 18 6.2.4. Network measured location information . . . . . . . . 19
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 18 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 19
6.4. Location and references to location . . . . . . . . . . . 19 6.4. Location and references to location . . . . . . . . . . . 20
6.5. End system location configuration . . . . . . . . . . . . 19 6.5. End system location configuration . . . . . . . . . . . . 20
6.6. When location should be configured . . . . . . . . . . . . 21 6.6. When location should be configured . . . . . . . . . . . . 22
6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 22 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 23
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 22 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 23
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 22 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 23
6.10. Location validation . . . . . . . . . . . . . . . . . . . 24 6.10. Location validation . . . . . . . . . . . . . . . . . . . 25
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 24 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 25
6.12. Location format conversion . . . . . . . . . . . . . . . . 25 6.12. Location format conversion . . . . . . . . . . . . . . . . 26
7. LIS and LoST discovery . . . . . . . . . . . . . . . . . . . . 25 7. LIS and LoST discovery . . . . . . . . . . . . . . . . . . . . 26
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 25 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 26
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 27 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 28
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. SIP signaling requirements for User Agents . . . . . . . . 28 9.2. SIP signaling requirements for User Agents . . . . . . . . 29
9.3. SIP signaling requirements for proxy servers . . . . . . . 28 9.3. SIP signaling requirements for proxy servers . . . . . . . 29
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 29 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 30
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 30 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 31
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 30 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 31
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
16. Security Considerations . . . . . . . . . . . . . . . . . . . 31 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
19. Informative References . . . . . . . . . . . . . . . . . . . . 32 19. Informative References . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Terminology 1. Terminology
This document uses terms from [RFC3261] and [RFC5012]. In addition This document uses terms from [RFC3261] and [RFC5012]. In addition
the following terms are used: the following terms are used:
Access network: The access network supplies IP packet service to an Access network: The access network supplies IP packet service to an
endpoint. Examples of access networks include digital subscriber endpoint. Examples of access networks include digital subscriber
lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local
area networks and cellular data networks. area networks and cellular data networks.
(Emergency) Call taker: An emergency call taker answers an emergency (Emergency) Call taker: An emergency call taker answers an emergency
skipping to change at page 6, line 35 skipping to change at page 6, line 35
conventional text telephony ("TTY") media streams. However, more conventional text telephony ("TTY") media streams. However, more
choices of media offer additional ways to communicate and evaluate choices of media offer additional ways to communicate and evaluate
the situation as well as to assist callers and call takers in the situation as well as to assist callers and call takers in
handling emergency calls. For example, instant messaging and video handling emergency calls. For example, instant messaging and video
could improve the ability to communicate and evaluate the situation could improve the ability to communicate and evaluate the situation
and to provide appropriate instruction prior to arrival of emergency and to provide appropriate instruction prior to arrival of emergency
crews. Thus, the architecture described here supports the creation crews. Thus, the architecture described here supports the creation
of sessions of any media type, negotiated between the caller and PSAP of sessions of any media type, negotiated between the caller and PSAP
using existing SIP protocol mechanisms [RFC3264]. using existing SIP protocol mechanisms [RFC3264].
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.
Since this document is a framework document, it does not include Since this document is a framework document, it does not include
normative behavior. A companion document, [I-D.ietf-ecrit-phonebcp], normative behavior. A companion document, [I-D.ietf-ecrit-phonebcp],
describes Best Current Practice for this subject and contains describes Best Current Practice for this subject and contains
normative language for devices, access and calling network elements. normative language for devices, access and calling network elements.
Supporting emergency calling does not require any specialized SIP Supporting emergency calling does not require any specialized SIP
header fields, request methods, status codes, message bodies, or header fields, request methods, status codes, message bodies, or
event packages, but does require that existing mechanisms be used in event packages, but does require that existing mechanisms be used in
certain specific ways, as described below. User Agents (UAs) unaware certain specific ways, as described below. User Agents (UAs) unaware
of the recommendations in this draft may be able to place emergency of the recommendations in this draft may be able to place emergency
skipping to change at page 29, line 35 skipping to change at page 30, line 35
In addition, a call-back identifier as an AoR must be included either In addition, a call-back identifier as an AoR must be included either
as the URI in the From header field [RFC3261] verified by SIP as the URI in the From header field [RFC3261] verified by SIP
Identity [RFC4474] or as a network asserted URI [RFC3325]. This Identity [RFC4474] or as a network asserted URI [RFC3325]. This
identifier would be used to initiate a call-back at a later time and identifier would be used to initiate a call-back at a later time and
may reach the caller, not necessarily on the same device (and at the may reach the caller, not necessarily on the same device (and at the
same location) as the original emergency call as per normal SIP same location) as the original emergency call as per normal SIP
rules. rules.
11. Mid-call behavior 11. Mid-call behavior
Some features often provided in telephony services, such as call
waiting, 3 way call, and the like, need to be disabled during
emergency calls. In [I-D.ietf-ecrit-phonebcp], reference is made to
"flash hold". This is a service in some PSTN systems where a short
duration "on hook" signals the network to put the call on hold,
provide dial tone, and await DTMF signaling. That form of hold, as
well as ISDN signaled hold is undesirable in emergency calls.
Some PSAPs often include dispatchers, responders or specialists on a Some PSAPs often include dispatchers, responders or specialists on a
call. Some responder's dispatchers are not located in the primary call. Some responder's dispatchers are not located in the primary
PSAP, the call may have to be transferred to another PSAP. Most PSAP, the call may have to be transferred to another PSAP. Most
often this will be an attended transfer, or a bridged transfer. often this will be an attended transfer, or a bridged transfer.
Therefore a PSAP may need to a REFER request [RFC3515] a call to a Therefore a PSAP may need to a REFER request [RFC3515] a call to a
bridge for conferencing. Devices which normally involve the user in bridge for conferencing. Devices which normally involve the user in
transfer operations should consider the effect of such interactions transfer operations should consider the effect of such interactions
when a stressed user places an emergency call. Requiring UI when a stressed user places an emergency call. Requiring UI
manipulation during such events may not be desirable. Relay services manipulation during such events may not be desirable. Relay services
for communication with people with disabilities may be included in for communication with people with disabilities may be included in
skipping to change at page 30, line 19 skipping to change at page 31, line 15
12. Call termination 12. Call termination
It is undesirable for the caller to terminate an emergency call. It is undesirable for the caller to terminate an emergency call.
PSAP terminates a call using the normal SIP call termination PSAP terminates a call using the normal SIP call termination
procedures, i.e with a BYE request. procedures, i.e with a BYE request.
13. Disabling of features 13. Disabling of features
Certain features that can be invoked while a normal call is active Certain features that can be invoked while a normal call is active
are not permitted when the call is an emergency call. Services such are not permitted when the call is an emergency call. Services such
as call waiting, call transfer, three way call and flash Hold should as call waiting, call transfer, three way call and hold should be
be disabled. disabled.
Certain features such as call forwarding can interfere with calls Certain features such as call forwarding can interfere with calls
from a PSAP and should be disabled. There is no way to reliably from a PSAP and should be disabled. There is no way to reliably
determine a PSAP call back. A UA may be able to determine a PSAP determine a PSAP call back. A UA may be able to determine a PSAP
call back by examining the domain of incoming calls after placing an call back by examining the domain of incoming calls after placing an
emergency call and comparing that to the domain of the answering PSAP emergency call and comparing that to the domain of the answering PSAP
from the emergency call. Any call from the same domain and directed from the emergency call. Any call from the same domain and directed
to the supplied Contact header or AoR after an emergency call should to the supplied Contact header or AoR after an emergency call should
be accepted as a call-back from the PSAP if it occurs within a be accepted as a call-back from the PSAP if it occurs within a
reasonable time after an emergency call was placed. reasonable time after an emergency call was placed.
skipping to change at page 32, line 15 skipping to change at page 33, line 9
Design Team members participating in this draft creation include Design Team members participating in this draft creation include
Martin Dolly, Stu Goldman, Ted Hardie, Marc Linsner, Roger Marshall, Martin Dolly, Stu Goldman, Ted Hardie, Marc Linsner, Roger Marshall,
Shida Schubert, Tom Taylor and Hannes Tschofenig,. Further comments Shida Schubert, Tom Taylor and Hannes Tschofenig,. Further comments
and input were provided by Richard Barnes, Barbara Stark and James and input were provided by Richard Barnes, Barbara Stark and James
Winterbottom. Winterbottom.
19. Informative References 19. 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., Cooper, A., Morris, J.,
Schulzrinne, "Additional Location Privacy Considerations", Tschofenig, H., and H. Schulzrinne, "An Architecture for
draft-barnes-geopriv-lo-sec-04 (work in progress), Location and Location Privacy in Internet Applications",
January 2009. draft-barnes-geopriv-lo-sec-05 (work in progress),
March 2009.
[I-D.ietf-ecrit-phonebcp] [I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-07 (work in progress), draft-ietf-ecrit-phonebcp-08 (work in progress),
January 2009. February 2009.
[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-13 (work in draft-ietf-geopriv-http-location-delivery-13 (work in
progress), February 2009. 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-07 (work in progress), draft-ietf-geopriv-lis-discovery-08 (work in progress),
February 2009. March 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-sip-gruu] [I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress), (SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007. October 2007.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-12 (work in progress), draft-ietf-sip-location-conveyance-13 (work in progress),
November 2008. March 2009.
[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] [I-D.ietf-sip-sips]
Audet, F., "The use of the SIPS URI Scheme in the Session Audet, F., "The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", draft-ietf-sip-sips-09 (work Initiation Protocol (SIP)", draft-ietf-sip-sips-09 (work
 End of changes. 12 change blocks. 
60 lines changed or deleted 65 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/