Network Working Group M. Dolly
Request for Comments: 5167 AT&T Labs
Category: Informational R. Even
Polycom
March 2008
Network Working Group M. Dolly
Request for Comments: 5167 AT&T Labs
Category: Informational R. Even
Polycom
March 2008
Media Server Control Protocol Requirements
媒体服务器控制协议要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document addresses the communication between an application server and media server. The current work in IETF working groups shows these logical entities, but it does not address the physical decomposition and the protocol between the entities.
本文档介绍应用程序服务器和媒体服务器之间的通信。IETF工作组的当前工作显示了这些逻辑实体，但它没有解决实体之间的物理分解和协议。
This document presents the requirements for a Media Server Control Protocol (MCP) that enables an application server to use a media server. It will address the aspects of announcements, Interactive Voice Response, and conferencing media services.
本文档介绍了媒体服务器控制协议（MCP）的要求，该协议允许应用服务器使用媒体服务器。它将涉及公告、交互式语音响应和会议媒体服务等方面。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Media Control Requirements . . . . . . . . . . . . . . . . 3
3.2. Media mixing Requirements . . . . . . . . . . . . . . . . . 5
3.3. IVR Requirements . . . . . . . . . . . . . . . . . . . . . 6
3.4. Operational Requirements . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Informative References . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Media Control Requirements . . . . . . . . . . . . . . . . 3
3.2. Media mixing Requirements . . . . . . . . . . . . . . . . . 5
3.3. IVR Requirements . . . . . . . . . . . . . . . . . . . . . 6
3.4. Operational Requirements . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Informative References . . . . . . . . . . . . . . . . . . . . 7
The IETF conferencing framework in RFC 4353 [CARCH] presents an architecture that is built of several functional entities. RFC 4353 [CARCH] does not specify the protocols between the functional entities since it is considered out of scope.
RFC 4353[CARCH]中的IETF会议框架提出了一种由多个功能实体构建的体系结构。RFC 4353[CARCH]未指定功能实体之间的协议，因为它被视为超出范围。
Based on RFC 4353 [CARCH], this document defines the requirements for a protocol that will enable one functional entity, known as an Application Server (AS), that includes the conference/media policy server, the notification server, and the focus, all defined in RFC 4353 [CARCH], to interact with one or more functional entities, called Media Server (MS), that serves as mixer or media server.
基于RFC 4353[CARCH]，本文件定义了协议要求，该协议将使一个功能实体（称为应用程序服务器（as））能够与一个或多个功能实体进行交互，该功能实体包括RFC 4353[CARCH]中定义的会议/媒体策略服务器、通知服务器和焦点，称为媒体服务器（MS），用作混音器或媒体服务器。
The media server can also be used for announcements and Interactive Voice Response (IVR) functions.
媒体服务器还可用于公告和交互式语音应答（IVR）功能。
Application servers host one or more instances of a communication 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].
应用服务器承载一个或多个通信应用程序实例。媒体服务器提供实时媒体处理功能。媒体控制框架文档[MEDIACTRL-FW]中描述了媒体服务器和应用服务器的分解示例。
This document presents the requirements for a Media Server Control Protocol (MCP) that enables an application server to control a media server. It will address the aspects of announcements, IVR, and conferencing media services.
本文档介绍了媒体服务器控制协议（MCP）的要求，该协议使应用程序服务器能够控制媒体服务器。它将涉及公告、IVR和会议媒体服务等方面。
The requirements are for the protocol and do not address the AS or MS functionality discussed in the media control framework.
这些要求是针对协议的，不涉及媒体控制框架中讨论的AS或MS功能。
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.
由于媒体服务器是一个集中式组件，工作组章程规定，这项工作不会研究分布式媒体处理算法或控制协议。
The media server work uses, when appropriate, and expands on the terminology introduced in the conferencing framework [CARCH] and Centralized Conferencing (XCON) framework [XCON-FRMWRK]. The following additional terms are defined:
媒体服务器工作在适当时使用并扩展了会议框架[CARCH]和集中会议（XCON）框架[XCON-FRMWRK]中引入的术语。定义了以下附加术语：
Application Server (AS) - A functional entity that hosts one or more instances of a communication application. The application server may include the conference policy server, the focus, and the conference notification server, as defined in [CARCH]. Also, it may include communication applications that use IVR or announcement services.
应用程序服务器（AS）-承载一个或多个通信应用程序实例的功能实体。应用服务器可以包括会议策略服务器、焦点和会议通知服务器，如[CARCH]中所定义。此外，它还可能包括使用IVR或公告服务的通信应用程序。
Media Server (MS) - The media server includes the mixer as defined in [CARCH]. The media server plays announcements, it processes media streams for functions like Dual Tone Multi-Frequency (DTMF) detection and transcoding. The media server may also record media streams for supporting IVR functions like announcing participants
媒体服务器（MS）-媒体服务器包括[CARCH]中定义的混音器。媒体服务器播放公告，处理媒体流以实现双音多频（DTMF）检测和转码等功能。媒体服务器还可以记录媒体流以支持IVR功能，例如宣布参与者
Media Resource Broker (MRB) - A logical entity that is responsible for both the collection of appropriate published Media Server (MS) information and supplying of appropriate MS information to consuming entities. The MRB is an optional entity and will be discussed in a separate document.
媒体资源代理（MRB）-一个逻辑实体，负责收集适当的已发布媒体服务器（MS）信息，并向使用实体提供适当的MS信息。MRB是一个可选实体，将在单独的文件中讨论。
Notification - A notification is used when there is a need to report event-related information from the MS to the AS.
通知-当需要从MS向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.
响应-响应用于发出信息信号，如回复先前发出的请求时的确认或错误代码。
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-01-MS控制协议应允许一个或多个应用服务器从一个或多个媒体服务器请求媒体服务。
REQ-MCP-02 - The MS Control Protocol shall use a reliable transport protocol.
REQ-MCP-02-MS控制协议应使用可靠的传输协议。
REQ-MCP-03 - The applications supported by the protocol shall include conferencing and Interactive Voice Response media services.
REQ-MCP-03-协议支持的应用应包括会议和交互式语音响应媒体服务。
Note: Though the protocol enables these services, the functionality is invoked through other mechanisms.
注意：尽管协议支持这些服务，但功能是通过其他机制调用的。
REQ-MCP-04 - Media types supported in the context of the applications shall include audio, tones, text, and video. Tones media include in-band audio or RFC 4733 payload.
REQ-MCP-04-应用环境中支持的媒体类型应包括音频、音调、文本和视频。音频媒体包括带内音频或RFC 4733有效负载。
REQ-MCP-05 - 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-05-MS控制协议应允许但不得要求媒体资源代理（MRB）或中间代理与应用程序服务器和媒体服务器共存。
REQ-MCP-06 - On the MS control channel, there shall be requests to the MS, responses from the MS, and notifications to the AS.
REQ-MCP-06-在MS控制通道上，应向MS发出请求、来自MS的响应以及向AS发出通知。
REQ-MCP-07 - SIP/SDP (Session Initiation Protocol / Session Description Protocol) shall be used to establish and modify media connections to a media server.
REQ-MCP-07-SIP/SDP（会话启动协议/会话描述协议）应用于建立和修改与媒体服务器的媒体连接。
REQ-MCP-08 - It should be possible to support a single conference spanning multiple media servers.
REQ-MCP-08-应该可以支持跨多个媒体服务器的单个会议。
Note: It is probable that spanning multiple MSs 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.
注：跨越多个MSs可能由AS完成，并且在我们考虑的场景中不需要协议中的任何内容。然而，令人担忧的是，如果对这一要求过于轻视，最终可能会有一个排除其支持的协议。
REQ-MCP-09 - 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-09-必须能够单独或成组地将呼叫分支从给定媒体服务器上的主会议中分离出来，而无需重新建立到MS的呼叫分支（例如，为了使用单个呼叫分支执行IVR或创建子会议，而不是为了创建全新的会议）。
REQ-MCP-10 - The MS control protocol should be extendable, facilitating forward and backward compatibility.
REQ-MCP-10-MS控制协议应可扩展，便于向前和向后兼容。
REQ-MCP-11 - The MS control protocol shall include an authentication component to ensure that only an authorized AS can communicate with the MS, and vice versa.
REQ-MCP-11-MS控制协议应包括一个认证组件，以确保只有授权AS才能与MS通信，反之亦然。
REQ-MCP-12 - The MS control protocol shall use some form of transport protection to ensure the confidentiality and integrity of the data between the AS and MS.
REQ-MCP-12-MS控制协议应使用某种形式的传输保护，以确保AS和MS之间数据的机密性和完整性。
REQ-MCP-13 - Different application servers may have different privileges for using an MS. The protocol should prevent the AS from doing unauthorized operations on a MS.
REQ-MCP-13-不同的应用程序服务器可能有不同的权限使用MS。协议应防止AS在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 needs to support multiple ASs controlling one MS.
REQ-MCP-14-MS控制协议需要机制来保护一个AS使用的MS资源不受另一个AS的影响，因为解决方案需要支持多个AS控制一个MS。
REQ-MCP-15 - During session establishment, there shall be a capability to negotiate parameters that are associated with media streams. This requirement should also enable an AS managing conference to specify the media streams allowed in the conference.
REQ-MCP-15-在会话建立期间，应能够协商与媒体流相关的参数。此要求还应使AS管理会议能够指定会议中允许的媒体流。
REQ-MCP-16 - The AS shall be able to instruct the MS to perform stream operations like mute and gain control.
REQ-MCP-16-AS应能够指示MS执行静音和增益控制等流操作。
REQ-MCP-17 - The AS shall be able to instruct the MS to play a specific announcement.
REQ-MCP-17-AS应能够指示MS播放特定公告。
REQ-MCP-18 - The AS shall be able to request the MS to create, delete, and manipulate a mixing, IVR, or announcement session.
REQ-MCP-18-AS应能够请求MS创建、删除和操作混合、IVR或公告会话。
REQ-MCP-19 - The AS shall be able to instruct the MS to play announcements to a single user or to a conference mix.
REQ-MCP-19-AS应能够指示MS向单个用户或会议混音播放公告。
REQ-MCP-20 - The MS control protocol should enable the AS to ask the MS for a session summary report. The report may include resource usage and quality metrics.
REQ-MCP-20-MS控制协议应允许AS向MS请求会话摘要报告。报告可能包括资源使用和质量指标。
REQ-MCP-21 - The MS shall be able to notify the AS of events received in the media stream if requested by the AS. (Examples - STUN request, Flow Control, etc.)
REQ-MCP-21-如果AS要求，MS应能够将媒体流中接收到的事件通知AS。（示例-眩晕请求、流量控制等）
REQ-MCP-22 - The AS shall be able to define a conference mix; the MS may offer different mixing topologies. The conference mix may be defined on a conference or user level.
REQ-MCP-22-AS应能够定义会议组合；MS可以提供不同的混合拓扑。会议组合可以在会议或用户级别上定义。
REQ-MCP-23 - The AS may be able to define a custom video layout built of rectangular sub-windows.
REQ-MCP-23-AS可能能够定义由矩形子窗口构建的自定义视频布局。
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.
REQ-MCP-24-对于视频，AS应能够将流映射到特定子窗口，或向MS定义如何决定哪个流将进入每个子窗口。
REQ-MCP-25 - The MS shall be able to notify the ASs of who the active sources of the media are; for example, who the active speaker is or 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-25-MS应能够通知ASs媒体的活跃来源；例如，谁是活跃的演讲者或谁正在会议中被观看。扬声器和视频源可以不同，例如，描述来自由不同用户管理的远程摄像机的视频流的人。
REQ-MCP-26 - The MS shall be able to inform the AS which layouts it supports.
REQ-MCP-26-MS应能够通知AS其支持的布局。
REQ-MCP-27 - The MS control protocol should enable the AS to instruct the MS to record a specific conference mix.
REQ-MCP-27-MS控制协议应使AS能够指示MS记录特定的会议混音。
REQ-MCP-28 - The AS shall be able to instruct the MS to perform one or more IVR scripts and receive the results. The script may be in a server or contained in the control message.
REQ-MCP-28-AS应能够指示MS执行一个或多个IVR脚本并接收结果。脚本可能位于服务器中或包含在控制消息中。
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-29-AS应能够通过向MS发送播放通知请求并接收响应（如DTMF）来管理IVR会话。在这种情况下，IVR会话流由AS根据其在当前阶段从MS收到的响应启动下一阶段来处理。
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.
REQ-MCP-30-AS应能够指示MS记录短参与者流并回放。这不是记录要求。
These requirements may be applicable to the MRB, but they can be used by an AS if it has a one-to-one connection to the MS.
这些要求可能适用于MRB，但可以由一个与MS一对一连接的系统使用。
REQ-MCP-31 - The MS control protocol must allow the AS to audit the MS state during an active session.
REQ-MCP-31-MS控制协议必须允许AS在活动会话期间审计MS状态。
REQ-MCP-32 - The MS shall be able to inform the AS about its status during an active session.
REQ-MCP-32-MS应能够在活动会话期间通知AS其状态。
This document discusses high-level requirements for MCP. The MCP has some specific security requirements, which will be summarized here at a very high level.
本文件讨论了MCP的高级要求。MCP有一些特定的安全要求，这里将从一个非常高的层次进行总结。
All of the operations and functions described in this document need to be authorized by an MS or an 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 RFC 3261 [RFC3261]. These MCP security requirements will be discussed in detail in the framework and protocol documents.
本文档中描述的所有操作和功能都需要由MS或AS授权。预期MS资源将由一组作为as/MS策略一部分定义的授权规则管理。为了实现策略，MS需要能够对请求进行身份验证。正常的SIP机制，包括摘要认证和证书，可以按照RFC 3261[RFC3261]中的规定使用。这些MCP安全要求将在框架和协议文件中详细讨论。
This RFC represents the work from two previous personal works in progress, "Media Control Protocol Requirements" and "Requirements for a Media Server Control Protocol". The authors would like to acknowledge the work of Gary Munson from AT&T Labs, and James Rafferty from Cantata who helped write "Media Control Protocol Requirements", on which this work is based.
本RFC代表了之前两项个人正在进行的工作，“媒体控制协议要求”和“媒体服务器控制协议要求”。作者要感谢AT&T实验室的Gary Munson和Cantata的James Rafferty的工作，他们帮助编写了“媒体控制协议要求”，这项工作就是基于他们的工作。
[CARCH] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[CARCH]Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，2006年2月。
[MEDIACTRL-FW] Melanchuk, T., Ed., "An Architectural Framework for Media Server Control", Work in Progress, February 2008.
[MEDIACTRL-FW]Melanchuk，T.，Ed.，“媒体服务器控制的体系结构框架”，正在进行的工作，2008年2月。
[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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[XCON-FRMWRK] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", Work in Progress, November 2007.
[XCON-FRMWRK]Barnes，M.，Boulton，C.，和O.Levin，“集中会议的框架”，正在进行的工作，2007年11月。
Authors' Addresses
作者地址
Martin Dolly AT&T Labs 200 Laurel Avenue Middletown, NJ 07748 USA
美国新泽西州米德尔顿劳雷尔大道200号马丁·多利AT&T实验室，邮编：07748
Phone: EMail: mdolly@att.com URI:
电话：电邮：mdolly@att.comURI:
Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel
Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130以色列
EMail: roni.even@polycom.co.il
EMail: roni.even@polycom.co.il
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.