Mediactrl M. Dolly
Internet-Draft AT&T Labs
Intended status: Informational R. Even
Expires: December 14, 2007 Polycom
June 12, 2007
Media Server Control Protocol Requirements
draft-dolly-mediactrl-requirements-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 14, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document addresses the communication between an application
server and media server. The current work in SIPPING and XCON
working groups show these logical entities but do not address the
physical decomposition and the protocol between the entities.
This document presents the requirements from a media server control
protocol (MCP) that enables an application server to use a media
Dolly & Even Expires December 14, 2007 [Page 1]
Internet-Draft MCP Requirements June 2007
server. It will address the aspects of announcements, IVR and
conferencing media services.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Media Control Requirements . . . . . . . . . . . . . . . . 4
3.2. Media mixing Requirements . . . . . . . . . . . . . . . . . 6
3.3. IVR Requirements . . . . . . . . . . . . . . . . . . . . . 6
3.4. Operational Requirements . . . . . . . . . . . . . . . . . 7
4. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Dolly & Even Expires December 14, 2007 [Page 2]
Internet-Draft MCP Requirements June 2007
1. Introduction
The IETF SIPPING conferencing framework RFC 4353[CARCH] presents an
architecture that is built of several functional entities. The
framework document does not specify the protocols between the
functional entities since it is considered out of scope.
There is an interest to work on a protocol that will enable one
physical entity that includes the conference/media policy server,
notification server and the focus also known as Application server to
interact with one or more physical entities, called Media Server,
that serves as mixer or media server.
The Media server may also be used for announcements and IVR
(Interactive Voice Response) functions.
The decomposition to a media server and application server is
described in the media control framework document[mediactrl-fw].
This document presents the requirements from a media server control
protocol (MCP) that enables an application server to use a media
server. It will address the aspects of announcements, IVR and
conferencing media services.
The requirements are from the protocol and do not address the AS or
MS functionality discussed in the media control framework.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119[RFC2119] and
indicate requirement levels for compliant RTP implementations.
The Media Server work uses, when appropriate, and expands on the
terminology introduced in the SIP conferencing framework[CARCH] and
XCON conferencing framework[xcon-framework]. The following
additional terms are defined:
Application Server (AS) - A functional entity that hosts one or more
instances of a communications application. The application server
includes the conference policy server, the focus and the conference
notification server as defined in [CARCH]. It can include also
communication applications that use IVR or announcements services.
Media Server (MS) - The media server includes the mixer as defined in
[CARCH]. The media server source media streams for announcements, it
Dolly & Even Expires December 14, 2007 [Page 3]
Internet-Draft MCP Requirements June 2007
process media streams for functions like DTMF detection and
transcoding. The media server may also record media streams for
supporting IVR functions like announcing participants
Media Resource Broker (MRB) - A logical entity that is responsible
for both collection of appropriate published Media Server (MS)
information and supplying of appropriate MS information to consuming
entities.
Notification - A notification is used when there is a need to report
event related information from the MS to the AS.
Request - A request is sent from the controlling entity, such as an
Application Server, to another resource, such as a Media Server,
asking that a particular type of operation be executed.
Response - A response is used to signal information such as an
acknowledgement or error code in reply to a previously issued
request.
3. Requirements
3.1. Media Control Requirements
The following are the media control requirements:
REQ-MCP-01 - The MS control protocol SHALL enable one or more
Application Servers to control one or more media servers.
REQ-MCP-02 The MS control protocol SHALL be independent from the
transport protocol.
REQ-MCP-03 The MS control protocol SHALL use a reliable transport
protocol.
REQ-MCP-04 - The application scope of the protocol shall include
Conferencing and Interactive Voice Response media services.
Note: Though the protocol enables these services, the functionality
is invoked through other mechanisms.
REQ-MCP-05 - Media types supported in the context of the
applications shall include audio, tones, text and video.
Dolly & Even Expires December 14, 2007 [Page 4]
Internet-Draft MCP Requirements June 2007
REQ-MCP-06- The MS control protocol should allow, but must not
require, a media resource broker (MRB) or intermediate proxy to
exist with the Application Server and Media Server.
REQ-MCP-07 - The solution MUST enable one control channel between an
AS and MS, and SHOULD allow for the support of multiple channels.
One control channel could control multiple sessions, but you could
have multiple control channels controlling one or more sessions.
REQ-MCP-8 - On the MS control channel, there shall be requests to
the MS, responses from the MS and notifications to the AS.
REQ-MCP-9 - SIP/SDP SHALL be used to establish and modify media
connections to a Media Server.
REQ-MCP-10 - It should be possible to support a single conference
spanning multiple Media Servers.
Note: It is probable that spanning multiple MS can be accomplished
by the AS and does not require anything in the protocol for the
scenarios we have in mind. However, the concern is that if this
requirement is treated too lightly, one may end up with a protocol
that precludes its support.
REQ-MCP-11 - It must be possible to split call legs individually or
in groups away from a main conference on a given Media Server,
without performing re-establishment of the call legs to the MS
(e.g., for purposes such as performing IVR with a single call leg
or creating sub-conferences, not for creating entirely new
conferences).
REQ-MCP-12 - The MS control protocol should be extendable,
facilitating forward and backward compatibility.
REQ-MCP-13 - The MS control protocol shall include security
mechanisms.
REQ-MCP-14 - During session establishment, there shall be a
capability to negotiate parameters that are associated with media
streams.
REQ-MCP-15 - The AS shall be able to define operations that the MS
will perform on streams like mute and gain control.
Dolly & Even Expires December 14, 2007 [Page 5]
Internet-Draft MCP Requirements June 2007
REQ-MCP-16 - The AS shall be able to instruct the MS to play a
specific announcement.
REQ-MCP-17 - The AS shall be able to request the MS to create,
delete, and manipulate a mixing, IVR or announcement session.
REQ-MCP-18 - The AS shall be able to instruct the MS to play
announcements to a single user or to a conference mix.
REQ-MCP-19 - The MS control protocol SHOULD enable the AS to ask the
MS for session summary report.
REQ-MCP-20 - The MS shall be able to notify the AS of events
received in the media stream if requested by AS. (Examples - STUN
request, Flow Control, etc.)
3.2. Media mixing Requirements
REQ-MCP-21 - The AS shall be able to define a conference mix.
REQ-MCP-22 - The AS may be able to define a separate mix for each
participant.
REQ-MCP-23 - The AS may be able to define a custom video layout
built of rectangular sub windows.
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
stream will go to each sub window. The number of sub-windows will
start from one.
REQ-MCP-25 - The MS shall be able to notify the AS who is the active
speaker.
REQ-MCP-26 - The MS shall be able to inform the AS which layouts it
supports.
REQ-MCP-27 - The MS control protocol should enable the AS to
instruct the MS to record a specific conference mix.
3.3. IVR Requirements
REQ-MCP-28 - The AS shall be able to load one or more IVR script to
the MS and receive the results.
Dolly & Even Expires December 14, 2007 [Page 6]
Internet-Draft MCP Requirements June 2007
REQ-MCP-29 - The AS shall be able to mange the IVR session by
sending announcements and receiving the response (e.g., DTMF).
REQ-MCP-30 - The AS should be able to instruct the MS to record a
short participant stream and play it back to the conference. This
is not a recording requirement.
3.4. Operational Requirements
These requirements may be applicable to the MRB.
REQ-MCP-31 - The MS control protocol must allow the AS to audit the
MS state, during an active session.
REQ-MCP-32 - The MS shall be able to inform the AS about its status
during an active session.
4. IANA consideration
There are no IANA considerations.
5. Security Considerations
The protocol shall include security mechanisms.
6. Acknowledgment
would also like to acknowledge the work of Gary Munson from AT &T
Labs and James Rafferty from Cantata who helped with drafting
draft-dolly-xcon-mediacntrlframe-02 on which this work is based.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[CARCH] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
February 2006.
Dolly & Even Expires December 14, 2007 [Page 7]
Internet-Draft MCP Requirements June 2007
[mediactrl-fw]
Melanchuk, T., "An Architectural Framework for Media
Server Control", draft-melanchuk-mediactrl-framework-00
(work in progress), June 2007.
[xcon-framework]
Barnes, M., "A Framework for Centralized Conferencing",
draft-ietf-xcon-framework-08 (work in progress), May 2007.
Authors' Addresses
Martin Dolly
AT&T Labs
200 Laurel Avenue
Middletown, NJ 07748
USA
Phone:
Email: mdolly@att.com
URI:
Roni Even
Polycom
94 Derech Em Hamoshavot
Petach Tikva 49130
Israel
Email: roni.even@polycom.co.il
Dolly & Even Expires December 14, 2007 [Page 8]
Internet-Draft MCP Requirements June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Dolly & Even Expires December 14, 2007 [Page 9]