Network Working Group R. Even
Request for Comments: 4573 A. Lochbaum
Category: Standard Track Polycom
July 2006
Network Working Group R. Even
Request for Comments: 4573 A. Lochbaum
Category: Standard Track Polycom
July 2006
MIME Type Registration for RTP Payload Format for H.224
H.224 RTP有效负载格式的MIME类型注册
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
In conversational video applications, far-end camera control protocol is used by participants to control the remote camera. The protocol that is commonly used is ITU H.281 over H.224. The document registers the H224 media type. It defines the syntax and the semantics of the Session Description Protocol (SDP) parameters needed to support far-end camera control protocol using H.224.
在会话视频应用中，参与者使用远端摄像机控制协议来控制远程摄像机。通常使用的协议是ITU H.281 over H.224。文档注册H224介质类型。它定义了使用H.224支持远端摄像机控制协议所需的会话描述协议（SDP）参数的语法和语义。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Far-End Camera Control Protocol .................................2
4. IANA Considerations .............................................2
4.1. Media Type Registration ....................................2
5. SDP Parameters ..................................................4
5.1. Usage with the SDP Offer Answer Model ......................4
6. Security Considerations .........................................5
7. References ......................................................5
7.1. Normative References .......................................5
7.2. Informative References .....................................6
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Far-End Camera Control Protocol .................................2
4. IANA Considerations .............................................2
4.1. Media Type Registration ....................................2
5. SDP Parameters ..................................................4
5.1. Usage with the SDP Offer Answer Model ......................4
6. Security Considerations .........................................5
7. References ......................................................5
7.1. Normative References .......................................5
7.2. Informative References .....................................6
The document registers the H224 media type, which may be used by systems that use SDP [RFC4566].
本文档登记了H224介质类型，可由使用SDP[RFC4566]的系统使用。
This media type is used for supporting the simple far-end camera control protocol on SDP-based systems. The media type helps signaling gateways between H.323 [ITU.H323] and SDP-based systems to use far-end camera control, end to end, without any protocol translation in the middle.
此媒体类型用于支持基于SDP的系统上的简单远端摄像机控制协议。媒体类型有助于H.323（ITU.H323）和基于SDP的系统之间的信号网关使用远端摄像机控制，端到端，中间没有任何协议转换。
The document defines the H224 media type since the RTP packets in H.323 annex Q [ITU.H323] carry H.224 frames [ITU.H224]. The far-end camera control protocol (FECC) is internal to the H.224 frame and is identified by the client ID field of the H.224 packet.
由于ITU H2Q.24定义了ITU文件中的帧[H2Q.24]类型，因此ITU H2Q.24定义了ITU中的帧[H2Q.24]。远端摄像机控制协议（FECC）是H.224帧的内部协议，由H.224分组的客户机ID字段标识。
The document will define the SDP [RFC4566] parameters needed to support the above far-end camera control protocol in systems that use SDP.
本文件将定义在使用SDP的系统中支持上述远端摄像机控制协议所需的SDP[RFC4566]参数。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC2119[RFC2119]中的描述进行解释，并指出符合RTP实施的要求级别。
This simple protocol is based on ITU-T H.281[ITU.281] frames carried in ITU-T H.224 packets in an RTP/UDP channel. H.323 annex Q specifies how to build the RTP packets from the H.224 packets.
该简单协议基于RTP/UDP信道中ITU-T H.224数据包中携带的ITU-T H.281[ITU.281]帧。H.323附录Q规定了如何从H.224数据包构建RTP数据包。
Using far end camera control protocol in point-to-point calls and multipoint calls for packet-switch networks is described in H.323, annex Q.
在分组交换网络的点到点呼叫和多点呼叫中使用远端摄像机控制协议在H.323附录Q中进行了描述。
This section describes the media types and names associated with this payload format. The registration uses the templates defined in RFC 4288 [RFC4288]. It follows RFC 3555 [RFC3555].
本节介绍与此有效负载格式关联的媒体类型和名称。注册使用RFC 4288[RFC4288]中定义的模板。它遵循RFC 3555[RFC3555]。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: H224
MIME子类型名称：H224
Required parameters: None
所需参数：无
Optional parameters: None
可选参数：无
Encoding considerations:
编码注意事项：
This media type is framed (see H.323, Annex Q [ITU.H323]) and contains binary data; see Section 4.8 of [RFC4288]
这种媒体类型是框架式的（见H.323，附录Q[ITU.H323]），包含二进制数据；见[RFC4288]第4.8节
Security considerations: See Section 6 of RFC 4573.
安全注意事项：见RFC 4573第6节。
Interoperability considerations:
互操作性注意事项：
Terminals sending simple far-end camera control commands should use this MIME type. Receivers who cannot support the protocol will reject the channel.
发送简单远端摄像机控制命令的终端应使用此MIME类型。不支持协议的接收器将拒绝该通道。
Published specification: RFC 4573
已发布规范：RFC 4573
Applications that use this media type:
使用此媒体类型的应用程序：
Video conferencing applications.
视频会议应用程序。
Additional information: None
其他信息：无
Person and email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Roni Even: roni.even@polycom.co.il
罗尼：罗尼。even@polycom.co.il
Intended usage: COMMON
预期用途：普通
Restrictions on usage:
使用限制：
This media type depends on RTP framing and thus is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[RFC3550]。此时未定义其他帧协议内的传输。
Author: Roni Even
作者：Roni Even
Change controller:
更改控制器：
IETF Audio/Video Transport working group, delegated from the IESG.
IETF音频/视频传输工作组，由IESG授权。
The media type application/h224 string is mapped to fields in the Session Description Protocol (SDP) as follows:
媒体类型application/h224字符串映射到会话描述协议（SDP）中的字段，如下所示：
o The media name in the "m=" line of SDP MUST be application. The transport SHALL be any applicable RTP profile (for example RFC 3551 [RFC3551]), and the payload type is dynamic.
o SDP的“m=”行中的媒体名称必须是应用程序。传输应为任何适用的RTP配置文件（例如RFC 3551[RFC3551]），有效载荷类型为动态。
o The encoding name in the "a=rtpmap" line of SDP MUST be h224 (the MIME subtype).
o SDP的“a=rtpmap”行中的编码名称必须是h224（MIME子类型）。
o The default clock rate in the "a=rtpmap" line MUST be 4800.
o “a=rtpmap”行中的默认时钟速率必须为4800。
The recommended maximum bandwidth for this protocol is 6.4 kbit/sec.
此协议的建议最大带宽为6.4 kbit/sec。
When offering FECC using SDP in an Offer/Answer model [RFC3264], the following considerations are necessary.
在提供/应答模型[RFC3264]中使用SDP提供FECC时，需要考虑以下事项。
Far-end camera control communication is uni-directional. H.224 is bi-directional and can be used to learn the capabilities of the remote video end point, e.g., how many cameras it has. The offer answer exchange is dependent on the functionality of both sides.
远端摄像机控制通信是单向的。H.224是双向的，可用于了解远程视频端点的功能，例如，它有多少个摄像头。提供-应答交换取决于双方的功能。
The offerer offers a sendonly channel if its camera cannot be remotely controlled and if the offerer does not intend to use H.224 to learn the capabilities of the remote video endpoints.
如果其摄像机无法远程控制，并且如果报价人不打算使用H.224了解远程视频端点的功能，则报价人提供sendonly频道。
In all other cases, when the offerer's camera can be remotely controlled and/or it intends to use H.224 capabilities negotiation, the offerer offers a sendrecv channel.
在所有其他情况下，当报价人的摄像头可以远程控制和/或打算使用H.224功能协商时，报价人提供sendrecv频道。
The answerer behavior is as follows:
回答者的行为如下：
If it receives an offer with sendonly, it answers with a recvonly if it supports far-end camera control; otherwise, it ignores/rejects the offer.
如果它收到sendonly的报价，如果它支持远端摄像头控制，它会回复RecvoOnly；否则，它将忽略/拒绝报价。
If it receives an offer with sendrecv and its camera can be remotely controlled, or it intends to use H.224 capabilities negotiation, it answers with a sendrecv option. If its camera cannot be remotely controlled, it can answer with a sendonly attribute. The answerer may also reject the offer if he does not support FECC or does not intend to use FECC at the moment.
如果它收到sendrecv的报价，并且它的摄像头可以远程控制，或者它打算使用H.224功能协商，那么它将使用sendrecv选项。如果其摄像头无法远程控制，则可以使用sendonly属性进行应答。如果回答者不支持FECC或目前不打算使用FECC，他也可以拒绝该提议。
H.224 payload format, defined in H.323, annex Q defines packet structure based on RTP using the RTP header structure from RFC 3550. Those packets are subject to the security considerations discussed in the RTP specification [RFC3550]. This implies that confidentiality of the media streams is achieved by encryption. Secure Realtime Transport Protocol (SRTP) [RFC3711] may be used to provide both encryption and integrity protection of RTP flow.
H.323附录Q中定义的H.224有效载荷格式使用RFC 3550中的RTP报头结构定义了基于RTP的数据包结构。这些数据包受RTP规范[RFC3550]中讨论的安全注意事项的约束。这意味着媒体流的机密性是通过加密实现的。安全实时传输协议（SRTP）[RFC3711]可用于提供RTP流的加密和完整性保护。
A potential denial-of-service threat exists for data that causes application behavior like camera movement. The attacker can inject pathological datagrams into the stream that cause the receiver to change the camera position. Therefore, the usage of data origin authentication and data integrity protection of at least the H.323 annex Q packet is RECOMMENDED; for example, with SRTP.
导致应用程序行为（如摄像头移动）的数据存在潜在的拒绝服务威胁。攻击者可以将病理数据报注入流中，从而导致接收器更改相机位置。因此，建议使用至少H.323附件Q分组的数据源认证和数据完整性保护；例如，使用SRTP。
Note that the appropriate mechanism to ensure confidentiality and integrity of H.323 annex Q packets and their payloads is very dependent on the application and on the transport and signaling protocols employed. Thus, although SRTP is given as an example above, other possible choices exist.
请注意，确保H.323附录Q数据包及其有效载荷的机密性和完整性的适当机制非常依赖于应用程序以及所采用的传输和信令协议。因此，尽管上面给出了SRTP作为示例，但存在其他可能的选择。
[ITU.281] International Telecommunications Union, "A far end camera control protocol for videoconferences using H.224", ITU- T Recommendation H.281, November 1994.
[ITU.281]国际电信联盟，“使用H.224的视频会议远端摄像机控制协议”，ITU-T建议H.281，1994年11月。
[ITU.H224] International Telecommunications Union, "A real time control protocol for simplex applications using the H.221 LSD/HSD/HLP channels.", ITU-T Recommendation H.224, February 2000.
[ITU.H224]国际电信联盟，“使用H.221 LSD/HSD/HLP信道的单工应用实时控制协议”，ITU-T建议H.224，2000年2月。
[ITU.H323] International Telecommunications Union, "Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service", ITU-T Recommendation H.323, July 2003.
[ITU.H323]国际电信联盟，“提供非保证服务质量的局域网可视电话系统和设备”，ITU-T建议H.323，2003年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[RFC3555]Casner，S.和P.Hoschka，“RTP有效载荷格式的MIME类型注册”，RFC 35552003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
Authors' Addresses
作者地址
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
Andrew Lochbaum Polycom 6500 River Place Blvd, Building 6 Austin, TX 78730 USA
美国德克萨斯州奥斯汀市河流大道6500号6号楼安德鲁·洛赫巴姆宝利通公司，邮编78730
EMail: alochbaum@polycom.com
EMail: alochbaum@polycom.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。