< draft-ietf-ecrit-data-only-ea-07.txt		draft-ietf-ecrit-data-only-ea-08.txt >
	ECRIT B. Rosen		ECRIT B. Rosen
	Internet-Draft NeuStar, Inc.		Internet-Draft NeuStar, Inc.
	Intended status: Standards Track H. Schulzrinne		Intended status: Standards Track H. Schulzrinne
	Expires: August 18, 2014 Columbia U.		Expires: January 25, 2015 Columbia U.
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	February 14, 2014		July 24, 2014
	Data-Only Emergency Calls		Data-Only Emergency Calls
	draft-ietf-ecrit-data-only-ea-07.txt		draft-ietf-ecrit-data-only-ea-08.txt
	Abstract		Abstract
	RFC 6443 'Framework for Emergency Calling Using Internet Multimedia'		RFC 6443 'Framework for Emergency Calling Using Internet Multimedia'
	describes how devices use the Internet to place emergency calls and		describes how devices use the Internet to place emergency calls and
	how Public Safety Answering Points (PSAPs) can handle Internet		how Public Safety Answering Points (PSAPs) can handle Internet
	multimedia emergency calls natively. The exchange of multimedia		multimedia emergency calls natively. The exchange of multimedia
	traffic typically involves a SIP session establishment starting with		traffic typically involves a SIP session establishment starting with
	a SIP INVITE that negotiates various parameters for that session.		a SIP INVITE that negotiates various parameters for that session.
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 18, 2014.		This Internet-Draft will expire on January 25, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 44 ¶		skipping to change at page 3, line 44 ¶
	citizen to authority "alerts", where the alert is sent without any		citizen to authority "alerts", where the alert is sent without any
	interactive media.		interactive media.
	This document describes a method of including a CAP message in a SIP		This document describes a method of including a CAP message in a SIP
	transaction, either by value (CAP message is in the body of the		transaction, either by value (CAP message is in the body of the
	message, using a CID) or by reference (A URI is included in the		message, using a CID) or by reference (A URI is included in the
	message, which when dereferenced returns the CAP message) by defining		message, which when dereferenced returns the CAP message) by defining
	it as a block of "additional data" as defined in		it as a block of "additional data" as defined in
	[I-D.ietf-ecrit-additional-data]. The additional data mechanism is		[I-D.ietf-ecrit-additional-data]. The additional data mechanism is
	also used to send alert specific data beyond that available in the		also used to send alert specific data beyond that available in the
	CAP message.		CAP message. This document also describes how a SIP MESSAGE
			[RFC3428] transaction can be used to send a data-only call.
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Architectural Overview		3. Architectural Overview
	This section illustrates two envisioned usage modes; targeted and		This section illustrates two envisioned usage modes; targeted and
	skipping to change at page 5, line 34 ¶		skipping to change at page 5, line 34 ¶
	| |		| |
	Figure 1: Targeted Emergency Alert Routing		Figure 1: Targeted Emergency Alert Routing
	In Figure 2 a scenario is shown whereby the alert is routed using		In Figure 2 a scenario is shown whereby the alert is routed using
	location information and the Service URN. An emergency services		location information and the Service URN. An emergency services
	routing proxy (ESRP) may use LoST to determine the next hop proxy to		routing proxy (ESRP) may use LoST to determine the next hop proxy to
	route the alert message to. A possible receiver is a PSAP and the		route the alert message to. A possible receiver is a PSAP and the
	recipient of the alert may be call taker. In the generic case, there		recipient of the alert may be call taker. In the generic case, there
	is very likely no prior relationship between the originator and the		is very likely no prior relationship between the originator and the
	receiver, e.g. PSAP. A PSAP, for example, is likely to receive and		receiver, e.g. PSAP. A PSAP, for example, is likely to receive and
	accept alerts from entities it cannot authorize. This scenario		accept alerts from entities it cannot authorize. This scenario
	corresponds more to the classical emergency services use case and the		corresponds more to the classical emergency services use case and the
	description in [RFC6881] is applicable. In this use case, the only		description in [RFC6881] is applicable. In this use case, the only
	difference between an emergency call, and an emergency data-only call		difference between an emergency call, and an emergency data-only call
	is that the former uses INVITE and creates a session and negotiates		is that the former uses INVITE, creates a session and negotiates one
	one or more media streams, and the latter uses MESSAGE, does not		or more media streams, while the latter uses MESSAGE, does not create
	create a session and does not have media.		a session and does not have media.
	+-----------+ +----------+		+-----------+ +----------+
	+--------+ | ESRP | | PSAP |		+--------+ | ESRP | | PSAP |
	| Sensor | | | | |		| Sensor | | | | |
	+---+----+ +---+-------+ +---+------+		+---+----+ +---+-------+ +---+------+
	| | |		| | |
	Sensors | |		Sensors | |
	trigger | |		trigger | |
	emergency | |		emergency | |
	alert | |		alert | |
	skipping to change at page 6, line 48 ¶		skipping to change at page 6, line 48 ¶
	| | |		| | |
	Figure 2: Location-Based Emergency Alert Routing		Figure 2: Location-Based Emergency Alert Routing
	4. Protocol Specification		4. Protocol Specification
	4.1. CAP Transport		4.1. CAP Transport
	A CAP message may be sent on the initial message of any SIP		A CAP message may be sent on the initial message of any SIP
	transaction. However, this document only describes specific behavior		transaction. However, this document only describes specific behavior
	when used with a SIP MESSAGE transaction for a one-shot, data-only		when used with a SIP INVITE that would accompany a normal emergency
			call and a SIP MESSAGE transaction for a one-shot, data-only
	emergency call. Behavior with other transactions is not defined.		emergency call. Behavior with other transactions is not defined.
	The CAP message included in a SIP message as an additional-data block		The CAP message included in a SIP message as an additional-data block
	[I-D.ietf-ecrit-additional-data]. Accordingly, it is introduced to		[I-D.ietf-ecrit-additional-data]. Accordingly, it is introduced to
	the SIP message with a Call-Info header with a purpose of		the SIP message with a Call-Info header with a purpose of
	"emergencyCall.cap". The header may contain a URI that is used by		"emergencyCall.cap". The header may contain a URI that is used by
	the recipient (or in some cases, an intermediary) to obtain the CAP		the recipient (or in some cases, an intermediary) to obtain the CAP
	message. Alternative, the Call-Info header may contain a Content		message. Alternative, the Call-Info header may contain a Content
	Indirect url [RFC2392] and the CAP message included in the body of		Indirect url [RFC2392] and the CAP message included in the body of
	the message. In either case, the CAP message is located in a MIME		the message. In either case, the CAP message is located in a MIME
	skipping to change at page 21, line 5 ¶		skipping to change at page 21, line 5 ¶
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,		[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
	and D. Gurle, "Session Initiation Protocol (SIP) Extension		and D. Gurle, "Session Initiation Protocol (SIP) Extension
	for Instant Messaging", RFC 3428, December 2002.		for Instant Messaging", RFC 3428, December 2002.
	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
	for Event State Publication", RFC 3903, October 2004.
	[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media		[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
	Types", RFC 3023, January 2001.		Types", RFC 3023, January 2001.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance		[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
	for the Session Initiation Protocol", RFC 6442, December		for the Session Initiation Protocol", RFC 6442, December
	2011.		2011.
	[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665,
	July 2012.
	[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for		[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
	Communications Services in Support of Emergency Calling",		Communications Services in Support of Emergency Calling",
	BCP 181, RFC 6881, March 2013.		BCP 181, RFC 6881, March 2013.
	[I-D.ietf-ecrit-additional-data]		[I-D.ietf-ecrit-additional-data]
	Rosen, B., Tschofenig, H., Marshall, R., Randy, R., and J.		Rosen, B., Tschofenig, H., Marshall, R., Randy, R., and J.
	Winterbottom, "Additional Data related to an Emergency		Winterbottom, "Additional Data related to an Emergency
	Call", draft-ietf-ecrit-additional-data-20 (work in		Call", draft-ietf-ecrit-additional-data-22 (work in
	progress), February 2014.		progress), April 2014.
	[I-D.rosen-ecrit-addldata-subnot]		[I-D.rosen-ecrit-addldata-subnot]
	Rosen, B., "Updating Additional Data related to an		Rosen, B., "Updating Additional Data related to an
	Emergency Call using Subscribe/ Notify", draft-rosen-		Emergency Call using Subscribe/ Notify", draft-rosen-
	ecrit-addldata-subnot-01 (work in progress), November		ecrit-addldata-subnot-01 (work in progress), November
	2013.		2013.
	13.2. Informative References		13.2. Informative References
	[I-D.ietf-ecrit-trustworthy-location]		[I-D.ietf-ecrit-trustworthy-location]
	Tschofenig, H., Schulzrinne, H., and B. Aboba,		Tschofenig, H., Schulzrinne, H., and B. Aboba,
	"Trustworthy Location", draft-ietf-ecrit-trustworthy-		"Trustworthy Location", draft-ietf-ecrit-trustworthy-
	location-08 (work in progress), January 2014.		location-13 (work in progress), June 2014.
	[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.
	[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.
End of changes. 12 change blocks.
	19 lines changed or deleted		15 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/