< draft-ietf-mediactrl-requirements-03.txt		draft-ietf-mediactrl-requirements-04.txt >
	Mediactrl M. Dolly		Mediactrl M. Dolly
	Internet-Draft AT&T Labs		Internet-Draft AT&T Labs
	Intended status: Informational R. Even		Intended status: Informational R. Even
	Expires: July 2, 2008 Polycom		Expires: August 27, 2008 Polycom
	December 30, 2007		February 24, 2008
	Media Server Control Protocol Requirements		Media Server Control Protocol Requirements
	draft-ietf-mediactrl-requirements-03.txt		draft-ietf-mediactrl-requirements-04.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 35 ¶
	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 July 2, 2008.		This Internet-Draft will expire on August 27, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document addresses the communication between an application		This document addresses the communication between an application
	server and media server. The current work in IETF working groups		server and media server. The current work in IETF working groups
	shows these logical entities but does not address the physical		shows these logical entities but does not address the physical
	decomposition and the protocol between the entities.		decomposition and the protocol between the entities.
	This document presents the requirements for a media server control		This document presents the requirements for a media server control
	protocol (MCP) that enables an application server to use a media		protocol (MCP) that enables an application server to use a media
	server. It will address the aspects of announcements, Interactive		server. It will address the aspects of announcements, Interactive
	Voice Response and conferencing media services.		Voice Response and conferencing media services.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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. Media mixing Requirements . . . . . . . . . . . . . . . . . 6		3.2. Media mixing Requirements . . . . . . . . . . . . . . . . 6
	3.3. IVR Requirements . . . . . . . . . . . . . . . . . . . . . 6		3.3. IVR Requirements . . . . . . . . . . . . . . . . . . . . . 7
	3.4. Operational Requirements . . . . . . . . . . . . . . . . . 7		3.4. Operational Requirements . . . . . . . . . . . . . . . . . 7
	4. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 7		4. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 7		6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 8
	7. Informative References . . . . . . . . . . . . . . . . . . . . 7		7. Informative References . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
	Intellectual Property and Copyright Statements . . . . . . . . . . 9		Intellectual Property and Copyright Statements . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The IETF conferencing framework in RFC 4353[CARCH] presents an		The IETF conferencing framework in RFC4353[CARCH] presents an
	architecture that is built of several functional entities. The		architecture that is built of several functional entities.
	framework document does not specify the protocols between the		RFC4353[CARCH] does not specify the protocols between the functional
	functional entities since it is considered out of scope.		entities since it is considered out of scope.
	There is an interest to work on a protocol that will enable one		Based on RFC4353 [CARCH] the document defines the requirements for a
	physical entity, known as an Application Server (AS), that includes		protocol that will enable one functional entity, known as an
	the conference/media policy server, the notification server and the		Application Server (AS), that includes the conference/media policy
	focus to interact with one or more physical entities, called Media		server, the notification server and the focus, all defined in RFC
	Server (MS), that serves as mixer or media server.		4353[CARCH], to interact with one or more functional entities, called
			Media Server (MS), that serves as mixer or media server.
	The Media server can also be used for announcements and Interactive		The Media server can also be used for announcements and Interactive
	Voice Response (IVR) functions.		Voice Response (IVR) functions.
	An example of the decomposition of a media server and an application		Application Servers host one or more instances of a communications
	server is described in the media control framework		application. Media servers provide real time media processing
			functions. An example of the decomposition of a media server and an
			application server is described in the media control framework
	document[mediactrl-fw].		document[mediactrl-fw].
	This document presents the requirements for a media server control		This document presents the requirements for a media server control
	protocol (MCP) that enables an application server to use a media		protocol (MCP) that enables an application server to control a media
	server. It will address the aspects of announcements, IVR and		server. It will address the aspects of announcements, IVR and
	conferencing media services.		conferencing media services.
	The requirements are for the protocol and do not address the AS or MS		The requirements are for the protocol and do not address the AS or MS
	functionality discussed in the media control framework.		functionality discussed in the media control framework.
			Since the media server is a centralized component, the charter of the
			working group states that this work will not investigate distributed
			media processing algorithms or control protocols.
	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 conferencing framework[CARCH] and		terminology introduced in the conferencing framework[CARCH] and
	Centralized Conferencing (XCON) conferencing		Centralized Conferencing (XCON) conferencing
	framework[xcon-framework]. The following additional terms are		framework[xcon-framework]. The following additional terms are
	defined:		defined:
	Application Server (AS) - A functional entity that hosts one or more		Application Server (AS) - A functional entity that hosts one or more
	instances of a communications application. The application server		instances of a communications application. The application server
	may include the conference policy server, the focus and the		may include the conference policy server, the focus and the
	conference notification server as defined in [CARCH]. It may include		conference notification server as defined in [CARCH]. It may include
	also communication applications that use IVR or announcements		also communication applications that use IVR or announcements
	services.		services.
	Media Server (MS) - The media server includes the mixer as defined in		Media Server (MS) - The media server includes the mixer as defined in
	[CARCH]. The media server plays announcements, it process media		[CARCH]. The media server plays announcements, it processes media
	streams for functions like DTMF detection and transcoding. The media		streams for functions like DTMF detection and transcoding. The media
	server may also record media streams for supporting IVR functions		server may also record media streams for supporting IVR functions
	like announcing participants		like announcing participants
	Media Resource Broker (MRB) - A logical entity that is responsible		Media Resource Broker (MRB) - A logical entity that is responsible
	for both collection of appropriate published Media Server (MS)		for both collection of appropriate published Media Server (MS)
	information and supplying of appropriate MS information to consuming		information and supplying of appropriate MS information to consuming
	entities.		entities. The MRB is an optional entity and will be discussed in a
			separate document.
	Notification - A notification is used when there is a need to report		Notification - A notification is used when there is a need to report
	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.
	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 - The MS control protocol shall enable one or more		REQ-MCP-01 - The MS Control Protocol shall enable one or more
	Application Servers to request media services from one or more		Application Servers to request media services from one or more
	media servers.		Media Servers.
	REQ-MCP-02 The MS control protocol shall use a reliable transport		REQ-MCP-02 The MS Control Protocol shall use a reliable transport
	protocol.		protocol.
	REQ-MCP-03 - The applications supported by the protocol shall		REQ-MCP-03 - The applications supported by the protocol shall
	include Conferencing and Interactive Voice Response media		include Conferencing and Interactive Voice Response media
	services.		services.
	Note: Though the protocol enables these services, the functionality		Note: Though the protocol enables these services, the functionality
	is invoked through other mechanisms.		is invoked through other mechanisms.
	REQ-MCP-04 - Media types supported in the context of the		REQ-MCP-04 - Media types supported in the context of the
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 46 ¶
	facilitating forward and backward compatibility.		facilitating forward and backward compatibility.
	REQ-MCP-11 - The MS control protocol shall include an authentication		REQ-MCP-11 - The MS control protocol shall include an authentication
	component to ensure that only an authorized AS can communicate		component to ensure that only an authorized AS can communicate
	with the MS and vice versa.		with the MS and vice versa.
	REQ-MCP-12 - The MS control protocol shall use some form of		REQ-MCP-12 - The MS control protocol shall use some form of
	transport protection to ensure the confidentiality and integrity		transport protection to ensure the confidentiality and integrity
	of the data between the AS and MS.		of the data between the AS and MS.
	REQ-MCP-13 - The MS control protocol requires mechanisms to protect		REQ-MCP-13 - Different Application Servers may have different
			privileges for using a MS. The protocol should prevent the AS for
			doing unauthorized operations on a MS.
			REQ-MCP-14 - The MS control protocol requires mechanisms to protect
	the MS resources used by one AS from another AS since the solution		the MS resources used by one AS from another AS since the solution
	need to support multiple AS controlling one MS.		need to support multiple AS controlling one MS.
	REQ-MCP-14 - During session establishment, there shall be a		REQ-MCP-15 - During session establishment, there shall be a
	capability to negotiate parameters that are associated with media		capability to negotiate parameters that are associated with media
	streams. This requirement should enable also an AS managing		streams. This requirement should enable also an AS managing
	conference to specify the media streams allowed in the conference.		conference to specify the media streams allowed in the conference.
	REQ-MCP-15 - The AS shall be able to define operations that the MS		REQ-MCP-16 - The AS shall be able to instruct the MS to perform
	will perform on streams like mute and gain control.		streams operations like mute and gain control.
	REQ-MCP-16 - The AS shall be able to instruct the MS to play a		REQ-MCP-17 - The AS shall be able to instruct the MS to play a
	specific announcement.		specific announcement.
	REQ-MCP-17 - The AS shall be able to request the MS to create,		REQ-MCP-18 - The AS shall be able to request the MS to create,
	delete, and manipulate a mixing, IVR or announcement session.		delete, and manipulate a mixing, IVR or announcement session.
	REQ-MCP-18 - The AS shall be able to instruct the MS to play		REQ-MCP-19 - The AS shall be able to instruct the MS to play
	announcements to a single user or to a conference mix.		announcements to a single user or to a conference mix.
	REQ-MCP-19 - The MS control protocol should enable the AS to ask the		REQ-MCP-20 - The MS control protocol should enable the AS to ask the
	MS for session summary report. The report may include resources		MS for session summary report. The report may include resources
	usage and quality metrics.		usage and quality metrics.
	REQ-MCP-20 - The MS shall be able to notify the AS of events		REQ-MCP-21 - The MS shall be able to notify the AS of events
	received in the media stream if requested by AS. (Examples - STUN		received in the media stream if requested by AS. (Examples - STUN
	request, Flow Control, etc.)		request, Flow Control, etc.)
	3.2. Media mixing Requirements		3.2. Media mixing Requirements
	REQ-MCP-21 - The AS shall be able to define a conference mix, MS may		REQ-MCP-22 - The AS shall be able to define a conference mix, MS may
	offer different mixing topologies. The conference mix may be		offer different mixing topologies. The conference mix may be
	defined on a conference or user level.		defined on a conference or user level.
	REQ-MCP-22 - The AS may be able to define a custom video layout		REQ-MCP-23 - The AS may be able to define a custom video layout
	built of rectangular sub windows.		built of rectangular sub windows.
	REQ-MCP-23 - For video the AS shall be able to map a stream to a		REQ-MCP-24 - For video the AS shall be able to map a stream to a
	specific sub-window or to define to the MS how to decide which		specific sub-window or to define to the MS how to decide which
	stream will go to each sub window.		stream will go to each sub window.
	REQ-MCP-24 - The MS shall be able to notify the AS who is the active		REQ-MCP-25 - The MS shall be able to notify the AS who are the
	speaker and who is being viewed in a conference. The speaker and		active sources of the media; for example who is the active speaker
	the video source may be different, for example a person describing		or who is being viewed in a conference. The speaker and the video
	a video stream from a remote camera managed by a different user.		source may be different, for example a person describing a video
			stream from a remote camera managed by a different user.
	REQ-MCP-25 - The MS shall be able to inform the AS which layouts it		REQ-MCP-26 - The MS shall be able to inform the AS which layouts it
	supports.		supports.
	REQ-MCP-26 - The MS control protocol should enable the AS to		REQ-MCP-27 - The MS control protocol should enable the AS to
	instruct the MS to record a specific conference mix.		instruct the MS to record a specific conference mix.
	3.3. IVR Requirements		3.3. IVR Requirements
	REQ-MCP-27 - The AS shall be able to instruct the MS to perform one		REQ-MCP-28 - The AS shall be able to instruct the MS to perform one
	or more IVR script and receive the results. The script may be in		or more IVR script and receive the results. The script may be in
	a server or contained in the control message.		a server or contained in the control message.
	REQ-MCP-28 - The AS shall be able to manage the IVR session by		REQ-MCP-29 - The AS shall be able to manage the IVR session by
	sending requests to play announcements to the MS and receiving the		sending requests to play announcements to the MS and receiving the
	response (e.g., DTMF). The IVR session flow in this case is		response (e.g., DTMF). The IVR session flow in this case is
	handled by the AS by starting a next phase based on the response		handled by the AS by starting a next phase based on the response
	it receives from the MS on the current phase.		it receives from the MS on the current phase.
	REQ-MCP-29 - The AS should be able to instruct the MS to record a		REQ-MCP-30 - The AS should be able to instruct the MS to record a
	short participant stream and play it back. This is not a		short participant stream and play it back. This is not a
	recording requirement.		recording requirement.
	3.4. Operational Requirements		3.4. Operational Requirements
	These requirements may be applicable to the MRB but can be used by an		These requirements may be applicable to the MRB but can be used by an
	AS if it has one to one connection to the MS.		AS if it has one to one connection to the MS.
	REQ-MCP-30 - The MS control protocol must allow the AS to audit the		REQ-MCP-31 - The MS control protocol must allow the AS to audit the
	MS state, during an active session.		MS state, during an active session.
	REQ-MCP-31 - The MS shall be able to inform the AS about its status		REQ-MCP-32 - The MS shall be able to inform the AS about its status
	during an active session.		during an active session.
	4. IANA consideration		4. IANA consideration
	There are no IANA considerations.		There are no IANA considerations.
	5. Security Considerations		5. Security Considerations
	The protocols that will meet the requirements described in this		This document discusses high-level requirements for MCP. The MCP has
	document will extend existing standards-track IETF protocols whose		some specific security requirements, which will be summarized here at
	security properties are well understood. Required security		a very high level.
	properties will be based on the available security tools.
			All of the operations and functions described in this document need
			to be authorized by a MS or a AS. It is expected that MS resources
			will be governed by a set of authorization rules defined as part of
			the AS / MS policy. In order for the policy to be implemented, the
			MS needs to be able to authenticate requests. Normal SIP mechanisms
			including Digest authentication and certificates can be used as
			specified in RFC3261[RFC3261] These MCP security requirements will be
			discussed in detail in the framework and protocol documents.
	6. Acknowledgment		6. Acknowledgment
	This draft represents the work from two previous personal drafts,		This draft represents the work from two previous personal drafts,
	draft-dolly-xcon-mediacntrlframe-02 and		draft-dolly-xcon-mediacntrlframe-02 and
	draft-even-media-server-req-02. The authors would like to		draft-even-media-server-req-02. The authors would like to
	acknowledge the work of Gary Munson from AT &T Labs and James		acknowledge the work of Gary Munson from AT &T Labs and James
	Rafferty from Cantata who helped with drafting		Rafferty from Cantata who helped with drafting
	draft-dolly-xcon-mediacntrlframe-02 on which this work is based.		draft-dolly-xcon-mediacntrlframe-02 on which this work is based.
	7. Informative References		7. Informative References
	[CARCH] Rosenberg, J., "A Framework for Conferencing with the		[CARCH] Rosenberg, J., "A Framework for Conferencing with the
	Session Initiation Protocol (SIP)", RFC 4353,		Session Initiation Protocol (SIP)", RFC 4353,
	February 2006.		February 2006.
			[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
			A., Peterson, J., Sparks, R., Handley, M., and E.
			Schooler, "SIP: Session Initiation Protocol", RFC 3261,
			June 2002.
	[mediactrl-fw]		[mediactrl-fw]
	Melanchuk, T., "An Architectural Framework for Media		Melanchuk, T., "An Architectural Framework for Media
	Server Control", draft-ietf-mediactrl-architecture-01		Server Control", draft-ietf-mediactrl-architecture-02
	(work in progress), November 2007.		(work in progress), February 2008.
	[xcon-framework]		[xcon-framework]
	Barnes, M., "A Framework for Centralized Conferencing",		Barnes, M., "A Framework for Centralized Conferencing",
	draft-ietf-xcon-framework-10 (work in progress),		draft-ietf-xcon-framework-10 (work in progress),
	November 2007.		November 2007.
	Authors' Addresses		Authors' Addresses
	Martin Dolly		Martin Dolly
	AT&T Labs		AT&T Labs
	skipping to change at page 9, line 7 ¶		skipping to change at page 10, line 7 ¶
	Roni Even		Roni Even
	Polycom		Polycom
	94 Derech Em Hamoshavot		94 Derech Em Hamoshavot
	Petach Tikva 49130		Petach Tikva 49130
	Israel		Israel
	Email: roni.even@polycom.co.il		Email: roni.even@polycom.co.il
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		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
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 38 change blocks.
	65 lines changed or deleted		91 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/