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




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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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.


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
1. Introduction
1. 介绍

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]).


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.


This memo updates Section 11 of [1].


2. Background
2. 出身背景

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:


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.


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.


3. Terminology
3. 术语

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]中所述进行解释。

4. Distinguishable RTP and RTCP Packets
4. 可区分的RTP和RTCP数据包

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 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.


The following conflicts between RTP and RTCP packet types are known:


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.


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.


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


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.


5. Multiplexing RTP and RTCP on a Single Port
5. 在单个端口上多路复用RTP和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.


5.1. Unicast Sessions
5.1. 单播会话

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.


5.1.1. SDP Signalling
5.1.1. SDP信令

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的多路复用。例如:

       o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
       c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
       t=1153134164 1153137764
       m=audio 49170 RTP/AVP 97
       a=rtpmap:97 iLBC/8000
       o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
       c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
       t=1153134164 1153137764
       m=audio 49170 RTP/AVP 97
       a=rtpmap:97 iLBC/8000

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.


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带宽。

5.1.2. Interactions with SIP Forking
5.1.2. 与SIP分叉的交互

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.


5.1.3. Interactions with ICE
5.1.3. 与冰的相互作用

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.


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:”属性所示)。

5.1.4. Interactions with Header Compression
5.1.4. 与报头压缩的交互

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.


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.


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.


5.2. Any Source Multicast Sessions
5.2. 任何源多播会话

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数据包不应多路传输到单个端口,而应使用单独的端口和多播组。

5.3. Source-Specific Multicast Sessions
5.3. 源特定多播会话

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.


Following the terminology of [6], we identify three RTP/RTCP flows in an SSM session:


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.


6. Multiplexing, Bandwidth, and Quality of Service
6. 多路复用、带宽和服务质量

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.


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.


7. Security Considerations
7. 安全考虑

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.


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.


8. IANA Considerations
8. IANA考虑

Following the guidelines in [8], the IANA has registered one new SDP attribute:


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.


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,以改进相对于随机数据包的有效性检查。

9. Acknowledgements
9. 致谢

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.


10. References
10. 工具书类
10.1. Normative References
10.1. 规范性引用文件

[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月。

10.2. Informative References
10.2. 资料性引用

[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



Magnus Westerlund Ericsson Farogatan 6 Stockholm SE-164 80 Sweden

Magnus Westerlund Ericsson Farogatan 6斯德哥尔摩SE-164 80瑞典