Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 5761 University of Glasgow
Updates: 3550, 3551 M. Westerlund
Category: Standards Track Ericsson
ISSN: 2070-1721 April 2010
Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 5761 University of Glasgow
Updates: 3550, 3551 M. Westerlund
Category: Standards Track Ericsson
ISSN: 2070-1721 April 2010
Multiplexing RTP Data and Control Packets on a Single Port
在单个端口上多路复用RTP数据和控制数据包
Abstract
摘要
This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions.
本备忘录讨论在单个UDP端口上复用RTP数据包和RTP控制协议（RTCP）包时出现的问题。它更新了RFC 3550和RFC 3551，以描述这种多路复用何时合适、何时不合适，并解释了如何使用会话描述协议（SDP）来发送多路复用会话的信号。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5761.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5761.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Background ......................................................3
3. Terminology .....................................................4
4. Distinguishable RTP and RTCP Packets ............................4
5. Multiplexing RTP and RTCP on a Single Port ......................6
5.1. Unicast Sessions ...........................................6
5.1.1. SDP Signalling ......................................6
5.1.2. Interactions with SIP Forking .......................7
5.1.3. Interactions with ICE ...............................7
5.1.4. Interactions with Header Compression ................8
5.2. Any Source Multicast Sessions ..............................9
5.3. Source-Specific Multicast Sessions .........................9
6. Multiplexing, Bandwidth, and Quality of Service ................10
7. Security Considerations ........................................10
8. IANA Considerations ............................................11
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
1. Introduction ....................................................3
2. Background ......................................................3
3. Terminology .....................................................4
4. Distinguishable RTP and RTCP Packets ............................4
5. Multiplexing RTP and RTCP on a Single Port ......................6
5.1. Unicast Sessions ...........................................6
5.1.1. SDP Signalling ......................................6
5.1.2. Interactions with SIP Forking .......................7
5.1.3. Interactions with ICE ...............................7
5.1.4. Interactions with Header Compression ................8
5.2. Any Source Multicast Sessions ..............................9
5.3. Source-Specific Multicast Sessions .........................9
6. Multiplexing, Bandwidth, and Quality of Service ................10
7. Security Considerations ........................................10
8. IANA Considerations ............................................11
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
The Real-time Transport Protocol (RTP) [1] comprises two components: a data transfer protocol and an associated control protocol (RTCP). Historically, RTP and RTCP have been run on separate UDP ports. With increased use of Network Address Port Translation (NAPT) [14], this has become problematic, since maintaining multiple NAT bindings can be costly. It also complicates firewall administration, since multiple ports must be opened to allow RTP traffic. This memo discusses how the RTP and RTCP flows for a single media type can be run on a single port, to ease NAT traversal and simplify firewall administration, and considers when such multiplexing is appropriate. The multiplexing of several types of media (e.g., audio and video) onto a single port is not considered here (but see Section 5.2 of [1]).
实时传输协议（RTP）[1]包括两个组件：数据传输协议和相关控制协议（RTCP）。历史上，RTP和RTCP都是在单独的UDP端口上运行的。随着越来越多地使用网络地址端口转换（NAPT）[14]，这已经成为一个问题，因为维护多个NAT绑定可能成本高昂。它还使防火墙管理复杂化，因为必须打开多个端口才能允许RTP通信。本备忘录讨论了如何在单个端口上运行单个媒体类型的RTP和RTCP流，以简化NAT穿越和防火墙管理，并考虑了这种多路复用何时合适。此处不考虑将几种类型的媒体（例如音频和视频）复用到单个端口上（但请参见[1]第5.2节）。
This memo is structured as follows: in Section 2 we discuss the design choices that led to the use of separate ports and comment on the applicability of those choices to current network environments. We discuss terminology in Section 3 and how to distinguish multiplexed packets in Section 4; we then specify when and how RTP and RTCP should be multiplexed, and how to signal multiplexed sessions, in Section 5. Quality of service and bandwidth issues are discussed in Section 6. We conclude with security considerations in Section 7 and IANA considerations in Section 8.
本备忘录的结构如下：在第2节中，我们讨论了导致使用单独端口的设计选择，并对这些选择对当前网络环境的适用性进行了评论。我们在第3节讨论术语，在第4节讨论如何区分多路复用数据包；然后，我们在第5节中指定RTP和RTCP应该何时以及如何多路复用，以及如何向多路复用会话发送信号。第6节讨论了服务质量和带宽问题。我们在第7节中总结了安全考虑，在第8节中总结了IANA考虑。
This memo updates Section 11 of [1].
本备忘录更新了[1]第11节。
An RTP session comprises data packets and periodic control (RTCP) packets. RTCP packets are assumed to use "the same distribution mechanism as the data packets", and the "underlying protocol MUST provide multiplexing of the data and control packets, for example using separate port numbers with UDP" [1]. Multiplexing was deferred to the underlying transport protocol, rather than being provided within RTP, for the following reasons:
RTP会话包括数据包和周期控制（RTCP）包。假设RTCP数据包使用“与数据包相同的分发机制”，并且“基础协议必须提供数据和控制数据包的多路复用，例如使用UDP的单独端口号”[1]。多路复用被推迟到底层传输协议，而不是在RTP中提供，原因如下：
1. Simplicity: an RTP implementation is simplified by moving the RTP and RTCP demultiplexing to the transport layer, since it need not concern itself with the separation of data and control packets. This allows the implementation to be structured in a very natural fashion, with a clean separation of data and control planes.
1. 简单性：RTP实现通过将RTP和RTCP解复用移动到传输层来简化，因为它本身不需要考虑数据包和控制包的分离。这允许实现以一种非常自然的方式进行结构化，将数据和控制平面完全分离。
2. Efficiency: following the principle of integrated layer processing [15], an implementation will be more efficient when demultiplexing happens in a single place (e.g., according to UDP port) than when split across multiple layers of the stack (e.g., according to UDP port and then according to packet type).
2. 效率：根据集成层处理的原则[15]，当解复用发生在单个位置（例如，根据UDP端口）时，实现将比在堆栈的多个层上拆分（例如，根据UDP端口，然后根据数据包类型）时更有效。
3. To enable third-party monitors: while unicast voice-over-IP has always been considered, RTP was also designed to support loosely coupled multicast conferences [16] and very large-scale multicast streaming media applications (such as the so-called triple-play IP television (IPTV) service). Accordingly, the design of RTP allows the RTCP packets to be multicast using a separate IP multicast group and UDP port to the data packets. This not only allows participants in a session to get reception-quality feedback but also enables deployment of third-party monitors, which listen to reception quality without access to the data packets. This was intended to provide manageability of multicast sessions, without compromising privacy.
3. 启用第三方监视器：虽然一直在考虑单播IP语音，但RTP也被设计为支持松散耦合的多播会议[16]和非常大规模的多播流媒体应用（如所谓的三网融合IP电视（IPTV）服务）。因此，RTP的设计允许RTCP分组使用单独的IP多播组和数据分组的UDP端口进行多播。这不仅允许会话的参与者获得接收质量反馈，还允许部署第三方监视器，该监视器在不访问数据包的情况下收听接收质量。这是为了在不损害隐私的情况下提供多播会话的可管理性。
While these design choices are appropriate for many uses of RTP, they are problematic in some cases. There are many RTP deployments that don't use IP multicast, and with the increased use of Network Address Translation (NAT) the simplicity of multiplexing at the transport layer has become a liability, since it requires complex signalling to open multiple NAT pinholes. In environments such as these, it is desirable to provide an alternative to demultiplexing RTP and RTCP using separate UDP ports, instead using only a single UDP port and demultiplexing within the application.
虽然这些设计选择适用于RTP的许多用途，但在某些情况下存在问题。有许多RTP部署不使用IP多播，并且随着网络地址转换（NAT）使用的增加，传输层多路复用的简单性已成为一种负担，因为它需要复杂的信令来打开多个NAT针孔。在这样的环境中，希望提供使用单独的UDP端口解复用RTP和RTCP的替代方案，而不是仅使用单个UDP端口并在应用程序内解复用。
This memo provides such an alternative by multiplexing RTP and RTCP packets on a single UDP port, distinguished by the RTP payload type and RTCP packet type values. This pushes some additional work onto the RTP implementation, in exchange for simplified NAT traversal.
此备忘录通过在单个UDP端口上多路复用RTP和RTCP数据包提供了这种替代方案，该端口由RTP有效负载类型和RTCP数据包类型值区分。这将把一些额外的工作推到RTP实现上，以换取简化的NAT遍历。
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]中所述进行解释。
When RTP and RTCP packets are multiplexed onto a single port, the RTCP packet type field occupies the same position in the packet as the combination of the RTP marker (M) bit and the RTP payload type (PT). This field can be used to distinguish RTP and RTCP packets when two restrictions are observed: 1) the RTP payload type values used are distinct from the RTCP packet types used; and 2) for each
当RTP和RTCP数据包被多路复用到单个端口上时，RTCP数据包类型字段在数据包中占据与RTP标记（M）位和RTP有效负载类型（PT）组合相同的位置。当遵守两个限制时，此字段可用于区分RTP和RTCP数据包：1）使用的RTP有效负载类型值与使用的RTCP数据包类型不同；和2）每个
RTP payload type (PT), PT+128 is distinct from the RTCP packet types used. The first constraint precludes a direct conflict between RTP payload type and RTCP packet type; the second constraint precludes a conflict between an RTP data packet with the marker bit set and an RTCP packet.
RTP有效负载类型（PT），PT+128不同于所使用的RTCP数据包类型。第一约束排除了RTP有效负载类型和RTCP分组类型之间的直接冲突；第二个约束排除了设置了标记位的RTP数据包与RTCP数据包之间的冲突。
The following conflicts between RTP and RTCP packet types are known:
已知RTP和RTCP数据包类型之间存在以下冲突：
o RTP payload types 64-65 conflict with the (obsolete) RTCP FIR and NACK packets defined in the original "RTP Payload Format for H.261 Video Streams" [3] (which was obsoleted by [17]).
o RTP有效负载类型64-65与原始“H.261视频流的RTP有效负载格式”[3]（已被[17]淘汰）中定义的（过时的）RTCP FIR和NACK数据包冲突。
o RTP payload types 72-76 conflict with the RTCP SR, RR, SDES, BYE, and APP packets defined in the RTP specification [1].
o RTP有效负载类型72-76与RTP规范[1]中定义的RTCP SR、RR、SDES、BYE和APP数据包冲突。
o RTP payload types 77-78 conflict with the RTCP RTPFB and PSFB packets defined in the RTP/AVPF profile [4].
o RTP有效负载类型77-78与RTP/AVPF配置文件中定义的RTCP RTPFB和PSFB数据包冲突[4]。
o RTP payload type 79 conflicts with RTCP Extended Report (XR) [5] packets.
o RTP有效负载类型79与RTCP扩展报告（XR）[5]数据包冲突。
o RTP payload type 80 conflicts with Receiver Summary Information (RSI) packets defined in "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback" [6].
o RTP有效负载类型80与“具有单播反馈的单源多播会话的RTCP扩展”中定义的接收器摘要信息（RSI）数据包冲突[6]。
New RTCP packet types may be registered in the future and will further reduce the RTP payload types that are available when multiplexing RTP and RTCP onto a single port. To allow this multiplexing, future RTCP packet type assignments SHOULD be made after the current assignments in the range 209-223, then in the range 194-199, so that only the RTP payload types in the range 64-95 are blocked. RTCP packet types in the ranges 1-191 and 224-254 SHOULD only be used when other values have been exhausted.
将来可能会注册新的RTCP数据包类型，这将进一步减少将RTP和RTCP多路复用到单个端口时可用的RTP有效负载类型。为了允许这种多路复用，未来的RTCP包类型分配应在209-223范围内的当前分配之后进行，然后在194-199范围内进行，以便仅阻塞64-95范围内的RTP有效负载类型。范围1-191和224-254中的RTCP数据包类型只能在其他值用尽时使用。
Given these constraints, it is RECOMMENDED to follow the guidelines in the RTP/AVP profile [7] for the choice of RTP payload type values, with the additional restriction that payload type values in the range 64-95 MUST NOT be used. Specifically, dynamic RTP payload types SHOULD be chosen in the range 96-127 where possible. Values below 64 MAY be used if that is insufficient, in which case it is RECOMMENDED that payload type numbers that are not statically assigned by [7] be used first.
考虑到这些限制，建议遵循RTP/AVP配置文件[7]中的指南选择RTP有效载荷类型值，并附加限制，即不得使用64-95范围内的有效载荷类型值。具体而言，动态RTP有效负载类型应尽可能选择在96-127范围内。如果低于64的值不够，则可以使用该值，在这种情况下，建议首先使用未由[7]静态分配的有效负载类型编号。
Note: Since Section 6.1 of [1] specifies that all RTCP packets MUST be sent as compound packets beginning with a Sender Report (SR) or a Receiver Report (RR) packet, one might wonder why RTP
注：由于[1]的第6.1节规定，所有RTCP数据包必须以发送方报告（SR）或接收方报告（RR）数据包开头的复合数据包的形式发送，人们可能想知道为什么RTP
payload types other than 72 and 73 are prohibited when multiplexing RTP and RTCP. This is done to support [18], which allows the use of non-compound RTCP packets in some circumstances.
复用RTP和RTCP时，禁止72和73以外的有效负载类型。这样做是为了支持[18]，它允许在某些情况下使用非复合RTCP数据包。
The procedures for multiplexing RTP and RTCP on a single port depend on whether the session is a unicast session or a multicast session. For multicast sessions, the procedures also depend on whether Any Source Multicast (ASM) or Source-Specific Multicast (SSM) is to be used.
在单个端口上复用RTP和RTCP的过程取决于会话是单播会话还是多播会话。对于多播会话，过程还取决于是否使用任何源多播（ASM）或源特定多播（SSM）。
It is acceptable to multiplex RTP and RTCP packets on a single UDP port to ease NAT traversal for unicast sessions, provided the RTP payload types used in the session are chosen according to the rules in Section 4, and provided that multiplexing is signalled in advance. The following sections describe how such multiplexed sessions can be signalled using the Session Initiation Protocol (SIP) with the offer/ answer model.
可以在单个UDP端口上多路复用RTP和RTCP数据包，以简化单播会话的NAT遍历，前提是会话中使用的RTP有效负载类型是根据第4节中的规则选择的，并且多路复用是预先发出信号的。以下各节描述了如何使用会话发起协议（SIP）和提供/应答模型来发送此类多路复用会话的信号。
When the Session Description Protocol (SDP) [8] is used to negotiate RTP sessions following the offer/answer model [9], the "a=rtcp-mux" attribute (see Section 8) indicates the desire to multiplex RTP and RTCP onto a single port. The initial SDP offer MUST include this attribute at the media level to request multiplexing of RTP and RTCP on a single port. For example:
当会话描述协议（SDP）[8]用于按照提供/应答模型[9]协商RTP会话时，“a=rtcp mux”属性（见第8节）表示希望将RTP和rtcp多路复用到单个端口上。初始SDP提供必须在媒体级别包含此属性，以便在单个端口上请求RTP和RTCP的多路复用。例如：
v=0
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
s=-
c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
t=1153134164 1153137764
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=rtcp-mux
v=0
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
s=-
c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
t=1153134164 1153137764
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=rtcp-mux
This offer denotes a unicast voice-over-IP session using the RTP/AVP profile with iLBC coding. The answerer is requested to send both RTP and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e.
此服务表示使用带有iLBC编码的RTP/AVP配置文件的单播IP语音会话。请求应答者将RTP和RTCP发送到IPv6地址2001:DB8:：211:24ff:fea3:7a2e上的端口49170。
If the answerer wishes to multiplex RTP and RTCP onto a single port, it MUST include a media-level "a=rtcp-mux" attribute in the answer. The RTP payload types used in the answer MUST conform to the rules in Section 4.
如果应答者希望将RTP和RTCP多路传输到单个端口上，则应答中必须包含媒体级“a=RTCP mux”属性。答案中使用的RTP有效负载类型必须符合第4节中的规则。
If the answer does not contain an "a=rtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=rtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=rtcp-mux" attribute.
如果答案不包含“a=rtcp mux”属性，则报价人不得在单个端口上多路传输RTP和rtcp数据包。相反，它应该在根据通常的端口选择规则分配的端口上发送和接收RTCP（端口对或信号端口，如果还包括“a=RTCP:”属性[10]）。当与不理解“a=rtcp mux”属性的对等方交谈时，会发生这种情况。
When SDP is used in a declarative manner, the presence of an "a=rtcp-mux" attribute signals that the sender will multiplex RTP and RTCP on the same port. The receiver MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation needs to be made including the RTCP bandwidth.
以声明方式使用SDP时，“a=rtcp mux”属性表示发送方将在同一端口上多路传输RTP和rtcp。接收器必须准备好在RTP端口上接收RTCP数据包，并且需要进行任何资源预留，包括RTCP带宽。
When using SIP with a forking proxy, it is possible that an INVITE request may result in multiple 200 (OK) responses. If RTP and RTCP multiplexing is offered in that INVITE, it is important to be aware that some answerers may support multiplexed RTP and RTCP, some not. This will require the offerer to listen for RTCP on both the RTP port and the usual RTCP port, and to send RTCP on both ports, unless branches of the call that support multiplexing are re-negotiated to use separate RTP and RTCP ports.
当将SIP与分叉代理一起使用时，INVITE请求可能会导致多个200（OK）响应。如果该INVITE中提供了RTP和RTCP多路复用，则需要注意的是，一些应答者可能支持多路复用的RTP和RTCP，有些则不支持。这将要求报价人在RTP端口和通常的RTCP端口上侦听RTCP，并在两个端口上发送RTCP，除非支持多路复用的呼叫分支重新协商使用单独的RTP和RTCP端口。
It is common to use the Interactive Connectivity Establishment (ICE) [19] methodology to establish RTP sessions in the presence of Network Address Translation (NAT) devices or other middleboxes. If RTP and RTCP are sent on separate ports, the RTP media stream comprises two components in ICE (one for RTP and one for RTCP), with connectivity checks being performed for each component. If RTP and RTCP are to be multiplexed on the same port some of these connectivity checks can be avoided, reducing the overhead of ICE.
通常使用交互式连接建立（ICE）[19]方法在存在网络地址转换（NAT）设备或其他中间盒的情况下建立RTP会话。如果RTP和RTCP在不同的端口上发送，则RTP媒体流包含ICE中的两个组件（一个用于RTP，一个用于RTCP），并对每个组件执行连接检查。如果RTP和RTCP要在同一端口上多路传输，则可以避免某些连接检查，从而减少ICE的开销。
If it is desired to use both ICE and multiplexed RTP and RTCP, the initial offer MUST contain an "a=rtcp-mux" attribute to indicate that RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:" line indicating a fallback port for RTCP in the case that the answerer does not support RTP and RTCP multiplexing. This MUST be done for each media where RTP and RTCP multiplexing is desired.
如果希望同时使用ICE和多路复用RTP和RTCP，则初始报价必须包含“a=RTCP mux”属性，以表明需要RTP和RTCP多路复用，并且必须包含RTP和RTCP的“a=候选者：”行以及“a=RTCP:”指示应答器不支持RTP和RTCP多路复用时RTCP的回退端口的行。对于需要RTP和RTCP多路复用的每个介质，都必须这样做。
If the answerer wishes to multiplex RTP and RTCP on a single port, it MUST generate an answer containing an "a=rtcp-mux" attribute and a single "a=candidate:" line corresponding to the RTP port (i.e., there is no candidate for RTCP) for each media where it is desired to use
如果应答者希望在单个端口上多路传输RTP和RTCP，则必须为每个需要使用的媒体生成一个应答，其中包含一个“a=RTCP mux”属性和一个与RTP端口相对应的“a=candidate:”行（即，没有RTCP的候选者）
RTP and RTCP multiplexing. The answerer then performs connectivity checks for that media as if the offer had contained only a single candidate for RTP. If the answerer does not want to multiplex RTP and RTCP on a single port, it MUST NOT include the "a=rtcp-mux" attribute in its answer and MUST perform connectivity checks for all offered candidates in the usual manner.
RTP和RTCP多路复用。然后，应答者对该介质执行连接检查，就好像报价中只包含一个RTP候选对象一样。如果应答者不希望在单个端口上多路传输RTP和RTCP，则应答中不得包含“a=RTCP mux”属性，并且必须以通常方式对所有提供的候选端口执行连接检查。
On receipt of the answer, the offerer looks for the presence of the "a=rtcp-mux" line for each media where multiplexing was offered. If this is present, then connectivity checks proceed as if only a single candidate (for RTP) were offered, and multiplexing is used once the session is established. If the "a=rtcp-mux" line is not present, the session proceeds with connectivity checks using both RTP and RTCP candidates, eventually leading to a session being established with RTP and RTCP on separate ports (as signalled by the "a=rtcp:" attribute).
收到答复后，报价人将查找提供多路复用的每个媒体是否存在“a=rtcp mux”线路。如果存在这种情况，则连接检查将继续进行，就好像只提供了一个候选对象（用于RTP），并且在建立会话后使用多路复用。如果“a=rtcp mux”行不存在，会话将使用RTP和rtcp候选进行连接检查，最终导致在单独的端口上使用RTP和rtcp建立会话（如“a=rtcp:”属性所示）。
Multiplexing RTP and RTCP packets onto a single port may negatively impact header compression schemes, for example, Compressed RTP (CRTP) [20] and RObust Header Compression (ROHC) [21] [22]. Header compression exploits patterns of change in the RTP headers of consecutive packets to send an indication that the packet changed in the expected way, rather than sending the complete header each time. This can lead to significant bandwidth savings if flows have uniform behaviour.
将RTP和RTCP数据包复用到单个端口可能会对报头压缩方案产生负面影响，例如，压缩RTP（CRTP）[20]和鲁棒报头压缩（ROHC）[21][22]。报头压缩利用连续数据包的RTP报头中的变化模式来发送数据包以预期方式发生变化的指示，而不是每次发送完整的报头。如果流具有一致的行为，这将导致显著的带宽节约。
The presence of RTCP packets multiplexed with RTP data packets can disrupt the patterns of change between headers and has the potential to significantly reduce header compression efficiency. The extent of this disruption depends on the header compression algorithm used and on the way flows are classified. A well-designed classifier should be able to separate RTP and RTCP multiplexed on the same port into different compression contexts, using the payload type field, such that the effect on the compression ratio is small. A classifier that assigns compression contexts based only on the IP addresses and UDP ports will not perform well. It is expected that implementations of header compression will need to be updated to efficiently support RTP and RTCP multiplexed on the same port.
与RTP数据包多路复用的RTCP数据包的存在会破坏报头之间的变化模式，并有可能显著降低报头压缩效率。这种中断的程度取决于所使用的报头压缩算法和流的分类方式。设计良好的分类器应能够使用有效负载类型字段将同一端口上多路复用的RTP和RTCP分离到不同的压缩上下文中，从而对压缩比的影响较小。仅基于IP地址和UDP端口分配压缩上下文的分类器将无法很好地执行。预计需要更新报头压缩的实现，以有效地支持在同一端口上多路复用的RTP和RTCP。
This effect of multiplexing RTP and RTCP on header compression may be especially significant in those environments, such as some wireless telephony systems, that rely on the efficiency of header compression to match the media to a limited-capacity channel. The implications of multiplexing RTP and RTCP should be carefully considered before use in such environments.
复用RTP和RTCP对报头压缩的这种影响在那些依赖报头压缩的效率来将媒体匹配到有限容量信道的环境中可能特别显著，例如一些无线电话系统。在此类环境中使用之前，应仔细考虑复用RTP和RTCP的影响。
The problem of NAT traversal is less severe for Any Source Multicast (ASM) RTP sessions than for unicast RTP sessions, and the benefit of using separate ports for RTP and RTCP is greater due to the ability to support third-party RTCP-only monitors. Accordingly, RTP and RTCP packets SHOULD NOT be multiplexed onto a single port when using ASM RTP sessions and SHOULD instead use separate ports and multicast groups.
与单播RTP会话相比，任何源多播（ASM）RTP会话的NAT遍历问题都不那么严重，并且由于能够支持仅使用第三方RTCP的监视器，因此为RTP和RTCP使用单独端口的好处更大。因此，在使用ASM RTP会话时，RTP和RTCP数据包不应多路传输到单个端口，而应使用单独的端口和多播组。
RTP sessions running over Source-Specific Multicast (SSM) send RTCP packets from the source to receivers via the multicast channel, but use a separate unicast feedback mechanism [6] to send RTCP from the receivers back to the source, with the source either reflecting the RTCP packets to the group or sending aggregate summary reports.
通过源特定多播（SSM）运行的RTP会话通过多播通道将RTCP数据包从源发送到接收器，但使用单独的单播反馈机制[6]将RTCP从接收器发送回源，源将RTCP数据包反映到组或发送聚合摘要报告。
Following the terminology of [6], we identify three RTP/RTCP flows in an SSM session:
按照[6]的术语，我们确定SSM会话中的三个RTP/RTCP流：
1. RTP and RTCP flows between media sender and distribution source. In many scenarios, the media sender and distribution source are co-located, so multiplexing is not a concern. If the media sender and distribution source are connected by a unicast connection, the rules in Section 5.1 of this memo apply to that connection. If the media sender and distribution source are connected by an Any Source Multicast connection, the rules in Section 5.2 apply to that connection. If the media sender and distribution source are connected by a Source-Specific Multicast connection, the RTP and RTCP packets MAY be multiplexed on a single port, provided this is signalled (using "a=rtcp-mux" if using SDP).
1. RTP和RTCP在媒体发送方和分发源之间流动。在许多情况下，媒体发送器和分发源位于同一位置，因此不需要考虑多路复用。如果媒体发送方和分发源通过单播连接连接，则本备忘录第5.1节中的规则适用于该连接。如果媒体发送方和分发源通过任意源多播连接连接，则第5.2节中的规则适用于该连接。如果媒体发送器和分发源通过特定于源的多播连接连接，则RTP和RTCP数据包可以在单个端口上进行多路复用，前提是这是有信号的（如果使用SDP，则使用“a=RTCP mux”）。
2. RTP and RTCP sent from the distribution source to the receivers. The distribution source MAY multiplex RTP and RTCP onto a single port to ease NAT traversal issues on the forward SSM path, although doing so may hinder third-party monitoring devices if the session uses the simple feedback model. When using SDP, the multiplexing SHOULD be signalled using the "a=rtcp-mux" attribute.
2. 从分发源发送到接收器的RTP和RTCP。分发源可以将RTP和RTCP多路复用到单个端口上，以缓解前向SSM路径上的NAT穿越问题，尽管这样做可能会妨碍第三方监控设备（如果会话使用简单反馈模型）。使用SDP时，应使用“a=rtcp mux”属性发出多路复用信号。
3. RTCP sent from receivers to distribution source. This is an RTCP-only path, so multiplexing is not a concern.
3. 从接收器发送到分发源的RTCP。这是一个只有RTCP的路径，因此不需要考虑多路复用。
Multiplexing RTP and RTCP packets on a single port in an SSM session has the potential for interactions with header compression described in Section 5.1.4.
在SSM会话中，在单个端口上多路复用RTP和RTCP数据包可能与第5.1.4节中描述的报头压缩进行交互。
Multiplexing RTP and RTCP has implications on the use of the Quality of Service (QoS) mechanism that handles flow that are determined by a three or five tuple (protocol, port, and address for source and/or destination). In these cases, the RTCP flow will be merged with the RTP flow when multiplexing them together. Thus, the RTCP bandwidth requirement needs to be considered when doing QoS reservations for the combined RTP and RTCP flow. However, from an RTCP perspective it is beneficial to receive the same treatment of RTCP packets as for RTP as it provides more accurate statistics for the measurements performed by RTCP.
复用RTP和RTCP对使用服务质量（QoS）机制有影响，该机制处理由三元组或五元组（协议、端口和源和/或目标地址）确定的流。在这些情况下，RTCP流将在多路复用时与RTP流合并。因此，在为组合RTP和RTCP流进行QoS预留时，需要考虑RTCP带宽需求。然而，从RTCP的角度来看，接收与RTP相同的RTCP数据包处理是有益的，因为它为RTCP执行的测量提供了更准确的统计数据。
The bandwidth required for a multiplexed stream comprises the session bandwidth of the RTP stream plus the bandwidth used by RTCP. In the usual case, the RTP session bandwidth is signalled in the SDP "b=AS:" (or "b=TIAS:" [11]) line, and the RTCP traffic is limited to 5% of this value. Any QoS reservation SHOULD therefore be made for 105% of the "b=AS:" value. If a non-standard RTCP bandwidth fraction is used, signalled by the SDP "b=RR:" and/or "b=RS:" lines [12], then any QoS reservation SHOULD be made for bandwidth equal to (AS + RS + RR), taking the RS and RR values from the SDP answer.
多路复用流所需的带宽包括RTP流的会话带宽加上RTCP使用的带宽。在通常情况下，RTP会话带宽在SDP“b=AS:”（或“b=TIAS:”[11]）行中发出信号，RTCP通信量限制在该值的5%。因此，应为“b=AS:”值的105%进行任何QoS预留。如果使用由SDP“b=RR:”和/或“b=RS:”行发出信号的非标准RTCP带宽分数[12]，则应为等于（AS+RS+RR）的带宽预留任何QoS，并从SDP应答中获取RS和RR值。
The usage of multiplexing RTP and RTCP is not believed to introduce any new security considerations. Known major issues are the integrity and authentication of the signalling used to set up the multiplexing as well as the integrity, authentication, and confidentiality of the actual RTP and RTCP traffic. The security considerations in the RTP specification [1] and any applicable RTP profile (e.g., [7]) and payload format(s) apply.
多路复用RTP和RTCP的使用不会带来任何新的安全考虑。已知的主要问题是用于设置多路复用的信令的完整性和身份验证，以及实际RTP和RTCP流量的完整性、身份验证和机密性。RTP规范[1]和任何适用的RTP配置文件（如[7]）和有效负载格式中的安全注意事项适用。
If the Secure Real-time Transport Protocol (SRTP) [13] is to be used in conjunction with multiplexed RTP and RTCP, then multiplexing MUST be done below the SRTP layer. The sender generates SRTP and SRTCP packets in the usual manner, based on their separate cryptographic contexts, and multiplexes them onto a single port immediately before transmission. At the receiver, the cryptographic context is derived from the synchronization source (SSRC), destination network address, and destination transport port number in the usual manner, augmented using the RTP payload type and RTCP packet type to demultiplex SRTP and SRTCP according to the rules in Section 4 of this memo. After the SRTP and SRTCP packets have been demultiplexed, cryptographic processing happens in the usual manner.
如果安全实时传输协议（SRTP）[13]将与多路复用RTP和RTCP一起使用，则多路复用必须在SRTP层下进行。发送方根据各自的加密上下文以通常的方式生成SRTP和SRTCP数据包，并在传输前将其多路复用到单个端口上。在接收器处，加密上下文以通常方式从同步源（SSRC）、目标网络地址和目标传输端口号派生，并根据本备忘录第4节中的规则，使用RTP有效负载类型和RTCP数据包类型对SRTP和SRTCP进行解复用。在SRTP和SRTCP数据包被解复用后，加密处理以通常的方式进行。
Following the guidelines in [8], the IANA has registered one new SDP attribute:
按照[8]中的指南，IANA注册了一个新的SDP属性：
o Contact name/email: authors of RFC 5761
o 联系人姓名/电子邮件：RFC 5761的作者
o Attribute name: rtcp-mux
o 属性名称：rtcp mux
o Long-form attribute name: RTP and RTCP multiplexed on one port
o 长格式属性名称：RTP和RTCP在一个端口上多路传输
o Type of attribute: media level
o 属性类型：媒体级别
o Subject to charset: no
o 以字符集为准：否
This attribute is used to signal that RTP and RTCP traffic should be multiplexed on a single port (see Section 5 of this memo). It is a property attribute, which does not take a value.
此属性用于表示RTP和RTCP流量应在单个端口上多路传输（请参阅本备忘录第5节）。它是一个属性属性，不接受值。
The rules for assignment of RTP RTCP Control Packet Types in the RTP Parameters registry are updated as follows. When assigning RTP RTCP Control Packet types, IANA is requested to assign unused values from the range 200-223 where possible. If that range is fully occupied, values from the range 194-199 may be used, and then values from the ranges 1-191 and 224-254. This improves header validity checking of RTCP packets compared to RTP packets or other unrelated packets. The values 0 and 255 are avoided for improved validity checking relative to random packets since all-zeros and all-ones are common values.
RTP参数注册表中RTP RTCP控制数据包类型的分配规则更新如下。分配RTP RTCP控制数据包类型时，请IANA尽可能分配200-223范围内的未使用值。如果该范围被完全占用，则可以使用范围194-199中的值，然后使用范围1-191和224-254中的值。与RTP数据包或其他无关数据包相比，这改进了RTCP数据包的报头有效性检查。由于所有0和1都是公共值，因此避免使用值0和255，以改进相对于随机数据包的有效性检查。
We wish to thank Steve Casner, Joerg Ott, Christer Holmberg, Gunnar Hellstrom, Randell Jesup, Hadriel Kaplan, Harikishan Desineni, Stephan Wenger, Jonathan Rosenberg, Roni Even, Ingemar Johansson, Dave Singer, Kevin Johns, and David Black for their comments on this memo. This work was supported in part by the UK Engineering and Physical Sciences Research Council.
我们要感谢史蒂夫·卡斯纳、约伯格·奥特、克里斯特·霍姆伯格、甘纳·赫尔斯特罗姆、兰德尔·杰苏普、哈德里尔·卡普兰、哈里基尚·德西尼尼、斯蒂芬·温格、乔纳森·罗森博格、甚至罗尼、英格玛·约翰逊、戴夫·辛格、凯文·约翰斯和大卫·布莱克对这份备忘录的评论。这项工作得到了英国工程和物理科学研究委员会的部分支持。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[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] Turletti, T., "RTP Payload Format for H.261 Video Streams", RFC 2032, October 1996.
[3] Turletti，T.，“H.261视频流的RTP有效载荷格式”，RFC 2032，1996年10月。
[4] 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.
[4] Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[5] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[5] Friedman，T.，Caceres，R.，和A.Clark，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[6] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010.
[6] Ott，J.，Chesterfield，J.，和E.Schooler，“具有单播反馈的单源多播会话的RTP控制协议（RTCP）扩展”，RFC 57602010年2月。
[7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[7] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[8] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[9] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[10] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[10] Huitema，C.，“会话描述协议（SDP）中的实时控制协议（RTCP）属性”，RFC 3605，2003年10月。
[11] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.
[11] Westerlund，M.“会话描述协议（SDP）的独立于传输的带宽修改器”，RFC 38902004年9月。
[12] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[12] Casner，S.，“RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽修饰符”，RFC 3556，2003年7月。
[13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[13] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[14] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[14] Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[15] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Proceedings of ACM SIGCOMM 1990, September 1990.
[15] Clark，D.和D.Tennenhouse，“新一代协议的架构考虑”，ACM SIGCOMM会议录，1990年，1990年9月。
[16] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM SIGCOMM Computer Communication Review, Volume 22, Number 3, July 1992.
[16] Casner，S.和S.Deering，“第一次IETF互联网音频广播”，ACM SIGCOMM计算机通信评论，第22卷，第3期，1992年7月。
[17] Even, R., "RTP Payload Format for H.261 Video Streams", RFC 4587, August 2006.
[17] 甚至，R.“H.261视频流的RTP有效载荷格式”，RFC4587，2006年8月。
[18] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009.
[18] Johansson，I.和M.Westerlund，“对缩减规模实时传输控制协议（RTCP）的支持：机会和后果”，RFC 5506，2009年4月。
[19] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[19] Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[20] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[20] Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[21] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[21] Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP和未压缩”，RFC 3095，2001年7月。
[22] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010.
[22] Sandlund，K.，Pelletier，G.和L-E.Jonsson，“鲁棒头压缩（ROHC）框架”，RFC 57952010年3月。
Authors' Addresses
作者地址
Colin Perkins University of Glasgow Department of Computing Science Glasgow G12 8QQ UK
柯林帕金斯格拉斯哥大学计算科学系格拉斯哥G128QQ英国
EMail: csp@csperkins.org
EMail: csp@csperkins.org
Magnus Westerlund Ericsson Farogatan 6 Stockholm SE-164 80 Sweden
Magnus Westerlund Ericsson Farogatan 6斯德哥尔摩SE-164 80瑞典
EMail: magnus.westerlund@ericsson.com
EMail: magnus.westerlund@ericsson.com