Network Working Group O. Levin
Request for Comments: 5168 Microsoft Corporation
Category: Informational R. Even
Polycom
P. Hagendorf
RADVISION
March 2008
Network Working Group O. Levin
Request for Comments: 5168 Microsoft Corporation
Category: Informational R. Even
Polycom
P. Hagendorf
RADVISION
March 2008
XML Schema for Media Control
用于媒体控制的XML模式
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 defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors. This document describes a method that has been deployed in Session Initiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. New implementations are discouraged from using the method described except for backward compatibility purposes. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel.
本文档定义了一个可扩展标记语言（XML）模式，用于在严格控制的环境中进行视频快速更新，该模式由Microsoft、Polycom、Radvision开发，并由多家供应商使用。本文档描述了一种方法，该方法在过去三年中已部署在基于会话初始化协议（SIP）的系统中，并以可互操作的方式在不同供应商的实时交互应用程序中使用。除非出于向后兼容的目的，否则不鼓励新的实现使用所描述的方法。在RTP控制协议（RTCP）通道中使用新的完整内部请求命令需要新的实现。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions .....................................................2
3. Background ......................................................3
4. The Video Control Commands ......................................3
5. The Schema Definition ...........................................4
6. Error Handling ..................................................5
7. Examples ........................................................5
7.1. The Fast Update Command for the Full Picture ...............5
7.2. Reporting an Error .........................................5
8. Transport .......................................................6
9. IANA Considerations .............................................6
9.1. Application/media_control+xml Media Type Registration ......6
10. Security Considerations ........................................7
11. References .....................................................8
11.1. Normative References ......................................8
11.2. Informative References ....................................8
1. Introduction ....................................................2
2. Conventions .....................................................2
3. Background ......................................................3
4. The Video Control Commands ......................................3
5. The Schema Definition ...........................................4
6. Error Handling ..................................................5
7. Examples ........................................................5
7.1. The Fast Update Command for the Full Picture ...............5
7.2. Reporting an Error .........................................5
8. Transport .......................................................6
9. IANA Considerations .............................................6
9.1. Application/media_control+xml Media Type Registration ......6
10. Security Considerations ........................................7
11. References .....................................................8
11.1. Normative References ......................................8
11.2. Informative References ....................................8
This document defines an Extensible Markup Language (XML) Schema for video fast update request in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors. Implementation of this schema for interactive video applications in Session Initiation Protocol (SIP) [5] environments was designed in order to improve user experience. This mechanism is being used by both end user video conferencing terminals and conferencing servers in shipping products. This document describes the current method, but new implementations are discouraged from using this method, except for backward compatibility with legacy systems. Shipping products and new products SHOULD use the Full Intra Request, described in [7].
本文档定义了一个可扩展标记语言（XML）模式，用于在严格控制的环境中进行视频快速更新请求，该模式由Microsoft、Polycom、Radvision开发，并由多家供应商使用。在会话初始化协议（SIP）[5]环境中为交互式视频应用程序设计此模式的实现是为了改善用户体验。最终用户视频会议终端和运输产品中的会议服务器都在使用此机制。本文档描述了当前的方法，但是不鼓励新的实现使用此方法，除了与遗留系统的向后兼容性。装运产品和新产品应使用[7]中所述的完整内部请求。
Sending video fast update using the SIP signaling path, as described in this document, is inferior to using the RTP Control Protocol (RTCP) feedback method [7], since the command flows through all the proxies in the signaling path adding delay to the messages and causing unnecessary overload to the proxies. RTCP messages flow end-to-end and not through the signaling proxies. The RTCP feedback document [7] also adds other required control functions, such as the flow control command, which is missing from this document.
如本文件所述，使用SIP信令路径发送视频快速更新不如使用RTP控制协议（RTCP）反馈方法[7]，因为命令流经信令路径中的所有代理，增加了消息延迟，并导致代理不必要的过载。RTCP消息端到端流动，而不是通过信令代理。RTCP反馈文件[7]还添加了其他所需的控制功能，如本文件中缺少的流量控制命令。
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 RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
SIP typically uses the Real-time Transport Protocol (RTP) [6] for the transferring of real-time media.
SIP通常使用实时传输协议（RTP）[6]传输实时媒体。
RTP is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks. The RTCP feedback mechanism [8] has been introduced in order to improve basic RTCP feedback time in case of loss conditions across different coding schemes. This technique addresses signaling of loss conditions and the recommended recovery steps.
RTP由一个控制协议（RTCP）扩展，以允许以可扩展到大型多播网络的方式监控数据传输。引入RTCP反馈机制[8]是为了在不同编码方案出现丢失情况时缩短基本RTCP反馈时间。这项技术解决了丢失情况的信令和建议的恢复步骤。
Just recently, an extension to the feedback mechanism has been proposed [7] to express control operations on media streams as a result of application logic rather than a result of loss conditions. Note that in the decomposed systems, the implementation of the new mechanism will require proprietary communications between the applications/call control components and the media components.
就在最近，有人提出了对反馈机制的扩展[7]，将媒体流上的控制操作表示为应用程序逻辑的结果，而不是丢失条件的结果。请注意，在分解的系统中，新机制的实现将需要应用程序/呼叫控制组件和媒体组件之间的专有通信。
This document describes a technology that has been deployed in SIP-based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. This memo documents this technology for the purpose of describing current practice and new implementation MUST use the RTCP Full Intra Request command specified in the RTCP-based codec control messages document[7].
本文档描述了一种技术，该技术在过去三年中已部署在基于SIP的系统中，并以可互操作的方式在不同供应商的实时交互应用程序中使用。本备忘录记录了该技术，旨在描述当前实践，新实施必须使用基于RTCP的编解码器控制消息文档[7]中指定的RTCP完整内部请求命令。
Output of a video codec is a frame. The frame can carry complete information about a picture or about a picture segment. These frames are known as "Intra" frames. In order to save bandwidth, other frames can carry only changes relative to previously sent frames. Frames carrying relative information are known as "Inter" frames.
视频编解码器的输出是一帧。帧可以携带关于图片或图片片段的完整信息。这些帧称为“帧内”帧。为了节省带宽，其他帧只能携带相对于先前发送的帧的更改。携带相关信息的帧称为“帧间”帧。
Based on application logic (such as need to present a new video source), the application needs to have an ability to explicitly request from a remote encoder the complete information about a "full" picture.
基于应用程序逻辑（例如需要呈现新的视频源），应用程序需要能够明确地从远程编码器请求关于“完整”图片的完整信息。
An "Intra" frame may be of large size. In order to prevent causing network congestion, the current media capacity and network conditions MUST be validated before sending an "Intra" frame when receiving a fast update command, defined in this document.
“帧内”帧可以是大尺寸的。为了防止造成网络拥塞，在接收本文档中定义的快速更新命令时，在发送“帧内”帧之前，必须验证当前媒体容量和网络状况。
In order to meet the presented requirements, a video primitive is defined by this document.
为了满足提出的要求，本文件定义了视频原语。
The following command is sent to the remote encoder:
将以下命令发送到远程编码器：
o Video Picture Fast Update
o 视频图片快速更新
<?xml version="1.0" encoding="utf-8" ?>
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema id="TightMediaControl"
elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:schema id="TightMediaControl"
elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="media_control">
<xs:complexType>
<xs:sequence>
<xs:element name="vc_primitive"
type="vc_primitive"
minOccurs="0"
maxOccurs="unbounded" />
<xs:element name="general_error"
type="xs:string"
minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="media_control">
<xs:complexType>
<xs:sequence>
<xs:element name="vc_primitive"
type="vc_primitive"
minOccurs="0"
maxOccurs="unbounded" />
<xs:element name="general_error"
type="xs:string"
minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- Video control primitive. -->
<!-- Video control primitive. -->
<xs:complexType name="vc_primitive">
<xs:sequence>
<xs:element name="to_encoder" type="to_encoder" />
<xs:element name="stream_id"
type="xs:string"
minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="vc_primitive">
<xs:sequence>
<xs:element name="to_encoder" type="to_encoder" />
<xs:element name="stream_id"
type="xs:string"
minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!-- Encoder Command: Picture Fast Update -->
<!-- 编码器命令：图片快速更新-->
<xs:complexType name="to_encoder">
<xs:choice>
<xs:element name="picture_fast_update"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="to_encoder">
<xs:choice>
<xs:element name="picture_fast_update"/>
</xs:choice>
</xs:complexType>
</xs:schema>
</xs:schema>
Currently, only a single general error primitive is defined. It MAY be used for indicating errors in free-text format. The general error primitive MAY report problems regarding XML document parsing, inadequate level of media control support, inability to perform the requested action, etc.
目前，只定义了一个通用错误原语。它可用于指示自由文本格式中的错误。一般错误原语可能会报告有关XML文档解析、媒体控制支持级别不足、无法执行请求的操作等问题。
The general error primitive MUST NOT be used for the indication of errors other than those related to media control parsing or to resultant execution. The general error primitive MUST NOT be sent back as a result of getting an error primitive.
除与媒体控制解析或结果执行相关的错误外，一般错误原语不得用于指示其他错误。获取错误原语后，不能发回常规错误原语。
When receiving the general error response, the user agent client (UAC) that sent the request SHOULD NOT send further fast update requests in the current dialog.
当收到一般错误响应时，发送请求的用户代理客户端（UAC）不应在当前对话框中发送进一步的快速更新请求。
According to RFC 2976 [3], the only allowable final response to a SIP INFO containing a message body is a 200 OK. If SIP INFO is used to carry the request, the error message should be carried in a separate INFO request.
根据RFC 2976[3]，对包含消息正文的SIP信息的唯一允许的最终响应是200 OK。如果使用SIP INFO传送请求，则错误消息应在单独的INFO请求中传送。
In the following example, the full picture "Fast Update" command is issued towards the remote video decoder(s).
在以下示例中，向远程视频解码器发出全图“快速更新”命令。
<?xml version="1.0" encoding="utf-8" ?>
<?xml version="1.0" encoding="utf-8" ?>
<media_control>
<media\u control>
<vc_primitive>
<to_encoder>
<picture_fast_update/>
</to_encoder>
</vc_primitive>
<vc_primitive>
<to_encoder>
<picture_fast_update/>
</to_encoder>
</vc_primitive>
</media_control>
</media_control>
If an error occurs during the parsing of the XML document, the following XML document would be sent back to the originator of the original Media Control document.
如果在解析XML文档期间发生错误，则会将以下XML文档发送回原始媒体控制文档的发起人。
<?xml version="1.0" encoding="utf-8" ?>
<?xml version="1.0" encoding="utf-8" ?>
<media_control>
<media\u control>
<general_error>
Parsing error: The original XML segment is:...
</general_error>
<general_error>
Parsing error: The original XML segment is:...
</general_error>
</media_control>
</media_control>
The defined XML document is conveyed using the SIP INFO method [3] with the "Content-Type" set to "application/media_control+xml". This approach benefits from the SIP built-in reliability.
定义的XML文档使用SIP INFO方法[3]传输，“内容类型”设置为“应用程序/媒体控制+XML”。这种方法得益于SIP内置的可靠性。
This document registers a new media type.
此文档注册了一种新的媒体类型。
Type name: application Subtype name: media_control+xml Required parameters: None Optional parameters: charset
类型名称：应用程序子类型名称：媒体控制+xml必需参数：无可选参数：字符集
Indicates the character encoding of enclosed XML.
指示封闭XML的字符编码。
Encoding considerations: 8bit Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [4], Section 3.2.
编码注意事项：8bit使用XML，它可以使用8位字符，具体取决于所使用的字符编码。参见RFC 3023[4]，第3.2节。
Security considerations: Security considerations specific to uses of this type are discussed in RFC 5168. RFC 1874 [1] and RFC 3023 [4] discuss security issues common to all uses of XML.
安全注意事项：RFC 5168中讨论了特定于此类型使用的安全注意事项。RFC1874[1]和RFC3023[4]讨论了所有XML使用中常见的安全问题。
Interoperability considerations: None.
互操作性考虑：无。
Published specification: RFC 5168
已发布规范：RFC 5168
Applications that use this media type: This media type is used to convey information regarding media control commands and responses between SIP endpoints particularly for allowing a Video Fast Update intra-frame request.
使用此媒体类型的应用程序：此媒体类型用于在SIP端点之间传递有关媒体控制命令和响应的信息，特别是用于允许视频快速更新帧内请求。
Additional information:
其他信息：
Magic Number(s): None. File Extension(s): None. Macintosh File Type Code(s): None.
幻数：无。文件扩展名：无。Macintosh文件类型代码：无。
Person and email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Name: Roni Even E-Mail: even.roni@gmail.com
姓名：Roni偶数电子邮件：偶数。roni@gmail.com
Intended usage: LIMITED USE
预期用途：有限用途
Restrictions on usage: None.
使用限制：无。
Author: Roni Even. <even.roni@gmail.com>
Author: Roni Even. <even.roni@gmail.com>
Change Controller: Roni Even. <even.roni@gmail.com>
Change Controller: Roni Even. <even.roni@gmail.com>
The video control command transported using the method described in the document may cause the sender of the video data to send more data within the allowed bandwidth, as described in Section 4.
使用文档中描述的方法传输的视频控制命令可能导致视频数据的发送方在允许的带宽内发送更多数据，如第4节所述。
This document defines one control message; changing the content of the message will cause the video sender to ignore the request and send an error response. This may prevent the display of a video stream. The control message itself does not carry any sensitive information.
本文件定义了一条控制信息；更改消息内容将导致视频发件人忽略该请求并发送错误响应。这可能会阻止视频流的显示。控制信息本身不携带任何敏感信息。
An eavesdropper may inject messages or change them, which may lead to either more data on the network or loss of video image. Using data integrity validation will prevent adding or changing of messages.
窃听者可能会插入或更改消息，这可能会导致网络上的更多数据或视频图像丢失。使用数据完整性验证将防止添加或更改消息。
If the video media is sent over a secure transport, it is recommended to secure the signaling using TLS as explained in [5]. In most cases, securing the media will require a secure signaling path.
如果视频媒体通过安全传输发送，建议使用TLS保护信令，如[5]中所述。在大多数情况下，保护媒体需要安全的信令路径。
The security considerations of [3] and [5] apply here.
[3]和[5]中的安全注意事项适用于此处。
[1] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
[1] Levinson，E.，“SGML媒体类型”，RFC1874，1995年12月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[3] Donovan，S.，“SIP信息方法”，RFC 29762000年10月。
[4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[4] Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[5] 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.
[5] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[6] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[7] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008.
[7] Wenger，S.，Chandra，U.，Westerlund，M.，和B.Burman，“带反馈的RTP视听配置文件（AVPF）中的编解码器控制消息”，RFC 5104，2008年2月。
[8] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[8] Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
Authors' Addresses
作者地址
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
奥利特·莱文微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: oritl@microsoft.com
EMail: oritl@microsoft.com
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
Pierre Hagendorf RADVISION 24, Raul Wallenberg St. Tel-Aviv, 69719 Israel
以色列特拉维夫劳尔·瓦伦堡大街皮埃尔·哈根多夫·拉德维辛24号，邮编：69719
EMail: pierre@radvision.com
EMail: pierre@radvision.com
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.