< draft-rosen-ecrit-ecall-07.txt		draft-rosen-ecrit-ecall-08.txt >
	ECRIT B. Rosen		ECRIT B. Rosen
	Internet-Draft NeuStar, Inc.		Internet-Draft NeuStar, Inc.
	Intended status: Informational H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: August 25, 2013 Nokia Siemens Networks		Expires: August 29, 2013 Nokia Siemens Networks
	February 21, 2013		R. Gellens
			QUALCOMM Incorporated
			February 25, 2013
	Internet Protocol-based In-Vehicle Emergency Call		Internet Protocol-based In-Vehicle Emergency Call
	draft-rosen-ecrit-ecall-07.txt		draft-rosen-ecrit-ecall-08.txt
	Abstract		Abstract
	This document describes how to use a subset of the IETF-based		This document describes how to re-use the emergency services
	emergency call framework for accomplishing emergency calling support		mechanisms specified for the Session Initiation Protocol (SIP) to
	in vehicles. Simplifications are possible due to the nature of the		accomplishing emergency calling support in vehicles. Profiling and
	functionality that is going to be provided in vehicles with the usage		simplifications are possible due to the nature of the functionality
	of GPS. Additionally, further profiling needs to be done regarding		that is going to be provided in vehicles with the usage of Global
	the encoding of location information.		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 25, 2013.		This Internet-Draft will expire on August 29, 2013.
	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
	skipping to change at page 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	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. At the time of writing the
	suppor for eCall are focused on legacy technology. This document		support for eCall is focused on legacy mobile circuit switched voice
	details how emergency calls triggered by vehicles can be accomplished		technology. This document details how the same functionality (and
	in an Internet Protocol-based environment.		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 is organized as follows: Section 2 defines the
	terminology, Section 3 describes how the required functionality can		terminology, Section 3 describes how the required functionality can
	be accomplished by combining several already existing standards, and		be accomplished by combining several already existing standards, and
	Section 4 shows an example message exchange. This document concludes		Section 4 shows an example message exchange. This document concludes
	with the security considerations in Section 5 and IANA considerations		with the security considerations in Section 5 and IANA considerations
	in Section 6.		in Section 6. Appendix A illustrates how to map the functionality in
			this document to the eCall Minimum Set of Data (MSD) specified for
			mobile circuit switched voice.
	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 [10].		This document re-uses terminology defined in Section 3 of [9].
	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 [2]), Circle (see Section 5.2.3
	of [2]), and Ellipsoid (see Section 5.2.7 of [2]). The coordinate		of [2]), and Ellipsoid (see Section 5.2.7 of [2]). The coordinate
	reference systems (CRS) specified in [2] are also mandatory for this		reference systems (CRS) specified in [2] are also mandatory for this
	document. The <direction> element, as defined in [3] which indicates		document. The <direction> element, as defined in [3] 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 [3] MUST be implemented and MAY be included.
	This specification also inherits the test call functionality from		This specification also inherits the ability to utilize test call
	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 1 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
	skipping to change at page 8, line 8 ¶		skipping to change at page 8, line 8 ¶
	<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 2: 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 [11]. As with emergency service systems with end host		described in [10]. 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 [12] for a		to a malfunctioning devices. The reader is referred to [11] for a
	discussion of some of these vulnerabilities.		discussion of some of these vulnerabilities.
	6. IANA Considerations		6. IANA Considerations
	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 [5].
	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
	skipping to change at page 12, line 40 ¶		skipping to change at page 12, line 40 ¶
	"Additional Data related to an Emergency Call",		"Additional Data related to an Emergency Call",
	draft-ietf-ecrit-additional-data-06 (work in progress),		draft-ietf-ecrit-additional-data-06 (work in progress),
	February 2013.		February 2013.
	[7] Peterson, J., "A Presence-based GEOPRIV Location Object		[7] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, December 2005.		Format", RFC 4119, December 2005.
	[8] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for		[8] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for
	the Session Initiation Protocol", RFC 6442, December 2011.		the Session Initiation Protocol", RFC 6442, December 2011.
	[9] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
	Preferences for the Session Initiation Protocol (SIP)",
	RFC 3841, August 2004.
	9.2. Informative references		9.2. Informative references
	[10] Schulzrinne, H. and R. Marshall, "Requirements for Emergency		[9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
	Context Resolution with Internet Technologies", RFC 5012,		Context Resolution with Internet Technologies", RFC 5012,
	January 2008.		January 2008.
	[11] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam,		[10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam,
	"Security Threats and Requirements for Emergency Call Marking		"Security Threats and Requirements for Emergency Call Marking
	and Mapping", RFC 5069, January 2008.		and Mapping", RFC 5069, January 2008.
	[12] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy		[11] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy
	Location", draft-ietf-ecrit-trustworthy-location-04 (work in		Location", draft-ietf-ecrit-trustworthy-location-04 (work in
	progress), October 2012.		progress), October 2012.
	[13] CEN, "Intelligent transport systems - eSafety - eCall minimum		[12] CEN, "Intelligent transport systems - eSafety - eCall minimum
	set of data (MSD), EN 15722", June 2011.		set of data (MSD), EN 15722", June 2011.
	[14] Schulzrinne, H., "Timed Presence Extensions to the Presence		[13] Schulzrinne, H., "Timed Presence Extensions to the Presence
	Information Data Format (PIDF) to Indicate Status Information		Information Data Format (PIDF) to Indicate Status Information
	for Past and Future Time Intervals", RFC 4481, July 2006.		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)
	[13] outlines a number of data elements that are transmitted in an		[12] outlines a number of data elements that are transmitted in an
	emergency call triggered by a vehicle. This list compares the eCall		emergency call triggered by a vehicle. Note that the work on eCall
	minimum set of data with the functionality provided in this document.		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
			vehicle to a PSAP. Since the functionality in this document is based
			on the Session Initiation Protocol these limitations do not exist.
			As such, it is not useful to transmit the MSD inband in the voice
			channel but to rather use the SIP-designed mechanisms. Any voice,
			video, or real-text communication will be negotiated using the
			Session Description Protocol (SDP), as shown in Figure 2, and the
			actual media stream will then take place in RTP packets.
			The following list compares the eCall minimum set of data with the
			functionality provided in this document.
	Version of the MSD Format		Version of the MSD Format
	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.].		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,
	skipping to change at page 14, line 49 ¶		skipping to change at page 15, line 14 ¶
	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
	[14].		[13].
	Number of Passengers: Minimum known number of fastened seatbelts.		Number of Passengers: Minimum known number of fastened seatbelts.
	[Editor's Note: Description to be added.]		[Editor's Note: Description to be added.]
	Additional Data: [6] provides the ability to carry additional data		Additional Data: [6] provides the ability to carry additional data
	for an emergency call.		for an emergency call.
	Authors' Addresses		Authors' Addresses
	Brian Rosen		Brian Rosen
	skipping to change at line 380 ¶		skipping to change at page 16, line 25 ¶
	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
			QUALCOMM Incorporated
			5775 Morehouse Drive
			San Diego 92651
			US
			Email: rg+ietf@qualcomm.com
End of changes. 20 change blocks.
	34 lines changed or deleted		47 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/