< draft-rosen-ecrit-ecall-00.txt		draft-rosen-ecrit-ecall-01.txt >
	ECRIT B. Rosen		ECRIT B. Rosen
	Internet-Draft NeuStar, Inc.		Internet-Draft NeuStar, Inc.
	Intended status: BCP H. Tschofenig		Intended status: BCP H. Tschofenig
	Expires: January 8, 2009 Nokia Siemens Networks		Expires: January 13, 2009 Nokia Siemens Networks
	July 7, 2008		U. Dietz
			Vodafone
			July 12, 2008
	Best Current Practice for IP-based In-Vehicle Emergency Calls		Best Current Practice for IP-based In-Vehicle Emergency Calls
	draft-rosen-ecrit-ecall-00.txt		draft-rosen-ecrit-ecall-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 35 ¶		skipping to change at page 1, line 37 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 8, 2009.		This Internet-Draft will expire on January 13, 2009.
	Abstract		Abstract
	This document describes how to use a subset of the IETF-based		This document describes how to use a subset of the IETF-based
	emergency call framework for accomplishing emergency calling support		emergency call framework for accomplishing emergency calling support
	in vehicles. Simplifications are possible due to the nature of the		in vehicles. Simplifications are possible due to the nature of the
	functionality that is going to be provided in vehicles with the usage		functionality that is going to be provided in vehicles with the usage
	of GPS. Additionally, further profiling needs to be done regarding		of GPS. Additionally, further profiling needs to be done regarding
	the encoding of location information.		the encoding of location information.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Protocol Profile . . . . . . . . . . . . . . . . . . . . . . . 5		3. Protocol Profile . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.2. Informative references . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		10.2. Informative references . . . . . . . . . . . . . . . . . 15
	Intellectual Property and Copyright Statements . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
			Intellectual Property and Copyright Statements . . . . . . . . . . 18
	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 instigated or automatic system		that may best be described as a user initiated or automatically
	to provide notification to 'Public Safety Answering Point's (PSAP),		triggered system to provide notifications to Public Safety Answering
	by means of cellular communications, that a vehicle has crashed, and		Point's (PSAP), by means of cellular communications, that a vehicle
	to provide coordinates, a defined minimum set of data, and where		has crashed, and to provide geodetic location information and where
	possible a voice link to the PSAP.". The current specifications		possible a voice channel to the PSAP. The current specifications
	being developed to offer the eCall solution are defined to work with		being developed to offer the eCall solution are defined to work with
	circuit switched telephony. This document details how the same		circuit switched telephony. This document details how the same
	functionality can be accomplished using IP-based mechanisms. Since		functionality can be accomplished using IP-based mechanisms. Since
	cellular systems are being replaced with IP-based infrastructure this		cellular systems are being enhanced with IP-based infrastructure this
	document complements the ambigous goal to provide widespread		document complements the ambiguous goal to provide widespread
	availability of in-vehicular emergency services solutions.		availability of in-vehicular emergency services solutions.
	This document is organized as follows: Section 2 defines the		This document is organized as follows: Section 2 defines the
	terminology, Section 3 illustrates the required protocol		terminology, Section 3 illustrates the required protocol
	functionality, Section 4 indicates the required data that has to be		functionality, Section 4 indicates the required data that has to be
	transmitted within a PIDF-LO and Section 5 shows an example message		transmitted within a PIDF-LO and Section 5 shows an example message
	exchange. This document concludes with the security consideratoins		exchange. This document concludes with the security considerations
	in Section 6 and IANA considerations in Section 7.		in Section 6 and IANA considerations in Section 7.
	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 a lot of the terminology defined in Section 3		This document re-uses a lot of the terminology defined in Section 3
	of [9].		of [9].
	skipping to change at page 5, line 48 ¶		skipping to change at page 5, line 48 ¶
	are not relevant for this document are multiple locations (Section		are not relevant for this document are multiple locations (Section
	6.9 of [2]), location validation (Section 6.10 of [2]), default		6.9 of [2]), location validation (Section 6.10 of [2]), default
	location (Section 6.11 of [2])		location (Section 6.11 of [2])
	LoST: Emergency call routing support, for example utilizing LoST, is		LoST: Emergency call routing support, for example utilizing LoST, is
	provided by VSP. As such, the description in Section 8 of [2] is		provided by VSP. As such, the description in Section 8 of [2] is
	applicable to this document, except for requirement SP-25 and		applicable to this document, except for requirement SP-25 and
	SP-26 regarding legacy devices.		SP-26 regarding legacy devices.
	Signaling of emergency calls: Section 9 of [2] is applicable to this		Signaling of emergency calls: Section 9 of [2] is applicable to this
	document with the following exceptions: video and real-time text		document with the following exception: ED-60/AN-25 is not
	are not supported by the end device, ED-60/AN-25 is not applicable		applicable as HELD is not used. Video and real-time text may be
	as HELD is not used. Additionally, ED-62 dealing with "SIP		supported by end device in the future, although currently not
	signaling requirements for User Agents" is simplified as follows.		envisioned. The corresponding text paragraphs are relevant from
	The initial SIP signaling method is an INVITE request with the		Section 9 of [2] when support is being provided. Additionally,
	following setting:		ED-62 dealing with "SIP signaling requirements for User Agents" is
			simplified as follows. The initial SIP signaling method is an
			INVITE request with the following setting:
	1. The Request URI MUST be the service URN 'urn:service:ecall'.		1. The Request URI MUST be the service URN 'urn:service:ecall'.
	2. The To header MUST be a service URN 'urn:service:ecall'.		2. The To header MUST be a service URN 'urn:service:ecall'.
	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.
	4. A Via header MUST be present.		4. A Via header MUST be present.
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	URI (either cid-URL or location-by-reference URI).		URI (either cid-URL or location-by-reference URI).
	12. SIP Caller Preferences [5] MAY be used to signal how the PSAP		12. SIP Caller Preferences [5] MAY be used to signal how the PSAP
	should handle the call. For example, a language preference		should handle the call. For example, a language preference
	expressed in an Accept-Language header may be used as a hint		expressed in an Accept-Language header may be used as a hint
	to cause the PSAP to route the call to a call taker who		to cause the PSAP to route the call to a call taker who
	speaks the requested language. SIP Caller Preferences may		speaks the requested language. SIP Caller Preferences may
	also be used to indicate a need to invoke a relay service for		also be used to indicate a need to invoke a relay service for
	communication with people with disabilities in the call.		communication with people with disabilities in the call.
	Call backs: The description in Section 10 of [2] is not relevant for		Call backs: The description in Section 10 of [2] is relevant for
	this document.		this document.
	Mid-call behavior: The description in Section 11 of [2] is fully		Mid-call behavior: The description in Section 11 of [2] is fully
	applicable to this document.		applicable to this document.
	Call termination: [This item is for further discussion.]		Call termination: The description in Section 12 of [2] is fully
			applicable to this document.
	Disabling of features: The description in Section 13 of [2] is fully		Disabling of features: The description in Section 13 of [2] is fully
	applicable to this document.		applicable to this document.
	Media: Real-time text and video are not supported. If voice calls		Media: Real-time text and video may be supported in devices some
	are supported then the description in Section 14 is applicable to		time in the future. If voice calls are supported then the
	this document.		description in Section 14 is applicable to this document.
	Testing: The description in Section 15 of [2] is fully applicable to		Testing: The description in Section 15 of [2] is fully applicable to
	this document.		this document.
	4. Data Profile		4. Data Profile
	Due to the requirement for a built-in GPS receiver only geodetic		Due to the requirement for a built-in GPS receiver only geodetic
	location information will be sent within an emergency call.		location information will be sent within an emergency call.
	Furthermore, the number of location shapes is is restricted. Hence,		Furthermore, the number of location shapes is is restricted. Hence,
	the following location shapes of [6] MUST be implemented: 2d and 3d		the following location shapes of [6] MUST be implemented: 2d and 3d
	skipping to change at page 11, line 8 ¶		skipping to change at page 11, line 8 ¶
	<method>GPS</method>		<method>GPS</method>
	</gp:geopriv>		</gp:geopriv>
	</device>		</device>
	</presence>		</presence>
	Figure 2: Example of In-Vehicular Emergency Call Message Flow		Figure 2: Example of In-Vehicular Emergency Call Message Flow
	6. Security Considerations		6. Security Considerations
	This document does not raise security considerations beyond those		This document does not raise security considerations beyond those
	described in [10].		described in [10]. As with emergency service systems with end host
			provided location information there is the possibility that that
			location is incorrect, either intentially (in case of an a denial of
			service attack against the emergency services infrastructure) or due
			to a malfunctioning devices. The reader is referred to [11] for a
			discussion of some of these vulnerabilities.
	7. IANA Considerations		7. IANA Considerations
	IANA is requested to register the URN 'urn:service:ecall' under the		IANA is requested to register the URN 'urn:service:ecall' under the
	sub-services 'sos' registry defined in Section 4.2 of [8].		sub-services 'sos' registry defined in Section 4.2 of [8].
	urn:service:ecall This service identifier reaches a public safety		urn:service:ecall This service identifier reaches a public safety
	answering point (PSAP), which in turn dispatches aid appropriate		answering point (PSAP), which in turn dispatches aid appropriate
	to the emergency related to accidents of vehicles.		to the emergency related to accidents of vehicles.
	8. Acknowledgements		8. Acknowledgements
	We would like to thank Michael Montag and Ulrich Dietz for their		We would like to thank Michael Montag for his feedback.
	feedback.
	9. References		9. Open Issues
	9.1. Normative References		While working on this document a few aspects where discovered that
			require further discussion:
			o Today's work on the eCall system does not necessary require a
			voice call to be established; a voice call may be established
			whenever possible by the functionality offered by the device.
			From a protocol mechanims, however, the design for establishing an
			emergency call including voice and without voice support are
			somewhat different. Further discussion on the design aspects are
			needed to align this aspect.
			o This document currently defines a new service URN to differentiate
			it from ordinary calls as in-vehicular emergency calls are, in
			some countries, routed to different PSAPs than regular emergency
			calls. More thoughts are needed to determine whether this is the
			best approach.
			o The current version of the document assumes the usage of LoST at
			the VSP to perform call routing of the in-vehicular emergency
			call. This is useful when there are no dial strings need to be
			learned nor any other service URNs need to be discovered. Further
			discussion is needed whether additional service URNs might be made
			available to the vehicle, for example to request roadside
			assistance or similar services. In that case the option might be
			provided to run LoST at the end host as well as on the VSP.
			10. References
			10.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 Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Rosen, B. and J. Polk, "Best Current Practice for		[2] 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-04 (work in progress), February 2008.		draft-ietf-ecrit-phonebcp-05 (work in progress), July 2008.
	[3] Peterson, J., "A Presence-based GEOPRIV Location Object		[3] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, December 2005.		Format", RFC 4119, December 2005.
	[4] Polk, J. and B. Rosen, "Location Conveyance for the Session		[4] Polk, J. and B. Rosen, "Location Conveyance for the Session
	Initiation Protocol", draft-ietf-sip-location-conveyance-10		Initiation Protocol", draft-ietf-sip-location-conveyance-10
	(work in progress), February 2008.		(work in progress), February 2008.
	[5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller		[5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
	Preferences for the Session Initiation Protocol (SIP)",		Preferences for the Session Initiation Protocol (SIP)",
	skipping to change at page 14, line 41 ¶		skipping to change at page 15, line 41 ¶
	[7] Vishal, S., Schulzrinne, H., and H. Tschofenig, "Dynamic		[7] Vishal, S., Schulzrinne, H., and H. Tschofenig, "Dynamic
	Feature Extensions to the Presence Information Data Format		Feature Extensions to the Presence Information Data Format
	Location Object (PIDF-LO)",		Location Object (PIDF-LO)",
	draft-singh-geopriv-pidf-lo-dynamic-02 (work in progress),		draft-singh-geopriv-pidf-lo-dynamic-02 (work in progress),
	November 2007.		November 2007.
	[8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency		[8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency
	and Other Well-Known Services", RFC 5031, January 2008.		and Other Well-Known Services", RFC 5031, January 2008.
	9.2. Informative references		10.2. Informative references
	[9] 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.
	[10] 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.
			[11] Tschofenig, H. and H. Schulzrinne, "Trustworthy Location
			Information", draft-tschofenig-ecrit-trustworthy-location-00
			(work in progress), July 2008.
	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:		Phone:
	Email: br@brianrosen.net		Email: br@brianrosen.net
	skipping to change at page 16, line 5 ¶		skipping to change at page 17, line 26 ¶
	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
			Ulrich Dietz
			Vodafone
			Chiemgaustrasse 116
			Munich 81549
			Germany
			Email: Ulrich.Dietz@vodafone.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	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
End of changes. 19 change blocks.
	35 lines changed or deleted		85 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/