Network Working Group D. Wing
Request for Comments: 4961 Cisco Systems
BCP: 131 July 2007
Category: Best Current Practice
Network Working Group D. Wing
Request for Comments: 4961 Cisco Systems
BCP: 131 July 2007
Category: Best Current Practice
Symmetric RTP / RTP Control Protocol (RTCP)
对称RTP/RTP控制协议（RTCP）
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document recommends using one UDP port pair for both communication directions of bidirectional RTP and RTP Control Protocol (RTCP) sessions, commonly called "symmetric RTP" and "symmetric RTCP".
本文档建议为双向RTP和RTP控制协议（RTCP）会话的两个通信方向使用一个UDP端口对，通常称为“对称RTP”和“对称RTCP”。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . . . 2
3. Definition of Symmetric RTP and Symmetric RTCP . . . . . . . . 3
4. Recommended Usage . . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . . 4
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . . . 2
3. Definition of Symmetric RTP and Symmetric RTCP . . . . . . . . 3
4. Recommended Usage . . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . . 4
TCP [RFC0793], which is inherently bidirectional, transmits and receives data using the same local port. That is, when a TCP connection is established from host A with source TCP port "a" to a remote host, the remote host sends packets back to host A's source TCP port "a".
TCP[RFC0793]本质上是双向的，使用相同的本地端口发送和接收数据。也就是说，当从具有源TCP端口“a”的主机a建立到远程主机的TCP连接时，远程主机将数据包发送回主机a的源TCP端口“a”。
However, UDP is not inherently bidirectional and UDP does not require using the same port for sending and receiving bidirectional traffic. Rather, some UDP applications use a single UDP port to transmit and receive (e.g., DNS [RFC1035]), some applications use different UDP ports to transmit and receive with explicit signaling (e.g., Trivial File Transfer Protocol (TFTP) [RFC1350]), and other applications don't specify the choice of transmit and receive ports (RTP [RFC3550]).
但是，UDP本身不是双向的，并且UDP不需要使用相同的端口来发送和接收双向流量。相反，一些UDP应用程序使用单个UDP端口进行发送和接收（例如DNS[RFC1035]），一些应用程序使用不同的UDP端口通过显式信令进行发送和接收（例如普通文件传输协议（TFTP）[RFC1350]），而其他应用程序不指定发送和接收端口的选择（RTP[RFC3550]）。
Because RTP and RTCP are not inherently bidirectional protocols, and UDP is not a bidirectional protocol, the usefulness of using the same UDP port for transmitting and receiving has been generally ignored for RTP and RTCP. Many firewalls, Network Address Translators (NATs) [RFC3022], and RTP implementations expect symmetric RTP, and do not work in the presence of asymmetric RTP. However, this term has never been defined. This document defines "symmetric RTP" and "symmetric RTCP".
由于RTP和RTCP本质上不是双向协议，UDP也不是双向协议，因此RTP和RTCP通常忽略了使用相同的UDP端口进行传输和接收的有用性。许多防火墙、网络地址转换器（NAT）[RFC3022]和RTP实现都需要对称RTP，并且在存在非对称RTP的情况下无法工作。然而，这个术语从未定义过。本文件定义了“对称RTP”和“对称RTCP”。
The UDP port number to receive media, and the UDP port to transmit media are both selected by the device that receives that media and transmits that media. For unicast flows, the receive port is communicated to the remote peer (e.g., Session Description Protocol (SDP) [RFC4566] carried in SIP [RFC3261], Session Announcement Protocol (SAP) [RFC2974], or Megaco/H.248 [RFC3525]).
接收媒体的UDP端口号和传输媒体的UDP端口号均由接收该媒体并传输该媒体的设备选择。对于单播流，接收端口与远程对等方通信（例如，SIP[RFC3261]中携带的会话描述协议（SDP）[RFC4566]、会话公告协议（SAP）[RFC2974]或Megaco/H.248[RFC3525]）。
There is no correspondence between the local RTP (or RTCP) port and the remote RTP (or RTCP) port. That is, device "A" might choose its local transmit and receive port to be 1234. Its peer, device "B", is not constrained to also use port 1234 for its port. In fact, such a constraint is impossible to meet because device "B" might already be using that port for another application.
本地RTP（或RTCP）端口和远程RTP（或RTCP）端口之间没有对应关系。也就是说，设备“A”可以选择其本地发送和接收端口为1234。它的对等设备“B”不受限制也使用端口1234作为其端口。事实上，这样的限制是不可能满足的，因为设备“B”可能已经将该端口用于另一个应用程序。
The benefits of using one UDP port pair is described below in Section 4.
使用一个UDP端口对的好处将在下面的第4节中介绍。
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]中所述进行解释。
A device supports symmetric RTP if it selects, communicates, and uses IP addresses and port numbers such that, when receiving a bidirectional RTP media stream on UDP port "A" and IP address "a", it also transmits RTP media for that stream from the same source UDP port "A" and IP address "a". That is, it uses the same UDP port to transmit and receive one RTP stream.
如果设备选择、通信和使用IP地址和端口号，以便在UDP端口“A”和IP地址“A”上接收双向RTP媒体流时，还从同一源UDP端口“A”和IP地址“A”为该流传输RTP媒体，则设备支持对称RTP。也就是说，它使用相同的UDP端口来发送和接收一个RTP流。
A device that doesn't support symmetric RTP would transmit RTP from a different port, or from a different IP address, than the port and IP address used to receive RTP for that bidirectional media steam.
不支持对称RTP的设备将从不同的端口或不同的IP地址传输RTP，而不是用于接收双向媒体流的RTP的端口和IP地址。
A device supports symmetric RTCP if it selects, communicates, and uses IP addresses and port numbers such that, when receiving RTCP packets for a media stream on UDP port "B" and IP address "b", it also transmits RTCP packets for that stream from the same source UDP port "B" and IP address "b". That is, it uses the same UDP port to transmit and receive one RTCP stream.
如果设备选择、通信和使用IP地址和端口号，以便在UDP端口“B”和IP地址“B”上接收媒体流的RTCP数据包时，还从同一源UDP端口“B”和IP地址“B”传输该流的RTCP数据包，则设备支持对称RTCP。也就是说，它使用相同的UDP端口发送和接收一个RTCP流。
A device that doesn't support symmetric RTCP would transmit RTCP from a different port, or from a different IP address, than the port and IP address used to receive RTCP.
不支持对称RTCP的设备将从用于接收RTCP的端口和IP地址以外的其他端口或IP地址传输RTCP。
There are two specific instances where symmetric RTP and symmetric RTCP are REQUIRED:
有两个特定实例需要对称RTP和对称RTCP：
The first instance is NATs that lack integrated Application Layer Gateway (ALG) functionality. Such NATs require that endpoints use symmetric UDP ports to establish bidirectional traffic. This requirement exists for all types of NATs described in Section 4 of [RFC4787]. ALGs are defined in Section 4.4 of [RFC3022].
第一个实例是缺乏集成应用层网关（ALG）功能的NAT。此类NAT要求端点使用对称UDP端口来建立双向通信。该要求适用于[RFC4787]第4节所述的所有类型的NAT。ALG的定义见[RFC3022]第4.4节。
The second instance is Session Border Controllers (SBCs) and other forms of RTP and RTCP relays (e.g., [TURN]). Media relays are necessary to establish bidirectional UDP communication across a NAT that is 'Address-Dependent' or 'Address and Port-Dependent' [RFC4787]. However, even with a media relay, symmetric UDP ports are still required to traverse such a NAT.
第二个实例是会话边界控制器（SBC）和其他形式的RTP和RTCP中继（例如[TURN]）。媒体中继对于跨“地址相关”或“地址和端口相关”的NAT建立双向UDP通信是必要的[RFC4787]。但是，即使使用媒体中继，也需要对称UDP端口来穿越这样的NAT。
There are other instances where symmetric RTP and symmetric RTCP are helpful, but not required. For example, if a firewall can expect symmetric RTP and symmetric RTCP, then the firewall's dynamic per-call port filter list can be more restrictive compared to asymmetric RTP and asymmetric RTCP. Symmetric RTP and symmetric RTCP can also ease debugging and troubleshooting.
在其他情况下，对称RTP和对称RTCP是有用的，但不是必需的。例如，如果防火墙可以预期对称RTP和对称RTCP，那么与非对称RTP和非对称RTCP相比，防火墙的动态每呼叫端口筛选器列表的限制性更大。对称RTP和对称RTCP还可以简化调试和故障排除。
Other UDP-based protocols can also benefit from common local transmit and receive ports.
其他基于UDP的协议也可以受益于通用的本地传输和接收端口。
There are no known cases where symmetric RTP or symmetric RTCP are harmful.
没有已知对称RTP或对称RTCP有害的情况。
For these reasons, it is RECOMMENDED that symmetric RTP and symmetric RTCP always be used for bidirectional RTP media streams.
出于这些原因，建议始终将对称RTP和对称RTCP用于双向RTP媒体流。
If an attacker learns the source and destination UDP ports of a symmetric RTP or symmetric RTCP flow, the attacker can send RTP or RTCP packets to that host. This differs from asymmetric RTP and asymmetric RTCP, where an attacker has to learn the UDP source and destination ports used for the reverse traffic, before it can send packets to that host. Thus, if a host uses symmetric RTP or symmetric RTCP, an attacker need only see one RTP or RTCP packet in order to attack either RTP endpoint. Note that this attack is similar to that of other UDP-based protocols that use one UDP port pair (e.g., DNS [RFC1035]).
如果攻击者了解对称RTP或对称RTCP流的源和目标UDP端口，则攻击者可以向该主机发送RTP或RTCP数据包。这与非对称RTP和非对称RTCP不同，在非对称RTP中，攻击者必须先了解用于反向通信的UDP源端口和目标端口，然后才能将数据包发送到该主机。因此，如果主机使用对称RTP或对称RTCP，攻击者只需看到一个RTP或RTCP数据包即可攻击任一RTP端点。请注意，此攻击类似于使用一个UDP端口对的其他基于UDP的协议（例如DNS[RFC1035]）。
The author thanks Francois Audet, Sunil Bhargo, Lars Eggert, Francois Le Faucheur, Cullen Jennings, Benny Rodrig, Robert Sparks, and Joe Stone for their assistance with this document.
作者感谢Francois Audet、Sunil Bhargo、Lars Eggert、Francois Le Faucheur、Cullen Jennings、Benny Rodrig、Robert Sparks和Joe Stone对本文件的帮助。
[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月。
[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月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[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月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[RFC1350]Sollins，K.，“TFTP协议（修订版2）”，STD 33，RFC 1350，1992年7月。
[TURN] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN)", Work in Progress, July 2007.
[TURN]Rosenberg，J.，“通过NAT下的简单遍历（STUN）获取中继地址”，正在进行的工作，2007年7月。
[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月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC3525]Groves，C.，Pantaleo，M.，Anderson，T.，和T.Taylor，“网关控制协议版本1”，RFC 35252003年6月。
Author's Address
作者地址
Dan Wing Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: dwing@cisco.com
EMail: dwing@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（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.
本文件受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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。