< draft-ietf-ecrit-phonebcp-00.txt		draft-ietf-ecrit-phonebcp-01.txt >
	ecrit B. Rosen		ecrit B. Rosen
	Internet-Draft NeuStar		Internet-Draft NeuStar
	Intended status: Standards Track J. Polk		Intended status: Standards Track J. Polk
	Expires: April 18, 2007 Cisco Systems		Expires: September 6, 2007 Cisco Systems
	October 15, 2006		March 05, 2007
	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-00.txt		draft-ietf-ecrit-phonebcp-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 April 18, 2007.		This Internet-Draft will expire on September 6, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	Requesting help in an emergency using a communications device such as		Requesting help in an emergency using a communications device such as
	a telephone or mobile is an accepted practice in most of the world.		a telephone or mobile is an accepted practice in most of the world.
	As communications devices increasingly utilize the Internet to		As communications devices increasingly utilize the Internet to
	interconnect and communicate, users will continue to expect to use		interconnect and communicate, users will continue to expect to use
	such devices to request help, regardless of whether or not they		such devices to request help, regardless of whether or not they
	communicate using IP. The emergency response community will have to		communicate using IP. The emergency response community will have to
	upgrade their facilities to support the wider range of communications		upgrade their facilities to support the wider range of communications
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	and service capability. The IETF has several efforts targeted at		and service capability. The IETF has several efforts targeted at
	standardizing various aspects of placing emergency calls. This memo		standardizing various aspects of placing emergency calls. This memo
	describes best current practice on how devices and services should		describes best current practice on how devices and services should
	use such standards to reliably make emergency calls		use such standards to reliably make emergency calls
	Table of Contents		Table of Contents
	1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3		1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Which devices and services should support emergency calls . . 4		3. Which devices and services should support emergency calls . . 4
	4. Determining Location . . . . . . . . . . . . . . . . . . . . . 4		4. Location . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
			4.1. Endpoints learn their own location . . . . . . . . . . . . 5
			4.2. Location Configuration Protocols . . . . . . . . . . . . . 5
			4.3. Self reported Location . . . . . . . . . . . . . . . . . . 6
			4.4. When Location should be Configured . . . . . . . . . . . . 6
			4.5. Other location considerations . . . . . . . . . . . . . . 7
	5. Determining an emergency call . . . . . . . . . . . . . . . . 7		5. Determining an emergency call . . . . . . . . . . . . . . . . 7
	6. Session Signaling . . . . . . . . . . . . . . . . . . . . . . 8		6. Session Signaling . . . . . . . . . . . . . . . . . . . . . . 9
	6.1. SIP signaling requirements for User Agents . . . . . . . . 8		6.1. SIP signaling requirements for User Agents . . . . . . . . 9
	6.2. Mapping from Location to a PSAP URI . . . . . . . . . . . 9		6.2. SIP signaling requirements for proxy servers and B2BUAs . 10
	6.3. Routing the call . . . . . . . . . . . . . . . . . . . . . 10		6.3. Mapping from Location to a PSAP URI . . . . . . . . . . . 11
	6.4. Responding to PSAP signaling . . . . . . . . . . . . . . . 10		6.4. Routing the call . . . . . . . . . . . . . . . . . . . . . 12
	6.5. Disabling of features . . . . . . . . . . . . . . . . . . 11		6.5. Responding to PSAP signaling . . . . . . . . . . . . . . . 12
	7. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		6.6. Disabling of features . . . . . . . . . . . . . . . . . . 13
	7.1. Testing Mechanism . . . . . . . . . . . . . . . . . . . . 11		7. Location Update . . . . . . . . . . . . . . . . . . . . . . . 13
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 12		8. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9. Normative References . . . . . . . . . . . . . . . . . . . . . 12		9. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		9.1. Testing Mechanism . . . . . . . . . . . . . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . . . . . 16		10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
			10.1. Threats against endpoints . . . . . . . . . . . . . . . . 15
			10.2. Threats against the Emergency Service . . . . . . . . . . 16
			11. Normative References . . . . . . . . . . . . . . . . . . . . . 16
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
			Intellectual Property and Copyright Statements . . . . . . . . . . 21
	1. Requirements notation		1. Requirements notation
	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].
	2. Introduction		2. Introduction
	This document describes how SIP User Agents and proxy servers support		This document describes how SIP User Agents and proxy servers support
	emergency calling, as outlined in [framework]. Here, an emergency		emergency calling, as outlined in [I-D.ietf-ecrit-framework]. Here,
	call refers to a communications session established by a user to a		an emergency call refers to a communications session established by a
	"Public Safety Answering Point" (PSAP) which is a call center		user to a "Public Safety Answering Point" (PSAP) which is a call
	established by response agencies to accept emergency calls. We		center established by response agencies to accept emergency calls.
	differentiate such calls from other sessions which are created by		We differentiate such calls from other sessions which are created by
	responders using public communications infrastructure often involving		responders using public communications infrastructure often involving
	some kind of priority access as defined in Emergency		some kind of priority access as defined in Emergency
	Telecommunications Service (ETS) in IP Telephony [RFC4190].		Telecommunications Service (ETS) in IP Telephony [RFC4190]. By
			implication, this document describes the interface between the
			emergency services network and the Internet. This memo also
			describes how location may be obtained from the local access
			infrastructure (broadband network), and thus specifies requirements
			to support location in such infrastructure.
	Making an emergency call involves the use of location information,		Making an emergency call involves the use of location information,
	referring to the physical location of the caller. Location is used		referring to the physical location of the caller. Location is used
	within the emergency calling system to route a call to the correct		within the emergency calling system to route a call to the correct
	PSAP, as well as by the PSAP to choose the correct responder, and		PSAP, as well as by the PSAP to choose the correct responder, and
	direct them to the person in need of assistance.		direct them to the person in need of assistance.
	The steps involved in an emergency call from an IP based device are		The steps involved in an emergency call from an IP based device are
	(with a rough ordering of operation)		(with a rough ordering of operation)
	1. Device connects to access network, and obtains initial location		1. Device connects to access network, and obtains initial location
	skipping to change at page 3, line 44 ¶		skipping to change at page 3, line 49 ¶
	4. User device includes location indication (by value or by		4. User device includes location indication (by value or by
	reference) in the call set-up messaging		reference) in the call set-up messaging
	5. emergency call set-up is routed to appropriate PSAP based on		5. emergency call set-up is routed to appropriate PSAP based on
	location of the caller		location of the caller
	6. call is established with PSAP		6. call is established with PSAP
	7. caller's location is presented to PSAP operator for dispatch		7. caller's location is presented to PSAP operator for dispatch
	As a quick overview for a typical Ethernet connected telephone using		As a quick overview for a typical Ethernet connected telephone using
	SIP signaling:		SIP signaling:
	o the phone "boots" and connects to its access network		o the phone "boots" and connects to its access network
	o the phone would get location from the DHCP server [or an L7		o the phone would get location from the DHCP server [an L7 server]
	server].		or the first level switch's LLDP server.
	o It would use "urn:service:sos" as the URI of an emergency call.
	o It would determine the PSAP's URI by using the
	[I-D.ietf-ecrit-lost] mapping server from the location provided in
	the signaling
			o the phone obtains the local emergency dialstring(s) from the
			[I-D.ietf-ecrit-lost] server.
			o It recognizes an emergency call from the dialstrings and uses
			"urn:service:sos" to mark an emergency call.
			o It would determine the PSAP's URI by using the
			[I-D.ietf-ecrit-lost] mapping server from the location provided
	o It would put its location in the SIP INVITE as a PIDF-LO in the		o It would put its location in the SIP INVITE as a PIDF-LO in the
	body of the INVITE (or a reference to location in a Location		body of the INVITE (or a reference to location in a Location
	header) and forward the call to its first hop proxy.		header) [I-D.ietf-sip-location-conveyance] and forward the call to
			its first hop proxy.
	o The proxy recognizes the call as an emergency call and routes the		o The proxy recognizes the call as an emergency call and routes the
	call using normal SIP routing mechanisms		call using normal SIP routing mechanisms.
	[RFC4504] details Best Current Practice for SIP user agents. This		o The call is established and common media streams opened.
	memo can be considered an addition to it for endpoints.
			Best Current Practice for SIP user agents including handling of audio
			and real-time text [RFC4103]media detailed in [RFC4504] SHOULD be
			applied. This memo can be considered an addition to it for
			endpoints.
	3. Which devices and services should support emergency calls		3. Which devices and services should support emergency calls
	Although present PSAPs have only support for voice calls placed		Support for voice calls and real-time text calls placed through PSTN
	through PSTN facilities or systems connected to the PSTN, future		facilities or systems connected to the PSTN is found in present
	PSAPs will support Internet connectivity and a wider range of media		PSAPs. Future PSAPs will however support Internet connectivity and a
	types. In general, if a user could reasonably expect to be able to		wider range of media types and provide higher functionality.. In
	call for help with the device, then the device or service should		general, if a user could reasonably expect to be able to call for
	support emergency calling. Certainly, any device or service that		help with the device, then the device or service should support
	looks like and works like a telephone (wired or mobile) should		emergency calling. Certainly, any device or service that looks like
	support emergency calling, but increasingly, users have expectations		and works like a telephone (wired or mobile) should support emergency
	that other devices and services should work.		calling, but increasingly, users have expectations that other devices
			and services should work.
	Using current (evolving) standards, devices that create media		Using current (evolving) standards, devices that create media
	sessions and exchange audio, video and/or text, and have the		sessions and exchange audio, video and/or text, and have the
	capability to establish sessions to a wide variety of addresses, and		capability to establish sessions to a wide variety of addresses, and
	communicate over private IP networks or the Internet, should support		communicate over private IP networks or the Internet, should support
	emergency calls.		emergency calls.
	4. Determining Location		4. Location
			Location is central to the operation of emergency services. Location
			is used to route a call to the PSAP that serves the location, and it
			is used to dispatch responders to the person in need of help. It is
			frequently the case that the user in an emergency is unable to
			provide a unique, valid location themselves. For this reason,
			automatic location is the norm.
			In Internet emergency calling, we "Determine" where the endpoint is
			located using a variety of measurement or wiretracing methods. We
			"Configure" endpoints with their own location. We "Map" the location
			to the URI to send the call to, and we "Convey" the location to the
			PSAP (and other elements) in the signaling. These topics are
			detailed in [I-D.ietf-ecrit-framework].
			4.1. Endpoints learn their own location
	With Internet based communications services, determining where the		With Internet based communications services, determining where the
	caller is located is more problematic than in PSTN and mobile		caller is located is more problematic than in PSTN and mobile
	systems. Existing wired phones are tethered with a wire that is		systems. Existing wired phones are tethered with a wire that is
	connected directly to a call control device, a circuit switch.		connected directly to a call control device, a circuit switch.
	Cellular phones are tethered via a radio channel to a cell tower,		Cellular phones are tethered via a radio channel to a cell tower,
	which connects that cell phone to a circuit switch. The primary		which connects that cell phone to a circuit switch. The primary
	difficulty with IP based phones is that the connectivity, whether		difficulty with IP based phones is that the connectivity, whether
	wired or radio channel, is decoupled from the call control device.		wired or radio channel, is decoupled from the call control device.
	The communications service may not have any relationship with the		The communications service may not have any relationship with the
	skipping to change at page 5, line 6 ¶		skipping to change at page 5, line 34 ¶
	way to even find out who the access carrier is.		way to even find out who the access carrier is.
	For this reason, standards have been created for endpoints (devices)		For this reason, standards have been created for endpoints (devices)
	to obtain location information where it is the access network that		to obtain location information where it is the access network that
	knows the location of the endpoint. To obtain location information,		knows the location of the endpoint. To obtain location information,
	the endpoint can use a Location Configuration Protocol. The endpoint		the endpoint can use a Location Configuration Protocol. The endpoint
	is a subscriber to both the access network and the communications		is a subscriber to both the access network and the communications
	service, and thus is in a position to obtain its location from the		service, and thus is in a position to obtain its location from the
	access network, and supply it to the communications service. These		access network, and supply it to the communications service. These
	issues, and the necessity for endpoints and access networks to		issues, and the necessity for endpoints and access networks to
	support LCPs is detailed in [framework].		support LCPs is detailed in [I-D.ietf-ecrit-framework].
			4.2. Location Configuration Protocols
	For devices that operate on a network where the network operator		For devices that operate on a network where the network operator
	controls the specification of every device connected to that network		controls the specification of every device connected to that network
	that could be used for emergency calls, the method by which location		that could be used for emergency calls, the method by which location
	is determined need not be an IETF standard, but can be any method		is determined need not be an IETF standard, but can be any method
	that achieves the desired result. Such a method MUST be specified,		that achieves the desired result. Such a method MUST be specified,
	and every device MUST support it.		and every device MUST support it. It is recommended that, in
			addition, the network SHOULD support one or more of DHCP,
			[Placeholder for L7 LCP} or LLDP-MED.
	For all other devices, location configuration by DHCP, [Placeholder		For all other devices, the device MUST support DHCP, [Placeholder for
	for L7 LCP] and LLDP-MED MUST be supported. DHCP [RFC2131] has been		L7 LCP] and LLDP-MED. The access network MUST support at least one
	enhanced to provide the location of a device. [RFC3825] describes		of these.
	how a geo-location (lat/lon/alt) may be obtained and
	[I-D.schulzrinne-geopriv-dhcp-civil] describes how a civic (street
	address) location can be obtained via DHCP.
	[Placeholder for HELD, LCP or other L7 location determination		DHCP [RFC2131] has been enhanced to provide the location of a device.
			[RFC3825] describes how a geo-location (lat/lon/alt) may be obtained
			and [RFC4676] describes how a civic (street address) location can be
			obtained via DHCP.
			[Placeholder for HELD, RELO or other L7 location determination
	methods]		methods]
	[LLDP] with [LLDP-MED] extensions provides an alternative to DHCP in		[LLDP] with [LLDP-MED] extensions provides location configuration
	many enterprise environments.		applicable in many enterprise environments.
	For devices that operate in a network where the network operator		For devices that operate in a network where the network operator
	controls the specification of every device connected to that network,		controls the specification of every device connected to that network,
	but the network attachment supports upstream networks to which		but the network attachment supports upstream networks to which
	communications devices are connected (such as any network that		communications devices are connected (such as any network that
	supports Ethernet connected telephones and terminal adapters), the		supports Ethernet connected telephones and terminal adapters), the
	method by which location is determined need not be an IETF standard,		method by which location is determined need not be an IETF standard,
	but can be any method which achieves the desired result. However,		but can be any method which achieves the desired result. However,
	the network attachment MUST support at least one of DHCP [L7 LCP] or		the network attachment MUST support at least one of DHCP [L7 LCP] or
	LLDP-MED for upstream communications devices to obtain location. For		LLDP-MED for upstream communications devices to obtain location. For
	smaller interior (e.g, LAN) networks, the DHCP, [L7 LCP] or LLDP-MED		smaller interior (e.g, LAN) networks, the DHCP, [L7 LCP] or LLDP-MED
	server should simply repeat the location obtained from the access		server should simply repeat the location obtained from the access
	network. For larger networks, other mechanisms, such as a DHCP Relay		network. For larger networks, other mechanisms, such as a DHCP Relay
	Agent [RFC3046] SHOULD be used to provide more accurate location of		Agent [RFC3046] SHOULD be used to provide more accurate location of
	endpoints.		endpoints.
	For devices that operate on a network where the network operator does		4.3. Self reported Location
	not control the specification of every device connected to the
	network, at least one of DHCP, [L7 LCP] or LLDP-MED MUST be supported
	on the network.
	Self Reported location is generally unacceptable in emergency calls,		Self reported location, where a user enters location himself, is
	although it is being used prior to automatic location determination		generally unacceptable in emergency calls, although it is being used
	schemes being fielded. Local laws may govern what is acceptable in		prior to automatic location determination schemes being fielded.
	any country or area. Devices and/or access networks SHOULD support a		Local laws may govern what is acceptable in any country or area.
	manual method to "override" the location the access network		Devices and/or access networks SHOULD support a manual method to
	determines. The access network generally only knows the location of		"override" the location the access network determines. The access
	its demarcation point between the access network and the subscriber.		network generally only knows the location of its demarcation point
	The subscriber could have an extended network behind the demarc		between the access network and the subscriber. The subscriber could
	unknown to the access network. A method to account for this		have an extended network behind the demarc unknown to the access
	condition SHOULD be provided.		network. A method to account for this condition SHOULD be provided.
			4.4. When Location should be Configured
	Devices SHOULD get location immediately after obtaining local network		Devices SHOULD get location immediately after obtaining local network
	configuration information. It is essential for the location to be		configuration information. It is essential for the location to be
	determined BEFORE any VPN tunnels are established. It is equally		determined BEFORE any VPN tunnels are established. It is equally
	essential that this location information is *not* overwritten by any		essential that this location information is *not* overwritten by any
	process engaged from establishing a VPN connection. In other words,		process engaged from establishing a VPN connection. In other words,
	the established VPN to Chicago from the device in Dallas should not		the established VPN to Chicago from the device in Dallas MUST NOT
	overwrite the Dallas location for any reason especially an emergency		overwrite the Dallas location for any reason especially an emergency
	call.		call.
	It is desirable that location information be periodically refreshed.		It is desirable that location information be periodically refreshed.
	For devices which are not expected to roam, refreshing on the order		For devices which are not expected to roam, refreshing on the order
	of once per day is RECOMMENDED. For devices which roam, refresh of		of once per day is RECOMMENDED. For devices which roam, refresh of
	location SHOULD be more frequent, with the frequency related to the		location SHOULD be more frequent, with the frequency related to the
	mobility of the device and the ability of the access network to		mobility of the device and the ability of the access network to
	support the refresh operation. There can be instances in which a		support the refresh operation. There can be instances in which a
	device is aware of when it moves, for example when it changes access		device is aware of when it moves, for example when it changes access
	skipping to change at page 6, line 45 ¶		skipping to change at page 7, line 30 ¶
	systems should ideally be designed such that the typical response is		systems should ideally be designed such that the typical response is
	under 100ms. These numbers are empirically derived, but are intended		under 100ms. These numbers are empirically derived, but are intended
	to keep total call signaling time below 2 seconds. There are		to keep total call signaling time below 2 seconds. There are
	conflicts between the time it takes to generate location when		conflicts between the time it takes to generate location when
	measuring techniques are used and the desire to route the call		measuring techniques are used and the desire to route the call
	quickly. If an accurate location cannot be determined quickly, a		quickly. If an accurate location cannot be determined quickly, a
	rough location SHOULD be returned within 100ms which can be used to		rough location SHOULD be returned within 100ms which can be used to
	route the call. The location of the nearest base station in a		route the call. The location of the nearest base station in a
	wireless network is an example of a rough location.		wireless network is an example of a rough location.
			4.5. Other location considerations
	If the LCP does not return location in the form of a PIDF-LO		If the LCP does not return location in the form of a PIDF-LO
	[RFC4119], the endpoint must map the location information it receives		[RFC4119], the endpoint MUST map the location information it receives
	from the configuration protocol to a PIDF-LO.		from the configuration protocol to a PIDF-LO.
			To prevent against spoofing of the DHCP server, devices implementing
			DHCP for location configuration SHOULD use [RFC3118].
	5. Determining an emergency call		5. Determining an emergency call
	An emergency call is distinguished by the device (or a downstream		An emergency call is distinguished by the device (or a downstream
	element) by an "address", which in most cases for Internet connected		element) by an "address", which in most cases for Internet connected
	devices is still a dialstring, although other user interfaces may be		devices is still a dialstring, although other user interfaces may be
	used.		used.
	Note: It is undesirable to have a single "button" emergency call user		Note: It is undesirable to have a single "button" emergency call user
	interface element. These mechanisms have a very high false call		interface element. These mechanisms have a very high false call
	rate. PSAPs prefer devices to use their local emergency call		rate. PSAPs prefer devices to use their local emergency call
	skipping to change at page 7, line 26 ¶		skipping to change at page 8, line 12 ¶
	While in some countries there is a single 3 digit dialstring that is		While in some countries there is a single 3 digit dialstring that is
	used for all emergency calls (i.e. 911 in North America), in some		used for all emergency calls (i.e. 911 in North America), in some
	countries there are several 3 digit numbers used for different types		countries there are several 3 digit numbers used for different types
	of calls. For example, in Switzerland, 117 is used to call police,		of calls. For example, in Switzerland, 117 is used to call police,
	118 is used to call the fire brigade, and 144 is used for emergency		118 is used to call the fire brigade, and 144 is used for emergency
	medical assistance. In other countries, there are no "short codes"		medical assistance. In other countries, there are no "short codes"
	or "service codes" for 3 digit dialing of emergency services and		or "service codes" for 3 digit dialing of emergency services and
	local (PSTN) numbers are used.		local (PSTN) numbers are used.
	[I-D.schulzrinne-sipping-service] introduces a universal emergency		[I-D.ietf-ecrit-service-urn] introduces a universal emergency service
	service URN scheme. On the wire, emergency calls SHOULD include this		URN scheme. On the wire, emergency calls SHOULD include this type of
	type of URI as a Route header [RFC3261]. The scheme includes a		URI as a Route header [RFC3261]. The scheme includes a single
	single emergency URN (urn:service:sos) and responder specific ones		emergency URN (urn:service:sos) and responder specific ones
	(urn:service:sos.police). Using the service:sos URN scheme,		(urn:service:sos.police). Using the service:sos URN scheme,
	emergency calls can be recognized as such throughout the Internet.		emergency calls can be recognized as such throughout the Internet.
	Devices MUST use the service:sos URN scheme to mark emergency calls.		Devices MUST use the service:sos URN scheme to mark emergency calls.
	To determine which calls are emergency calls, some entity needs to		To determine which calls are emergency calls, some entity needs to
	map a user entered dialstring into this URN scheme. A user may		map a user entered dialstring into this URN scheme. A user may
	"dial" 1-1-2, but the call would be sent to urn:service:sos. This		"dial" 1-1-2, but the call would be sent to urn:service:sos. This
	mapping is SHOULD performed at the endpoint device, but MAY be		mapping is SHOULD performed at the endpoint device, but MAY be
	performed at an intermediate entity (such as a SIP proxy server).		performed at an intermediate entity (such as a SIP proxy server).
	skipping to change at page 7, line 52 ¶		skipping to change at page 8, line 38 ¶
	dialstring(s) and map to the universal emergency URN. If devices		dialstring(s) and map to the universal emergency URN. If devices
	cannot do "dial plan interpretation", then the first signaling aware		cannot do "dial plan interpretation", then the first signaling aware
	element (first hop proxy in SIP signaled devices) SHOULD do the		element (first hop proxy in SIP signaled devices) SHOULD do the
	mapping. It is important to not require a large number of active		mapping. It is important to not require a large number of active
	elements handle a call before it is recognized as an emergency call		elements handle a call before it is recognized as an emergency call
	In systems that support roaming, there may be a concept of "visited"		In systems that support roaming, there may be a concept of "visited"
	and "home" networks. Even when there is not a "visited network", the		and "home" networks. Even when there is not a "visited network", the
	user may be roaming (or nomadic) in a different country from their		user may be roaming (or nomadic) in a different country from their
	home. This gives rise to the problem of which dialstring(s) to		home. This gives rise to the problem of which dialstring(s) to
	recognize, the "home" or "visited"? While it is desirable that the		recognize, the "home" or "visited"? While the "home" dialstrings
	"home" dialstrings be recognized, it is required (by law in some		SHOULD be recognized, it is required (by law in some countries) that
	countries) that the "visited" dialstrings be recognized. Dial plan		the "visited" dialstrings MUST be recognized. "Visited" dialstrings
			would be essential if a guest used a roaming phone. Dial plan
	interpretation may need to take "visited" emergency dialstrings into		interpretation may need to take "visited" emergency dialstrings into
	account.		account.
	To give an example of this difference in dialstrings: If the device		To give an example of this difference in dialstrings: If the device
	is from North America, the home and visited emergency dialstring is		is from North America, the home and visited emergency dialstring is
	"9-1-1". If that devices roams to the UK, the home emergency		"9-1-1". If that devices roams to the UK, the home emergency
	dialstring is still "9-1-1", but the visited emergency dialstring		dialstring is still "9-1-1", but the visited emergency dialstring
	would become "9-9-9". If the device roams to Paris, the home		would become "9-9-9". If the device roams to Paris, the home
	dialstring remains the same, "9-1-1", but the visited dialstring		dialstring remains the same, "9-1-1", but the visited dialstring
	changes from 999 to "1-1-2".		changes from 999 to "1-1-2".
	The home emergency dialstrings MAY be provisioned into the device (or		The home emergency dialstrings MAY be provisioned into the device (or
	other element doing dialstring to universal emergency call URN		other element doing dialstring to universal emergency call URN
	mapping). [I-D.ietf-ecrit-lost]) provides dialstrings for a given		mapping). [I-D.ietf-ecrit-lost]) provides dialstrings for a given
	location and SHOULD be used by devices to learn the local (i.e.		location and SHOULD be used by devices to learn the local (i.e.
	"visited" dialstrings.		"visited" dialstrings. "Home" dialstrings MAY be learned by
			configuration.
	6. Session Signaling		6. Session Signaling
	SIP signaling [RFC3261] is expected be supported by upgraded PSAPs.		SIP signaling [RFC3261] is expected be supported by upgraded PSAPs.
	Gateways MAY be used between Internet connected devices and older		Gateways MAY be used between Internet connected devices and older
	PSAPs. Some countries may support other signaling protocols into		PSAPs. Some countries may support other signaling protocols into
	PSAPs.		PSAPs.
	6.1. SIP signaling requirements for User Agents		6.1. SIP signaling requirements for User Agents
	The initial signaling Method is INVITE.		The initial SIP signaling Method is an INVITE.
	1. The Request URI SHOULD be a PSAP URI obtained from LoST (see		1. The Request URI SHOULD be a PSAP URI obtained from LoST (see
	Section 6.2). If the device cannot access a LoST server, the		Section 6.3). If the device cannot access a LoST server, the
	To: SHOULD be a service URN in the "sos" tree. If the device		To: SHOULD be a service URN in the "sos" tree. If the device
	cannot do local dialstring interpretation, the Request URI:		cannot do local dialstring interpretation, the Request-URI
	SHOULD be a dialstring URI [I-D.rosen-iptel-dialstring]with the		SHOULD be a dialstring URI [I-D.rosen-iptel-dialstring]with the
	dialed digits. sips MUST be specified, unless the operation must		dialed digits. A sips URI [RFC3261] MUST be specified, unless
	be retried due to a failure to establish a TLS connection.		the operation must be retried due to a failure to establish a
			TLS connection.
	2. The To: header MUST be present and SHOULD be a service URN in		2. The To: header MUST be present and SHOULD be a service URN in
	the "sos" tree. If the device cannot do local dialstring		the "sos" tree. If the device cannot do local dialstring
	interpretation, the To: SHOULD be a dialstring URI with the		interpretation, the To: SHOULD be a dialstring URI with the
	dialed digits. sips MUST be specified, unless the operation must		dialed digits. sips MUST be specified, unless the operation must
	be retried due to a failure to establish a TLS connection.		be retried due to a failure to establish a TLS connection.
	3. The From: header MUST be present and SHOULD be the AoR of the		3. The From: header MUST be present and SHOULD be the AoR of the
	caller.		caller.
	NOTE: unintialized devices may not have an AoR available		NOTE: unintialized devices may not have an AoR available
	4. A Via: header MUST be present and SHOULD include the URI of the		4. A Via: header MUST be present and SHOULD include the URI of the
	device		device
	5. A Route header SHOULD be present with the service URN in the		5. A Route header SHOULD be present with the service URN in the
	"sos" tree, and the loose route parameter.		"sos" tree, and the loose route parameter.
	6. Either a P-Asserted-Identity [RFC3325] or an Identity header		6. Either a P-Asserted-Identity [RFC3325] or an Identity header
	[RFC4474], or both, SHOULD be included to identify the sender.		[RFC4474], or both, SHOULD be included to identify the sender.
	7. A Contact header MUST be present (which might contain a GRUU		7. A Contact header MUST be present (which might contain a GRUU
	[I-D.ietf-sip-gruu]) to permit an immediate call-back to the		[I-D.ietf-sip-gruu]) to permit an immediate call-back to the
	specific device which placed the emergency call.		specific device which placed the emergency call.
	8. Other headers MAY be included as per normal sip behavior		8. Other headers MAY be included as per normal sip behavior
	9. A Supported: header MUST be included with the 'geolocation'		9. A Supported: header MUST be included with the 'geolocation'
	option tag[I-D.ietf-sip-location-conveyance], unless the device		option tag [I-D.ietf-sip-location-conveyance], unless the device
	does not understand the concept of SIP Location ;		does not understand the concept of SIP Location.
	10. If the device's location is by-reference, a Geolocation:
	header[I-D.ietf-sip-location-conveyance] MUST be present		10. If the device's location is by-reference, a Geolocation: header
	containing the URI of the PIDF-LO reference for that device;		[I-D.ietf-sip-location-conveyance] MUST be present containing
			the URI of the PIDF-LO reference for that device. Whichever
			location is used for routing the message towards the PSAP or
			ESRP, even if there is only one, the Geolocation "message-
			routed-on-this-uri" header parameter SHOULD be added to the
			corresponding URI in the Geolocation header.
	11. if a device understands the SIP Location Conveyance		11. if a device understands the SIP Location Conveyance
	[I-D.ietf-sip-location-conveyance] extension and has its		[I-D.ietf-sip-location-conveyance] extension and has its
	location available, it MUST include location either by-value or		location available, it MUST include location either by-value or
	by-reference. If it is by-value, the INVITE contains a		by-reference. If it is by-value, the INVITE contains a
	Supported header with a "geolocation" option tag, and a "cidURL"		Supported header with a "geolocation" option tag, and a "cid-
	[RFC2396]as the value in the Geolocation header, indicating		URL" [RFC2396] as the value in the Geolocation header,
	which message body part contains the PIDF-LO. If the INVITE		indicating which message body part contains the PIDF-LO. If the
	contains a location by-reference, it includes the same Supported		INVITE contains a location by-reference, it includes the same
	header with the "geolocation" option tag, and includes the URI		Supported header with the "geolocation" option tag, and includes
	of the PIDF-LO on a remote node in a Geolocation header.		the URI of the PIDF-LO on a remote node in a Geolocation header.
	[I-D.ietf-geopriv-pdif-lo-profile] MUST be used		[I-D.ietf-geopriv-pdif-lo-profile] MUST be used
	12. If a device understand the SIP Location Conveyance extension and		12. If a device understands the SIP Location Conveyance extension
	has its location unavailable or unknown to that device, it MUST		and has its location unavailable or unknown to that device, it
	include a Supported header with a "geolocation" option tag, and		MUST include a Supported header with a "geolocation" option tag,
	not include a Geoocation header, and not include a PIDF-LO		and not include a Geolocation header, and not include a PIDF-LO
	message body.;		message body.
	13. A normal SDP offer SHOULD be included in the INVITE. The offer		13. A normal SDP offer SHOULD be included in the INVITE. The offer
	SHOULD NOT include compressed audio codecs, although a wideband		MUST include the G.711 codec, see Section 8.
	codec offer MAY be included.		14. If the device includes location-by-value, the UA MUST support
			multipart message bodies, since SDP will likely be also in the
			INVITE.
			15. A UAC SHOULD include the Geolocation "inserted-by=endpoint"
			header parameter. This informs downstream elements which device
			entered the location at this URI (either cid-URL or location-by-
			reference URI).
	Note: Silence suppression (Voice Activity Detection methods) MUST NOT		6.2. SIP signaling requirements for proxy servers and B2BUAs
	be used on emergency calls. PSAP call takers sometimes get
	information on what is happening in the background to determine how
	to process the call.
	6.2. Mapping from Location to a PSAP URI		SIP Proxy servers processing emergency calls:
			1. If the proxy does dial plan interpretation on behalf of user
			agents, the proxy MUST look for the local emergency dialstring at
			the location of the end device. If it finds it it MUST:
			* Obtain the location (or a reference to it) for the endpoint
			* Insert a Geolocation header as per 10-12 above
			* Include the Geolocation "inserted-by=server" AND "routed-by-
			this-uri" parameters.
			* Map the location to a PSAP uri using LoST.
			* Add a Route header with the service URN appropriate for the
			emergency dialstring.
			* Replace the Request-URI (which was the dialstring) with the
			PSAP URI obtained from LoST.
			* Route the call using normal SIP routing mechanisms.
			2. The "inserted-by=" header parameter MUST NOT be modified or
			deleted in transit.
			3. If a Geolocation "message-routed-on-this-uri" header parameter
			exists when a new SIP server processes a message, and the message
			is routing is now to be done based on another Geolocation URI
			(by-value or by-reference), the "message-routed-on-this-uri"
			header parameter MUST be removed from the old Geolocation URI and
			inserted with the now applicable location URI in the Geolocation
			header.
			6.3. Mapping from Location to a PSAP URI
	To route an emergency call, we make use of the [I-D.ietf-ecrit-lost]		To route an emergency call, we make use of the [I-D.ietf-ecrit-lost]
	mapping service which takes a location expressed by a PIDF-LO and		mapping service which takes a location expressed by a PIDF-LO and
	returns one or more PSAP URIs. The request includes the service URN		returns one or more PSAP URIs. The request includes the service URN
	which is used to determine which entity should receive the call.		which is used to determine which entity should receive the call.
	Ideally, mapping from location to the PSAP URI would be accomplished		Ideally, mapping from location to the PSAP URI would be accomplished
	at the time the emergency call is placed. However, it could be that		at the time the emergency call is placed. However, it could be that
	when the emergency occurs, the LoST server is unavailable to the		when the emergency occurs, the LoST server is unavailable to the
	caller, or busy. To guard against that, devices MUST cache a		caller, or busy. To guard against that, devices MUST cache a
	mapping. The mapping MUST be performed at boot time, and whenever		mapping. The mapping MUST be performed at boot time, and whenever
	skipping to change at page 10, line 21 ¶		skipping to change at page 11, line 42 ¶
	Devices where location changes SHOULD use this mechanism to maintain		Devices where location changes SHOULD use this mechanism to maintain
	a desired mapping.		a desired mapping.
	User agents that can obtain location information MUST perform the		User agents that can obtain location information MUST perform the
	mapping from location information to PSAP URI using		mapping from location information to PSAP URI using
	[I-D.ietf-ecrit-lost]. The mapping is performed whenever the UA		[I-D.ietf-ecrit-lost]. The mapping is performed whenever the UA
	acquires new location information that is outside the bounds of the		acquires new location information that is outside the bounds of the
	current PSAP coverage region specified in the LoST response or the		current PSAP coverage region specified in the LoST response or the
	time-to-live value of that response has expired.		time-to-live value of that response has expired.
			Determining when the device leaves the area provided by the LoST
			service can tax small mobile devices. For this reason, the LoST
			server SHOULD return a simple (small number of points) polygon for
			geo reported location. This can be an enclosing subset of the area
			when the reported point is not near an edge, or a smaller edge
			section when the reported location is near an edge. Civic location
			is uncommon for mobile devices, but reporting that the same mapping
			is good within a community name, or even a street, may be very
			helpful for WiFi connected devices that roam and obtain civic
			location from the AP they are connected to.
	All proxies in the outbound path SHOULD recognize emergency calls		All proxies in the outbound path SHOULD recognize emergency calls
	with a Request URI of the service URN in the "sos" tree. A proxy		with a Request URI of the service URN in the "sos" tree. A proxy
	recognizing such a call (which indicates that the endpoint understood		recognizing such a call (which indicates that the endpoint understood
	the call was an emergency call, but was unable to map its location to		the call was an emergency call, but was unable to map its location to
	a PSAP URI) MUST perform the LoST mapping and retarget the call to		a PSAP URI) MUST perform the LoST mapping and retarget the call to
	the PSAP URI (the service URN SHOULD remain as a Route header).		the PSAP URI (the service URN SHOULD remain as a Route header).
	To deal with old user agents that predate this specification and with		To deal with old user agents that predate this specification and with
	UAs that do not have access to their own location data, proxies that		UAs that do not have access to their own location data, proxies that
	recognize a call as an emergency call that is not marked as such (see		recognize a call as an emergency call that is not marked as such (see
	Section 5) or where the Request-URI is a service:sos URN MUST also		Section 5) or where the Request-URI is a service:sos URN MUST also
	perform this mapping, with the best location it has available for the		perform this mapping, with the best location it has available for the
	endpoint. The resulting PSAP URI would become the Request URI.		endpoint. The resulting PSAP URI would become the Request URI.
	6.3. Routing the call		6.4. Routing the call
	Normal routing mechanisms for the specified URI should be used. For		Normal routing mechanisms for the specified URI should be used. For
	SIP signaled devices, the domain of the URI should be extracted, and		SIP signaled devices, the domain of the URI should be extracted, and
	the DNS consulted for a sip (or sips) SRV. The resulting NAPTR, if		the DNS consulted for a sip (or sips) SRV. The resulting NAPTR, if
	present, should be used for the FQDN of the server.		present, should be used for the FQDN of the server.
	6.4. Responding to PSAP signaling		6.5. Responding to PSAP signaling
	The PSAP is expected to use normal signaling (e.g. SIP) as per IETF		The PSAP is expected to use normal signaling (e.g. SIP) as per IETF
	standards. Devices and proxies should expect to:		standards. Devices and proxies should expect to:
	1. Be REFERed to a conference bridge; PSAPs often include		1. Be REFERed to a conference bridge; PSAPs often include
	dispatchers, responders or specialists on a call.		dispatchers, responders or specialists on a call.
	2. Be REFERed to a secondary PSAP. Some responder's dispatchers are		2. Be REFERed to a secondary PSAP. Some responder's dispatchers are
	not located in the primary PSAP. The call may have to be		not located in the primary PSAP. The call may have to be
	transferred to another PSAP. Most often this will be an attended		transferred to another PSAP. Most often this will be an attended
	transfer, or a bridged transfer.		transfer, or a bridged transfer.
	3. (For devices that are Mobile) SUBSCRIBE to the Presence of the		3. (For devices that are Mobile) SUBSCRIBE to the Presence of the
	AoR (or equivalent for other signaling schemes) to get location		AoR (or equivalent for other signaling schemes) to get location
	updates.		updates.
	4. Support Session Timer (or equivalent) to guard against session		4. Support Session Timer (or equivalent) to guard against session
	corruption		corruption
	Devices with an active emergency call (i.e. SIP Dialog) MUST NOT		Devices with an active emergency call (i.e. SIP Dialog) MUST NOT
	generate a BYE request (or equivalent for other non-SIP signaling).		generate a BYE request (or equivalent for other non-SIP signaling).
	The PSAP must be the only entity that can terminate a call. If the		The PSAP must be the only entity that can terminate a call. If the
	user "hangs up" an emergency call, the device should ring, and when		user "hangs up" an emergency call, the device should ring, and when
	answered, reconnect the caller to the PSAP.		answered, reconnect the caller to the PSAP.
	There can be a case where the session signaling path is lost, and the		There can be a case where the session signaling path is lost, and the
	user agent does not receive the BYE. If the call is hung up, the		user agent does not receive the BYE. If the call is hung up, the
	session timer expires, and 5 minutes elapses from the last message		session timer expires, and 5 minutes elapses from the last message
	received by the device from the PSAP, the call may be declared lost.		received by the device from the PSAP, the call may be declared lost.
	If in the 5 minute interval an incoming call is received from the		If in the 5 minute interval an incoming call is received from the
	domain of the PSAP, the device should drop the old call and alert for		domain of the PSAP, the device should drop the old call and alert for
	the (new) incoming call.		the (new) incoming call.
	6.5. Disabling of features		6.6. Disabling of features
	The calling device and/or service SHOULD disable outgoing call		The calling device and/or service SHOULD disable outgoing call
	features such as:		features such as:
	o Call Waiting		o Call Waiting
	o Call Transfer		o Call Transfer
	o Three Way Call		o Three Way Call
	o Flash hold		o Flash hold
	o Outbound Call Blocking		o Outbound Call Blocking
	The emergency dialstrings SHOULD NOT be permitted in Call Forward		The emergency dialstrings SHOULD NOT be permitted in Call Forward
	numbers or speed dial lists.		numbers or speed dial lists.
	The device and/or service SHOULD disable the following incoming call		The device and/or service SHOULD disable the following incoming call
	features on calls from the PSAP:		features on calls from the PSAP:
	o Call Waiting (all kinds)		o Call Waiting (all kinds)
	o Do Not Disturb		o Do Not Disturb
	o Call Forward (all kinds) (if the PSAP calls back within some		o Call Forward (all kinds) (if the PSAP calls back within some
	(30min?) interval)		(30min) interval)
	7. Testing		7. Location Update
	7.1. Testing Mechanism		Devices which are mobile may not be able to report an accurate
			location when an emergency call is placed. Some deployments of
			location measurement are not always on, and when an emergency call is
			initiated, the time to get an accurate "first fix" may be several
			seconds. That is too long to wait to begin processing of the call.
			In such cases, a fast fix, or the location of a tower serving a
			wireless mobile device may be used to route the call, with accurate
			location coming later on, after the call is answered. It is possible
			that the PSAP that should handle the call once the accurate location
			is available is different from the PSAP serving the tower or the
			first fix location.
			Mobile devices may be moving while an emergency call is in progress.
			The PSAPs, and/or the responders may change as the location changes.
			For these reasons, and others, update of location is needed.
			Generally, updates should occur after the call is completed. The
			PSAP controls location update. For calls sent with location-by-
			value, the PSAP MAY reINVITE the endpoint and the 200 OK from the
			endpoint MUST include the location. For calls send with location-by-
			reference, with a SIP or SIPS scheme, the server resolving the
			reference MUST support a SUBSCRIBE [RFC3118] to the presence event
			[RFC3856]. For other location-by-reference schemes, a repeated
			location dereference by the PSAP MUST be supported.
			8. Media
			Endpoints MUST send and receive media streams on RTP [RFC3550].
			Traditionally, voice has been the only media stream accepted by
			PSAPs. In some countries, text, in the form of BAUDOT codes or
			similar tone encoded signaling within a voiceband is accepted ("TTY")
			for persons who have hearing disabilities. With the Internet comes a
			wider array of potential media which a PSAP should accept. Using SIP
			signaling includes the capability to negotiate media. Normal SIP
			offer/answer [RFC3264] negotiations MUST be used to agree on the
			media streams to be used.
			Endpoints supporting voice MUST support G.711 A law (and mu Law in
			North America) encoded voice as described in [RFC3551]. It is
			desirable to support wideband codecs in the offer Silence suppression
			(Voice Activity Detection methods) MUST NOT be used on emergency
			calls. PSAP call takers sometimes get information on what is
			happening in the background to determine how to process the call.
			Newer text forms are rapidly appearing, with Instant Messaging now
			very common, endpoints supporting IM MUST support either [RFC3428] or
			[RFC3920]. Endpoints supporting real-time text MUST use [RFC4103].
			The expectations for emergency service support for the real-time text
			medium, described in [I-D.ietf-sipping-toip], section 7.1 SHOULD be
			fulfilled.
			Video may be important to support Video Relay Service (Sign language
			interpretation) as well as modern video phones. Endpoints supporting
			video MUST support H.264 per [RFC3984].
			9. Testing
			9.1. Testing Mechanism
	INVITE requests to a service urn with a urn parameter of "test"		INVITE requests to a service urn with a urn parameter of "test"
	indicates a request for an automated test. For example,		indicates a request for an automated test. For example,
	"urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response		"urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response
	indicates that the address was recognized and a 404 (Not found) that		indicates that the address was recognized and a 404 (Not found) that
	it was not. A 486 (Busy Here) should be returned if the test service		it was not. A 486 (Busy Here) MUST be returned if the test service
	is busy, and a 488 (Not Acceptable Here) should be returned if the		is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP
	PSAP does not support the test mechanism.		does not support the test mechanism.
	In its response to the test, the PSAP MAY include a text body		In its response to the test, the PSAP MAY include a text body
	indicating the identity of the PSAP, the requested service, and the		indicating the identity of the PSAP, the requested service, and the
	location reported with the call. For the latter, the PSAP SHOULD		location reported with the call. For the latter, the PSAP SHOULD
	return location-by-value even if the original location delivered with		return location-by-value even if the original location delivered with
	the test was by-reference.		the test was by-reference.
	A PSAP accepting a test call SHOULD accept a media loopback		A PSAP accepting a test call SHOULD accept a media loopback
	test[I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-pkt-		test[I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-pkt-
	loopback" and "rtp-start-loopback" options. The user agent would		loopback" and "rtp-start-loopback" options. The user agent would
	skipping to change at page 12, line 35 ¶		skipping to change at page 15, line 29 ¶
	After an initial IP address assignment test, a full test SHOULD be		After an initial IP address assignment test, a full test SHOULD be
	repeated approximately every 30 days with a random interval.		repeated approximately every 30 days with a random interval.
	User agents MUST NOT place a test call immediately after booting, as		User agents MUST NOT place a test call immediately after booting, as
	a widespread power outage and subsequent restoration would impose an		a widespread power outage and subsequent restoration would impose an
	inordinate load on the emergency call routing system.		inordinate load on the emergency call routing system.
	PSAPs MAY refuse repeated requests for test from the same device in a		PSAPs MAY refuse repeated requests for test from the same device in a
	short period of time.		short period of time.
	8. Security Considerations		10. Security Considerations
	There are no new security considerations beyond those in the		There are no new security considerations beyond those in the
	normative references. This memo does not introduce any new		normative references. This memo does not introduce any new
	protocols; it specifies use of several of them. Implementers are		protocols; it specifies use of several of them.
	admonished to ,,,
	9. Normative References		10.1. Threats against endpoints
			The largest threat against the endpoint is inadvertent disclosure of
			its location. The endpoint acquires location from a Location
			Configuration Protocol. Some of the protocols are very limited as to
			the scope which messages within the protocol are distributed. DHCP
			for example is limited to the local subnet. LLDP is limited to the
			link. The [L7 LCP] is not limited and TLS SHOULD be used to protect
			location privacy.
			The location configuration server could be spoofed, thus providing
			wrong location, and misdirecting help when an emergency call is
			placed. When DHCP is the LCP [RFC3118] SHOULD be used to prevent
			spoofing if possible. LLDP server spoofing would be limited to
			devices connected to the link and is not seen as a credible threat.
			Deployments should limit hubs and downstream switches to IP connected
			devices that could be used to place emergency calls. [L7 LCP] SHOULD
			use DIGEST authentication (or better) to identify the LIS.
			The LoST server, which is the source of Location to PSAP URI mapping,
			and local dialstrings, could be spoofed. Use of DHCP to obtain the
			location of the server limits the ability to misdirect the user.
			LoST protocol use SHOULD include TLS with server certs to prevent
			spoofing.
			The PSAP could be spoofed. Client SHOULD use TLS with server certs
			to prevent spoofing.
			10.2. Threats against the Emergency Service
			The largest threats to the Emergency Service are forgery of location
			and denial of service attacks on the PSAP and/or ESRP.
			To mitigate forgery of location, location object SHOULD be signed.
			Since access networks and PSAPs are usually local to each other,
			providing a PKI should not be onerous for many residential
			deployments. However, enterprises may deploy access networks with
			location, which is to be encouraged. PKI covering all enterprises
			within a PSAP service area may be much more problematic.
			To mitigate denial of service attacks, endpoint SHOULD use TLS (which
			implies TCP) in the signaling towards the LoST server and the PSAP/
			ESRP. Return routability of signaling would help significantly. Use
			of P-Asserted-Identity or SIP Identity is also REQUIRED of calling
			networks.
			11. Normative References
			[I-D.ietf-ecrit-framework]
			Rosen, B., "Framework for Emergency Calling in Internet
			Multimedia", draft-ietf-ecrit-framework-00 (work in
			progress), October 2006.
	[I-D.ietf-ecrit-lost]		[I-D.ietf-ecrit-lost]
	Hardie, T., "LoST: A Location-to-Service Translation		Hardie, T., "LoST: A Location-to-Service Translation
	Protocol", draft-ietf-ecrit-lost-01 (work in progress),		Protocol", draft-ietf-ecrit-lost-04 (work in progress),
	September 2006.		February 2007.
			[I-D.ietf-ecrit-service-urn]
			Schulzrinne, H., "A Uniform Resource Name (URN) for
			Services", draft-ietf-ecrit-service-urn-05 (work in
			progress), August 2006.
	[I-D.ietf-geopriv-pdif-lo-profile]		[I-D.ietf-geopriv-pdif-lo-profile]
	Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,		Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
	Considerations and Recommendations",		Considerations and Recommendations",
	draft-ietf-geopriv-pdif-lo-profile-04 (work in progress),		draft-ietf-geopriv-pdif-lo-profile-05 (work in progress),
	May 2006.		October 2006.
	[I-D.ietf-mmusic-media-loopback]		[I-D.ietf-mmusic-media-loopback]
	Hedayat, K., "An Extension to the Session Description		Hedayat, K., "An Extension to the Session Description
	Protocol (SDP) for Media Loopback",		Protocol (SDP) for Media Loopback",
	draft-ietf-mmusic-media-loopback-05 (work in progress),		draft-ietf-mmusic-media-loopback-05 (work in progress),
	September 2006.		September 2006.
	[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-10 (work in progress),		(SIP)", draft-ietf-sip-gruu-11 (work in progress),
	August 2006.		October 2006.
	[I-D.ietf-sip-location-conveyance]		[I-D.ietf-sip-location-conveyance]
	Polk, J. and B. Rosen, "Session Initiation Protocol		Polk, J. and B. Rosen, "Session Initiation Protocol
	Location Conveyance",		Location Conveyance",
	draft-ietf-sip-location-conveyance-04 (work in progress),		draft-ietf-sip-location-conveyance-07 (work in progress),
	August 2006.		February 2007.
			[I-D.ietf-sipping-service-examples]
			Johnston, A., "Session Initiation Protocol Service
			Examples", draft-ietf-sipping-service-examples-12 (work in
			progress), January 2007.
	[I-D.ietf-sipping-toip]		[I-D.ietf-sipping-toip]
	Wijk, A. and G. Gybels, "Framework for real-time text over		Wijk, A. and G. Gybels, "Framework for real-time text over
	IP using the Session Initiation Protocol (SIP)",		IP using the Session Initiation Protocol (SIP)",
	draft-ietf-sipping-toip-07 (work in progress),		draft-ietf-sipping-toip-07 (work in progress),
	August 2006.		August 2006.
	[I-D.rosen-iptel-dialstring]		[I-D.rosen-iptel-dialstring]
	Rosen, B., "Dialstring parameter for the Session		Rosen, B., "Dialstring parameter for the Session
	Initiation Protocol Uniform Resource Identifier",		Initiation Protocol Uniform Resource Identifier",
	draft-rosen-iptel-dialstring-04 (work in progress),		draft-rosen-iptel-dialstring-05 (work in progress),
	June 2006.		March 2007.
	[I-D.schulzrinne-geopriv-dhcp-civil]
	Schulzrinne, H., "DHCP Option for Civil Location",
	draft-schulzrinne-geopriv-dhcp-civil-01 (work in
	progress), February 2003.
	[I-D.schulzrinne-sipping-service]
	Schulzrinne, H., "A Uniform Resource Name (URN) for
	Services", draft-schulzrinne-sipping-service-01 (work in
	progress), October 2005.
	[LLDP] "IEEE802.1ab Station and Media Access Control", Dec 2004.		[LLDP] IEEE, "IEEE 802.1AB-2005, Station and Media Access Control
			Connectivity Discovery (aka Link Layer Discovery Protocol
			- LLDP)", May 2004.
	[LLDP-MED]		[LLDP-MED]
	TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media		TIA, "ANSI/TIA-1057, Link Layer Discovery Protocol for
	Endpoint Discovery".		Media Endpoint Devices (aka LLDP-MED)", Apr 2006.
	[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.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
	RFC 2131, March 1997.		RFC 2131, March 1997.
	[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifiers (URI): Generic Syntax", RFC 2396,		Resource Identifiers (URI): Generic Syntax", RFC 2396,
	August 1998.		August 1998.
	[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",		[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
	RFC 3046, January 2001.		RFC 3046, January 2001.
			[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
			Messages", RFC 3118, June 2001.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
			[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
			with Session Description Protocol (SDP)", RFC 3264,
			June 2002.
	[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private		[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
	Extensions to the Session Initiation Protocol (SIP) for		Extensions to the Session Initiation Protocol (SIP) for
	Asserted Identity within Trusted Networks", RFC 3325,		Asserted Identity within Trusted Networks", RFC 3325,
	November 2002.		November 2002.
			[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
			and D. Gurle, "Session Initiation Protocol (SIP) Extension
			for Instant Messaging", RFC 3428, December 2002.
			[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
			Jacobson, "RTP: A Transport Protocol for Real-Time
			Applications", STD 64, RFC 3550, July 2003.
			[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
			Video Conferences with Minimal Control", STD 65, RFC 3551,
			July 2003.
	[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host		[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
	Configuration Protocol Option for Coordinate-based		Configuration Protocol Option for Coordinate-based
	Location Configuration Information", RFC 3825, July 2004.		Location Configuration Information", RFC 3825, July 2004.
			[RFC3856] Rosenberg, J., "A Presence Event Package for the Session
			Initiation Protocol (SIP)", RFC 3856, August 2004.
			[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
			Protocol (XMPP): Core", RFC 3920, October 2004.
			[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,
			M., and D. Singer, "RTP Payload Format for H.264 Video",
			RFC 3984, February 2005.
	[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text		[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
	Conversation", RFC 4103, June 2005.		Conversation", RFC 4103, June 2005.
	[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object		[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, December 2005.		Format", RFC 4119, December 2005.
	[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for		[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
	Supporting Emergency Telecommunications Service (ETS) in		Supporting Emergency Telecommunications Service (ETS) in
	IP Telephony", RFC 4190, November 2005.		IP Telephony", RFC 4190, November 2005.
	[RFC4474] Peterson, J. and C. Jennings, "Enhancements for		[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	Authenticated Identity Management in the Session		Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474, August 2006.		Initiation Protocol (SIP)", RFC 4474, August 2006.
	[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony		[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony
	Device Requirements and Configuration", RFC 4504,		Device Requirements and Configuration", RFC 4504,
	May 2006.		May 2006.
	[framework]		[RFC4676] Schulzrinne, H., "Dynamic Host Configuration Protocol
	Rosen, B., Polk, J., Schulzrinne, H., and A. Newton,		(DHCPv4 and DHCPv6) Option for Civic Addresses
	"Framework for Emergency Calling in Internet Multimedia",		Configuration Information", RFC 4676, October 2006.
	October 2006.
	Authors' Addresses		Authors' Addresses
	Brian Rosen		Brian Rosen
	NeuStar		NeuStar
	470 Conrad Dr.		470 Conrad Dr.
	Mars, PA 16046		Mars, PA 16046
	US		US
	Phone: +1 724 382 1051		Phone: +1 724 382 1051
	skipping to change at page 15, line 20 ¶		skipping to change at page 20, line 4 ¶
	Authors' Addresses		Authors' Addresses
	Brian Rosen		Brian Rosen
	NeuStar		NeuStar
	470 Conrad Dr.		470 Conrad Dr.
	Mars, PA 16046		Mars, PA 16046
	US		US
	Phone: +1 724 382 1051		Phone: +1 724 382 1051
	Email: br@brianrosen.net		Email: br@brianrosen.net
	James M. Polk		James M. Polk
	Cisco Systems		Cisco Systems
	3913 Treemont Circle		3913 Treemont Circle
	Colleyville, TX 76034		Colleyville, TX 76034
	US		US
	Phone: +1-817-271-3552		Phone: +1-817-271-3552
	Email: jmpolk@cisco.com		Email: jmpolk@cisco.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 66 change blocks.
	155 lines changed or deleted		386 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/