[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-dolly-mediactrl-requirements) 00 01 02 03 04 RFC 5167

Mediactrl                                                       M. Dolly
Internet-Draft                                                 AT&T Labs
Intended status: Informational                                   R. Even
Expires: April 25, 2008                                          Polycom
                                                        October 23, 2007

               Media Server Control Protocol Requirements

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   This document addresses the communication between an application
   server and media server.  The current work in IETF 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 April 25, 2008                 [Page 1]

Internet-Draft              MCP Requirements                October 2007

   server.  It will address the aspects of announcements, Interactive
   Voice Response 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  . . . . . . . . . . . . . . . . . . . . . 7
     3.4.  Operational Requirements  . . . . . . . . . . . . . . . . . 7
   4.  IANA consideration  . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9

Dolly & Even             Expires April 25, 2008                 [Page 2]

Internet-Draft              MCP Requirements                October 2007

1.  Introduction

   The IETF conferencing framework in 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
   (AS) to interact with one or more physical entities, called Media
   Server (MS), that serves as mixer or media server.

   The Media server can also be used for announcements and Interactive
   Voice Response (IVR) functions.

   An example of 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",
   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 conferencing framework[CARCH] and
   Centralized Conferencing (XCON) conferencing
   framework[xcon-framework].  The following additional terms are

   Application Server (AS) - A functional entity that hosts one or more
   instances of a communications application.  The application server
   may include the conference policy server, the focus and the
   conference notification server as defined in [CARCH].  It may include
   also communication applications that use IVR or announcements

Dolly & Even             Expires April 25, 2008                 [Page 3]

Internet-Draft              MCP Requirements                October 2007

   Media Server (MS) - The media server includes the mixer as defined in
   [CARCH].  The media server source media streams for announcements, it
   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

   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

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 request media services from 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

   REQ-MCP-04 -  The application supported by 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.

Dolly & Even             Expires April 25, 2008                 [Page 4]

Internet-Draft              MCP Requirements                October 2007

   REQ-MCP-05 -  Media types supported in the context of the
      applications shall include audio, tones, text and video.

   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-08 -  On the MS control channel, there shall be requests to
      the MS, responses from the MS and notifications to the AS.

   REQ-MCP-09 -  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

   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

   REQ-MCP-14 -  During session establishment, there shall be a
      capability to negotiate parameters that are associated with media
      streams.  This requirement should enable also an AS managing
      conference to specify the media streams allowed in the conference.

Dolly & Even             Expires April 25, 2008                 [Page 5]

Internet-Draft              MCP Requirements                October 2007

   REQ-MCP-15 -  The AS shall be able to define operations that the MS
      will perform on streams like mute and gain control.

   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.  The report may include resources
      usage and quality metrics.

   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

   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 and who is being viewed in a conference.  The speaker and
      the video source may be different, for example a person describing
      a video stream from a remote camera managed by a different user.

   REQ-MCP-26 -  The MS shall be able to inform the AS which layouts it

   REQ-MCP-27 -  The MS control protocol should enable the AS to
      instruct the MS to record a specific conference mix.

Dolly & Even             Expires April 25, 2008                 [Page 6]

Internet-Draft              MCP Requirements                October 2007

3.3.  IVR Requirements

   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
      a server or contained in the control message.

   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
      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
      it receives from the MS on the current phase.

   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
      recording requirement.

3.4.  Operational Requirements

   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.

   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 protocols that will meet the requirements described in this
   document will extend existing standards-track IETF protocols, and
   will not create additional security issues beyond the security
   considerations required for these existing protocols.

6.  Acknowledgment

   This draft represents the work from two previous presonal drafts,
   draft-dolly-xcon-mediacntrlframe-02 and
   draft-even-media-server-req-02.  The authors would like to
   acknowledge the work of Gary Munson from AT &T Labs and James
   Rafferty from Cantata who helped with drafting

Dolly & Even             Expires April 25, 2008                 [Page 7]

Internet-Draft              MCP Requirements                October 2007

   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.

              Melanchuk, T., "An Architectural Framework for Media
              Server Control", draft-ietf-mediactrl-architecture-00
              (work in progress), October 2007.

              Barnes, M., "A Framework for Centralized Conferencing",
              draft-ietf-xcon-framework-09 (work in progress),
              August 2007.

Authors' Addresses

   Martin Dolly
   AT&T Labs
   200 Laurel Avenue
   Middletown, NJ  07748

   Email: mdolly@att.com

   Roni Even
   94 Derech Em Hamoshavot
   Petach Tikva  49130

   Email: roni.even@polycom.co.il

Dolly & Even             Expires April 25, 2008                 [Page 8]

Internet-Draft              MCP Requirements                October 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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Dolly & Even             Expires April 25, 2008                 [Page 9]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/