< draft-dolly-xcon-mediacntrlframe-01.txt		draft-dolly-xcon-mediacntrlframe-02.txt >
	XCON M. Dolly		XCON M. Dolly
	Internet-Draft G. Munson		Internet-Draft G. Munson
	Expires: August 16, 2006 AT&T Labs		Expires: December 14, 2006 AT&T Labs
	J. Rafferty		J. Rafferty
	Brooktrout		Cantata
	February 12, 2006		June 12, 2006
	Media Control Protocol Framework		Media Control Protocol Requirements
	draft-dolly-xcon-mediacntrlframe-01.txt		draft-dolly-xcon-mediacntrlframe-02.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 36 ¶		skipping to change at page 1, line 36 ¶
	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 August 16, 2006.		This Internet-Draft will expire on December 14, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document provides requirements for a protocol, that will enable		This document provides requirements for a protocol, that will enable
	one physical entity that includes the media policy server,		one physical entity that includes the media policy server,
	notification server and the focus to interact with one or more		notification server and the focus to interact with one or more
	physical entities that serves as mixer or media server. It will		physical entities that serves as mixer or media server. It will
	address all phases and aspects of media handling in a conferencing		address all phases and aspects of media handling in a conferencing
	service including announcements and IVR functionality.		service including announcements and IVR functionality.
	Table of Contents		Table of Contents
	1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Media Control Requirements . . . . . . . . . . . . . . . . 4		3.1. Media Control Requirements . . . . . . . . . . . . . . . . 4
	3.2. Operational Requirements . . . . . . . . . . . . . . . . . 5		3.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		3.3. Operational Requirements . . . . . . . . . . . . . . . . . 6
	5. Changes from previous . . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5		5. Changes from Version-01 . . . . . . . . . . . . . . . . . . . 6
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 5		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6.2. Informative References . . . . . . . . . . . . . . . . . . 6		6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
			6.2. Informative References . . . . . . . . . . . . . . . . . . 7
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	Intellectual Property and Copyright Statements . . . . . . . . . . 10		Intellectual Property and Copyright Statements . . . . . . . . . . 10
	1. Overview		1. Overview
	The IETF XCON conferencing framework presents an architecture that is		The IETF XCON conferencing framework presents an architecture that is
	built of several functional entities. The framework document does		built of several functional entities. The framework document does
	not specify the protocols between the functional entities since it is		not specify the protocols between the functional entities since it is
	considered out of scope.		considered out of scope.
	There is an interest to work on a protocol that will enable one		There is an interest to work on a protocol that will enable one
	physical entity that includes the media policy server, notification		physical entity that includes the media policy server, notification
	server and the focus to interact with one or more physical entities		server and the focus to interact with one or more physical entities
	that serves as mixer or media server.		that serves as mixer or media server.
	The document will present the requirements for such a protocol. It		The document will present the requirements for such a protocol. It
	will address all phases and aspects of media handling in a enhanced		will address all phases and aspects of media handling in a enhanced
	conferencing service including announcements and IVR functionality.		conferencing service including announcements and IVR functionality.
	The following items are out of scope of this document:		The following items are out of scope of this document:
	Media session establishment.		Mechanism for MS to advertise its capabilities and other
	Mechanism for MS to advertise its capabilities.		attributes (e.g, Geolocation).
	Mechanism for the AS to discsover a MS.		Mechanism for the AS to discover a MS.
	Ability to move an existing conference from the current Media		Ability to move an existing conference from the current Media
	Servers supporting it to other Media Servers, where the latter		Servers supporting it to other Media Servers, where the latter
	have been identified to the AS.		have been identified to the AS.
	2. Terminology		2. Terminology
	The Media Server work uses when appropriate and expands on the		The Media Server work uses when appropriate and expands on the
	terminology introduced in the SIP conferencing framework and XCON		terminology introduced in the SIP conferencing framework and XCON
	conferencing framework. The following additional terms are defined		conferencing framework. The following additional terms are defined
	for use within the Media Server work.		for use within the Media Server work.
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 9 ¶
	event related information from the MS to the AS.		event related information from the MS to the AS.
	Request - A request is sent from the controlling entity, such as an		Request - A request is sent from the controlling entity, such as an
	Application Server, to another resource, such as a Media Server,		Application Server, to another resource, such as a Media Server,
	asking that a particular type of operation be executed.		asking that a particular type of operation be executed.
	Response - A response is used to signal information such as an		Response - A response is used to signal information such as an
	acknowledgement or error code in reply to a previously issued		acknowledgement or error code in reply to a previously issued
	request.		request.
			Need to add additional definitions
	3. Requirements		3. Requirements
	3.1. Media Control Requirements		3.1. Media Control Requirements
	The following are the media control requirements:		The following are the media control requirements:
	REQ-MCP-01 - There MUST be a requirement for a control protocol that		REQ-MCP-01 - There MUST be a requirement for a control protocol that
	will enable one or more Application Servers to control a media		will enable one or more Application Servers to control a media
	server.		server.
	REQ-MCP-02 The protocol MUST be independent from the transport		REQ-MCP-02 The protocol MUST be independent from the transport
	protocol.		protocol.
	REQ-MCP-03 The protocol MUST use a reliable transport protocol.		REQ-MCP-03 The protocol MUST use a reliable transport protocol.
	REQ-MCP-04 - The application scope of the protocol shall include		REQ-MCP-04 - The application scope of the protocol shall include
	Enhanced Conferencing Control and Interactive Voice Response.		Enhanced Conferencing Control and Interactive Voice Response.
	Though the protocol enables these services, the functionality is
	invoked through other mechanisms.		Though the protocol enables these services, the functionality is
			invoked through other mechanisms.
	REQ-MCP-05 - The protocol will utilize an XML markup language.		REQ-MCP-05 - The protocol will utilize an XML markup language.
	REQ-MCP-06 - A Media Server SHOULD be application/service		REQ-MCP-06 - A Media Server SHOULD be application/service
	independent. It should be possible to have a many-to-many		independent. It should be possible to have a many-to-many
	relationship between Application Servers and Media Servers that		relationship between Application Servers and Media Servers that
	use this protocol.		use this protocol.
	REQ-MCP-07 - Media types that are supported in the context of the		REQ-MCP-07 - Media types that are supported in the context of the
	applications shall include audio, tones and video.		applications shall include audio, tones, text and video.
	REQ-MCP-08 - The protocol should allow, but must not require, a media		REQ-MCP-08 - The protocol should allow, but must not require, a media
	server resource broker or intermediate proxy to exist between the		server resource broker or intermediate proxy to exist between the
	Application Server and Media Server.		Application Server and Media Server.
	REQ-MCP-09 - One channel could control multiple conferences, but you		REQ-MCP-09 - The solution MUST enable one control channel between an
	could have multiple channels controlling one or more conferences.		AS and MS, and shall allow for the support of multiple channels.
	There can be a connection per conference or one connection from
	the AS to MS for controlling many conferences		One channel could control multiple conferences, but you could have
			multiple channels controlling one or more conferences.
			There can be a connection per conference or one connection from the
			AS to MS for controlling many conferences
	REQ-MCP-10 - On the control channel, there shall be requests to the		REQ-MCP-10 - On the control channel, there shall be requests to the
	MS, responses from the MS and notifications to the AS.		MS, responses from the MS and notifications to the AS.
	REQ-MCP-11 - SIP SHALL be used to establish and modify RTP		REQ-MCP-11 - SIP/SDP SHALL be used to establish and modify RTP
	connections to a Media Server.		connections to a Media Server.
	REQ-MCP-12 - It should be possible to support a single conference		REQ-MCP-12 - It should be possible to support a single conference
	spanning multiple Media Servers.		spanning multiple Media Servers.
	Note: The previous draft used "must". It is probably true that		Note: The previous draft used "must". It is probably true that
	spanning multiple MSes can be accomplished by the AS and does not		spanning multiple MSes can be accomplished by the AS and does not
	require anything in the protocol for the scenarios we have in		require anything in the protocol for the scenarios we have in
	mind. However, the concern is that if this requirement is treated		mind. However, the concern is that if this requirement is treated
	too lightly, one may end up with a protocol that precludes its		too lightly, one may end up with a protocol that precludes its
	support. Therefore, we are reluctant to weaken this requirement		support. Therefore, we are reluctant to weaken this requirement
	any further than "should".		any further than "should".
	REQ-MCP-13 - It must be possible to split call legs individually or		REQ-MCP-13 - It must be possible to split call legs individually or
	in groups away from a main conference on a given Media Server,		in groups away from a main conference on a given Media Server,
	without performing SIP re-establishment of the call legs to the MS		without performing SIP re-establishment of the call legs to the MS
	(e.g., for purposes such as performing IVR with a single call leg		(e.g., for purposes such as performing IVR with a single call leg
	or creating sub-conferences, not for creating entirely new		or creating sub-conferences, not for creating entirely new
	conferences).		conferences).
	REQ-MCP-14 - The protocol should be extendable, facilitating forward		REQ-MCP-14 - The protocol should be extendable, facilitating forward
	and backward compatability.		and backward compatibility.
	3.2. Operational Requirements		REQ-MCP-15 - The protocol shall include security mechanisms.
	REQ-MCP-15 - The AS-MS control protocol must allow the AS to audit		REQ-MCP-16 - During session establishment, there shall be a
	the MS state.		capability to negotiate parameters that are associated with media
			streams.
			REQ-MCP-17 - The AS shall be able to define operations that the MS
			will perform on streams like mute and gain control.
			REQ-MCP-18 - The AS shall be able to instruct the MS to play a
			specific announcement.
			REQ-MCP-19 - The MS shall be able to retrieve announcements from an
			external connection.
			REQ-MCP-20 - The MS shall be able to request the MS to create,
			delete, and manipulate a mixing, IVR or announcement session.
			REQ-MCP-21 - The AS shall be able to tell the MS if the message can
			be delayed if the MS cannot play it immediately.
			REQ-MCP-22 - The AS shall be able to instruct the MS to play
			announcements to a single user or to a conference mix.
			3.2.
			Media Mixing Requirements are for further discussion.
			3.3. Operational Requirements
			REQ-MCP-23 - The AS-MS control protocol must allow the AS to audit
			the MS state, during an active session.
			REQ-MCP-24 - The MS shall be able to inform the AS about its status
			during an active session.
	4. Security Considerations		4. Security Considerations
	As an XML markup, all of the security considerations of RFC3023		As an XML markup, all of the security considerations of RFC3023
	[RFC3023] and RFC3406 [RFC3406] must be met. Pay particular		[RFC3023] and RFC3406 [RFC3406] must be met. Pay particular
	attention to the robustness requirements of parsing XML.		attention to the robustness requirements of parsing XML.
	5. Changes from previous		The protocol shall include security mechanisms.
			5. Changes from Version-01
			The document was updated per the notes from the BOF meeting in March,
			and comments from Roni Even.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[I-D.ietf-sip-gruu]		[I-D.ietf-sip-gruu]
	Rosenberg, J., "Obtaining and Using Globally Routable User		Rosenberg, J., "Obtaining and Using Globally Routable User
	Agent (UA) URIs (GRUU) in the Session Initiation Protocol		Agent (UA) URIs (GRUU) in the Session Initiation Protocol
	(SIP)", draft-ietf-sip-gruu-01 (work in progress),		(SIP)", draft-ietf-sip-gruu-01 (work in progress),
	February 2004.		February 2004.
	skipping to change at page 9, line 28 ¶		skipping to change at page 9, line 28 ¶
	AT&T Labs		AT&T Labs
	200 Laurel Avenue		200 Laurel Avenue
	Middletown, NJ 07748		Middletown, NJ 07748
	USA		USA
	Phone:		Phone:
	Email: gamunson@att.com		Email: gamunson@att.com
	URI:		URI:
	James Rafferty		James Rafferty
	Brooktrout		Cantata
	410 First Avenue		410 First Avenue
	Needham, MA 02494		Needham, MA 02494
	US		US
	Phone:		Phone:
	Email: jraff@brooktrout.com		Email: jraff@cantata.com
	URI:		URI:
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 17 change blocks.
	30 lines changed or deleted		74 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/