Internet Engineering Task Force (IETF) J. Lennox
Request for Comments: 8108 Vidyo
Updates: 3550, 4585 M. Westerlund
Category: Standards Track Ericsson
ISSN: 2070-1721 Q. Wu
Huawei
C. Perkins
University of Glasgow
March 2017
Internet Engineering Task Force (IETF) J. Lennox
Request for Comments: 8108 Vidyo
Updates: 3550, 4585 M. Westerlund
Category: Standards Track Ericsson
ISSN: 2070-1721 Q. Wu
Huawei
C. Perkins
University of Glasgow
March 2017
Sending Multiple RTP Streams in a Single RTP Session
在单个RTP会话中发送多个RTP流
Abstract
摘要
This memo expands and clarifies the behavior of Real-time Transport Protocol (RTP) endpoints that use multiple synchronization sources (SSRCs). This occurs, for example, when an endpoint sends multiple RTP streams in a single RTP session. This memo updates RFC 3550 with regard to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTP Control Protocol (RTCP) behavior. It also updates RFC 4585 to change and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages.
本备忘录扩展并澄清了使用多个同步源（SSRC）的实时传输协议（RTP）端点的行为。例如，当端点在单个RTP会话中发送多个RTP流时，就会发生这种情况。本备忘录更新了RFC 3550，内容涉及在RTP会话中处理每个端点的多个SSRC，特别关注RTP控制协议（RTCP）行为。它还更新了RFC 4585，以更改和澄清SSRC超时的计算以及反馈消息的包含。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8108.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8108.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Use Cases for Multi-Stream Endpoints ............................4
3.1. Endpoints with Multiple Capture Devices ....................4
3.2. Multiple Media Types in a Single RTP Session ...............5
3.3. Multiple Stream Mixers .....................................5
3.4. Multiple SSRCs for a Single Media Source ...................5
4. Use of RTP by Endpoints That Send Multiple Media Streams ........6
5. Use of RTCP by Endpoints That Send Multiple Media Streams .......6
5.1. RTCP Reporting Requirement .................................7
5.2. Initial Reporting Interval .................................7
5.3. Aggregation of Reports into Compound RTCP Packets ..........8
5.3.1. Maintaining AVG_RTCP_SIZE ...........................9
5.3.2. Scheduling RTCP when Aggregating Multiple SSRCs ....10
5.4. Use of RTP/AVPF or RTP/SAVPF Feedback .....................13
5.4.1. Choice of SSRC for Feedback Packets ................13
5.4.2. Scheduling an RTCP Feedback Packet .................14
6. Adding and Removing SSRCs ......................................15
6.1. Adding RTP Streams ........................................16
6.2. Removing RTP Streams ......................................16
7. RTCP Considerations for Streams with Disparate Rates ...........17
7.1. Timing Out SSRCs ..........................................19
7.1.1. Problems with the RTP/AVPF T_rr_interval
Parameter ..........................................19
7.1.2. Avoiding Premature Timeout .........................20
7.1.3. Interoperability between RTP/AVP and RTP/AVPF ......21
7.1.4. Updated SSRC Timeout Rules .........................22
7.2. Tuning RTCP Transmissions .................................22
7.2.1. RTP/AVP and RTP/SAVP ...............................22
7.2.2. RTP/AVPF and RTP/SAVPF .............................24
8. Security Considerations ........................................25
9. References .....................................................26
9.1. Normative References ......................................26
9.2. Informative References ....................................26
Acknowledgments ...................................................29
Authors' Addresses ................................................29
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Use Cases for Multi-Stream Endpoints ............................4
3.1. Endpoints with Multiple Capture Devices ....................4
3.2. Multiple Media Types in a Single RTP Session ...............5
3.3. Multiple Stream Mixers .....................................5
3.4. Multiple SSRCs for a Single Media Source ...................5
4. Use of RTP by Endpoints That Send Multiple Media Streams ........6
5. Use of RTCP by Endpoints That Send Multiple Media Streams .......6
5.1. RTCP Reporting Requirement .................................7
5.2. Initial Reporting Interval .................................7
5.3. Aggregation of Reports into Compound RTCP Packets ..........8
5.3.1. Maintaining AVG_RTCP_SIZE ...........................9
5.3.2. Scheduling RTCP when Aggregating Multiple SSRCs ....10
5.4. Use of RTP/AVPF or RTP/SAVPF Feedback .....................13
5.4.1. Choice of SSRC for Feedback Packets ................13
5.4.2. Scheduling an RTCP Feedback Packet .................14
6. Adding and Removing SSRCs ......................................15
6.1. Adding RTP Streams ........................................16
6.2. Removing RTP Streams ......................................16
7. RTCP Considerations for Streams with Disparate Rates ...........17
7.1. Timing Out SSRCs ..........................................19
7.1.1. Problems with the RTP/AVPF T_rr_interval
Parameter ..........................................19
7.1.2. Avoiding Premature Timeout .........................20
7.1.3. Interoperability between RTP/AVP and RTP/AVPF ......21
7.1.4. Updated SSRC Timeout Rules .........................22
7.2. Tuning RTCP Transmissions .................................22
7.2.1. RTP/AVP and RTP/SAVP ...............................22
7.2.2. RTP/AVPF and RTP/SAVPF .............................24
8. Security Considerations ........................................25
9. References .....................................................26
9.1. Normative References ......................................26
9.2. Informative References ....................................26
Acknowledgments ...................................................29
Authors' Addresses ................................................29
At the time the Real-Time Transport Protocol (RTP) [RFC3550] was originally designed, and for quite some time after, endpoints in RTP sessions typically only transmitted a single media source and, thus, used a single RTP stream and synchronization source (SSRC) per RTP session, where separate RTP sessions were typically used for each distinct media type. Recently, however, a number of scenarios have emerged in which endpoints wish to send multiple RTP streams, distinguished by distinct RTP synchronization source (SSRC) identifiers, in a single RTP session. These are outlined in Section 3. Although the initial design of RTP did consider such scenarios, the specification was not consistently written with such use cases in mind; thus, the specification is somewhat unclear in places.
在最初设计实时传输协议（RTP）[RFC3550]时，RTP会话中的端点通常只传输单个媒体源，因此每个RTP会话使用单个RTP流和同步源（SSRC），其中，每个不同的媒体类型通常使用单独的RTP会话。然而，最近出现了一些场景，其中端点希望在单个RTP会话中发送多个RTP流，以不同的RTP同步源（SSRC）标识符区分。这些在第3节中概述。虽然RTP最初的设计确实考虑了这样的场景，但是规范并没有用这样的用例来写。因此，某些地方的规范有些不明确。
This memo updates [RFC3550] to clarify behavior in use cases where endpoints use multiple SSRCs. It also updates [RFC4585] to resolve problems with regard to timeout of inactive SSRCs and to clarify behavior around inclusion of feedback messages.
本备忘录更新了[RFC3550]，以澄清端点使用多个SSRC的用例中的行为。它还更新了[RFC4585]，以解决与非活动SSRC超时有关的问题，并澄清包含反馈消息的行为。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释，并指出合规实施的要求级别。
This section discusses several use cases that have motivated the development of endpoints that sends RTP data using multiple SSRCs in a single RTP session.
本节讨论了几个促使端点开发的用例，这些端点在单个RTP会话中使用多个SSRC发送RTP数据。
The most straightforward motivation for an endpoint to send multiple simultaneous RTP streams in a single RTP session is when an endpoint has multiple capture devices and, hence, can generate multiple media sources, of the same media type and characteristics. For example, telepresence systems of the type described by the CLUE Telepresence Framework [CLUE-FRAME] often have multiple cameras or microphones covering various areas of a room and, hence, send several RTP streams of each type within a single RTP session.
端点在单个RTP会话中同时发送多个RTP流的最直接动机是当端点具有多个捕获设备，因此可以生成具有相同媒体类型和特征的多个媒体源时。例如，线索临场感框架[CLUE-FRAME]所述类型的临场感系统通常具有多个摄像头或麦克风，覆盖房间的各个区域，因此，在单个RTP会话中发送每种类型的多个RTP流。
Recent work has updated RTP [MULTI-RTP] and Session Description Protocol (SDP) [SDP-BUNDLE] to remove the historical assumption in RTP that media sources of different media types would always be sent on different RTP sessions. In this work, a single endpoint's audio and video RTP streams (for example) are instead sent in a single RTP session to reduce the number of transport-layer flows used.
最近的工作更新了RTP[MULTI-RTP]和会话描述协议（SDP）[SDP-BUNDLE]，以消除RTP中的历史假设，即不同媒体类型的媒体源总是在不同的RTP会话上发送。在这项工作中，单个端点的音频和视频RTP流（例如）改为在单个RTP会话中发送，以减少使用的传输层流的数量。
There are several RTP topologies that can involve a central device that itself generates multiple RTP streams in a session. An example is a mixer providing centralized compositing for a multi-capture scenario like that described in Section 3.1. In this case, the centralized node is behaving much like a multi-capturer endpoint, generating several similar and related sources.
有几种RTP拓扑可以涉及一个中心设备，该设备本身在会话中生成多个RTP流。例如，混合器为第3.1节所述的多捕获场景提供集中合成。在这种情况下，集中式节点的行为非常类似于多捕获器端点，生成多个相似和相关的源。
A more complex example is the selective forwarding middlebox, described in Section 3.7 of [RFC7667]. This is a middlebox that receives RTP streams from several endpoints and then selectively forwards modified versions of some RTP streams toward the other endpoints to which it is connected. For each connected endpoint, a separate media source appears in the session for every other source connected to the middlebox, "projected" from the original streams, but at any given time many of them can appear to be inactive (and thus are receivers, not senders, in RTP). This sort of device is closer to being an RTP mixer than an RTP translator: it terminates RTCP reporting about the mixed streams; it can rewrite SSRCs, timestamps, and sequence numbers, as well as the contents of the RTP payloads; and it can turn sources on and off at will without appearing to generate packet loss. Each projected stream will typically preserve its original RTCP source description (SDES) information.
[RFC7667]第3.7节中描述的一个更复杂的示例是选择性转发中间盒。这是一个从多个端点接收RTP流的中间盒，然后有选择地将某些RTP流的修改版本转发到它所连接的其他端点。对于每个连接的端点，连接到中间盒的每个其他源的会话中都会显示一个单独的媒体源，从原始流“投影”而来，但在任何给定时间，它们中的许多都会显示为非活动的（因此在RTP中是接收方，而不是发送方）。这种设备比RTP转换器更接近RTP混频器：它终止RTCP对混合流的报告；它可以重写SSRC、时间戳和序列号，以及RTP有效负载的内容；而且它可以随意打开和关闭源，而不会出现数据包丢失。每个投影流通常将保留其原始RTCP源描述（SDES）信息。
There are also several cases where multiple SSRCs can be used to send data from a single media source within a single RTP session. These include, but are not limited to, transport robustness tools, such as the RTP retransmission payload format [RFC4588], that require one SSRC to be used for the media data and another SSRC for the repair data. Similarly, some layered media encoding schemes, for example, H.264 Scalable Video Coding (SVC) [RFC6190], can be used in a configuration where each layer is sent using a different SSRC within a single RTP session.
还有几种情况下，可以使用多个SSRC在单个RTP会话中从单个媒体源发送数据。这些包括但不限于传输健壮性工具，例如RTP重传有效负载格式[RFC4588]，其要求一个SSRC用于媒体数据，另一个SSRC用于修复数据。类似地，一些分层媒体编码方案，例如，H.264可伸缩视频编码（SVC）[RFC6190]，可用于在单个RTP会话中使用不同的SSRC发送每个层的配置中。
RTP is inherently a group communication protocol. Each endpoint in an RTP session will use one or more SSRCs, as will some types of RTP-level middlebox. Accordingly, unless restrictions on the number of SSRCs have been signaled, RTP endpoints can expect to receive RTP data packets sent using a number of different SSRCs, within a single RTP session. This can occur irrespective of whether the RTP session is running over a point-to-point connection or a multicast group, since middleboxes can be used to connect multiple transport connections together into a single RTP session (the RTP session is defined by the shared SSRC space, not by the transport connections). Furthermore, if RTP mixers are used, some SSRCs might only be visible in the contributing source (CSRC) list of an RTP packet and in RTCP, and might not appear directly as the SSRC of an RTP data packet.
RTP本质上是一种组通信协议。RTP会话中的每个端点将使用一个或多个SSRC，某些类型的RTP级中间盒也将使用SSRC。因此，除非对SSRC的数量进行了限制，否则RTP端点可以期望在单个RTP会话中接收使用多个不同SSRC发送的RTP数据包。无论RTP会话是通过点对点连接还是多播组运行，都可能发生这种情况，因为可以使用中间盒将多个传输连接连接到一个RTP会话中（RTP会话由共享SSRC空间定义，而不是由传输连接定义）。此外，如果使用RTP混频器，一些SSRC可能仅在RTP数据包的贡献源（CSC）列表和RTCP中可见，并且可能不会直接显示为RTP数据包的SSRC。
Every RTP endpoint will have an allocated share of the available session bandwidth, as determined by signaling and congestion control. The endpoint needs to keep its total media sending rate within this share. However, endpoints that send multiple RTP streams do not necessarily need to subdivide their share of the available bandwidth independently or uniformly to each RTP stream and its SSRCs. In particular, an endpoint can vary the bandwidth allocation to different streams depending on their needs, and it can dynamically change the bandwidth allocated to different SSRCs (for example, by using a variable-rate codec), provided the total sending rate does not exceed its allocated share. This includes enabling or disabling RTP streams, or their redundancy streams, as more or less bandwidth becomes available.
每个RTP端点都将拥有分配的可用会话带宽份额，这由信令和拥塞控制决定。端点需要将其总媒体发送速率保持在此共享范围内。然而，发送多个RTP流的端点不一定需要将其可用带宽份额独立或统一地细分到每个RTP流及其SSRC。特别地，端点可以根据不同流的需要改变其带宽分配，并且可以动态地改变分配给不同ssrc的带宽（例如，通过使用可变速率编解码器），前提是总发送速率不超过其分配的份额。这包括启用或禁用RTP流或其冗余流，因为可用带宽或多或少。
RTCP is defined in Section 6 of [RFC3550]. The description of the protocol is phrased in terms of the behavior of "participants" in an RTP session, under the assumption that each endpoint is a participant with a single SSRC. However, for correct operation in cases where endpoints have multiple SSRC values, implementations MUST treat each SSRC as a separate participant in the RTP session, so that an endpoint that has multiple SSRCs counts as multiple participants.
RTCP的定义见[RFC3550]第6节。协议的描述是根据RTP会话中“参与者”的行为来表述的，假设每个端点都是具有单个SSRC的参与者。但是，为了在端点具有多个SSRC值的情况下正确操作，实现必须将每个SSRC视为RTP会话中的一个单独参与者，以便具有多个SSRC的端点算作多个参与者。
An RTP endpoint that has multiple SSRCs MUST treat each SSRC as a separate participant in the RTP session. Each SSRC will maintain its own RTCP-related state information and, hence, will have its own RTCP reporting interval that determines when it sends RTCP reports. If the mechanism in [MULTI-STREAM-OPT] is not used, then each SSRC will send RTCP reports for all other SSRCs, including those co-located at the same endpoint.
具有多个SSRC的RTP端点必须将每个SSRC视为RTP会话中的单独参与者。每个SSRC将维护自己的RTCP相关状态信息，因此，将有自己的RTCP报告间隔，以确定何时发送RTCP报告。如果未使用[MULTI-STREAM-OPT]中的机制，则每个SSRC将发送所有其他SSRC的RTCP报告，包括位于同一端点的SSRC。
If the endpoint has some SSRCs that are sending data and some that are only receivers, then they will receive different shares of the RTCP bandwidth and calculate different base RTCP reporting intervals. Otherwise, all SSRCs at an endpoint will calculate the same base RTCP reporting interval. The actual reporting intervals for each SSRC are randomized in the usual way, but reports can be aggregated as described in Section 5.3.
如果端点具有一些正在发送数据的SSRC和一些仅为接收器的SSRC，则它们将接收不同的RTCP带宽共享，并计算不同的基本RTCP报告间隔。否则，端点处的所有SSRC将计算相同的基本RTCP报告间隔。每个SSRC的实际报告间隔以通常的方式随机化，但报告可按第5.3节所述进行汇总。
When a participant joins a unicast session, the following text from Section 6.2 of [RFC3550] is relevant: "For unicast sessions... the delay before sending the initial compound RTCP packet MAY be zero." The basic assumption is that this also ought to apply in the case of multiple SSRCs. Caution has to be exercised, however, when an endpoint (or middlebox) with a large number of SSRCs joins a unicast session, since immediate transmission of many RTCP reports can create a significant burst of traffic, leading to transient congestion and packet loss due to queue overflows.
当参与者加入单播会话时，[RFC3550]第6.2节中的以下文本相关：“对于单播会话……发送初始复合RTCP数据包之前的延迟可能为零。”基本假设是，这也应适用于多个SSRC的情况。但是，当具有大量SSRC的端点（或中间盒）加入单播会话时，必须谨慎，因为许多RTCP报告的即时传输可能会产生大量流量，导致队列溢出导致暂时拥塞和数据包丢失。
To ensure that the initial burst of traffic generated by an RTP endpoint is no larger than would be generated by a TCP connection, an RTP endpoint MUST NOT send more than four compound RTCP packets with zero initial delay when it joins an RTP session, independent of the number of SSRCs used by the endpoint. Each of those initial compound RTCP packets MAY include aggregated reports from multiple SSRCs, provided the total compound RTCP packet size does not exceed the MTU, and the avg_rtcp_size is maintained as in Section 5.3.1. Aggregating reports from several SSRCs in the initial compound RTCP packets allows a substantial number of SSRCs to report immediately. Endpoints SHOULD prioritize reports on SSRCs that are likely to be most immediately useful, e.g., for SSRCs that are initially senders.
为确保RTP端点生成的初始流量突发不大于TCP连接生成的流量突发，RTP端点在加入RTP会话时不得发送超过四个初始延迟为零的复合RTCP数据包，这与端点使用的SSRC数量无关。每个初始复合RTCP数据包可包括来自多个SSRC的聚合报告，前提是复合RTCP数据包的总大小不超过MTU，且平均RTCP数据包大小如第5.3.1节所述保持不变。将来自初始复合RTCP数据包中多个SSRC的报告聚合在一起，允许大量SSRC立即报告。端点应优先考虑可能最直接有用的SSRC报告，例如，对于最初是发送者的SSRC。
An endpoint that needs to report on more SSRCs than will fit into the four compound RTCP reports that can be sent immediately MUST send the other reports later, following the usual RTCP timing rules including timer reconsideration. Those reports MAY be aggregated as described in Section 5.3.
需要报告的SSRC数量超过可立即发送的四个复合RTCP报告的SSRC数量的端点必须稍后发送其他报告，并遵循通常的RTCP计时规则，包括计时器。这些报告可按第5.3节所述进行汇总。
Note: The above is chosen to match the TCP maximum initial window of four packets [RFC3390], not the larger TCP initial windows for which there is an ongoing experiment [RFC6928]. The reason for this is a desire to be conservative, since an RTP endpoint will also in many cases start sending RTP data packets at the same time as these initial RTCP packets are sent.
注：选择以上选项是为了匹配四个数据包的TCP最大初始窗口[RFC3390]，而不是正在进行实验的较大TCP初始窗口[RFC6928]。这样做的原因是希望保守，因为RTP端点在许多情况下也会在发送这些初始RTCP数据包的同时开始发送RTP数据包。
As outlined in Section 5.1, an endpoint with multiple SSRCs has to treat each SSRC as a separate participant when it comes to sending RTCP reports. This will lead to each SSRC sending a compound RTCP packet in each reporting interval. Since these packets are coming from the same endpoint, it might reasonably be expected that they can be aggregated to reduce overheads. Indeed, Section 6.1 of [RFC3550] allows RTP translators and mixers to aggregate packets in similar circumstances:
如第5.1节所述，具有多个SSRC的端点在发送RTCP报告时必须将每个SSRC视为单独的参与者。这将导致每个SSRC在每个报告间隔内发送一个复合RTCP数据包。由于这些数据包来自同一个端点，因此可以合理地预期它们可以聚合以减少开销。实际上，[RFC3550]第6.1节允许RTP转换器和混频器在类似情况下聚合数据包：
It is RECOMMENDED that translators and mixers combine individual RTCP packets from the multiple sources they are forwarding into one compound packet whenever feasible in order to amortize the packet overhead (see Section 7). An example RTCP compound packet as might be produced by a mixer is shown in Fig. 1. If the overall length of a compound packet would exceed the MTU of the network path, it SHOULD be segmented into multiple shorter compound packets to be transmitted in separate packets of the underlying protocol. This does not impair the RTCP bandwidth estimation because each compound packet represents at least one distinct participant. Note that each of the compound packets MUST begin with an SR or RR packet.
建议翻译器和混频器在可行的情况下，将来自其转发的多个源的单个RTCP数据包合并为一个复合数据包，以分摊数据包开销（见第7节）。图1中示出了可能由混合器产生的示例RTCP复合分组。如果复合数据包的总长度将超过网络路径的MTU，则应将其分割为多个较短的复合数据包，以在基础协议的单独数据包中传输。这不会影响RTCP带宽估计，因为每个复合数据包至少代表一个不同的参与者。请注意，每个复合数据包必须以SR或RR数据包开头。
This allows RTP translators and mixers to generate compound RTCP packets that contain multiple Sender Report (SR) or Receiver Report (RR) packets from different SSRCs, as well as any of the other packet types. There are no restrictions on the order in which the RTCP packets can occur within the compound packet, except the regular rule that the compound RTCP packet starts with an SR or RR packet. Due to this rule, correctly implemented RTP endpoints will be able to handle compound RTCP packets that contain RTCP packets relating to multiple SSRCs.
这允许RTP转换器和混合器生成复合RTCP数据包，其中包含来自不同SSRC的多个发送方报告（SR）或接收方报告（RR）数据包以及任何其他数据包类型。除了复合RTCP数据包以SR或RR数据包开始的常规规则外，RTCP数据包在复合数据包中出现的顺序没有限制。由于此规则，正确实现的RTP端点将能够处理包含与多个SSRC相关的RTCP数据包的复合RTCP数据包。
Accordingly, endpoints that use multiple SSRCs can aggregate the RTCP packets sent by their different SSRCs into compound RTCP packets, provided 1) the resulting compound RTCP packets begin with an SR or RR packet, 2) they maintain the average RTCP packet size as described in Section 5.3.1, and 3) they schedule packet transmission and manage aggregation as described in Section 5.3.2.
因此，使用多个SSRC的端点可以将其不同SSRC发送的RTCP数据包聚合为复合RTCP数据包，前提是1）生成的复合RTCP数据包以SR或RR数据包开始，2）它们保持第5.3.1节所述的平均RTCP数据包大小，以及3）他们按照第5.3.2节所述安排数据包传输和管理聚合。
The RTCP scheduling algorithm in [RFC3550] works on a per-SSRC basis. Each SSRC sends a single compound RTCP packet in each RTCP reporting interval. When an endpoint uses multiple SSRCs, it is desirable to aggregate the compound RTCP packets sent by its SSRCs, reducing the overhead by forming a larger compound RTCP packet. This aggregation can be done as described in Section 5.3.2, provided the average RTCP packet size calculation is updated as follows.
[RFC3550]中的RTCP调度算法基于每个SSRC工作。每个SSRC在每个RTCP报告间隔内发送一个复合RTCP数据包。当端点使用多个SSRC时，需要聚合其SSRC发送的复合RTCP数据包，通过形成更大的复合RTCP数据包来减少开销。可按照第5.3.2节所述进行聚合，前提是平均RTCP数据包大小计算更新如下。
Participants in an RTP session update their estimate of the average RTCP packet size (avg_rtcp_size) each time they send or receive an RTCP packet (see Section 6.3.3 of [RFC3550]). When a compound RTCP packet that contains RTCP packets from several SSRCs is sent or received, the avg_rtcp_size estimate for each SSRC that is reported upon is updated using div_packet_size rather than the actual packet size:
RTP会话的参与者在每次发送或接收RTCP数据包时更新其对平均RTCP数据包大小（平均RTCP数据包大小）的估计值（见[RFC3550]第6.3.3节）。当发送或接收包含来自多个SSRC的RTCP数据包的复合RTCP数据包时，使用div_packet_size（而非实际数据包大小）更新报告的每个SSRC的平均RTCP大小估计值：
avg_rtcp_size = (1/16) * div_packet_size + (15/16) * avg_rtcp_size
avg_rtcp_size = (1/16) * div_packet_size + (15/16) * avg_rtcp_size
where div_packet_size is packet_size divided by the number of SSRCs reporting in that compound packet. The number of SSRCs reporting in a compound packet is determined by counting the number of different SSRCs that are the source of SR or RR RTCP packets within the compound RTCP packet. Non-compound RTCP packets (i.e., RTCP packets that do not contain an SR or RR packet [RFC5506]) are considered to report on a single SSRC.
其中，div_packet_size是packet_size除以该复合数据包中报告的SSRC数量。复合数据包中报告的SSRC数量通过计算复合RTCP数据包中作为SR或RR RTCP数据包源的不同SSRC的数量来确定。非复合RTCP数据包（即不包含SR或RR数据包[RFC5506]）的RTCP数据包被视为报告单个SSRC。
A participant that doesn't follow the above rule, and instead uses the full RTCP compound packet size to calculate avg_rtcp_size, will derive an RTCP reporting interval that is overly large by a factor that is proportional to the number of SSRCs aggregated into compound RTCP packets and the size of set of SSRCs being aggregated relative to the total number of participants. This increased RTCP reporting interval can cause premature timeouts if it is more than five times the interval chosen by the SSRCs that understand compound RTCP that aggregate reports from many SSRCs. A 1500-octet MTU can fit five typical-size reports into a compound RTCP packet, so this is a real concern if endpoints aggregate RTCP reports from multiple SSRCs.
不遵循上述规则，而是使用完整RTCP复合数据包大小来计算平均RTCP大小的参与者，将得出RTCP报告间隔过大的系数，该系数与聚合为复合RTCP数据包的SSRC数量以及聚合的SSRC集相对于参与者总数的大小成正比。如果RTCP报告间隔的增加超过SSRC选择的间隔的五倍，则RTCP报告间隔的增加可能会导致过早超时。SSRC理解从多个SSRC汇总报告的复合RTCP。一个1500个八位组的MTU可以将五个典型大小的报告放入一个复合RTCP数据包中，因此如果端点聚合来自多个SSRC的RTCP报告，这是一个真正的问题。
The issue raised in the previous paragraph is mitigated by the modification in timeout behavior specified in Section 7.1.2 of this memo. This mitigation is in place in those cases where the RTCP bandwidth is sufficiently high that an endpoint, using avg_rtcp_size calculated without taking into account the number of reporting SSRCs, can transmit more frequently than approximately every 5 seconds. Note, however, that the non-updated endpoint's RTCP reporting is still negatively impacted even if the premature timeouts of its SSRCs
通过修改本备忘录第7.1.2节中规定的超时行为，缓解了上一段中提出的问题。这种缓解措施适用于RTCP带宽足够高的情况，即使用在不考虑报告SSRC数量的情况下计算的avg_RTCP_大小的端点可以比大约每5秒更频繁地传输。但是，请注意，即使其SSRC过早超时，未更新端点的RTCP报告仍会受到负面影响
are avoided. If compatibility with non-updated endpoints is a concern, the number of reports from different SSRCs aggregated into a single compound RTCP packet SHOULD either be limited to two reports or aggregation ought not be used at all. This will limit the non-updated endpoint's RTCP reporting interval to be no larger than twice the RTCP reporting interval that would be chosen by an endpoint following this specification.
这是避免的。如果关注与未更新端点的兼容性，则聚合到单个复合RTCP数据包中的来自不同SSRC的报告数量应限制为两个报告，或者根本不应使用聚合。这将限制未更新端点的RTCP报告间隔不大于端点根据本规范选择的RTCP报告间隔的两倍。
This section revises and extends the behavior defined in Section 6.3 of [RFC3550], and in Section 3.5.3 of [RFC4585] if the RTP/AVPF profile or the RTP/SAVPF profile is used, regarding actions to take when scheduling and sending RTCP packets where multiple reporting SSRCs are aggregating their RTCP packets into the same compound RTCP packet. These changes to the RTCP scheduling rules are needed to maintain important RTCP timing properties, including the inter-packet distribution, and the behavior during flash joins and other changes in session membership.
本节修改并扩展了[RFC3550]第6.3节和[RFC4585]第3.5.3节（如果使用RTP/AVPF配置文件或RTP/SAVPF配置文件）中定义的行为，涉及多个报告SSRC将其RTCP数据包聚合为同一复合RTCP数据包时调度和发送RTCP数据包时要采取的行动。需要对RTCP调度规则进行这些更改，以维护重要的RTCP定时属性，包括数据包间分布、闪存连接期间的行为以及会话成员资格的其他更改。
The variables tn, tp, tc, T, and Td used in the following are defined in Section 6.3 of [RFC3550]. The variables T_rr_interval and T_rr_last are defined in [RFC4585].
[RFC3550]第6.3节定义了下文中使用的变量tn、tp、tc、T和Td。[RFC4585]中定义了变量T_rr_interval和T_rr_last。
Each endpoint MUST schedule RTCP transmission independently for each of its SSRCs using the regular calculation of tn for the RTP profile being used. Each time the timer tn expires for an SSRC, the endpoint MUST perform RTCP timer reconsideration and, if applicable, suppression based on T_rr_interval. If the result indicates that a compound RTCP packet is to be sent by that SSRC, and the transmission is not an early RTCP packet [RFC4585], then the endpoint SHOULD try to aggregate RTCP packets of additional SSRCs that are scheduled in the future into the compound RTCP packet before it is sent. The reason to limit or not aggregate due to backwards compatibility reasons is discussed in Section 5.3.1.
每个端点必须使用正在使用的RTP配置文件的tn的常规计算，为其每个SSRC独立调度RTCP传输。每次SSRC的计时器tn过期时，端点必须执行RTCP计时器重新考虑，如果适用，还必须基于T_rr_间隔执行抑制。如果结果表明该SSRC将发送复合RTCP数据包，且传输不是早期RTCP数据包[RFC4585]，则端点应尝试在发送复合RTCP数据包之前将未来调度的附加SSRC的RTCP数据包聚合到该复合RTCP数据包中。第5.3.1节讨论了由于向后兼容性原因而限制或不聚合的原因。
Aggregation proceeds as follows. The endpoint selects the SSRC that has the smallest tn value after the current time, tc, and prepares the RTCP packets that SSRC would send if its timer tn expired at tc. If those RTCP packets will fit into the compound RTCP packet that is being generated, taking into account the path MTU and the previously added RTCP packets, then they are added to the compound RTCP packet; otherwise, they are discarded. This process is repeated for each SSRC, in order of increasing tn, until the compound RTCP packet is full or all SSRCs have been aggregated. At that point, the compound RTCP packet is sent.
汇总如下。端点选择在当前时间tc之后具有最小tn值的SSRC，并准备在其计时器tn在tc过期时SSRC将发送的RTCP数据包。如果考虑到路径MTU和先前添加的RTCP数据包，这些RTCP数据包将适合正在生成的复合RTCP数据包，则将它们添加到复合RTCP数据包中；否则，它们将被丢弃。对每个SSRC重复此过程，以增加tn的顺序，直到复合RTCP数据包已满或所有SSRC已聚合。此时，发送复合RTCP数据包。
When the compound RTCP packet is sent, the endpoint MUST update tp, tn, and T_rr_last (if applicable) for each SSRC that was included. These variables are updated as follows:
发送复合RTCP数据包时，端点必须为包含的每个SSRC更新tp、tn和T_rr_last（如果适用）。这些变量更新如下：
a. For the first SSRC that reported in the compound RTCP packet, set the effective transmission time, tt, of that SSRC to tc.
a. 对于复合RTCP数据包中报告的第一个SSRC，将该SSRC的有效传输时间tt设置为tc。
b. For each additional SSRC that reported in the compound RTCP packet, calculate the transmission time that SSRC would have had if it had not been aggregated into the compound RTCP packet. This is derived by taking tn for that SSRC, then performing reconsideration and updating tn until tp + T <= tn. Once this is done, set the effective transmission time, tt, for that SSRC to the calculated value of tn. If the RTP/AVPF profile or the RTP/ SAVPF profile is being used, then suppression based on T_rr_interval MUST NOT be used in this calculation.
b. 对于复合RTCP数据包中报告的每个附加SSRC，计算SSRC在未聚合到复合RTCP数据包中时的传输时间。取该SSRC的tn，然后重新考虑和更新tn，直到tp+T<=tn。完成后，将该SSRC的有效传输时间tt设置为tn的计算值。如果使用RTP/AVPF配置文件或RTP/SAVPF配置文件，因此，基于T_rr_间隔的抑制不能用于此计算。
c. Calculate average effective transmission time, tt_avg, for the compound RTCP packet based on the tt values for all SSRCs sent in the compound RTCP packet. Set tp for each of the SSRCs sent in the compound RTCP packet to tt_avg. If the RTP/AVPF profile or the RTP/SAVPF profile is being used, set T_tt_last for each SSRC sent in the compound RTCP packet to tt_avg.
c. 根据复合RTCP数据包中发送的所有SSRC的tt值，计算复合RTCP数据包的平均有效传输时间tt_avg。将复合RTCP数据包中发送的每个SSRC的tp设置为tt_平均值。如果使用RTP/AVPF配置文件或RTP/SAVPF配置文件，则将复合RTCP数据包中发送的每个SSRC的T_tt_最后设置为tt_平均值。
d. For each of the SSRCs sent in the compound RTCP packet, calculate new tn values based on the updated parameters and the usual RTCP timing rules and reschedule the timers.
d. 对于复合RTCP数据包中发送的每个SSRC，根据更新的参数和通常的RTCP定时规则计算新的tn值，并重新安排计时器。
When using the RTP/AVPF profile or the RTP/SAVPF profile, the above mechanism only attempts to aggregate RTCP packets when the compound RTCP packet to be sent is not an early RTCP packet, and hence the algorithm in Section 3.5.3 of [RFC4585] will control RTCP scheduling. If T_rr_interval == 0, or if T_rr_interval != 0 and option 1, 2a, or 2b of the algorithm are chosen, then the above mechanism updates the necessary variables. However, if the transmission is suppressed per option 2c of the algorithm, then tp is updated to tc as aggregation has not taken place.
当使用RTP/AVPF配置文件或RTP/SAVPF配置文件时，上述机制仅在要发送的复合RTCP数据包不是早期RTCP数据包时尝试聚合RTCP数据包，因此[RFC4585]第3.5.3节中的算法将控制RTCP调度。如果T_rr_interval==0，或如果T_rr_interval！=选择0和算法的选项1、2a或2b，然后上述机制更新必要的变量。然而，如果根据算法的选项2c抑制传输，则tp将更新为tc，因为没有发生聚合。
Reverse reconsideration MUST be performed following Section 6.3.4 of [RFC3550]. In some cases, this can lead to the value of tp after reverse reconsideration being larger than tc. This is not a problem, and has the desired effect of proportionally pulling the tp value towards tc (as well as tn) as the reporting interval shrinks in direct proportion the reduced group size.
必须按照[RFC3550]第6.3.4节进行反向重新审议。在某些情况下，这可能导致反向重新考虑后tp的值大于tc。这不是一个问题，并且当报告间隔与减少的组大小成正比收缩时，具有将tp值按比例拉向tc（以及tn）的预期效果。
The above algorithm has been shown in simulations [Sim88] [Sim92] to maintain the inter-RTCP packet transmission time distribution for each SSRC and to consume the same amount of bandwidth as
上述算法已在模拟[Sim88][Sim92]中显示，以维持每个SSRC的RTCP间数据包传输时间分布，并消耗与SSRC相同的带宽
non-aggregated RTCP packets. With this algorithm, the actual transmission interval for an SSRC triggering an RTCP compound packet transmission is following the regular transmission rules. The value tp is set to somewhere in the interval [0, 1.5/1.21828*Td] ahead of tc. The actual value is the average of one instance of tc and the randomized transmission times of the additional SSRCs; thus, the lower range of the interval is more probable. This compensates for the bias that is otherwise introduced by picking the shortest tn value out of the N SSRCs included in aggregate.
非聚合RTCP数据包。使用该算法，触发RTCP复合数据包传输的SSRC的实际传输间隔遵循常规传输规则。值tp设置为tc之前间隔[0,1.5/1.21828*Td]的某个位置。实际值是tc的一个实例和附加SSRC的随机传输时间的平均值；因此，间隔的较低范围更有可能。这补偿了通过从骨料中包含的N个SSRC中选取最短tn值引入的偏差。
The algorithm also handles the cases where the number of SSRCs that can be included in an aggregated packet varies. An SSRC that previously was aggregated and fails to fit in a packet still has its own transmission scheduled according to normal rules. Thus, it will trigger a transmission in due time, or the SSRC will be included in another aggregate. The algorithm's behavior under SSRC group size changes is as follows:
该算法还处理可包含在聚合数据包中的SSRC数量变化的情况。以前聚合的SSRC无法放入数据包中，根据正常规则，它仍有自己的传输计划。因此，它将在适当的时候触发传输，或者SSRC将包含在另一个聚合中。算法在SSRC组大小变化时的行为如下：
RTP sessions where the number of SSRCs is growing: When the group size is growing, Td grows in proportion to the number of new SSRCs in the group. When reconsideration is performed due to expiry of the tn timer, that SSRC will reconsider the transmission and with a certain probability reschedule the tn timer. This part of the reconsideration algorithm is only impacted by the above algorithm having tp values that were in the future instead of set to the time of the actual last transmission at the time of updating tp.
SSRC数量增长的RTP会话：当组规模增长时，Td与组中新SSRC的数量成比例增长。当由于tn定时器到期而重新考虑时，SSRC将重新考虑传输，并以一定的概率重新安排tn定时器。重新考虑算法的这一部分仅受上述算法的影响，该算法具有将来的tp值，而不是在更新tp时设置为实际最后一次传输的时间。
RTP sessions where the number of SSRCs is shrinking: When the group shrinks, reverse reconsideration moves the tp and tn values towards tc proportionally to the number of SSRCs that leave the session compared to the total number of participants when they left. The setting of the tp value forward in time related to the tc could be believed to have negative effect. However, the reason for this setting is to compensate for bias caused by picking the shortest tn out of the N aggregated. This bias remains over a reduction in the number of SSRCs. The reverse reconsideration compensates the reduction independently of whether or not aggregation is being used. The negative effect that can occur on removing an SSRC is that the most favorable tn belonged to the removed SSRC. The impact of this is limited to delaying the transmission, in the worst case, one reporting interval.
SSRC数量减少的RTP会话：当组缩小时，反向重新考虑将tp和tn值移向tc，与离开会话的SSRC数量与离开时的参与者总数成比例。与tc相关的tp值在时间上向前设置可能会产生负面影响。但是，此设置的原因是为了补偿从N个聚合的tn中选取最短tn所导致的偏差。这种偏见仍然存在于SSRC数量的减少上。反向重新考虑独立于是否使用聚合来补偿减少。去除SSRC可能产生的负面影响是，最有利的tn属于去除的SSRC。其影响仅限于延迟传输，在最坏的情况下，延迟一个报告间隔。
In conclusion, the investigations performed have found no significant negative impact on the scheduling algorithm.
总之，所进行的调查未发现对调度算法的重大负面影响。
This section discusses the transmission of RTP/AVPF feedback packets when the transmitting endpoint has multiple SSRCs. The guidelines in this section also apply to endpoints using the RTP/SAVPF profile.
本节讨论当传输端点具有多个SSRC时RTP/AVPF反馈数据包的传输。本节中的指南也适用于使用RTP/SAVPF配置文件的端点。
When an RTP/AVPF endpoint has multiple SSRCs, it can choose what SSRC to use as the source for the RTCP feedback packets it sends. Several factors can affect that choice:
当RTP/AVPF端点具有多个SSRC时，它可以选择使用哪个SSRC作为其发送的RTCP反馈数据包的源。有几个因素会影响这种选择：
o RTCP feedback packets relating to a particular media type SHOULD be sent by an SSRC that receives that media type. For example, when audio and video are multiplexed onto a single RTP session, endpoints will use their audio SSRC to send feedback on the audio received from other participants.
o 与特定媒体类型相关的RTCP反馈数据包应由接收该媒体类型的SSRC发送。例如，当音频和视频多路传输到单个RTP会话时，端点将使用其音频SSRC发送从其他参与者接收的音频反馈。
o RTCP feedback packets and RTCP codec control messages that are notifications or indications regarding RTP data processed by an endpoint MUST be sent from the SSRC used for that RTP data. This includes notifications that relate to a previously received request or command [RFC4585][RFC5104].
o RTCP反馈数据包和RTCP编解码器控制消息是关于端点处理的RTP数据的通知或指示，必须从用于该RTP数据的SSRC发送。这包括与先前收到的请求或命令[RFC4585][RFC5104]相关的通知。
o If separate SSRCs are used to send and receive media, then the corresponding SSRC SHOULD be used for feedback, since they have differing RTCP bandwidth fractions. This can also affect the consideration of whether or not the SSRC can be used in immediate mode.
o 如果使用单独的SSRC发送和接收媒体，则应使用相应的SSRC进行反馈，因为它们具有不同的RTCP带宽分数。这也会影响是否可以在即时模式下使用SSRC的考虑。
o Some RTCP feedback packet types require consistency in the SSRC used. For example, if a Temporary Maximum Media Stream Bit Rate Request (TMMBR) limitation [RFC5104] is set by an SSRC, the same SSRC needs to be used to remove the limitation.
o 某些RTCP反馈数据包类型要求所用SSRC的一致性。例如，如果SSRC设置了临时最大媒体流比特率请求（TMMBR）限制[RFC5104]，则需要使用相同的SSRC来消除该限制。
o If several SSRCs are suitable for sending feedback, it might be desirable to use an SSRC that allows the sending of feedback as an early RTCP packet.
o 如果多个SSRC适合发送反馈，则可能需要使用允许作为早期RTCP数据包发送反馈的SSRC。
When an RTCP feedback packet is sent as part of a compound RTCP packet that aggregates reports from multiple SSRCs, there is no requirement that the compound packet contain an SR or RR packet generated by the sender of the RTCP feedback packet. For reduced-size RTCP packets, aggregation of RTCP feedback packets from multiple sources is not limited further than Section 4.2.2 of [RFC5506].
当RTCP反馈数据包作为聚合多个SSRC报告的复合RTCP数据包的一部分发送时，不要求复合数据包包含RTCP反馈数据包发送方生成的SR或RR数据包。对于较小的RTCP数据包，来自多个来源的RTCP反馈数据包的聚合不受[RFC5506]第4.2.2节的限制。
When an SSRC has a need to transmit a feedback packet in early mode, it MUST schedule that packet following the algorithm in Section 3.5 of [RFC4585] modified as follows:
当SSRC需要在早期模式下传输反馈数据包时，它必须按照[RFC4585]第3.5节中的算法调度该数据包，修改如下：
o To determine whether an RTP session is considered to be a point-to-point session or a multiparty session, an endpoint MUST count the number of distinct RTCP SDES CNAME values used by the SSRCs listed in the SSRC field of RTP data packets it receives and in the "SSRC of sender" field of RTCP SR, RR, RTPFB, or PSFB packets it receives. An RTP session is considered to be a multiparty session if more than one CNAME is used by those SSRCs, unless signaling indicates that the session is to be handled as point to point or RTCP reporting groups [MULTI-STREAM-OPT] are used. If RTCP reporting groups are used, an RTP session is considered to be a point-to-point session if the endpoint receives only a single reporting group and is considered to be a multiparty session if multiple reporting groups are received or a combination of reporting groups and SSRCs that are not part of a reporting group are received. Endpoints MUST NOT determine whether an RTP session is multiparty or point to point based on the type of connection (unicast or multicast) used, or on the number of SSRCs received.
o 要确定RTP会话被视为点对点会话还是多方会话，端点必须统计其接收的RTP数据包的SSRC字段和RTCP SR、RR、RTPFB或PSFB数据包的“SSRC of sender”字段中列出的SSRC使用的不同RTCP SDES CNAME值的数量。如果这些SSRC使用多个CNAME，则RTP会话被视为多方会话，除非信令指示该会话将作为点对点或使用RTCP报告组[MULTI-STREAM-OPT]进行处理。如果使用RTCP报告组，如果端点仅接收单个报告组，则RTP会话被视为点对点会话；如果接收到多个报告组，或接收到不属于报告组的报告组和SSRC的组合，则RTP会话被视为多方会话。端点不得根据所使用的连接类型（单播或多播）或接收的SSRC数量确定RTP会话是多方会话还是点对点会话。
o When checking if there is already a scheduled compound RTCP packet containing feedback messages (Step 2 in Section 3.5.2 of [RFC4585]), that check MUST be done considering all local SSRCs.
o 当检查是否已经存在包含反馈消息的预定复合RTCP数据包（RFC4585第3.5.2节中的步骤2）时，必须考虑所有本地SSRC进行检查。
o If an SSRC is not allowed to send an early RTCP packet, then the feedback message MAY be queued for transmission as part of any early or regular scheduled transmission that can occur within the maximum useful lifetime of the feedback message (T_max_fb_delay). This modifies the behavior in item 4a in Section 3.5.2 of [RFC4585].
o 如果不允许SSRC发送早期RTCP数据包，则反馈消息可排队等待传输，作为任何早期或常规预定传输的一部分，该传输可在反馈消息的最大使用寿命内发生（T_max_fb_delay）。这修改了[RFC4585]第3.5.2节第4a项中的行为。
The first bullet point above specifies a rule to determine if an RTP session is to be considered a point-to-point session or a multiparty session. This rule is straightforward to implement, but is known to incorrectly classify some sessions as multiparty sessions. The known problems are as follows:
上面的第一个要点指定了一个规则，用于确定RTP会话是被视为点对点会话还是多方会话。此规则易于实现，但已知会错误地将某些会话分类为多方会话。已知的问题如下：
Endpoint with multiple synchronization contexts: An endpoint that is part of a point-to-point session can have multiple synchronization contexts, for example, due to forwarding an external media source into an interactive real-time conversation. In this case, the classification will consider the peer as two endpoints, while the actual RTP/RTCP transmission will be under the control of one endpoint.
具有多个同步上下文的端点：作为点到点会话一部分的端点可以具有多个同步上下文，例如，由于将外部媒体源转发到交互式实时会话中。在这种情况下，分类将考虑对等点作为两个端点，而实际的RTP/RTCP传输将在一个端点的控制之下。
Selective Forwarding Middlebox: The Selective Forwarding Middlebox (SFM) as defined in Section 3.7 of [RFC7667] has control over the transmission and configurations between itself and each peer endpoint individually. It also fully controls the RTCP packets being forwarded between the individual legs. Thus, this type of middlebox can be compared to the RTP mixer, which uses its own SSRCs to mix or select the media it forwards, that will be classified as a point-to-point RTP session by the above rule.
选择性转发中间箱：[RFC7667]第3.7节中定义的选择性转发中间箱（SFM）可以单独控制自身和每个对等端点之间的传输和配置。它还完全控制各个分支之间转发的RTCP数据包。因此，这种类型的中间盒可以与RTP混合器相比较，RTP混合器使用自己的SSRC来混合或选择它转发的媒体，根据上述规则，这些媒体将被分类为点对点RTP会话。
In the above cases, it is very reasonable to use RTCP reporting groups [MULTI-STREAM-OPT]. If that extension is used, an endpoint can indicate that the multitude of CNAMEs are in fact under a single endpoint or middlebox control by using only a single reporting group.
在上述情况下，使用RTCP报告组[MULTI-STREAM-OPT]是非常合理的。如果使用该扩展，端点可以通过仅使用单个报告组来指示多个CNAME实际上处于单个端点或中间盒控制之下。
The above rules will also classify some sessions where the endpoint is connected to an RTP mixer as being point to point. For example, the mixer could act as gateway to an RTP session based on Any Source Multicast for the discussed endpoint. However, this will, in most cases, be okay, as the RTP mixer provides separation between the two parts of the session. The responsibility falls on the mixer to act accordingly in each domain.
上述规则还将端点连接到RTP混合器的某些会话分类为点对点会话。例如，混合器可以作为基于所讨论端点的任何源多播的RTP会话的网关。但是，在大多数情况下，这是可以的，因为RTP混合器在会话的两个部分之间提供分离。责任落在混合器上，以在每个域中采取相应的行动。
Finally, we note that signaling mechanisms could be defined to override the rules when they would result in the wrong classification.
最后，我们注意到，当信号机制导致错误分类时，可以将其定义为覆盖规则。
The set of SSRCs present in a single RTP session can vary over time due to changes in the number of endpoints in the session or due to changes in the number or type of RTP streams being sent.
单个RTP会话中存在的SSRC集可能会随着时间的推移而变化，这是由于会话中端点数量的变化，或者由于正在发送的RTP流的数量或类型的变化。
Every endpoint in an RTP session will have at least one SSRC that it uses for RTCP reporting, and for sending media if desired. It can also have additional SSRCs, for sending extra media sources or for additional RTCP reporting. If the set of media sources being sent changes, then the set of SSRCs being sent will change. Changes in the media format or clock rate might also require changes in the set of SSRCs used. An endpoint can also have more SSRCs than it has active RTP streams, and send RTCP relating to SSRCs that are not currently sending RTP data packets so that its peers are aware of the SSRCs, and have the associated context (e.g., clock synchronization and an SDES CNAME) in place to be able to play out media as soon as they becomes active.
RTP会话中的每个端点将至少有一个SSRC，用于RTCP报告和发送媒体（如果需要）。它还可以有额外的SSRC，用于发送额外的媒体源或额外的RTCP报告。如果要发送的媒体源集更改，则要发送的SSRC集将更改。媒体格式或时钟频率的更改也可能需要更改所使用的SSRC集。端点还可以具有比其具有活动RTP流更多的SSRC，并发送与当前未发送RTP数据包的SSRC相关的RTCP，以便其对等方知道SSRC，并具有相关上下文（例如，时钟同步和SDES CNAME），以便在媒体变为活动时能够播放媒体。
In the following, we describe some considerations around adding and removing RTP streams and their associated SSRCs.
在下文中，我们将介绍有关添加和删除RTP流及其相关SSRC的一些注意事项。
When an endpoint joins an RTP session, it can have zero, one, or more RTP streams it will send, or that it is prepared to send. If it has no RTP stream it plans to send, it still needs an SSRC that will be used to send RTCP feedback. If it will send one or more RTP streams, it will need the corresponding number of SSRC values. The SSRCs used by an endpoint are made known to other endpoints in the RTP session by sending RTP and RTCP packets. SSRCs can also be signaled using non-RTP means (e.g., [RFC5576]). Unless restricted by signaling, an endpoint can, at any time, send an additional RTP stream, identified by a new SSRC (this might be associated with a signaling event, but that is outside the scope of this memo). This makes the new SSRC visible to the other endpoints in the session, since they share the single SSRC space inherent in the definition of an RTP session.
当端点加入RTP会话时，它可以有零个、一个或多个要发送的RTP流，或者准备发送的RTP流。如果它没有计划发送的RTP流，它仍然需要一个SSRC来发送RTCP反馈。如果它将发送一个或多个RTP流，它将需要相应数量的SSRC值。在RTP会话中，通过发送RTP和RTCP数据包，使端点使用的SSRC为其他端点所知。也可以使用非RTP方式（例如，[RFC5576]）向SSRC发送信号。除非受到信令的限制，否则端点可以随时发送由新SSRC标识的附加RTP流（这可能与信令事件相关，但不在本备忘录的范围内）。这使得会话中的其他端点可以看到新的SSRC，因为它们共享RTP会话定义中固有的单个SSRC空间。
An endpoint that has never sent an RTP stream will have an SSRC that it uses for RTCP reporting. If that endpoint wants to start sending an RTP stream, it is RECOMMENDED that it use its existing SSRC for that stream, since otherwise the participant count in the RTP session will be unnecessarily increased, leading to a longer RTCP reporting interval and larger RTCP reports due to cross reporting. If the endpoint wants to start sending more than one RTP stream, it will need to generate a new SSRC for the second and any subsequent RTP streams.
从未发送RTP流的端点将具有用于RTCP报告的SSRC。如果该端点想要开始发送RTP流，建议它对该流使用其现有的SSRC，因为否则RTP会话中的参与者计数将不必要地增加，从而由于交叉报告而导致更长的RTCP报告间隔和更大的RTCP报告。如果端点想要开始发送多个RTP流，它将需要为第二个和任何后续RTP流生成新的SSRC。
An endpoint that has previously stopped sending an RTP stream, and that wants to start sending a new RTP stream, cannot generally reuse the existing SSRC, and often needs to generate a new SSRC, because an SSRC cannot change media type (e.g., audio to video) or RTP timestamp clock rate [RFC7160] and because the SSRC might be associated with a particular semantic by the application (note: an RTP stream can pause and restart using the same SSRC, provided RTCP is sent for that SSRC during the pause; these rules only apply to new RTP streams reusing an existing SSRC).
先前已停止发送RTP流且希望开始发送新RTP流的端点通常无法重用现有SSRC，并且通常需要生成新SSRC，因为SSRC无法更改媒体类型（例如，音频到视频）或RTP时间戳时钟速率[RFC7160]由于SSRC可能与应用程序的特定语义相关联（注意：RTP流可以使用相同的SSRC暂停和重新启动，前提是在暂停期间为该SSRC发送RTCP；这些规则仅适用于重用现有SSRC的新RTP流）。
An SSRC is removed from an RTP session in one of two ways. When an endpoint stops sending RTP and RTCP packets using an SSRC, then that SSRC will eventually time out as described in Section 6.3.5 of [RFC3550]. Alternatively, an SSRC can be explicitly removed from use by sending an RTCP BYE packet as described in Section 6.3.7 of [RFC3550]. It is RECOMMENDED that SSRCs be removed from use by sending an RTCP BYE packet. Note that [RFC3550] requires that the RTCP BYE SHOULD be the last RTP/RTCP packet sent in the RTP session
SSRC通过以下两种方式之一从RTP会话中删除。当端点停止使用SSRC发送RTP和RTCP数据包时，该SSRC将最终超时，如[RFC3550]第6.3.5节所述。或者，如[RFC3550]第6.3.7节所述，通过发送RTCP BYE数据包，SSRC可以明确地从使用中删除。建议通过发送RTCP BYE数据包将SSRC从使用中删除。注意，[RFC3550]要求RTCP BYE应该是RTP会话中发送的最后一个RTP/RTCP数据包
for an SSRC. If an endpoint needs to restart an RTP stream after sending an RTCP BYE for its SSRC, it needs to generate a new SSRC value for that stream.
对于SSRC。如果端点在为其SSRC发送RTCP BYE后需要重新启动RTP流，则需要为该流生成新的SSRC值。
The finality of sending RTCP BYE means that endpoints need to consider if the ceasing of transmission of an RTP stream is temporary or permanent. Temporary suspension of media transmission using a particular RTP stream (SSRC) needs to maintain that SSRC as an active participant, by continuing RTCP transmission for it. That way the media sending can be resumed immediately, knowing that the context is in place. When permanently halting transmission, a participant needs to send an RTCP BYE to allow the other participants to use the RTCP bandwidth resources and clean up their state databases.
发送RTCP再见的终结意味着如果RTP流的传输停止是暂时的或永久的，则需要考虑端点。使用特定RTP流（SSRC）临时暂停媒体传输需要通过继续RTCP传输来保持SSRC作为活动参与者。这样，在知道上下文已就位的情况下，可以立即恢复媒体发送。永久停止传输时，参与者需要发送RTCP BYE，以允许其他参与者使用RTCP带宽资源并清理其状态数据库。
An endpoint that ceases transmission of all its RTP streams but remains in the RTP session MUST maintain at least one SSRC that is to be used for RTCP reporting and feedback (i.e., it cannot send a BYE for all SSRCs, but needs to retain at least one active SSRC). As some Feedback packets can be bound to media type, there might be a need to maintain one SSRC per media type within an RTP session. An alternative can be to create a new SSRC to use for RTCP reporting and feedback. However, to avoid the perception that an endpoint drops completely out of an RTP session, such a new SSRC ought to be established first -- before terminating all the existing SSRCs.
停止传输其所有RTP流但仍保留在RTP会话中的端点必须维护至少一个用于RTCP报告和反馈的SSRC（即，它不能为所有SSRC发送BYE，但需要保留至少一个活动SSRC）。由于某些反馈数据包可以绑定到媒体类型，因此可能需要在RTP会话中为每个媒体类型维护一个SSRC。另一种方法是创建新的SSRC，用于RTCP报告和反馈。然而，为了避免端点完全退出RTP会话的感觉，应该首先建立这样一个新的SSRC——然后再终止所有现有的SSRC。
An RTP session has a single set of parameters that configure the session bandwidth. These are the RTCP sender and receiver fractions (e.g., the SDP "b=RR:" and "b=RS:" lines [RFC3556]) and the parameters of the RTP/AVPF profile [RFC4585] (e.g., trr-int) if that profile (or its secure extension, RTP/SAVPF [RFC5124]) is used. As a consequence, the base RTCP reporting interval, before randomization, will be the same for every sending SSRC in an RTP session. Similarly, every receiving SSRC in an RTP session will have the same base reporting interval, although this can differ from the reporting interval chosen by sending SSRCs. This uniform RTCP reporting interval for all SSRCs can result in RTCP reports being sent more often, or too seldom, than is considered desirable for an RTP stream.
RTP会话只有一组参数来配置会话带宽。这些是RTCP发送方和接收方部分（例如，SDP“b=RR:”和“b=RS:”行[RFC3556]）以及RTP/AVPF配置文件[RFC4585]（例如，trr int）的参数（如果使用该配置文件（或其安全扩展，RTP/SAVPF[RFC5124]）。因此，在随机化之前，RTP会话中每个发送SSRC的基本RTCP报告间隔将相同。类似地，RTP会话中的每个接收SSRC将具有相同的基本报告间隔，尽管这可能与发送SSRC选择的报告间隔不同。所有SSRC的统一RTCP报告间隔可能导致发送RTCP报告的频率高于或低于RTP流所需的频率。
For example, consider a scenario in which an audio flow sending at tens of kilobits per second is multiplexed into an RTP session with a multi-megabit high-quality video flow. If the session bandwidth is configured based on the video sending rate, and the default RTCP bandwidth fraction of 5% of the session bandwidth is used, it is likely that the RTCP bandwidth will exceed the audio sending rate. If the reduced minimum RTCP interval described in Section 6.2 of [RFC3550] is then used in the session, as appropriate for video where
例如，考虑一种场景，其中以每秒几十千兆字节发送的音频流被多路复用到具有多兆比特高质量视频流的RTP会话中。如果根据视频发送速率配置会话带宽，并使用会话带宽5%的默认RTCP带宽分数，则RTCP带宽可能会超过音频发送速率。如果在会话中使用[RFC3550]第6.2节中所述的缩短的最小RTCP间隔，视情况而定，用于视频，其中
rapid feedback on damaged I-frames is wanted, the uniform reporting interval for all senders could mean that audio sources are expected to send RTCP packets more often than they send audio data packets. This bandwidth mismatch can be reduced by careful tuning of the RTCP parameters, especially trr_int when the RTP/AVPF profile is used, but cannot be avoided entirely as it is inherent in the design of the RTCP timing rules, and affects all RTP sessions that contain flows with greatly mismatched bandwidth.
需要对损坏的I帧进行快速反馈，所有发送方的统一报告间隔可能意味着音频源发送RTCP数据包的频率比发送音频数据包的频率更高。通过仔细调整RTCP参数，尤其是使用RTP/AVPF配置文件时的trr_int，可以减少这种带宽不匹配，但不能完全避免，因为这是RTCP定时规则设计中固有的，并且会影响包含带宽严重不匹配流的所有RTP会话。
Different media rates or desired RTCP behaviors can also occur with SSRCs carrying the same media type. A common case in multiparty conferencing is when a small number of video streams are shown in high resolution, while the others are shown as low-resolution thumbnails, with the choice of which is shown in high resolution being voice-activity controlled. Here the differences are both in actual media rate and in choices for what feedback messages might be needed. Other examples of differences that can exist are due to the intended usage of a media source. A media source carrying the video of the speaker in a conference is different from a document camera. Basic parameters that can differ in this case are frame-rate, acceptable end-to-end delay, and the Signal-to-Noise Ratio (SNR) fidelity of the image. These differences affect not only the needed bitrates, but also possible transmission behaviors, usable repair mechanisms, what feedback messages the control and repair requires, the transmission requirements on those feedback messages, and monitoring of the RTP stream delivery. Other similar scenarios can also exist.
对于承载相同媒体类型的SSRC，也可能出现不同的媒体速率或期望的RTCP行为。多方会议中的一种常见情况是，少量视频流以高分辨率显示，而其他视频流以低分辨率缩略图显示，其中高分辨率显示的选择受语音活动控制。这里的差异在于实际的媒体速率和可能需要的反馈信息的选择。其他可能存在的差异示例是由于媒体源的预期用途。会议中携带演讲者视频的媒体源不同于文档摄像机。在这种情况下可能不同的基本参数是帧速率、可接受的端到端延迟以及图像的信噪比（SNR）保真度。这些差异不仅影响所需的比特率，还影响可能的传输行为、可用的修复机制、控制和修复所需的反馈消息、这些反馈消息的传输要求以及RTP流交付的监控。也可能存在其他类似的情况。
Sending multiple media types in a single RTP session causes that session to contain more SSRCs than if each media type was sent in a separate RTP session. For example, if two participants each send an audio and a video RTP stream in a single RTP session, that session will comprise four SSRCs; but if separate RTP sessions had been used for audio and video, each of those two RTP sessions would comprise only two SSRCs. Hence, sending multiple RTP streams in an RTP session increases the amount of cross reporting between the SSRCs, as each SSRC reports on all other SSRCs in the session. This increases the size of the RTCP reports, causing them to be sent less often than would be the case if separate RTP sessions where used for a given RTCP bandwidth.
在单个RTP会话中发送多种媒体类型会导致该会话包含比在单独RTP会话中发送每种媒体类型更多的SSRC。例如，如果两个参与者在单个RTP会话中各自发送音频和视频RTP流，则该会话将包括四个SSRC；但如果单独的RTP会话用于音频和视频，那么这两个RTP会话中的每一个都将只包含两个SSRC。因此，在RTP会话中发送多个RTP流会增加SSRC之间的交叉报告量，因为每个SSRC报告会话中的所有其他SSRC。这增加了RTCP报告的大小，导致它们发送的频率低于用于给定RTCP带宽的单独RTP会话的情况。
Finally, when an RTP session contains multiple media types, it is important to note that the RTCP reception quality reports, feedback messages, and extended report blocks used might not be applicable to all media types. Endpoints will need to consider the media type of each SSRC, and only send or process reports and feedback that apply to that particular SSRC and its media type. Signaling solutions
最后，当RTP会话包含多种媒体类型时，请务必注意，使用的RTCP接收质量报告、反馈消息和扩展报告块可能不适用于所有媒体类型。端点将需要考虑每个SSRC的媒体类型，并且只发送或处理适用于特定SSRC及其媒体类型的报告和反馈。信号解决方案
might have shortcomings when it comes to indicating that a particular set of RTCP reports or feedback messages only apply to a particular media type within an RTP session.
在指出一组特定的RTCP报告或反馈消息仅适用于RTP会话中的特定媒体类型时，可能存在缺陷。
From an RTCP perspective, therefore, it can be seen that there are advantages to using separate RTP sessions for each media source, rather than sending multiple media sources in a single RTP session. However, these are frequently offset by the need to reduce port use, to ease NAT/firewall traversal, achieved by combining media sources into a single RTP session. The following sections consider some of the issues with using RTCP in sessions with multiple media sources in more detail.
因此，从RTCP的角度来看，可以看出，对每个媒体源使用单独的RTP会话，而不是在一个RTP会话中发送多个媒体源，具有优势。然而，通过将媒体源合并到单个RTP会话中，减少端口使用以简化NAT/防火墙穿越的需要经常会抵消这些影响。下面的部分将详细讨论在多个媒体源会话中使用RTCP的一些问题。
Various issues have been identified with timing out SSRC values when sending multiple RTP streams in an RTP session.
在RTP会话中发送多个RTP流时，已发现SSRC值超时的各种问题。
The RTP/AVPF profile includes a method to prevent regular RTCP reports from being sent too often. This mechanism is described in Section 3.5.3 of [RFC4585]; it is controlled by the T_rr_interval parameter. It works as follows. When a regular RTCP report is sent, a new random value, T_rr_current_interval, is generated, drawn evenly in the range 0.5 to 1.5 times T_rr_interval. If a regular RTCP packet is to be sent earlier than T_rr_current_interval seconds after the previous regular RTCP packet, and there are no feedback messages to be sent, then that regular RTCP packet is suppressed and the next regular RTCP packet is scheduled. The T_rr_current_interval is recalculated each time a regular RTCP packet is sent. The benefit of suppression is that it avoids wasting bandwidth when there is nothing requiring frequent RTCP transmissions, but still allows utilization of the configured bandwidth when feedback is needed.
RTP/AVPF配置文件包括一种防止经常发送RTCP报告的方法。[RFC4585]第3.5.3节描述了该机制；它由T_rr_interval参数控制。它的工作原理如下。发送常规RTCP报告时，将生成一个新的随机值T_rr_current_interval，在T_rr_interval的0.5到1.5倍范围内均匀绘制。如果在上一个常规RTCP数据包之后的T_rr_current_interval秒之前发送一个常规RTCP数据包，并且没有要发送的反馈消息，则该常规RTCP数据包将被抑制，并计划下一个常规RTCP数据包。每次发送常规RTCP数据包时，都会重新计算T_rr_current_间隔。抑制的好处是，它避免了在不需要频繁RTCP传输时浪费带宽，但在需要反馈时仍允许利用配置的带宽。
Unfortunately, this suppression mechanism skews the distribution of the RTCP sending intervals compared to the regular RTCP reporting intervals. The standard RTCP timing rules, including reconsideration and the compensation factor, result in the intervals between sending RTCP packets having a distribution that is skewed towards the upper end of the range [0.5/1.21828, 1.5/1.21828]*Td, where Td is the deterministic calculated RTCP reporting interval. With Td = 5 s, this distribution covers the range [2.052 s, 6.156 s]. In comparison, the RTP/AVPF suppression rules act in an interval that is 0.5 to 1.5 times T_rr_interval; for T_rr_interval = 5s, this is [2.5 s, 7.5 s].
不幸的是，与常规RTCP报告间隔相比，这种抑制机制使RTCP发送间隔的分布发生偏差。标准RTCP定时规则，包括重新考虑和补偿系数，导致发送RTCP数据包之间的间隔，其分布向[0.5/1.21828,1.5/1.21828]*Td范围的上端倾斜，其中Td是确定性计算的RTCP报告间隔。当Td=5秒时，此分布覆盖范围为[2.052秒，6.156秒]。相比之下，RTP/AVPF抑制规则的作用间隔为T_-rr_间隔的0.5到1.5倍；对于T_rr_间隔=5s，这是[2.5秒，7.5秒]。
The effect of this is that the time between consecutive RTCP packets when using T_rr_interval suppression can become large. The maximum time interval between sending one regular RTCP packet and the next, when T_rr_interval is being used, occurs when T_rr_current_interval takes its maximum value and a regular RTCP packet is suppressed at the end of the suppression period, then the next regular RTCP packet is scheduled after its largest possible reporting interval. Taking the worst case of the two intervals gives a maximum time between two RTCP reports of 1.5*T_rr_interval + 1.5/1.21828*Td.
这样做的效果是，当使用T_rr_间隔抑制时，连续RTCP数据包之间的时间可能变大。当使用T_rr_interval时，发送一个常规RTCP数据包和下一个RTCP数据包之间的最大时间间隔发生在T_rr_current_interval取其最大值时，并且在抑制期结束时抑制一个常规RTCP数据包，然后在其最大可能报告间隔后调度下一个常规RTCP数据包。采用两个时间间隔中的最坏情况，两个RTCP报告之间的最长时间间隔为1.5*T_rr_间隔+1.5/1.21828*Td。
This behavior can be surprising when Td and T_rr_interval have the same value. That is, when T_rr_interval is configured to match the regular RTCP reporting interval. In this case, one might expect that regular RTCP packets are sent according to their usual schedule, but feedback packets can be sent early. However, the above-mentioned issue results in the RTCP packets actually being sent in the range [0.5*Td, 2.731*Td] with a highly non-uniform distribution, rather than the range [0.41*Td, 1.23*Td]. This is perhaps unexpected, but is not a problem in itself. However, when coupled with packet loss, it raises the issue of premature timeout.
当Td和T_rr_interval具有相同的值时，这种行为可能会令人惊讶。也就是说，当T_rr_间隔配置为与常规RTCP报告间隔匹配时。在这种情况下，人们可能期望常规RTCP数据包按照其通常的时间表发送，但反馈数据包可以提前发送。然而，上述问题导致RTCP分组实际在具有高度非均匀分布的范围[0.5*Td，2.731*Td]内发送，而不是在范围[0.41*Td，1.23*Td]内发送。这也许出乎意料，但本身并不是问题。然而，当与数据包丢失相结合时，它会引发过早超时的问题。
In RTP/AVP [RFC3550] the timeout behavior is simple; it is 5 times Td, where Td is calculated with a Tmin value of 5 seconds. In other words, if the configured RTCP bandwidth allows for an average RTCP reporting interval shorter than 5 seconds, the timeout is 25 seconds of no activity from the SSRC (RTP or RTCP); otherwise, the timeout is 5 average reporting intervals.
在RTP/AVP[RFC3550]中，超时行为很简单；它是Td的5倍，其中Td用5秒的Tmin值计算。换句话说，如果配置的RTCP带宽允许平均RTCP报告间隔小于5秒，则超时为25秒，SSRC（RTP或RTCP）无活动；否则，超时为5个平均报告间隔。
RTP/AVPF [RFC4585] introduces different timeout behaviors depending on the value of T_rr_interval. When T_rr_interval is 0, it uses the same timeout calculation as RTP/AVP. However, when T_rr_interval is non-zero, it replaces Tmin in the timeout calculation, most likely to speed up detection of timed out SSRCs. However, using a non-zero T_rr_interval has two consequences for RTP behavior.
RTP/AVPF[RFC4585]根据T_rr_interval的值引入不同的超时行为。当T_rr_interval为0时，它使用与RTP/AVP相同的超时计算。但是，当T_rr_interval为非零时，它将在超时计算中替换Tmin，最有可能加快超时SSRC的检测速度。然而，使用非零T_rr_间隔对RTP行为有两个后果。
First, due to suppression, the number of RTP and RTCP packets sent by an SSRC that is not an active RTP sender can become very low, because of the issue discussed in Section 7.1.1. As the RTCP packet interval can be as long as 2.73*Td, during a 5*Td time period, an endpoint might in fact transmit only a single RTCP packet. The long intervals result in fewer RTCP packets, to a point where a single RTCP packet loss can sometimes result in timing out an SSRC.
首先，由于抑制，由非活动RTP发送方的SSRC发送的RTP和RTCP数据包的数量可能会变得非常低，这是因为第7.1.1节中讨论的问题。由于RTCP数据包间隔可以长达2.73*Td，因此在5*Td的时间段内，一个端点实际上可能只发送一个RTCP数据包。长时间间隔导致RTCP数据包减少，单个RTCP数据包丢失有时会导致SSRC超时。
Second, the RTP/AVPF changes to the timeout rules reduce robustness to misconfiguration. It is common to use RTP/AVPF configured such that RTCP packets can be sent frequently to allow rapid feedback;
其次，RTP/AVPF对超时规则的更改降低了对错误配置的鲁棒性。通常使用RTP/AVPF配置，以便可以频繁发送RTCP数据包以允许快速反馈；
however, this makes timeouts very sensitive to T_rr_interval. For example, if two SSRCs are configured, one with T_rr_interval = 0.1 s and the other with T_rr_interval = 0.6 s, then this small difference will result in the SSRC with the shorter T_rr_interval timing out the other if it stops sending RTP packets, since the other RTCP reporting interval is more than five times its own. When RTP/AVP is used, or RTP/AVPF with T_rr_interval = 0, this is a non-issue, as the timeout period will be 25 s, and differences between configured RTCP bandwidth can only cause premature timeouts when the reporting intervals are greater than 5 s and differ by a factor of five. To limit the scope for such problematic misconfiguration, we define an update to the RTP/AVPF timeout rules in Section 7.1.4.
然而，这使得超时对T_rr_间隔非常敏感。例如，如果配置了两个SSRC，一个具有T_rr_间隔=0.1 s，另一个具有T_rr_间隔=0.6 s，则此微小差异将导致具有较短T_rr_间隔的SSRC在停止发送RTP数据包时超时，因为另一个RTCP报告间隔是其自身的五倍以上。当使用RTP/AVP或RTP/AVPF且T_rr_间隔=0时，这不是问题，因为超时时间为25秒，并且当报告间隔大于5秒且相差五倍时，配置的RTCP带宽之间的差异只能导致过早超时。为了限制此类有问题的错误配置的范围，我们在第7.1.4节中定义了对RTP/AVPF超时规则的更新。
If endpoints implementing the RTP/AVP and RTP/AVPF profiles (or their secure variants) are combined within a single RTP session, and the RTP/AVPF endpoints use a non-zero T_rr_interval that is significantly below 5 seconds, there is a risk that the RTP/AVPF endpoints will prematurely time out the SSRCs of the RTP/AVP endpoints, due to their different RTCP timeout rules. Conversely, if the RTP/AVPF endpoints use a T_rr_interval that is significantly larger than 5 seconds, there is a risk that the RTP/AVP endpoints will time out the SSRCs of the RTP/AVPF endpoints.
如果实现RTP/AVP和RTP/AVPF配置文件（或其安全变体）的端点组合在单个RTP会话中，并且RTP/AVPF端点使用显著低于5秒的非零T_rr_间隔，则RTP/AVPF端点将过早超时RTP/AVP端点的SSRC的风险，由于它们的RTCP超时规则不同。相反，如果RTP/AVPF端点使用的T_-rr_间隔明显大于5秒，则RTP/AVP端点有可能使RTP/AVPF端点的SSRC超时。
Mixing endpoints using two different RTP profiles within a single RTP session is NOT RECOMMENDED. However, if mixed RTP profiles are used, and the RTP/AVPF endpoints are not updated to follow Section 7.1.4 of this memo, then the RTP/AVPF session SHOULD be configured to use T_rr_interval = 4 seconds to avoid premature timeouts.
不建议在单个RTP会话中混合使用两个不同RTP配置文件的端点。但是，如果使用混合RTP配置文件，并且RTP/AVPF端点未按照本备忘录第7.1.4节进行更新，则RTP/AVPF会话应配置为使用T_rr_interval=4秒，以避免过早超时。
The choice of T_rr_interval = 4 seconds for interoperability might appear strange. Intuitively, this value ought to be 5 seconds, to make both the RTP/AVP and RTP/AVPF use the same timeout period. However, the behavior outlined in Section 7.1.1 shows that actual RTP/AVPF reporting intervals can be longer than expected. Setting T_rr_interval = 4 seconds gives actual RTCP intervals near to those expected by RTP/AVP, ensuring interoperability.
为互操作性选择T_rr_interval=4秒可能看起来很奇怪。直观地说，这个值应该是5秒，以使RTP/AVP和RTP/AVPF使用相同的超时时间。然而，第7.1.1节中概述的行为表明，实际RTP/AVPF报告间隔可能比预期更长。设置T_rr_interval=4秒可使实际RTCP间隔接近RTP/AVP预期的间隔，从而确保互操作性。
To ensure interoperability and avoid premature timeouts, all SSRCs in an RTP session MUST use the same timeout behavior. However, previous specifications are inconsistent in this regard. To avoid interoperability issues, this memo updates the timeout rules as follows:
为了确保互操作性并避免过早超时，RTP会话中的所有SSRC必须使用相同的超时行为。但是，以前的规范在这方面不一致。为避免互操作性问题，此备忘录更新了超时规则，如下所示：
o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, the timeout interval SHALL be calculated using a multiplier of five times the deterministic RTCP reporting interval. That is, the timeout interval SHALL be 5*Td.
o 对于RTP/AVP、RTP/SAVP、RTP/AVPF和RTP/SAVPF配置文件，应使用确定性RTCP报告间隔五倍的乘数计算超时间隔。即，超时间隔应为5*Td。
o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, calculation of Td, for the purpose of calculating the participant timeout only, SHALL be done using a Tmin value of 5 seconds and not the reduced minimal interval, even if the reduced minimum interval is used to calculate RTCP packet transmission intervals.
o 对于RTP/AVP、RTP/SAVP、RTP/AVPF和RTP/SAVPF配置文件，仅为了计算参与者超时，应使用5秒的Tmin值，而不是减少的最小间隔来计算Td，即使减少的最小间隔用于计算RTCP数据包传输间隔。
This changes the behavior for the RTP/AVPF or RTP/SAVPF profiles when T_rr_interval != 0. Specifically, the first paragraph of Section 3.5.4 of [RFC4585] is updated to use Tmin instead of T_rr_interval in the timeout calculation for RTP/AVPF entities.
当T_rr_interval！=0具体而言，[RFC4585]第3.5.4节的第一段更新为在RTP/AVPF实体的超时计算中使用Tmin而不是T_rr_间隔。
This subsection discusses what tuning can be done to reduce the downsides of the shared RTCP packet intervals. First, what possibilities exist for the RTP/AVP [RFC3551] profile are listed followed by what additional tools are provided by RTP/AVPF [RFC4585].
本小节讨论如何进行调优以减少共享RTCP数据包间隔的缺点。首先，列出了RTP/AVP[RFC3551]配置文件存在的可能性，然后是RTP/AVPF[RFC4585]提供的其他工具。
When using the RTP/AVP or RTP/SAVP profiles, the options for tuning the RTCP reporting intervals are limited to the RTCP sender and receiver bandwidth, and whether the minimum RTCP interval is scaled according to the bandwidth. As the scheduling algorithm includes both randomization and reconsideration, one cannot simply calculate the expected average transmission interval using the formula for Td given in Section 6.3.1 of [RFC3550]. However, by considering the inputs to that expression, and the randomization and reconsideration rules, we can begin to understand the behavior of the RTCP transmission interval.
使用RTP/AVP或RTP/SAVP配置文件时，调整RTCP报告间隔的选项仅限于RTCP发送方和接收方带宽，以及是否根据带宽调整最小RTCP间隔。由于调度算法包括随机化和重新考虑，因此不能简单地使用[RFC3550]第6.3.1节给出的Td公式计算预期平均传输间隔。然而，通过考虑该表达式的输入以及随机化和重新考虑规则，我们可以开始了解RTCP传输间隔的行为。
Let's start with some basic observations:
让我们从一些基本观察开始：
a. Unless the scaled minimum RTCP interval is used, Td prior to randomization and reconsideration can never be less than Tmin. The default value of Tmin is 5 seconds.
a. 除非使用标度最小RTCP间隔，否则随机化和重新考虑之前的Td不得小于Tmin。Tmin的默认值为5秒。
b. If the scaled minimum RTCP interval is used, Td can become as low as 360 divided by RTP Session bandwidth in kilobits per second. In SDP, the RTP session bandwidth is signaled using a "b=AS" line. An RTP Session bandwidth of 72 kbps results in Tmin being 5 seconds. An RTP session bandwidth of 360 kbps of course gives a Tmin of 1 second, and to achieve a Tmin equal to once every frame for a 25 frame-per-second video stream requires an RTP session bandwidth of 9 Mbps. Use of the RTP/AVPF or RTP/SAVPF profile allows more frequent RTCP reports for the same bandwidth, as discussed below.
b. 如果使用按比例缩放的最小RTCP间隔，Td可以低至360除以RTP会话带宽（千比特/秒）。在SDP中，RTP会话带宽使用“b=AS”行发出信号。72 kbps的RTP会话带宽导致Tmin为5秒。当然，360 kbps的RTP会话带宽会产生1秒的Tmin，而对于每秒25帧的视频流，要实现等于每帧一次的Tmin，则需要9 Mbps的RTP会话带宽。如下文所述，使用RTP/AVPF或RTP/SAVPF配置文件允许对相同带宽进行更频繁的RTCP报告。
c. The value of Td scales with the number of SSRCs and the average size of the RTCP reports to keep the overall RTCP bandwidth constant.
c. Td值随SSRC的数量和RTCP报告的平均大小而变化，以保持整个RTCP带宽不变。
d. The actual transmission interval for a Td value is in the range [0.5*Td/1.21828, 1.5*Td/1.21828], and the distribution is skewed, due to reconsideration, with the majority of the probability mass being above Td. This means, for example, that for Td = 5 s, the actual transmission interval will be distributed in the range [2.052 s, 6.156 s], and tending towards the upper half of the interval. Note that Tmin parameter limits the value of Td before randomization and reconsideration are applied, so the actual transmission interval will cover a range extending below Tmin.
d. Td值的实际传输间隔在[0.5*Td/1.21828,1.5*Td/1.21828]范围内，由于重新考虑，分布是倾斜的，大部分概率质量高于Td。这意味着，例如，对于Td=5 s，实际传输间隔将分布在范围[2.052 s，6.156 s]内，并趋向于间隔的上半部分。注意，在应用随机化和重新考虑之前，Tmin参数限制了Td的值，因此实际传输间隔将覆盖延伸至Tmin以下的范围。
Given the above, we can calculate the number of SSRCs, n, that an RTP session with 5% of the session bandwidth assigned to RTCP can support while maintaining Td equal to Tmin. This will tell us how many RTP streams we can report on, keeping the RTCP overhead within acceptable bounds. We make two assumptions that simplify the calculation: that all SSRCs are senders, and that they all send compound RTCP packets comprising an SR packet with n-1 report blocks, followed by an SDES packet containing a 16 octet CNAME value [RFC7022] (such RTCP packets will vary in size between 54 and 798 octets depending on n, up to the maximum of 31 report blocks that can be included in an SR packet). If we put this packet size, and a 5% RTCP bandwidth fraction into the RTCP interval calculation in Section 6.3.1 of [RFC3550], and calculate the value of n needed to give Td = Tmin for the scaled minimum interval, we find n=9 SSRCs can be supported (irrespective of the interval, due to the way the reporting interval scales with the session bandwidth). We see that to support more SSRCs without changing the scaled minimum interval, we need to increase the RTCP
鉴于上述情况，我们可以计算SSRC的数量n，即分配给RTCP的会话带宽为5%的RTP会话可以支持的SSRC数量，同时保持Td等于Tmin。这将告诉我们可以报告多少RTP流，从而将RTCP开销保持在可接受的范围内。我们做了两个简化计算的假设：所有SSRC都是发送方，并且它们都发送复合RTCP数据包，其中包含一个具有n-1个报告块的SR数据包，然后是一个包含16个八位组CNAME值的SDES数据包[RFC7022]（此类RTCP数据包的大小将在54到798个八位字节之间变化，具体取决于n，最多可包含在SR数据包中的31个报告块）。如果我们将此数据包大小和5%RTCP带宽分数放入[RFC3550]第6.3.1节中的RTCP间隔计算中，并计算为缩放最小间隔提供Td=Tmin所需的n值，我们发现可以支持n=9个SSRC（不考虑间隔，因为报告间隔随会话带宽缩放）。我们发现，要在不更改缩放最小间隔的情况下支持更多SSRC，我们需要增加RTCP
bandwidth fraction from 5%; changing the session bandwidth to a higher value would reduce the Tmin. However, if using the default 5% allocation of RTCP bandwidth, an increase will result in more SSRCs being supported given a fixed Td target.
带宽分数从5%；将会话带宽更改为更高的值将降低Tmin。但是，如果使用默认的5%RTCP带宽分配，在给定固定Td目标的情况下，增加将导致支持更多SSRC。
Based on the above, when using the RTP/AVP profile or the RTP/SAVP profile, the key limitation for rapid RTCP reporting in small unicast sessions is going to be the Tmin value. The RTP session bandwidth configured in RTCP has to be sufficiently high to reach the reporting goals the application has following the rules for the scaled minimal RTCP interval.
基于上述情况，当使用RTP/AVP配置文件或RTP/SAVP配置文件时，小型单播会话中快速RTCP报告的关键限制将是Tmin值。RTCP中配置的RTP会话带宽必须足够高，以达到应用程序遵循最小RTCP间隔缩放规则的报告目标。
When using RTP/AVPF or RTP/SAVPF, we have a powerful additional tool for tuning RTCP transmissions: the T_rr_interval parameter. Use of this parameter allows short RTCP reporting intervals; alternatively it gives the ability to sent frequent RTCP feedback without sending frequent regular RTCP reports.
当使用RTP/AVPF或RTP/SAVPF时，我们有一个强大的额外工具来调优RTCP传输：T_rr_interval参数。使用此参数可缩短RTCP报告间隔；或者，它能够发送频繁的RTCP反馈，而无需发送频繁的定期RTCP报告。
The use of the RTP/AVPF or RTP/SAVPF profile with T_rr_interval set to a value greater than zero but smaller than Tmin allows more frequent RTCP feedback than the RTP/AVP or RTP/SAVP profiles, for a given RTCP bandwidth. This happens because Tmin is set to zero after the transmission of the initial RTCP report, causing the reporting interval for later packet to be determined by the usual RTCP bandwidth-based calculation, with Tmin=0, and the T_rr_interval. This has the effect that we are no longer restricted by the minimal interval (whether the default 5-second minimum or the reduced minimum interval). Rather, the RTCP bandwidth and the T_rr_interval are the governing factors, allowing faster feedback. Applications that care about rapid regular RTCP feedback ought to consider using the RTP/ AVPF or RTP/SAVPF profile, even if they don't use the feedback features of that profile.
对于给定的RTCP带宽，使用RTP/AVP或RTP/SAVP配置文件，将T_rr_间隔设置为大于零但小于Tmin的值，允许RTP反馈比RTP/AVP或RTP/SAVP配置文件更频繁。这是因为在传输初始RTCP报告后，Tmin被设置为零，导致后续数据包的报告间隔由通常的基于RTCP带宽的计算确定，Tmin=0，T_rr_间隔。这使得我们不再受最小间隔的限制（无论是默认的5秒最小间隔还是缩短的最小间隔）。相反，RTCP带宽和T_rr_间隔是控制因素，允许更快的反馈。关注快速正则RTCP反馈的应用程序应该考虑使用RTP/AVPF或RTP /SAVPF配置文件，即使它们不使用该配置文件的反馈特征。
The use of the RTP/AVPF or RTP/SAVPF profile allows RTCP feedback packets to be sent frequently, without also requiring regular RTCP reports to be sent frequently, since T_rr_interval limits the rate at which regular RTCP packets can be sent, while still permitting RTCP feedback packets to be sent. Applications that can use feedback packets for some RTP streams, e.g., video streams, but don't want frequent regular reporting for other RTP streams, can configure the T_rr_interval to a value so that the regular reporting for both audio and video is at a level that is considered acceptable for the audio. They could then use feedback packets, which will include RTCP SR/RR packets unless reduced size RTCP feedback packets [RFC5506] are used,
使用RTP/AVPF或RTP/SAVPF配置文件允许频繁发送RTCP反馈数据包，而不需要频繁发送常规RTCP报告，因为T_rr_间隔限制了常规RTCP数据包的发送速率，同时仍然允许发送RTCP反馈数据包。可以对某些RTP流（例如视频流）使用反馈数据包，但不希望对其他RTP流进行频繁定期报告的应用程序可以将t_rr_间隔配置为一个值，以便音频和视频的定期报告处于音频可接受的水平。然后，他们可以使用反馈数据包，其中包括RTCP SR/RR数据包，除非使用减小尺寸的RTCP反馈数据包[RFC5506]，
for the video reporting. This allows the available RTCP bandwidth to be devoted on the feedback that provides the most utility for the application.
用于视频报道。这允许将可用RTCP带宽用于为应用程序提供最大效用的反馈。
Using T_rr_interval still requires one to determine suitable values for the RTCP bandwidth value. Indeed, it might make this choice even more important, as this is more likely to affect the RTCP behavior and performance than when using the RTP/AVP or RTP/SAVP profile, as there are fewer limitations affecting the RTCP transmission.
使用T_rr_interval仍然需要确定RTCP带宽值的合适值。事实上，这可能使这一选择更加重要，因为这比使用RTP/AVP或RTP/SAVP配置文件时更可能影响RTCP行为和性能，因为影响RTCP传输的限制更少。
When T_rr_interval is non-zero, there are configurations that need to be avoided. If the RTCP bandwidth chosen is such that the Td value is smaller than, but close to, T_rr_interval, then the actual regular RTCP packet transmission interval can become very large, as discussed in Section 7.1.1. Therefore, for configuration where one intends to have Td smaller than T_rr_interval, then Td is RECOMMENDED to be targeted at values less than 1/4th of T_rr_interval, which results in the range becoming [0.5*T_rr_interval, 1.81*T_rr_interval].
当T_rr_interval为非零时，需要避免一些配置。如果选择的RTCP带宽使得Td值小于但接近T_rr_间隔，则实际的常规RTCP数据包传输间隔可能变得非常大，如第7.1.1节所述。因此，对于希望Td小于T_rr_间隔的配置，建议Td的目标值小于T_rr_间隔的1/4，这导致范围变为[0.5*T_rr_间隔，1.81*T_rr_间隔]。
With the RTP/AVPF or RTP/SAVPF profiles, using T_rr_interval = 0 has utility and results in a behavior where the RTCP transmission is only limited by the bandwidth, i.e., no Tmin limitations at all. This allows more frequent regular RTCP reporting than can be achieved using the RTP/AVP profile. Many configurations of RTCP will not consume all the bandwidth that they have been configured to use, but this configuration will consume what it has been given. Note that the same behavior will be achieved as long as T_rr_interval is smaller than 1/3 of Td as that prevents T_rr_interval from affecting the transmission.
对于RTP/AVPF或RTP/SAVPF配置文件，使用T_rr_interval=0具有实用性，并导致RTCP传输仅受带宽限制的行为，即根本没有Tmin限制。这允许比使用RTP/AVP配置文件更频繁地进行RTCP定期报告。RTCP的许多配置不会消耗它们已配置使用的所有带宽，但此配置将消耗已提供的带宽。注意，只要T_-rr_间隔小于Td的1/3，就可以实现相同的行为，因为这可以防止T_-rr_间隔影响传输。
There exists no method for using different regular RTCP reporting intervals depending on the media type or individual RTP stream, other than using a separate RTP session for each type or stream.
除了为每种类型或流使用单独的RTP会话外，不存在根据媒体类型或单个RTP流使用不同的常规RTCP报告间隔的方法。
When using the secure RTP protocol (RTP/SAVP) [RFC3711], or the secure variant of the feedback profile (RTP/SAVPF) [RFC5124], the cryptographic context of a compound secure RTCP packet is the SSRC of the sender of the first RTCP (sub-)packet. This could matter in some cases, especially for keying mechanisms such as MIKEY [RFC3830] that allow use of per-SSRC keying.
当使用安全RTP协议（RTP/SAVP）[RFC3711]或反馈配置文件的安全变体（RTP/SAVPF）[RFC5124]时，复合安全RTCP数据包的加密上下文是第一个RTCP（子）数据包的发送方的SSRC。这在某些情况下可能很重要，特别是对于允许使用每SSRC键控的MIKEY[RFC3830]等键控机制。
Otherwise, the standard security considerations of RTP apply; sending multiple RTP streams from a single endpoint in a single RTP session does not appear to have different security consequences than sending the same number of RTP streams spread across different RTP sessions.
否则，RTP的标准安全注意事项适用；在单个RTP会话中从单个端点发送多个RTP流与在不同RTP会话中发送相同数量的RTP流相比，似乎不会产生不同的安全后果。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<http://www.rfc-editor.org/info/rfc3550>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 3711，DOI 10.17487/RFC3711，2004年3月<http://www.rfc-editor.org/info/rfc3711>.
[RFC4585] 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, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 4585，DOI 10.17487/RFC4585，2006年7月<http://www.rfc-editor.org/info/rfc4585>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124]Ott，J.和E.Carrara，“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”，RFC 5124DOI 10.17487/RFC5124，2008年2月<http://www.rfc-editor.org/info/rfc5124>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, <http://www.rfc-editor.org/info/rfc5506>.
[RFC5506]Johansson，I.和M.Westerlund，“支持缩小尺寸实时传输控制协议（RTCP）：机会和后果”，RFC 5506，DOI 10.17487/RFC5506，2009年4月<http://www.rfc-editor.org/info/rfc5506>.
[CLUE-FRAME] Duckworth, M., Ed., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", Work in Progress, draft-ietf-clue-framework-25, January 2016.
[CLUE-FRAME]Duckworth，M.，Ed.，Pepperl，A.，和S.Wenger，“远程呈现多流的框架”，正在进行的工作，草稿-ietf-CLUE-FRAME-252016年1月。
[MULTI-RTP] Westerlund, M., Perkins, C., and J. Lennox, "Sending Multiple Types of Media in a Single RTP Session", Work in Progress, draft-ietf-avtcore-multi-media-rtp-session-13, December 2015.
[MULTI-RTP]Westerlund，M.，Perkins，C.，和J.Lennox，“在一次RTP会话中发送多种类型的媒体”，正在进行的工作，草稿-ietf-avtcore-MULTI-Media-RTP-Session-132015年12月。
[MULTI-STREAM-OPT] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback", Work in Progress, draft-ietf-avtcore-rtp-multi-stream-optimisation-12, March 2016.
[MULTI-STREAM-OPT]Lennox，J.，Westerlund，M.，Wu，Q.，和C.Perkins，“在单个RTP会话中发送多个媒体流：分组RTCP接收统计数据和其他反馈”，正在进行的工作，草稿-ietf-avtcore-RTP-MULTI-STREAM-OPTIMIZATION-12，2016年3月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, DOI 10.17487/RFC3390, October 2002, <http://www.rfc-editor.org/info/rfc3390>.
[RFC3390]奥尔曼，M.，弗洛伊德，S.，和C.帕特里奇，“增加TCP的初始窗口”，RFC 3390，DOI 10.17487/RFC3390，2002年10月<http://www.rfc-editor.org/info/rfc3390>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，DOI 10.17487/RFC3551，2003年7月<http://www.rfc-editor.org/info/rfc3551>.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, <http://www.rfc-editor.org/info/rfc3556>.
[RFC3556]Casner，S.，“RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽修饰符”，RFC 3556，DOI 10.17487/RFC3556，2003年7月<http://www.rfc-editor.org/info/rfc3556>.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, DOI 10.17487/RFC3830, August 2004, <http://www.rfc-editor.org/info/rfc3830>.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，DOI 10.17487/RFC3830，2004年8月<http://www.rfc-editor.org/info/rfc3830>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <http://www.rfc-editor.org/info/rfc4588>.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，DOI 10.17487/RFC4588，2006年7月<http://www.rfc-editor.org/info/rfc4588>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5104]Wenger，S.，Chandra，U.，Westerlund，M.，和B.Burman，“带反馈的RTP视听配置文件（AVPF）中的编解码器控制消息”，RFC 5104，DOI 10.17487/RFC5104，2008年2月<http://www.rfc-editor.org/info/rfc5104>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <http://www.rfc-editor.org/info/rfc5576>.
[RFC5576]Lennox，J.，Ott，J.，和T.Schierl，“会话描述协议（SDP）中的源特定媒体属性”，RFC 5576，DOI 10.17487/RFC5576，2009年6月<http://www.rfc-editor.org/info/rfc5576>.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, <http://www.rfc-editor.org/info/rfc6190>.
[RFC6190]Wenger，S.，Wang，Y.，Schierl，T.，和A.Eleftheriadis，“可伸缩视频编码的RTP有效载荷格式”，RFC 6190，DOI 10.17487/RFC6190，2011年5月<http://www.rfc-editor.org/info/rfc6190>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/RFC6928, April 2013, <http://www.rfc-editor.org/info/rfc6928>.
[RFC6928]Chu，J.，Dukkipati，N.，Cheng，Y.，和M.Mathis，“增加TCP的初始窗口”，RFC 6928，DOI 10.17487/RFC6928，2013年4月<http://www.rfc-editor.org/info/rfc6928>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[RFC7022]Begen，A.，Perkins，C.，Wing，D.，和E.Rescorla，“选择RTP控制协议（RTCP）规范名称（CNAMEs）的指南”，RFC 7022，DOI 10.17487/RFC7022，2013年9月<http://www.rfc-editor.org/info/rfc7022>.
[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014, <http://www.rfc-editor.org/info/rfc7160>.
[RFC7160]Petit Huguenin，M.和G.Zorn，Ed.，“在RTP会话中支持多个时钟速率”，RFC 7160，DOI 10.17487/RFC7160，2014年4月<http://www.rfc-editor.org/info/rfc7160>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <http://www.rfc-editor.org/info/rfc7667>.
[RFC7667]Westerlund，M.和S.Westerlund，M.和S.Wenger，“RTP拓扑”，RFC 7667，DOI 10.17487/RFC7667，2015年11月<http://www.rfc-editor.org/info/rfc7667>.
[SDP-BUNDLE] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Work in Progress, draft-ietf-mmusic-sdp-bundle-negotiation-36, October 2016.
[SDP-BUNDLE]Holmberg，C.，Alvestrand，H.，和C.Jennings，“使用会话描述协议（SDP）协商媒体多路复用”，正在进行的工作，草稿-ietf-mmusic-SDP-BUNDLE-negotiation-362016年10月。
[Sim88] Westerlund, M., "SIMULATION RESULTS FOR MULTI-STREAM", IETF 88 Proceedings, November 2013, <https://www.ietf.org/proceedings/88/slides/ slides-88-avtcore-0.pdf>.
[Sim88]Westerlund，M.，“多流模拟结果”，IETF 88会议记录，2013年11月<https://www.ietf.org/proceedings/88/slides/ 幻灯片-88-avtcore-0.pdf>。
[Sim92] Westerlund, M., Lennox, J., Perkins, C., and Q. Wu, "Changes in RTP Multi-stream", IETF 92 Proceedings, March 2015, <https://www.ietf.org/proceedings/92/slides/ slides-92-avtcore-0.pdf>.
[Sim92]Westerlund，M.，Lennox，J.，Perkins，C.，和Q.Wu，“RTP多流的变化”，IETF 92会议记录，2015年3月<https://www.ietf.org/proceedings/92/slides/ 幻灯片-92-avtcore-0.pdf>。
Acknowledgments
致谢
The authors like to thank Harald Alvestrand and everyone else who has been involved in the development of this document.
作者要感谢Harald Alvestrand和参与本文件开发的所有其他人。
Authors' Addresses
作者地址
Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 United States of America
Jonathan Lennox Vidyo，Inc.美国新泽西州哈肯萨克大街433号七楼，邮编：07601
Email: jonathan@vidyo.com
Email: jonathan@vidyo.com
Magnus Westerlund Ericsson Farogatan 2 SE-164 80 Kista Sweden
Magnus Westerlund Ericsson Farogatan 2 SE-164 80瑞典基斯塔
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com
Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
中国江苏省南京市雨花区华为软件大道101号秦武210012
Email: bill.wu@huawei.com
Email: bill.wu@huawei.com
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom
柯林帕金斯格拉斯哥大学计算科学学院格拉斯哥G128QQ英国
Email: csp@csperkins.org
Email: csp@csperkins.org