draft-ietf-sipcore-info-events-09.txt		draft-ietf-sipcore-info-events-10.txt
	SIPCORE C. Holmberg		SIPCORE C. Holmberg
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Obsoletes: 2976 (if approved) E. Burger		Obsoletes: 2976 (if approved) E. Burger
	Intended status: Standards Track NeuStar, Inc.		Intended status: Standards Track NeuStar, Inc.
	Expires: April 1, 2011 H. Kaplan		Expires: April 15, 2011 H. Kaplan
	Acme Packet		Acme Packet
	September 28, 2010		October 12, 2010
	Session Initiation Protocol (SIP) INFO Method and Package Framework		Session Initiation Protocol (SIP) INFO Method and Package Framework
	draft-ietf-sipcore-info-events-09		draft-ietf-sipcore-info-events-10
	Abstract		Abstract
	This document defines a method, INFO, for the Session Initiation		This document defines a method, INFO, for the Session Initiation
	Protocol (SIP), and an Info Package mechanism. The document		Protocol (SIP), and an Info Package mechanism. The document
	obsoletes RFC 2976. For backward compatibility the document also		obsoletes RFC 2976. For backward compatibility the document also
	specifies a "legacy" mode of usage of the INFO method that is		specifies a "legacy" mode of usage of the INFO method that is
	compatible with the usage previously defined in RFC 2976, referred to		compatible with the usage previously defined in RFC 2976, referred to
	as "legacy INFO Usage" in this document.		as "legacy INFO Usage" in this document.
	skipping to change at page 1, line 44		skipping to change at page 1, line 44
	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 April 1, 2011.		This Internet-Draft will expire on April 15, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 2, line 47		skipping to change at page 2, line 47
	5.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12		5.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12
	6. Formal INFO Method Definition . . . . . . . . . . . . . . . . 13		6. Formal INFO Method Definition . . . . . . . . . . . . . . . . 13
	6.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 13		6.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 13
	7. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14		7. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14
	7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14		7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
	7.2. Info-Package header field . . . . . . . . . . . . . . . . 15		7.2. Info-Package header field . . . . . . . . . . . . . . . . 15
	7.3. Recv-Info header field . . . . . . . . . . . . . . . . . 16		7.3. Recv-Info header field . . . . . . . . . . . . . . . . . 16
	8. Info Package Considerations . . . . . . . . . . . . . . . . . 16		8. Info Package Considerations . . . . . . . . . . . . . . . . . 16
	8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16		8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16
	8.2. Appropriateness of Info Package Usage . . . . . . . . . . 16		8.2. Appropriateness of Info Package Usage . . . . . . . . . . 16
	8.3. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16		8.3. INFO Request Rate and Volume . . . . . . . . . . . . . . 16
	8.3.1. Alternative SIP signaling plane mechanisms . . . . . . 16		8.4. Alternative Mechanisms . . . . . . . . . . . . . . . . . 17
	8.3.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 18		8.4.1. Alternative SIP signaling plane mechanisms . . . . . . 17
	8.3.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 19		8.4.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 18
			8.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 19
	9. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19		9. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19		9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 19		9.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19		10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19
	10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19		10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19
	10.2. Overall Description . . . . . . . . . . . . . . . . . . . 20		10.2. Overall Description . . . . . . . . . . . . . . . . . . . 20
	10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20		10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20
	10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 21		10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 21
	10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21		10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21
	10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21		10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21
	skipping to change at page 6, line 24		skipping to change at page 6, line 24
	2976, referred to as "legacy INFO Usage".		2976, referred to as "legacy INFO Usage".
	For backward compatibility purposes, this document does not deprecate		For backward compatibility purposes, this document does not deprecate
	legacy INFO usages, and does not mandate users to define Info		legacy INFO usages, and does not mandate users to define Info
	Packages for such usages. However:		Packages for such usages. However:
	1. A UA MUST NOT insert an Info-Package header field in a legacy		1. A UA MUST NOT insert an Info-Package header field in a legacy
	INFO request (as described in Section 3, an INFO request		INFO request (as described in Section 3, an INFO request
	associated with an Info Package always contains an Info-Package		associated with an Info Package always contains an Info-Package
	header field).		header field).
	2. It is strongly RECOMMENDED that any new usage uses the Info		2. Any new usage MUST use the Info Package mechanism defined in this
	Package mechanism defined in this specification, since it does		specification, since it does not share the issues associated with
	not share the issues associated with legacy INFO usage, and since		legacy INFO usage, and since Info Packages can be registered with
	Info Packages can be registered with IANA.		IANA.
	3. UAs are allowed to enable both legacy INFO usages and Info		3. UAs are allowed to enable both legacy INFO usages and Info
	Package usages as part of the same invite dialog usage, but UAs		Package usages as part of the same invite dialog usage, but UAs
	SHALL NOT mix legacy INFO usages and Info Package usages in order		SHALL NOT mix legacy INFO usages and Info Package usages in order
	to transport the same application level information. If		to transport the same application level information. If
	possible, UAs SHALL prefer the usage of an Info Package.		possible, UAs SHALL prefer the usage of an Info Package.
	4. The INFO Method		4. The INFO Method
	4.1. General		4.1. General
	skipping to change at page 16, line 34		skipping to change at page 16, line 34
	8.2. Appropriateness of Info Package Usage		8.2. Appropriateness of Info Package Usage
	When designing an Info Package, for application level information		When designing an Info Package, for application level information
	exchange, it is important to consider: is signaling, using INFO		exchange, it is important to consider: is signaling, using INFO
	requests, within a SIP dialog, an appropriate mechanism for the use-		requests, within a SIP dialog, an appropriate mechanism for the use-
	case? Is it because it is the most reasonable and appropriate		case? Is it because it is the most reasonable and appropriate
	choice, or merely because "it's easy"? Choosing an inappropriate		choice, or merely because "it's easy"? Choosing an inappropriate
	mechanism for a specific use-case can cause negative effects in SIP		mechanism for a specific use-case can cause negative effects in SIP
	networks where the mechanism is used.		networks where the mechanism is used.
	8.3. Alternative Mechanisms		8.3. INFO Request Rate and Volume
	8.3.1. Alternative SIP signaling plane mechanisms
	8.3.1.1. General
	This subsection describes some alternative mechanisms for
	transporting application information on the SIP signaling plane,
	using SIP messages.
	8.3.1.2. INFO Request Rate and Volume
	INFO messages differ from many other sorts of SIP messages in that		INFO messages differ from many other sorts of SIP messages in that
	they carry application information, and the size and rate of the INFO		they carry application information, and the size and rate of the INFO
	message is directly determined by the application. This can cause		message is directly determined by the application. This can cause
	application information traffic to interfere with other traffic on		application information traffic to interfere with other traffic on
	that infrastructure, or to self-interfere when data rates become too		that infrastructure, or to self-interfere when data rates become too
	high.		high.
	There is no default throttling mechanism for INFO requests. Apart		There is no default throttling mechanism for INFO requests. Apart
	from the SIP session establishment, the number of SIP messages		from the SIP session establishment, the number of SIP messages
	skipping to change at page 17, line 37		skipping to change at page 17, line 27
	exchange of bulk data beyond these limits, especially if the headers		exchange of bulk data beyond these limits, especially if the headers
	plus body exceed the User Datagram Protocol (UDP) MTU [RFC0768].		plus body exceed the User Datagram Protocol (UDP) MTU [RFC0768].
	Appropriate mechanisms for such traffic include the Hypertext		Appropriate mechanisms for such traffic include the Hypertext
	Transfer Protocol (HTTP) [RFC2616], the Message Session Relay		Transfer Protocol (HTTP) [RFC2616], the Message Session Relay
	Protocol (MSRP) [RFC4975], or other media plane data transport		Protocol (MSRP) [RFC4975], or other media plane data transport
	mechanisms.		mechanisms.
	RFC 5405 [RFC5405] provides additional guidelines for applications		RFC 5405 [RFC5405] provides additional guidelines for applications
	using UDP that may be useful background reading.		using UDP that may be useful background reading.
	8.3.1.3. SUBSCRIBE/NOTIFY		8.4. Alternative Mechanisms
			8.4.1. Alternative SIP signaling plane mechanisms
			8.4.1.1. General
			This subsection describes some alternative mechanisms for
			transporting application information on the SIP signaling plane,
			using SIP messages.
			8.4.1.2. SUBSCRIBE/NOTIFY
	An alternative for application level interaction is to use		An alternative for application level interaction is to use
	subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and		subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and
	NOTIFY methods. Using that mechanism, a UA requests state		NOTIFY methods. Using that mechanism, a UA requests state
	information, such as key pad presses from a device to an application		information, such as key pad presses from a device to an application
	server or key map images from an application server to a device.		server or key map images from an application server to a device.
	Event Packages [RFC3265] perform the role of disambiguating the		Event Packages [RFC3265] perform the role of disambiguating the
	context of a message for subscription-based events. The Info Package		context of a message for subscription-based events. The Info Package
	mechanism provides similar functionality for application information		mechanism provides similar functionality for application information
	skipping to change at page 18, line 23		skipping to change at page 18, line 23
	and B2BUAs, the resource impact caused by the subscription dialogs		and B2BUAs, the resource impact caused by the subscription dialogs
	needs to be considered. The number of subscription dialogs per user		needs to be considered. The number of subscription dialogs per user
	also needs to be considered.		also needs to be considered.
	As for any other SIP signaling plane based mechanism for transporting		As for any other SIP signaling plane based mechanism for transporting
	application information, the SUBSCRIBE/NOTIFY messages can put a		application information, the SUBSCRIBE/NOTIFY messages can put a
	significant burden on intermediate SIP entities which are part of the		significant burden on intermediate SIP entities which are part of the
	dialog route set, but do not have any interest in the application		dialog route set, but do not have any interest in the application
	information transported between the end users.		information transported between the end users.
	8.3.1.4. MESSAGE		8.4.1.3. MESSAGE
	The MESSAGE method [RFC3428] defines one-time instant message		The MESSAGE method [RFC3428] defines one-time instant message
	exchange, typically for sending MIME contents for rendering to the		exchange, typically for sending MIME contents for rendering to the
	user.		user.
	8.3.2. Media Plane Mechanisms		8.4.2. Media Plane Mechanisms
	8.3.2.1. General		8.4.2.1. General
	In SIP, media plane channels associated with SIP dialogs are		In SIP, media plane channels associated with SIP dialogs are
	established using SIP signaling, but the data exchanged on the media		established using SIP signaling, but the data exchanged on the media
	plane channel does not traverse SIP signaling intermediates, so if		plane channel does not traverse SIP signaling intermediates, so if
	there will be a lot of information exchanged, and there is no need		there will be a lot of information exchanged, and there is no need
	for the SIP signaling intermediaries to examine the information, it		for the SIP signaling intermediaries to examine the information, it
	is recommended to use a media plane mechanism, rather than a SIP		is recommended to use a media plane mechanism, rather than a SIP
	signaling based.		signaling based.
	A low latency requirement for the exchange of information is one		A low latency requirement for the exchange of information is one
	strong indicator for using a media channel. Exchanging information		strong indicator for using a media channel. Exchanging information
	through the SIP routing network can introduce hundreds of		through the SIP routing network can introduce hundreds of
	milliseconds of latency.		milliseconds of latency.
	8.3.2.2. MRCP		8.4.2.2. MRCP
	One mechanism for media plane exchange of application data is the		One mechanism for media plane exchange of application data is the
	Media Resource Control Protocol (MRCP) [I-D.ietf-speechsc-mrcpv2],		Media Resource Control Protocol (MRCP) [I-D.ietf-speechsc-mrcpv2],
	where a media plane connection-oriented channel, such as a		where a media plane connection-oriented channel, such as a
	Transmission Control Protocol (TCP) [RFC0793] or Stream Control		Transmission Control Protocol (TCP) [RFC0793] or Stream Control
	Transmission Protocol (SCTP) [RFC4960] stream is established.		Transmission Protocol (SCTP) [RFC4960] stream is established.
	8.3.2.3. MRSP		8.4.2.3. MRSP
	MSRP [RFC4975] defines session-based instant messaging as well as		MSRP [RFC4975] defines session-based instant messaging as well as
	bulk file transfer and other such large-volume uses.		bulk file transfer and other such large-volume uses.
	8.3.3. Non-SIP related mechanisms		8.4.3. Non-SIP related mechanisms
	Another alternative is to use a SIP-independent mechanism, such as		Another alternative is to use a SIP-independent mechanism, such as
	HTTP [RFC2616]. In this model, the UA knows about a rendezvous point		HTTP [RFC2616]. In this model, the UA knows about a rendezvous point
	to direct HTTP requests to for the transfer of information. Examples		to direct HTTP requests to for the transfer of information. Examples
	include encoding of a prompt to retrieve in the SIP Request URI in		include encoding of a prompt to retrieve in the SIP Request URI in
	[RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC-		[RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC-
	voicexml21-20070619] script.		voicexml21-20070619] script.
	9. Syntax		9. Syntax
	skipping to change at page 20, line 21		skipping to change at page 20, line 21
	Info Package specifications MUST NOT weaken any behavior designated		Info Package specifications MUST NOT weaken any behavior designated
	with "SHOULD" or "MUST" in this specification. However, Info		with "SHOULD" or "MUST" in this specification. However, Info
	Packages specifications MAY strengthen "SHOULD", "MAY", or		Packages specifications MAY strengthen "SHOULD", "MAY", or
	"RECOMMENDED" requirements to "MUST" strength if applications		"RECOMMENDED" requirements to "MUST" strength if applications
	associated with the Info Package require it.		associated with the Info Package require it.
	Info Package specifications MUST address the issues defined in the		Info Package specifications MUST address the issues defined in the
	following subsections, or document why an issue is not applicable for		following subsections, or document why an issue is not applicable for
	the specific Info Package.		the specific Info Package.
	Section 8.3 describes alternative mechanisms, which should be		Section 8.4 describes alternative mechanisms, which should be
	considered as part of the process for solving a specific use-case,		considered as part of the process for solving a specific use-case,
	when there is a need for transporting application information.		when there is a need for transporting application information.
	10.2. Overall Description		10.2. Overall Description
	The Info Package specification MUST contain an overall description of		The Info Package specification MUST contain an overall description of
	the Info Package: what type of information are carried in INFO		the Info Package: what type of information are carried in INFO
	requests associated with the Info Package, and for what type of		requests associated with the Info Package, and for what type of
	applications and functionalities UAs can use the Info Package.		applications and functionalities UAs can use the Info Package.
	skipping to change at page 34, line 21		skipping to change at page 34, line 21
	November 2008.		November 2008.
	[RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup		[RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup
	Language (MSML)", RFC 5707, February 2010.		Language (MSML)", RFC 5707, February 2010.
	[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet		[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
	Mail Extensions (S/MIME) Version 3.2 Message		Mail Extensions (S/MIME) Version 3.2 Message
	Specification", RFC 5751, January 2010.		Specification", RFC 5751, January 2010.
	[W3C.REC-voicexml21-20070619]		[W3C.REC-voicexml21-20070619]
	Rehor, K., Bodell, M., Burke, D., Baggia, P., Auburn, R.,		Porter, B., McGlashan, S., Lee, A., Auburn, R., Carter,
	Burnett, D., Candell, E., Carter, J., McGlashan, S., Lee,		J., Rehor, K., Oshry, M., Bodell, M., Burke, D., Baggia,
	A., Porter, B., and M. Oshry, "Voice Extensible Markup		P., Candell, E., and D. Burnett, "Voice Extensible Markup
	Language (VoiceXML) 2.1", World Wide Web Consortium		Language (VoiceXML) 2.1", World Wide Web Consortium
	Recommendation REC-voicexml21-20070619, June 2007,		Recommendation REC-voicexml21-20070619, June 2007,
	<http://www.w3.org/TR/2007/REC-voicexml21-20070619>.		<http://www.w3.org/TR/2007/REC-voicexml21-20070619>.
	[I-D.ietf-speechsc-mrcpv2]		[I-D.ietf-speechsc-mrcpv2]
	Burnett, D. and S. Shanmugham, "Media Resource Control		Burnett, D. and S. Shanmugham, "Media Resource Control
	Protocol Version 2 (MRCPv2)",		Protocol Version 2 (MRCPv2)",
	draft-ietf-speechsc-mrcpv2-21 (work in progress),		draft-ietf-speechsc-mrcpv2-21 (work in progress),
	July 2010.		July 2010.
End of changes. 16 change blocks.
	34 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/