< 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 15, line 39 ¶		skipping to change at page 15, line 39 ¶
	warranted, in future documents.		warranted, in future documents.
	6.1. Types of location information		6.1. Types of location information
	Location can be specified in several ways:		Location can be specified in several ways:
	Civic: Civic location information describes the location of a person		Civic: Civic location information describes the location of a person
	or object by a street address that corresponds to a building or		or object by a street address that corresponds to a building or
	other structure. Civic location may include more fine grained		other structure. Civic location may include more fine grained
	location information such as floor, room and cubicle. Civic		location information such as floor, room and cubicle. Civic
	information comes in two forms:		information comes in two forms:
	Jurisdictional refers to a civic location using actual political		Jurisdictional refers to a civic location using actual political
	subdivisions, especially for the community name.		subdivisions, especially for the community name.
	Postal refers to a civic location for mail delivery. The name of		Postal refers to a civic location for mail delivery. The name of
	the post office sometimes does not correspond to the community		the post office sometimes does not correspond to the community
	name and a postal address may contain post office boxes or		name and a postal address may contain post office boxes or
	street addresses that do not correspond to an actual building.		street addresses that do not correspond to an actual building.
	Postal addresses are generally unsuitable for emergency call		Postal addresses are generally unsuitable for emergency call
	dispatch because the post office conventions (for community		dispatch because the post office conventions (for community
	name, for example) do not match those known by the responders.		name, for example) do not match those known by the responders.
	The fact that they are unique can sometimes be exploited to		The fact that they are unique can sometimes be exploited to
	provide a mapping between a postal address and a civic address		provide a mapping between a postal address and a civic address
	suitable to dispatch a responder to. In IETF location		suitable to dispatch a responder to. In IETF location
	protocols, there is an element (Postal Community Name) that can		protocols, there is an element (Postal Community Name) that can
	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. 20 change blocks.
	51 lines changed or deleted		45 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/