< draft-rosen-ecrit-ecall-08.txt		draft-rosen-ecrit-ecall-09.txt >
	ECRIT B. Rosen		ECRIT B. Rosen
	Internet-Draft NeuStar, Inc.		Internet-Draft NeuStar, Inc.
	Intended status: Standards Track H. Tschofenig		Intended status: Informational H. Tschofenig
	Expires: August 29, 2013 Nokia Siemens Networks		Expires: January 14, 2014 Nokia Siemens Networks
	R. Gellens		R. Gellens
	QUALCOMM Incorporated		QUALCOMM Incorporated
	February 25, 2013		July 13, 2013
	Internet Protocol-based In-Vehicle Emergency Call		Internet Protocol-based In-Vehicle Emergency Call
	draft-rosen-ecrit-ecall-08.txt		draft-rosen-ecrit-ecall-09.txt
	Abstract		Abstract
	This document describes how to re-use the emergency services		This document describes how to re-use the emergency services
	mechanisms specified for the Session Initiation Protocol (SIP) to		mechanisms specified for the Session Initiation Protocol (SIP) to
	accomplishing emergency calling support in vehicles. Profiling and		accomplishing emergency calling support in vehicles. Profiling and
	simplifications are possible due to the nature of the functionality		simplifications are possible due to the nature of the functionality
	that is going to be provided in vehicles with the usage of Global		that is going to be provided in vehicles with the usage of Global
	Positioning System (GPS).		Positioning System (GPS).
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted 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). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on August 29, 2013.		This Internet-Draft will expire on January 14, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Overview of Current Deployment Models . . . . . . . . . . 3
	3. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Migration to IP-based Models . . . . . . . . . . . . . . 4
	4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		3. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		6.1. Service URN Registration . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 12		6.2. MIME Content-type Registration for
	9.2. Informative references . . . . . . . . . . . . . . . . . . 12		'application/emergencyCall.VEDS+xml' . . . . . . . . . . 9
			6.3. Registration of the 'VEDS' entry in the Emergency Call
			Additional Data registry . . . . . . . . . . . . . . . . 10
			7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
			8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
			9.1. Normative References . . . . . . . . . . . . . . . . . . 10
			9.2. Informative references . . . . . . . . . . . . . . . . . 11
	Appendix A. Matching Functionality with eCall Minimum Set of		Appendix A. Matching Functionality with eCall Minimum Set of
	Data (MSD) . . . . . . . . . . . . . . . . . . . . . 14		Data (MSD) . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	Emergency calls made from vehicles can assist with the objective of		Emergency calls made from vehicles can assist with the objective of
	significantly reducing road deaths and injuries. Unfortunately,		significantly reducing road deaths and injuries. Unfortunately,
	drivers often have a poor location-awareness, especially on urban		drivers often have a poor location-awareness, especially on urban
	roads (also during night) and abroad. In the most crucial cases, the		roads (also during night) and abroad. In the most crucial cases, the
	victim(s) may not be able to call because they have been injured or		victim(s) may not be able to call because they have been injured or
	trapped.		trapped.
	In Europe the European Commission has launched the 'eCall' initiative		In Europe the European Commission has launched the 'eCall' initiative
	that may best be described as a user initiated or automatically		that may best be described as a user-initiated or automatically
	triggered system to provide notifications to Public Safety Answering		triggered system to provide notifications to Public Safety Answering
	Point's (PSAP), by means of cellular communications, that a vehicle		Point's (PSAP), by means of cellular communications, that a vehicle
	has crashed, and to provide geodetic location information and where		has crashed, and to provide geodetic location information and where
	possible a voice channel to the PSAP. At the time of writing the		possible a voice channel to the PSAP.
	support for eCall is focused on legacy mobile circuit switched voice
	technology. This document details how the same functionality (and
	even more) can be accomplished using Internet protocols and SIP. The
	goal is to re-use existing specifications in the area of SIP-based
	emergency calling.
	This document is organized as follows: Section 2 defines the		This document registers the 'application/emergencyCall.VEDS+xml' MIME
	terminology, Section 3 describes how the required functionality can		content-type, and registers the 'VEDS' entry in the Emergency Call
	be accomplished by combining several already existing standards, and		Additional Data registry.
	Section 4 shows an example message exchange. This document concludes
	with the security considerations in Section 5 and IANA considerations		The Vehicle Emergency Data Set (VEDS) is an XML structure defined by
	in Section 6. Appendix A illustrates how to map the functionality in		the Association of Public-Safety Communications Officials (APCO) and
	this document to the eCall Minimum Set of Data (MSD) specified for		the National Emergency Number Association (NENA). The 'application/
	mobile circuit switched voice.		emergencyCall.VEDS+xml' MIME content-type is used to identify it.
			The 'VEDS' entry in the Emergency Call Additional Data registry is
			used to construct a 'purpose' parameter value for conveying VEDS data
			in a Call-Info header.
			Circuit-switched eCall systems transmit crash data as a defined set,
			the Minimum Set of Data (MSD) [15]. The MSD for circuit-switched
			eCall is a binary format defined by CEN, the European Committee for
			Standardization. It is expected that CEN will choose to define the
			XML schema for the eCall MSD for use in next-generation systems.
			Once this done, a MIME content-type (e.g., 'application/
			emergencyCall.eCall.MSD+xml') and Emergency Call Additional Data
			entry (e.g., 'eCall.MSD') need to be registered for the MSD. Note
			that Appendix A explains how the functionality available in IETF
			specifications maps to the functionality required for the MSD of the
			mobile circuit switched voice solution.
			CEN and/or other entities may define additional sets of data in the
			same manor: a standardized format, such as XML, is defined, and a
			MIME content-type and Emergency Call Additional Data entry
			registered.
			An In-Vehicle System (IVS) transmits crash data by encoding it in one
			of the standardized and registered formats (such as VEDS or
			eCall.MSD) and attaching it to an INVITE as a data block. The block
			is identified by its MIME content-type, and pointed to by a CID URL
			in a Call-Info header with a 'purpose' parameter value corresponding
			to the block.
			1.1. Overview of Current Deployment Models
			Current (circuit-switched or legacy) systems for placing emergency
			calls from vehicles, including automatic crash notification system,
			generally use one of three architectural models: Telematics Service
			Provider (TSP), direct, and paired handset. These three models are
			illustrated below.
			In the TSP model the IVS transmits crash data to the TSP using
			proprietary means. The TSP operator bridges in the PSAP and
			communicates location, crash, and other data to the call taker
			verbally (there is a three-way voice call between the vehicle, the
			TSP, and the PSAP).
			///----\\\ proprietary +------+ 911 trunk +------+
			||| IVS |||-------------->+ TSP +------------------>+ PSAP |
			\\\----/// crash data +------+ +------+
			Figure 1: TSP Model.
			In the paired model the IVS uses a Bluetooth link to a previously-
			paired handset to establish an emergency call with the PSAP and then
			communicates location data to the PSAP via text-to-speech; crash data
			is not conveyed.
			++
			///----\\\ || 911 voice call via handset +------+
			||| IVS |||--->|+----------------------------------->+ PSAP |
			\\\----/// ++ +------+
			Figure 2: Paired Model
			In the direct model the IVS communicates crash data to the PSAP via
			the eCall in-band modem (in the voice call).
			///----\\\ 112/911 voice call via IVS +------+
			||| IVS |||---------------------------------------->+ PSAP |
			\\\----/// crash data via eCall in-band modem +------+
			Figure 3: Direct Model
			1.2. Migration to IP-based Models
			The migration to next-generation (all-IP) would then look like as
			follows.
			In the TSP model The IVS transmits crash data to the TSP using either
			proprietary or standard means. The TSP bridges in the PSAP and
			transmits crash and other data to the PSAP using IETF specifications.
			There is a three-way call between the vehicle, the TSP, and the PSAP.
			proprietary
			///----\\\ or standard +------+ standard +------+
			IVS ------------->+ TSP +------------------->+ PSAP |
			\\\----/// crash data +------+ crash + other data +------+
			Figure 4: TSP Model
			In the paired model, the IVS uses a Bluetooth link to a previously-
			paired handset to establish an emergency call with the PSAP; it is
			not clear what facilities are or will be available for transmitting
			crash data.
			++
			///----\\\ || IP-based Emergency Call +------+
			IVS --->|+----------------------------------->+ PSAP |
			\\\----/// ++ +------+
			Figure 5: Paired Model
			In the direct model the IVS communicates crash data to PSAP using
			Internet protocols.
			///----\\\ IP-based Emergency Call via IVS +------+
			IVS ----------------------------------------->+ PSAP |
			\\\----/// +------+
			Figure 6: Direct Model
			This document is focused on the interface to the PSAP, that is, how
			an emergency call (including location and crash data) is setup and
			data is transmitted to the PSAP using existing IETF specifications.
			The goal is to re-use existing specifications rather than to invent
			new. For the direct model (such as the European eCall), this is the
			end-to-end description. For the TSP model, this describes the right-
			hand side, leaving the left-hand side up to the entities involved
			(e.g., IVS and TSP vendors) who are then free to use the same
			mechanism as for the right-hand side or not.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [1].		document are to be interpreted as described in [1].
	This document re-uses terminology defined in Section 3 of [9].		This document re-uses terminology defined in Section 3 of [11].
			Additionally, we use the following abbreviations:
			IVS: In-Vehicle System
			TSP: Telematics Service Provider
			MSD: Minimum Set of Data
			VEDS: Vehicle Emergency Data Set
			NENA: National Emergency Number Association
			APCO: Association of Public-Safety Communications Officials
			CEN: European Committee for Standardization
	3. Profile		3. Profile
	In the context of emergncy calls placed from a vehicle it is assumed		In the context of emergncy calls placed from a vehicle it is assumed
	that the car is equipped with a built-in GPS receiver. For this		that the car is equipped with a built-in GPS receiver. For this
	reason only geodetic location information will be sent within an		reason only geodetic location information will be sent within an
	emergency call. The following location shapes MUST be implemented:		emergency call. The following location shapes MUST be implemented:
	2d and 3d Point (see Section 5.2.1 of [2]), Circle (see Section 5.2.3		2d and 3d Point (see Section 5.2.1 of [3]), Circle (see Section 5.2.3
	of [2]), and Ellipsoid (see Section 5.2.7 of [2]). The coordinate		of [3]), and Ellipsoid (see Section 5.2.7 of [3]). The coordinate
	reference systems (CRS) specified in [2] are also mandatory for this		reference systems (CRS) specified in [3] are also mandatory for this
	document. The <direction> element, as defined in [3] which indicates		document. The <direction> element, as defined in [6] which indicates
	the direction of travel of the vehicle, is important for dispatch and		the direction of travel of the vehicle, is important for dispatch and
	hence it MUST be included in the PIDF-LO . The <heading> element		hence it MUST be included in the PIDF-LO . The <heading> element
	specified in [3] MUST be implemented and MAY be included.		specified in [6] MUST be implemented and MAY be included.
	This specification also inherits the ability to utilize test call		This specification also inherits the ability to utilize test call
	functionality from Section 15 of [4].		functionality from Section 15 of [4].
	4. Example		4. Example
	Figure 1 shows an emergency call placed from a vehicle whereby		Figure 7 shows an emergency call placed from a vehicle whereby
	location information information is directly attached to the SIP		location information information is directly attached to the SIP
	INVITE message itself. The call is marked as an emergency call using		INVITE message itself. The call is marked as an emergency call using
	the 'urn:service:sos.ecall.automatic' service URN and the PSAP of the		the 'urn:service:sos.ecall.automatic' service URN and the PSAP of the
	VoIP provider determines which PSAP to contact based on the provided		VoIP provider determines which PSAP to contact based on the provided
	location information. The emergency call continues towards the PSAP		location information. The emergency call continues towards the PSAP
	and in this example it hits the ESRP, as the entry point to the PSAP		and in this example it hits the ESRP, as the entry point to the PSAP
	operators emergency services network. Finally, the emergency call		operators emergency services network. Finally, the emergency call
	will be received by a call taker and first reponders will be		will be received by a call taker and first reponders will be
	dispatched.		dispatched.
	+--------+		+--------+
	| LoST |		| LoST |
	| Server |		| Server |
	+--------+		+--------+
	^ +-------+		^ +-------+
	| | PSAP2 |		| | PSAP2 |
	| +-------+		| +-------+
	v		v
	+-------+ +------+ +-------+		+-------+ +------+ +-------+
	Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker		Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker
	+-------+ +------+ +-------+		+-------+ +------+ +-------+
	+-------+		+-------+
	| PSAP3 |		| PSAP3 |
	+-------+		+-------+
	Figure 1: Example of In-Vehicular Emergency Call Message Flow		Figure 7: Example of In-Vehicular Emergency Call Message Flow
	The example, shown in Figure 2, illustrates a SIP INVITE and location		The example, shown in Figure 8, illustrates a SIP INVITE and location
	information encoded in a PIDF-LO that is being conveyed in such an		information encoded in a PIDF-LO that is being conveyed in such an
	emergency call.		emergency call.
	INVITE urn:service:sos.ecall.automatic SIP/2.0		INVITE urn:service:sos.ecall.automatic SIP/2.0
	To: urn:service:sos.ecall.automatic		To: urn:service:sos.ecall.automatic
	From: <sip:+13145551111@example.com>;tag=9fxced76sl		From: <sip:+13145551111@example.com>;tag=9fxced76sl
	Call-ID: 3848276298220188511@atlanta.example.com		Call-ID: 3848276298220188511@atlanta.example.com
	Geolocation: <cid:target123@example.com>		Geolocation: <cid:target123@example.com>
	Geolocation-Routing: no		Geolocation-Routing: no
	Accept: application/sdp, application/pidf+xml		Accept: application/sdp, application/pidf+xml
	skipping to change at page 7, line 32 ¶		skipping to change at page 8, line 16 ¶
	xmlns:gs="http://www.opengis.net/pidflo/1.0"		xmlns:gs="http://www.opengis.net/pidflo/1.0"
	entity="sip:+13145551111@example.com">		entity="sip:+13145551111@example.com">
	<dm:device id="123">		<dm:device id="123">
	<gp:geopriv>		<gp:geopriv>
	<gp:location-info>		<gp:location-info>
	<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">		<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
	<gml:pos>-34.407 150.883</gml:pos>		<gml:pos>-34.407 150.883</gml:pos>
	</gml:Point>		</gml:Point>
	<dyn:Dynamic>		<dyn:Dynamic>
	<dyn:heading>278</dyn:heading>		<dyn:heading>278</dyn:heading>
	<dyn:direction><dyn:direction>		<dyn:direction><dyn:direction>
	</dyn:Dynamic>		</dyn:Dynamic>
	</gp:location-info>		</gp:location-info>
	<gp:usage-rules/>		<gp:usage-rules/>
	<method>gps</method>		<method>gps</method>
	</gp:geopriv>		</gp:geopriv>
	<timestamp>2012-04-5T10:18:29Z</timestamp>		<timestamp>2012-04-5T10:18:29Z</timestamp>
	<dm:deviceID>1M8GDM9A_KP042788</dm:deviceID>		<dm:deviceID>1M8GDM9A_KP042788</dm:deviceID>
	</dm:device>		</dm:device>
	</presence>		</presence>
	--boundary1--		--boundary1--
	Figure 2: SIP INVITE indicating an In-Vehicular Emergency Call		Figure 8: SIP INVITE indicating an In-Vehicular Emergency Call
	5. Security Considerations		5. Security Considerations
	This document does not raise security considerations beyond those		This document does not raise security considerations beyond those
	described in [10]. As with emergency service systems with end host		described in [12]. As with emergency service systems with end host
	provided location information there is the possibility that that		provided location information there is the possibility that that
	location is incorrect, either intentially (in case of an a denial of		location is incorrect, either intentially (in case of an a denial of
	service attack against the emergency services infrastructure) or due		service attack against the emergency services infrastructure) or due
	to a malfunctioning devices. The reader is referred to [11] for a		to a malfunctioning devices. The reader is referred to [13] for a
	discussion of some of these vulnerabilities.		discussion of some of these vulnerabilities.
	6. IANA Considerations		6. IANA Considerations
			6.1. Service URN Registration
	IANA is requested to register the URN 'urn:service:sos.ecall' under		IANA is requested to register the URN 'urn:service:sos.ecall' under
	the sub-services 'sos' registry defined in Section 4.2 of [5].		the sub-services 'sos' registry defined in Section 4.2 of [10].
	This service identifier reaches a public safety answering point		This service identifier reaches a public safety answering point
	(PSAP), which in turn dispatches aid appropriate to the emergency		(PSAP), which in turn dispatches aid appropriate to the emergency
	related to accidents of vehicles. Two sub-services are registered as		related to accidents of vehicles. Two sub-services are registered as
	well, namely		well, namely
	urn:service:sos.ecall.manual		urn:service:sos.ecall.manual
	This service URN indicates that an eCall had been triggered based		This service URN indicates that an eCall had been triggered based
	on the manual interaction of the driver or a passenger.		on the manual interaction of the driver or a passenger.
	urn:service:sos.ecall.automatic		urn:service:sos.ecall.automatic
	This service URN indicates that an eCall had been triggered		This service URN indicates that an eCall had been triggered
	automatically, for example, due to a crash. No human involvement		automatically, for example, due to a crash. No human involvement
	was detected.		was detected.
			6.2. MIME Content-type Registration for 'application/
			emergencyCall.VEDS+xml'
			This specification requests the registration of a new MIME type
			according to the procedures of RFC 4288 [8] and guidelines in RFC
			3023 [7].
			MIME media type name: application
			MIME subtype name: emergencyCall.VEDS+xml
			Mandatory parameters: none
			Optional parameters: charset Indicates the character encoding of
			enclosed XML.
			Encoding considerations: Uses XML, which can employ 8-bit
			characters, depending on the character encoding used. See
			Section 3.2 of RFC 3023 [7].
			Security considerations: This content type is designed to carry
			vehicle crash data during an emergency call. This data may
			contains personal information including vehicle VIN, location,
			direction, etc. appropriate precautions need to be taken to limit
			unauthorized access, inappropriate disclosure to third parties,
			and eavesdropping of this information. Please refer to Section 7
			and Section 8 of [9] for more information.
			Interoperability considerations: None
			Published specification: [TBD: This specification]
			Applications which use this media type: Emergency Services
			Additional information: None
			Magic Number: None
			File Extension: .xml
			Macintosh file type code: 'TEXT'
			Person and email address for further information: Hannes
			Tschofenig, Hannes.Tschofenig@gmx.net
			Intended usage: LIMITED USE
			Author: This specification is a work item of the IETF ECRIT
			working group, with mailing list address <ecrit@ietf.org>.
			Change controller: The IESG <ietf@ietf.org>
			6.3. Registration of the 'VEDS' entry in the Emergency Call Additional
			Data registry
			This specification requests IANA to add the 'VEDS' entry to the
			Emergency Call Additional Data registry, with a reference to this
			document. The Emergency Call Additional Data registry has been
			established with [9].
	7. Contributors		7. Contributors
	We would like to thank Ulrich Dietz for his help with earlier		We would like to thank Ulrich Dietz for his help with earlier
	versions of the document.		versions of the document.
	8. Acknowledgements		8. Acknowledgements
	We would like to thank Michael Montag, Arnoud van Wijk, Ban Al-Bakri,		We would like to thank Michael Montag, Arnoud van Wijk, Ban Al-Bakri,
	and Gunnar Hellstroem for their feedback.		and Gunnar Hellstroem for their feedback.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate
	Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[2] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV		[2] Peterson, J., "A Presence-based GEOPRIV Location Object
	Presence Information Data Format Location Object (PIDF-LO)		Format", RFC 4119, December 2005.
	Usage Clarification, Considerations, and Recommendations",
	RFC 5491, March 2009.
	[3] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson,		[3] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
	"Dynamic Extensions to the Presence Information Data Format		Presence Information Data Format Location Object (PIDF-LO)
	Location Object (PIDF-LO)", RFC 5962, September 2010.		Usage Clarification, Considerations, and Recommendations",
			RFC 5491, March 2009.
	[4] Rosen, B. and J. Polk, "Best Current Practice for		[4] 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-20 (work in progress),		BCP 181, RFC 6881, March 2013.
	September 2011.
	[5] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency		[5] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
	and Other Well-Known Services", RFC 5031, January 2008.		for the Session Initiation Protocol", RFC 6442, December
			2011.
	[6] Rosen, B., Tschofenig, H., Marshall, R., and R. Randy,		[6] Schulzrinne, H., Singh, V., Tschofenig, H., and M.
	"Additional Data related to an Emergency Call",		Thomson, "Dynamic Extensions to the Presence Information
	draft-ietf-ecrit-additional-data-06 (work in progress),		Data Format Location Object (PIDF-LO)", RFC 5962,
	February 2013.		September 2010.
	[7] Peterson, J., "A Presence-based GEOPRIV Location Object		[7] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
	Format", RFC 4119, December 2005.		Types", RFC 3023, January 2001.
	[8] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for		[8] Freed, N. and J. Klensin, "Media Type Specifications and
	the Session Initiation Protocol", RFC 6442, December 2011.		Registration Procedures", RFC 4288, December 2005.
			[9] Rosen, B., Tschofenig, H., Marshall, R., and R. Randy,
			"Additional Data related to an Emergency Call", draft-
			ietf-ecrit-additional-data-09 (work in progress), May
			2013.
			[10] Schulzrinne, H., "A Uniform Resource Name (URN) for
			Emergency and Other Well-Known Services", RFC 5031,
			January 2008.
	9.2. Informative references		9.2. Informative references
	[9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency		[11] Schulzrinne, H. and R. Marshall, "Requirements for
	Context Resolution with Internet Technologies", RFC 5012,		Emergency Context Resolution with Internet Technologies",
	January 2008.		RFC 5012, January 2008.
	[10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam,		[12] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
	"Security Threats and Requirements for Emergency Call Marking		Shanmugam, "Security Threats and Requirements for
	and Mapping", RFC 5069, January 2008.		Emergency Call Marking and Mapping", RFC 5069, January
			2008.
	[11] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy		[13] Tschofenig, H., Schulzrinne, H., and B. Aboba,
	Location", draft-ietf-ecrit-trustworthy-location-04 (work in		"Trustworthy Location", draft-ietf-ecrit-trustworthy-
	progress), October 2012.		location-05 (work in progress), March 2013.
	[12] CEN, "Intelligent transport systems - eSafety - eCall minimum		[14] Schulzrinne, H., "Timed Presence Extensions to the
	set of data (MSD), EN 15722", June 2011.		Presence Information Data Format (PIDF) to Indicate Status
			Information for Past and Future Time Intervals", RFC 4481,
			July 2006.
	[13] Schulzrinne, H., "Timed Presence Extensions to the Presence		[15] CEN, ., "Intelligent transport systems - eSafety - eCall
	Information Data Format (PIDF) to Indicate Status Information		minimum set of data (MSD), EN 15722", June 2011.
	for Past and Future Time Intervals", RFC 4481, July 2006.
	Appendix A. Matching Functionality with eCall Minimum Set of Data (MSD)		Appendix A. Matching Functionality with eCall Minimum Set of Data (MSD)
	[12] outlines a number of data elements that are transmitted in an		[15] outlines a number of data elements that are transmitted in an
	emergency call triggered by a vehicle. Note that the work on eCall		emergency call triggered by a vehicle. Note that the work on eCall
	for mobile circuit switched voice is constrained in a number of ways.		for mobile circuit switched voice is constrained in a number of ways
	For example, eCall uses an inband voice modem to transmit data from a		since legacy eCall uses an inband voice modem for backwards
	vehicle to a PSAP. Since the functionality in this document is based		compatibility with the already deployed cellular infrastructure to
	on the Session Initiation Protocol these limitations do not exist.		transmit data from a vehicle to a PSAP. Since the functionality in
	As such, it is not useful to transmit the MSD inband in the voice		this document is based on the Session Initiation Protocol (SIP) these
	channel but to rather use the SIP-designed mechanisms. Any voice,		limitations do not exist. As such, it is not useful to transmit the
	video, or real-text communication will be negotiated using the		MSD inband in the voice channel but to rather use the SIP mechanisms
	Session Description Protocol (SDP), as shown in Figure 2, and the		standardized for emergency call handling. Any voice, video, or real-
	actual media stream will then take place in RTP packets.		text communication will be negotiated using the Session Description
			Protocol (SDP), as shown in Figure 8, and the actual media stream
			will then take place in RTP packets. For transmitting location
			information an XML-based data structure had been defined, the so-
			called Presence Information Data Format Location Object (PIDF-LO).
	The following list compares the eCall minimum set of data with the		The following list compares the eCall minimum set of data with the
	functionality provided in this document.		functionality provided in this document.
	Version of the MSD Format		Version of the MSD Format: Conveying information in a SIP-based
			emergency call is accomplished by using XML payloads and XML
			provides namespace declarations that allow a receipient of that
			information to distinguish different versions and additional
			extensions. For example, if additional data about a vehicle is
			defined and can be transmitted by vehicle then a respective
			extension can be defined inside the additional data XML structure
			[9]. Selecting the appropriate extension point depends on the
			type of extension envisioned.
	Message Identifier: Every SIP INVITE message contains a Call-ID,		Message Identifier: Every SIP INVITE message contains a Call-ID,
	which is a globally unique identifier for this call.		which is a globally unique identifier for this call.
	Vehicle Type Encoding: [Editor's Note: Description to be added.].
	Test Call Indication A service URN starting with "test." indicates a		Test Call Indication A service URN starting with "test." indicates a
	request for an automated test. For example,		request for an automated test. For example,
	"urn:service:test.sos.ecall.automatic" indicates such a test		"urn:service:test.sos.ecall.automatic" indicates such a test
	feature. This functionality is defined in [4].		feature. This functionality is defined in [4].
	Automatic Activation Indication: This document registers new service		Automatic Activation Indication: This document registers new service
	URNs, which allow the differentiation between manually and		URNs, which allow the differentiation between manually and
	automatically triggered emergency calls. The two service URNs		automatically triggered emergency calls. The two service URNs
	are: urn:service:sos.ecall.automatic and		are: urn:service:sos.ecall.automatic and
	urn:service:sos.ecall.manual		urn:service:sos.ecall.manual
	Vehicle Identification: The PIDF data structure contains a deviceID		Vehicle Identification: The PIDF data structure contains a deviceID
	field that holds the Vehicle Identification Number (VIN).		field that holds the Vehicle Identification Number (VIN).
	Vehicle Propulsion Storage type: These parameters identify the type
	of vehicle energy storage(s) present. [Editor's Note:
	Description to be added.]
	Timestamp of Incident Event: The PIDF-LO element contains the		Timestamp of Incident Event: The PIDF-LO element contains the
	timestamp when the PIDF-LO was created, which is at the time of		timestamp when the PIDF-LO was created, which is at the time of
	the incident.		the incident.
	Vehicle Location: The location of the vehicle is conveyed using the		Vehicle Location: The location of the vehicle is conveyed using the
	PIDF location objection, as described in Section 3.		PIDF location objection, as described in Section 3.
	Vehicle Direction: The direction of the vehicle is part of location		Vehicle Direction: The direction of the vehicle is part of location
	information, as described in Section 3.		information, as described in Section 3.
	Recent Vehicle Location: With this optional functionality multiple		Recent Vehicle Location: With this optional functionality multiple
	location objects may be required to be transported simultaneously.		location objects may be required to be transported simultaneously.
	This can be achieved using <timed-presence>, defined in RFC 4481		This can be achieved using <timed-presence>, defined in RFC 4481
	[13].		[14].
	Number of Passengers: Minimum known number of fastened seatbelts.
	[Editor's Note: Description to be added.]
	Additional Data: [6] provides the ability to carry additional data		Additional Data: [9] provides the ability to carry additional data
	for an emergency call.		for an emergency call.
			While most fields have an equivalent already in the corresponding SIP
			emergency signaling payloads there are currently no fields defined in
			the additional data structure [9] that allow information about the
			"Vehicle Type Encoding", "Number of Passengers", and "Vehicle
			Propulsion Storage type" to be conveyed. Extensions for those fields
			will have to be defined.
	Authors' Addresses		Authors' Addresses
	Brian Rosen		Brian Rosen
	NeuStar, Inc.		NeuStar, Inc.
	470 Conrad Dr		470 Conrad Dr
	Mars, PA 16046		Mars, PA 16046
	US		US
	Phone:		Email: br@brianrosen.net
	Email: br@brianrosen.net
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Phone: +358 (50) 4871445		Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
	Randall Gellens		Randall Gellens
	QUALCOMM Incorporated		QUALCOMM Incorporated
	5775 Morehouse Drive		5775 Morehouse Drive
	San Diego 92651		San Diego 92651
	US		US
	Email: rg+ietf@qualcomm.com		Email: rg+ietf@qualcomm.com
End of changes. 52 change blocks.
	131 lines changed or deleted		342 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/