Network Working Group C. Huitema
Request for Comments: 3605 Microsoft
Category: Standards Track October 2003
Network Working Group C. Huitema
Request for Comments: 3605 Microsoft
Category: Standards Track October 2003
Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)
会话描述协议（SDP）中的实时控制协议（RTCP）属性
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP.
会话描述协议（SDP）用于描述多媒体会话中使用的媒体流的参数。当会话需要多个端口时，SDP假定这些端口具有连续编号。但是，当会话跨越也使用端口映射的网络地址转换设备时，端口的顺序可能会被转换破坏。为了处理这个问题，我们向SDP提出了一个扩展属性。
The session invitation protocol (SIP, [RFC3261]) is often used to establish multi-media sessions on the Internet. There are often cases today in which one or both ends of the connection are hidden behind a network address translation device [RFC2766]. In this case, the SDP text must document the IP addresses and UDP ports as they appear on the "public Internet" side of the NAT. In this memo, we will suppose that the host located behind a NAT has a way to obtain these numbers. A possible way to learn these numbers is briefly outlined in section 3, however, just learning the numbers is not enough.
会话邀请协议（SIP，[RFC3261]）通常用于在Internet上建立多媒体会话。如今，经常有这样的情况，连接的一端或两端隐藏在网络地址转换设备[RFC2766]后面。在这种情况下，SDP文本必须记录IP地址和UDP端口，因为它们出现在NAT的“公共Internet”端。在本备忘录中，我们将假设位于NAT后面的主机有一种获取这些号码的方法。第3节简要介绍了学习这些数字的一种可能方法，然而，仅仅学习这些数字是不够的。
The SIP messages use the encoding defined in SDP [RFC2327] to describe the IP addresses and TCP or UDP ports used by the various media. Audio and video are typically sent using RTP [RFC3550], which requires two UDP ports, one for the media and one for the control protocol (RTCP). SDP carries only one port number per media, and
SIP消息使用SDP[RFC2327]中定义的编码来描述各种媒体使用的IP地址和TCP或UDP端口。音频和视频通常使用RTP[RFC3550]发送，这需要两个UDP端口，一个用于媒体，一个用于控制协议（RTCP）。SDP在每个介质中只携带一个端口号，并且
states that "other ports used by the media application (such as the RTCP port) should be derived algorithmically from the base media port." RTCP port numbers were necessarily derived from the base media port in older versions of RTP (such as [RFC1889]), but now that this restriction has been lifted, there is a need to specify RTCP ports explicitly in SDP. Note, however, that implementations of RTP adhering to the earlier [RFC1889] specification may not be able to make use of the SDP attributes specified in this document.
声明“媒体应用程序使用的其他端口（如RTCP端口）应通过算法从基本媒体端口派生。”RTCP端口号必须从旧版本RTP（如[RFC1889]）中的基本媒体端口派生，但现在此限制已解除，需要在SDP中明确指定RTCP端口。但是，请注意，遵循早期[RFC1889]规范的RTP实现可能无法使用本文档中指定的SDP属性。
When the NAT device performs port mapping, there is no guarantee that the mappings of two separate ports reflects the sequencing and the parity of the original port numbers; in fact, when the NAT manages a pool of IP addresses, it is even possible that the RTP and the RTCP ports may be mapped to different addresses. In order to successfully establish connections despite the misordering of the port numbers and the possible parity switches caused by the NAT, we propose to use a specific SDP attribute to document the RTCP port and optionally the RTCP address.
NAT设备进行端口映射时，不能保证两个单独端口的映射反映了原始端口号的顺序和奇偶性；事实上，当NAT管理IP地址池时，RTP和RTCP端口甚至可能映射到不同的地址。为了在NAT导致的端口号错误排序和可能的奇偶校验开关的情况下成功建立连接，我们建议使用特定的SDP属性来记录RTCP端口和可选的RTCP地址。
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]中所述进行解释。
The main part of our solution is the declaration of an SDP attribute for documenting the port used by RTCP.
我们解决方案的主要部分是声明SDP属性，用于记录RTCP使用的端口。
The RTCP attribute is used to document the RTCP port used for media stream, when that port is not the next higher (odd) port number following the RTP port described in the media line. The RTCP attribute is a "value" attribute, and follows the general syntax specified page 18 of [RFC2327]: "a=<attribute>:<value>". For the RTCP attribute:
RTCP属性用于记录用于媒体流的RTCP端口，如果该端口不是媒体行中描述的RTP端口之后的下一个较高（奇数）端口号。RTCP属性是一个“值”属性，遵循[RFC2327]第18页指定的一般语法：“a=<attribute>：<value>”。对于RTCP属性：
* the name is the ascii string "rtcp" (lower case),
* 名称为ascii字符串“rtcp”（小写），
* the value is the RTCP port number and optional address.
* 该值是RTCP端口号和可选地址。
The formal description of the attribute is defined by the following ABNF [RFC2234] syntax:
属性的形式描述由以下ABNF[RFC2234]语法定义：
rtcp-attribute = "a=rtcp:" port [nettype space addrtype space connection-address] CRLF
rtcp attribute=“a=rtcp:“端口[nettype space addrttype space connection address]CRLF”
In this description, the "port", "nettype", "addrtype" and "connection-address" tokens are defined as specified in "Appendix A: SDP Grammar" of [RFC2327].
在本说明中，“端口”、“nettype”、“addrtype”和“连接地址”标记的定义见[RFC2327]的“附录A:SDP语法”。
Example encodings could be:
示例编码可以是：
m=audio 49170 RTP/AVP 0
a=rtcp:53020
m=audio 49170 RTP/AVP 0
a=rtcp:53020
m=audio 49170 RTP/AVP 0
a=rtcp:53020 IN IP4 126.16.64.4
m=audio 49170 RTP/AVP 0
a=rtcp:53020 IN IP4 126.16.64.4
m=audio 49170 RTP/AVP 0
a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD
m=audio 49170 RTP/AVP 0
a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD
The RTCP attribute MAY be used as a media level attribute; it MUST NOT be used as a session level attribute. Though the examples below relate to a method that will return only unicast addresses, both unicast and multicast values are valid.
RTCP属性可用作媒体级属性；它不能用作会话级属性。尽管下面的示例涉及只返回单播地址的方法，但单播和多播值都是有效的。
The implementation of the solution is fairly straightforward. The questions that have been most often asked regarding this solution are whether this is useful, i.e., whether a host can actually discover port numbers in an unmodified NAT, whether it is sufficient, i.e., whether or not there is a need to document more than one ancillary port per media type, and whether why should not change the media definition instead of adding a new attribute.
解决方案的实现相当简单。关于此解决方案，最常被问到的问题是，这是否有用，即主机是否能够在未修改的NAT中实际发现端口号，这是否足够，即是否需要记录每个媒体类型的多个辅助端口，以及为什么不更改媒体定义而不是添加新属性。
The proposed solution is only useful if the host can discover the "translated port numbers", i.e., the value of the ports as they appear on the "external side" of the NAT. One possibility is to ask the cooperation of a well connected third party that will act as a server according to STUN [RFC3489]. We thus obtain a four step process:
只有当主机能够发现“转换后的端口号”，即NAT“外部”上出现的端口值时，建议的解决方案才有用。一种可能性是，根据STUN[RFC3489]的规定，要求作为服务器的连接良好的第三方进行合作。因此，我们获得了一个四步流程：
1 - The host allocates two UDP ports numbers for an RTP/RTCP pair,
1-主机为RTP/RTCP对分配两个UDP端口号，
2 - The host sends a UDP message from each port to the STUN server,
2-主机从每个端口向STUN服务器发送UDP消息，
3 - The STUN server reads the source address and port of the packet, and copies them in the text of a reply,
3-STUN服务器读取数据包的源地址和端口，并将其复制到回复文本中，
4 - The host parses the reply according to the STUN protocol and learns the external address and port corresponding to each of the two UDP ports.
4-主机根据STUN协议解析应答，并学习两个UDP端口中每个端口对应的外部地址和端口。
This algorithm supposes that the NAT will use the same translation for packets sent to the third party and to the "SDP peer" with which the host wants to establish a connection. There is no guarantee that all NAT boxes deployed on the Internet have this characteristic. Implementers are referred to the STUN specification [RFC3489] for an extensive discussion of the various types of NAT.
该算法假设NAT将对发送到第三方和主机想要建立连接的“SDP对等方”的数据包使用相同的翻译。无法保证部署在Internet上的所有NAT盒都具有此特性。实现者可以参考STUN规范[RFC3489]来广泛讨论各种类型的NAT。
Most media streams are transmitted using a single pair of RTP and RTCP ports. It is possible, however, to transmit a single media over several RTP flows, for example using hierarchical encoding. In this case, SDP will encode the port number used by RTP on the first flow, and the number of flows, as in:
大多数媒体流使用一对RTP和RTCP端口传输。然而，可以通过几个RTP流传输单个媒体，例如使用分层编码。在这种情况下，SDP将对RTP在第一个流上使用的端口号和流的数量进行编码，如下所示：
m=video 49170/2 RTP/AVP 31
m=video 49170/2 RTP/AVP 31
In this example, the media is sent over 2 consecutive pairs of ports, corresponding respectively to RTP for the first flow (even number, 49170), RTCP for the first flow (odd number, 49171), RTP for the second flow (even number, 49172), and RTCP for the second flow (odd number, 49173).
在此示例中，通过2对连续端口发送媒体，分别对应于第一个流的RTP（偶数，49170）、第一个流的RTCP（奇数，49171）、第二个流的RTP（偶数，49172）和第二个流的RTCP（奇数，49173）。
In theory, it would be possible to modify SDP and document the many ports corresponding to the separate encoding layers. However, layered encoding is not much used in practice, and when used is mostly used in conjunction with multicast transmission. The translation issues documented in this memo apply uniquely to unicast transmission, and thus there is no short term need for the support of multiple port descriptions. It is more convenient and more robust to focus on the simple case in which a media is sent over exactly one RTP/RTCP stream.
理论上，可以修改SDP并记录对应于单独编码层的多个端口。然而，分层编码在实践中并没有太多的使用，并且在使用分层编码时，通常与多播传输结合使用。本备忘录中记录的翻译问题仅适用于单播传输，因此短期内不需要支持多端口描述。将重点放在一个简单的情况上更方便、更健壮，在这个简单的情况下，一个媒体只通过一个RTP/RTCP流发送。
The RTP ports are documented in the media description line, and it would seem convenient to document the RTCP port at the same place, rather than create an RTCP attribute. We considered this design alternative and rejected it for two reasons: adding an extra port number and an option address in the media description would be awkward, and more importantly it would create problems with existing applications, which would have to reject the entire media description if they did not understand the extension. On the contrary, adding an attribute has a well defined failure mode: implementations that don't
RTP端口记录在介质描述行中，在同一位置记录RTCP端口似乎比创建RTCP属性更方便。我们考虑了这一设计方案，并出于两个原因拒绝了它：在介质描述中添加额外的端口号和选项地址会很尴尬，更重要的是，这会给现有应用程序带来问题，如果它们不理解扩展，则必须拒绝整个介质描述。相反，添加一个属性有一个定义良好的失败模式：没有定义的实现
understand the "a=rtcp" attribute will simply ignore it; they will fail to send RTCP packets to the specified address, but they will at least be able to receive the media in the RTP packets.
理解“a=rtcp”属性将忽略它；他们将无法向指定地址发送RTCP数据包，但至少能够接收RTP数据包中的媒体。
The RTCP attribute in SDP is used to enable establishment of RTP/RTCP flows through NAT. This mechanism can be used in conjunction with an address discovery mechanism such as STUN [RFC3489]. STUN is a short term fix to the NAT traversal problem, which requires thus consideration of the general issues linked to "Unilateral self-address fixing" [RFC3424].
SDP中的RTCP属性用于通过NAT建立RTP/RTCP流。此机制可与地址发现机制（如STUN[RFC3489]）结合使用。STUN是NAT穿越问题的短期修复，因此需要考虑与“单边自地址修复”相关的一般问题[RFC3424]。
The RTCP attribute addresses a very specific problem, the documentation of port numbers as they appear after address translation by a port-mapping NAT. The RTCP attribute SHOULD NOT be used for other applications.
RTCP属性解决了一个非常具体的问题，即端口映射NAT转换地址后出现的端口号文档。RTCP属性不应用于其他应用程序。
We expect that, with time, one of two exit strategies can be developed. The IETF may develop an explicit "middlebox control" protocol that will enable applications to obtain a pair of port numbers appropriate for RTP and RTCP. Another possibility is the deployment of IPv6, which will enable use of "end to end" addressing and guarantee that the two hosts will be able to use appropriate ports. In both cases, there will be no need for documenting a "non standard" RTCP port with the RTCP attribute.
我们预计，随着时间的推移，可以制定两种退出战略之一。IETF可以开发一个明确的“中间箱控制”协议，使应用程序能够获得一对适合RTP和RTCP的端口号。另一种可能性是部署IPv6，这将允许使用“端到端”寻址，并保证两台主机能够使用适当的端口。在这两种情况下，都不需要使用RTCP属性记录“非标准”RTCP端口。
This SDP extension is not believed to introduce any significant security risk to multi-media applications. One could conceive that a malevolent third party would use the extension to redirect the RTCP fraction of an RTP exchange, but this requires intercepting and rewriting the signaling packet carrying the SDP text; if an interceptor can do that, many more attacks are available, including a wholesale change of the addresses and port numbers at which the media will be sent.
据信，此SDP扩展不会给多媒体应用程序带来任何重大安全风险。可以设想，恶意的第三方将使用该扩展重定向RTP交换的RTCP部分，但这需要拦截并重写承载SDP文本的信令包；如果拦截器能够做到这一点，那么就有更多的攻击可用，包括对媒体发送地址和端口号的大规模更改。
In order to avoid attacks of this sort, when SDP is used in a signaling packet where it is of the form application/sdp, end-to-end integrity using S/MIME [RFC3369] is the technical method to be implemented and applied. This is compatible with SIP [RFC3261].
为了避免此类攻击，当SDP用于形式为application/SDP的信令分组时，使用S/MIME[RFC3369]的端到端完整性是要实现和应用的技术方法。这与SIP[RFC3261]兼容。
This document defines a new SDP parameter, the attribute field "rtcp", which per [RFC2327] has been registered by IANA. This attribute field is designed for use at media level only.
本文档定义了一个新的SDP参数，即属性字段“rtcp”，IANA已根据[RFC2327]注册了该字段。此属性字段仅设计用于媒体级别。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat.
IETF对可能声称与本文件中描述的实施或使用其他技术有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
The original idea for using the "rtcp" attribute was developed by Ann Demirtjis. The document was reviewed by the MMUSIC and AVT working groups of the IETF.
使用“rtcp”属性的最初想法是由Ann Demirtjis提出的。该文件由IETF的MMUSIC和AVT工作组审查。
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson. "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[RFC1889]Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson。“RTP：实时应用的传输协议”，RFC1889，1996年1月。
[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月。
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327]Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy. "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489]罗森伯格，J.，温伯格，J.，惠特马，C.和R.马伊。“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson. "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson。“RTP：实时应用的传输协议”，RFC3550，2003年7月。
[RFC2766] Tsirtsis, G. and P. Srisuresh. "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766]Tsirtsis，G.和P.Srisuresh。“网络地址转换-协议转换（NAT-PT）”，RFC2762000年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月。
[RFC3369] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002.
[RFC3369]Housley，R.，“加密消息语法（CMS）”，RFC3369，2002年8月。
[RFC3424] Daigle, L., "IAB considerations for UNilateral Self-Address Fixing (UNSAF) across network address translation", RFC 3424, November 2002.
[RFC3424]Daigle，L.，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Christian Huitema微软公司华盛顿州雷德蒙微软大道一号，邮编：98052-6399
EMail: huitema@microsoft.com
EMail: huitema@microsoft.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。