draft-ietf-ecrit-framework-09.txt   draft-ietf-ecrit-framework-10.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Informational H. Schulzrinne Intended status: Informational H. Schulzrinne
Expires: September 28, 2009 Columbia U. Expires: January 28, 2010 Columbia U.
J. Polk J. Polk
Cisco Systems Cisco Systems
A. Newton A. Newton
TranTech/MediaSolv TranTech/MediaSolv
March 27, 2009 July 27, 2009
Framework for Emergency Calling using Internet Multimedia Framework for Emergency Calling using Internet Multimedia
draft-ietf-ecrit-framework-09 draft-ietf-ecrit-framework-10
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 September 28, 2009. This Internet-Draft will expire on January 28, 2010.
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 32 skipping to change at page 2, line 32
6.2.2. Access network "wire database" location information . 17 6.2.2. Access network "wire database" location information . 17
6.2.3. End-system measured location information . . . . . . . 18 6.2.3. End-system measured location information . . . . . . . 18
6.2.4. Network measured location information . . . . . . . . 19 6.2.4. Network measured location information . . . . . . . . 19
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 19 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 19
6.4. Location and references to location . . . . . . . . . . . 20 6.4. Location and references to location . . . . . . . . . . . 20
6.5. End system location configuration . . . . . . . . . . . . 20 6.5. End system location configuration . . . . . . . . . . . . 20
6.6. When location should be configured . . . . . . . . . . . . 22 6.6. When location should be configured . . . . . . . . . . . . 22
6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 23 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 23
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 23 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 23
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 23 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 23
6.10. Location validation . . . . . . . . . . . . . . . . . . . 25 6.10. Location validation . . . . . . . . . . . . . . . . . . . 24
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 25 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 25
6.12. Location format conversion . . . . . . . . . . . . . . . . 26 6.12. Location format conversion . . . . . . . . . . . . . . . . 26
7. LIS and LoST discovery . . . . . . . . . . . . . . . . . . . . 26 7. LIS and LoST discovery . . . . . . . . . . . . . . . . . . . . 26
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 26 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 26
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 28 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 28
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. SIP signaling requirements for User Agents . . . . . . . . 29 9.2. SIP signaling requirements for User Agents . . . . . . . . 29
9.3. SIP signaling requirements for proxy servers . . . . . . . 29 9.3. SIP signaling requirements for proxy servers . . . . . . . 29
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 30 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 30
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 31 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 30
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 31 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 30
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
19. Informative References . . . . . . . . . . . . . . . . . . . . 33 19. Informative References . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
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 23, line 52 skipping to change at page 23, line 52
When using a HELD dereference, the PSAP must specify the value When using a HELD dereference, the PSAP must specify the value
"emergencyDispatch" for the ResponseTime parameter. Since typically "emergencyDispatch" for the ResponseTime parameter. Since typically
the LIS is local relative to the PSAP, the LIS can be aware of the the LIS is local relative to the PSAP, the LIS can be aware of the
update requirements of the PSAP update requirements of the PSAP
6.9. Multiple locations 6.9. Multiple locations
Getting multiple locations all purported to describe the location of Getting multiple locations all purported to describe the location of
the caller is confusing to all, and should be avoided. Handling the caller is confusing to all, and should be avoided. Handling
multiple locations at the point where a PIDF is created is discussed multiple locations at the point where a PIDF is created is discussed
in [I-D.ietf-geopriv-pdif-lo-profile]. Conflicting location in [RFC5491]. Conflicting location information is particularly
information is particularly harmful if different routes (PSAPs) harmful if different routes (PSAPs) result from LoST queries for the
result from LoST queries for the multiple locations. When they occur multiple locations. When they occur anyway, the general guidance is
anyway, the general guidance is that the entity earliest in the chain that the entity earliest in the chain generally has more knowledge
generally has more knowledge than later elements to make an than later elements to make an intelligent decision, especially about
intelligent decision, especially about which location will be used which location will be used for routing. It is permissible to send
for routing. It is permissible to send multiple locations towards multiple locations towards the PSAP, but the element that chooses the
the PSAP, but the element that chooses the route must select exactly route must select exactly one location to use with LoST.
one location to use with LoST.
Guidelines for dealing with multiple locations are also given in Guidelines for dealing with multiple locations are also given in
[RFC5222]. If a UA gets multiple locations, it must choose the one [RFC5222]. If a UA gets multiple locations, it must choose the one
to use for routing, but it may send all of the locations it has in to use for routing, but it may send all of the locations it has in
the signaling. If a proxy is inserting location and has multiple the signaling. If a proxy is inserting location and has multiple
locations, it must choose exactly one to use for routing, marking it locations, it must choose exactly one to use for routing, marking it
as such (per [I-D.ietf-sip-location-conveyance], and send it as well as such (per [I-D.ietf-sip-location-conveyance], and send it as well
as any others it has. as any others it has.
The UA or proxy should have the ability to understand how and from The UA or proxy should have the ability to understand how and from
skipping to change at page 30, line 46 skipping to change at page 30, line 35
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
the call with the bridge. The UA should be prepared to have the call the call with the bridge. The UA should be prepared to have the call
transferred (usually attended, but possibly blind) per transferred (usually attended, but possibly blind) per [RFC5359].
[I-D.ietf-sipping-service-examples].
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
skipping to change at page 32, line 15 skipping to change at page 31, line 48
15. Testing 15. Testing
Since the emergency calling architecture consists of a number of Since the emergency calling architecture consists of a number of
pieces operated by independent entities, it is important to be able pieces operated by independent entities, it is important to be able
to test whether an emergency call is likely to succeed without to test whether an emergency call is likely to succeed without
actually occupying the human resources at a PSAP. Both signaling and actually occupying the human resources at a PSAP. Both signaling and
media paths need to be tested since NATs and firewalls may allow the media paths need to be tested since NATs and firewalls may allow the
session setup request to reach the PSAP, while preventing the session setup request to reach the PSAP, while preventing the
exchange of media. exchange of media.
<> includes a description of an automated test procedure that includes a description of an automated test procedure that validates
validates routing, signaling and media path continuity. This test routing, signaling and media path continuity. This test would be
would be used within some random interval after boot time, and used within some random interval after boot time, and whenever the
whenever the device location changes enough that a new PSAP mapping device location changes enough that a new PSAP mapping is returned by
is returned by the LoST server. the LoST server.
The PSAP needs to be able to control frequency and duration of the The PSAP needs to be able to control frequency and duration of the
test, and since the process could be abused, it may temporarily or test, and since the process could be abused, it may temporarily or
permanently suspend its operation. permanently suspend its operation.
There is a concern associated with testing during a so-called There is a concern associated with testing during a so-called
"avalanche-restart" event where, for example a large power outage "avalanche-restart" event where, for example a large power outage
affects a large number of endpoints, that, when power is restored, affects a large number of endpoints, that, when power is restored,
all attempt to reboot and, possibly, test. Devices need to randomize all attempt to reboot and, possibly, test. Devices need to randomize
their initiation of a boot time test to avoid the problem. their initiation of a boot time test to avoid the problem.
skipping to change at page 33, line 18 skipping to change at page 33, line 6
[I-D.barnes-geopriv-lo-sec] [I-D.barnes-geopriv-lo-sec]
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
draft-barnes-geopriv-lo-sec-05 (work in progress), draft-barnes-geopriv-lo-sec-05 (work in progress),
March 2009. 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-08 (work in progress), draft-ietf-ecrit-phonebcp-12 (work in progress),
February 2009. July 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-15 (work in
progress), February 2009. progress), June 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-08 (work in progress), draft-ietf-geopriv-lis-discovery-11 (work in progress),
March 2009. May 2009.
[I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
(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-13 (work in progress), draft-ietf-sip-location-conveyance-13 (work in progress),
March 2009. March 2009.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C., "Managing Client Initiated Connections in
Connections in the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-16 (work in progress), draft-ietf-sip-outbound-20 (work in progress), June 2009.
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
in progress), November 2008. in progress), November 2008.
[I-D.ietf-sipping-service-examples]
Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service
Examples", draft-ietf-sipping-service-examples-15 (work in
progress), July 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".
[NENAi3TRD] [NENAi3TRD]
NENA, "08-751 NENA i3 Technical Requirements for", 2006. NENA, "08-751 NENA i3 Technical Requirements for", 2006.
skipping to change at page 36, line 48 skipping to change at page 36, line 22
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008. Protocol", RFC 5222, August 2008.
[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.
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service
Examples", BCP 144, RFC 5359, October 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
[WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of [WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of
Defense World Geodetic System 1984, Its Definition and Defense World Geodetic System 1984, Its Definition and
Relationships With Local Geodetic Systems, Third Edition", Relationships With Local Geodetic Systems, Third Edition",
July 1997. July 1997.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar, Inc. NeuStar, Inc.
470 Conrad Dr 470 Conrad Dr
 End of changes. 18 change blocks. 
49 lines changed or deleted 43 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/