Internet Engineering Task Force (IETF) J. Ott
Request for Comments: 5968 Aalto University
Category: Informational C. Perkins
ISSN: 2070-1721 University of Glasgow
September 2010
Internet Engineering Task Force (IETF) J. Ott
Request for Comments: 5968 Aalto University
Category: Informational C. Perkins
ISSN: 2070-1721 University of Glasgow
September 2010
Guidelines for Extending the RTP Control Protocol (RTCP)
扩展RTP控制协议（RTCP）的指南
Abstract
摘要
The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptation and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient.
RTP控制协议（RTCP）与实时传输协议（RTP）一起用于在媒体发送方和接收方之间提供控制通道。这允许构造一个反馈循环，以支持应用程序自适应和监视，以及其他用途。RTCP提供的基本报告机制是通用的，但功能相当强大，足以涵盖一系列用途。本文件提供了在这些基本机制证明不充分时扩展RTCP的指南。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5968.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5968.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. RTP and RTCP Operation Overview .................................4
3.1. RTCP Capabilities ..........................................5
3.2. RTCP Limitations ...........................................7
3.3. Interactions with Network- and Transport-Layer Mechanisms ..8
4. Issues with RTCP Extensions .....................................9
5. Guidelines .....................................................10
6. Security Considerations ........................................14
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
1. Introduction ....................................................3
2. Terminology .....................................................4
3. RTP and RTCP Operation Overview .................................4
3.1. RTCP Capabilities ..........................................5
3.2. RTCP Limitations ...........................................7
3.3. Interactions with Network- and Transport-Layer Mechanisms ..8
4. Issues with RTCP Extensions .....................................9
5. Guidelines .....................................................10
6. Security Considerations ........................................14
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
The Real-time Transport Protocol (RTP) [RFC3550] is used to carry time-dependent (often continuous) media such as audio or video across a packet network in an RTP session. RTP usually runs on top of an unreliable transport such as UDP, Datagram Transport Layer Security (DTLS), or the Datagram Congestion Control Protocol (DCCP), so that RTP packets are susceptible to loss, re-ordering, or duplication. Associated with RTP is the RTP Control Protocol (RTCP), which provides a control channel for each session: media senders provide information about their current sending activities ("feed forward"), and media receivers report on their reception statistics ("feedback") in terms of received packets, losses, and jitter. Senders and receivers provide self-descriptions allowing them to disambiguate all entities in an RTP session and correlate synchronisation source (SSRC) identifiers with specific application instances. RTCP is carried over the same transport as RTP and is inherently best-effort; hence the RTCP reports are designed for such an unreliable environment, e.g., by making them "for information only".
实时传输协议（RTP）[RFC3550]用于在RTP会话中通过分组网络传输与时间相关的（通常是连续的）媒体，例如音频或视频。RTP通常运行在不可靠的传输之上，如UDP、数据报传输层安全（DTLS）或数据报拥塞控制协议（DCCP），因此RTP数据包容易丢失、重新排序或复制。与RTP相关联的是RTP控制协议（RTCP），它为每个会话提供一个控制通道：媒体发送方提供有关其当前发送活动的信息（“前馈”），媒体接收方根据接收到的数据包、丢失和抖动报告其接收统计信息（“反馈”）。发送方和接收方提供自我描述，允许它们消除RTP会话中所有实体的歧义，并将同步源（SSRC）标识符与特定应用程序实例关联起来。RTCP通过与RTP相同的传输进行传输，本质上是尽力而为的；因此，RTCP报告是针对这种不可靠的环境设计的，例如，使其“仅供参考”。
The RTCP control channel provides coarse-grained information about the session in two respects: 1) the RTCP sender report (SR) and receiver report (RR) packets contain only cumulative information or means over a certain period of time and 2) the time period is in the order of seconds and thus neither has a high resolution nor does the feedback come back instantaneously. Both these restrictions have their origin in RTP being scalable and generic. Even these basic mechanisms (which are still not implemented everywhere despite their simplicity and very precise specification, including sample code) offer substantial information for designing adaptive applications and for monitoring purposes, among others.
RTCP控制通道在两个方面提供关于会话的粗粒度信息：1）RTCP发送方报告（SR）和接收方报告（RR）数据包仅包含特定时间段内的累积信息或方法，2）时间段以秒为单位，因此既没有高分辨率，也没有即时反馈。这两种限制都源于RTP，具有可扩展性和通用性。即使是这些基本机制（尽管它们简单且规范非常精确，但仍然没有在任何地方实现，包括示例代码），也为设计自适应应用程序和监控目的提供了大量信息。
Recently, numerous extensions have been proposed in different contexts to RTCP that significantly increase the complexity of the protocol and the reported values, mutate it toward a command channel, and/or attempt turning it into a reliable messaging protocol. While the reasons for such extensions may be legitimate, many of the resulting designs appear ill-advised in the light of the RTP architecture. Moreover, extensions are often badly motivated and thus appear unnecessary given what can be achieved with the RTCP mechanisms in place today.
最近，在不同的上下文中，已经提出了许多对RTCP的扩展，这些扩展显著增加了协议和报告值的复杂性，使其向命令通道转变，和/或试图将其转变为可靠的消息传递协议。虽然这种扩展的原因可能是合理的，但鉴于RTP体系结构，许多最终的设计似乎是不明智的。此外，扩展的动机往往很差，因此，考虑到目前RTCP机制可以实现的目标，扩展似乎是不必要的。
This document is intended to provide some guidelines for designing RTCP extensions. It is particularly intended to avoid an extension creep for corner cases that can only harm interoperability and future evolution of the protocol at large. We first outline the basic operation of RTCP and constructing feedback loops using the basic RTCP mechanisms. Subsequently, we outline categories of extensions
本文档旨在为设计RTCP扩展提供一些指导。它特别旨在避免角落情况下的扩展蔓延，这只会损害互操作性和协议的未来发展。我们首先概述RTCP的基本操作，并使用基本RTCP机制构建反馈回路。随后，我们概述了扩展的类别
proposed (and partly already accepted) for RTCP and discuss issues and alternative ways of thinking by example. Finally, we provide some guidelines and highlight a number of questions to ask (and answer!) before writing up an RTCP extension.
为RTCP提出（部分已被接受），并通过实例讨论问题和备选思维方式。最后，在编写RTCP扩展之前，我们提供了一些指导方针，并强调了一些要问（和回答）的问题。
The terminology defined in "RTP: A Transport Protocol for Real-Time Applications" [RFC3550], "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551], and "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" [RFC4585] apply.
“RTP：实时应用的传输协议”[RFC3550]、“具有最小控制的音频和视频会议的RTP配置文件”[RFC3551]和“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”[RFC4585]中定义的术语适用。
One of the twelve networking truths in [RFC1925] states: "In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away". Despite (or because of) this being an April 1st RFC, this specific truth is very valid, and it applies to RTCP as well.
[RFC1925]中的十二条网络真理中有一条指出：“在协议设计中，完美不是在没有什么可添加的时候，而是在没有什么可带走的时候。”。尽管（或因为）这是4月1日的RFC，但这一具体事实非常有效，也适用于RTCP。
In this section, we will briefly review what is available from the basic RTP/RTCP specifications. As specifications, we include those that are generic, i.e., do not have dependencies on particular media types. This includes the RTP base specification [RFC3550] and profile [RFC3551], the RTCP bandwidth modifiers for session descriptions [RFC3556], the timely feedback extensions (RFC 4585), and the extensions to run RTCP over source-specific multicast (SSM) networks [RFC5760]. RTCP extended reports (XRs) [RFC3611] provide extended reporting mechanisms that are partly generic in nature, and partly specific to a certain media stream.
在本节中，我们将简要回顾基本RTP/RTCP规范中提供的内容。作为规范，我们包括那些通用的，即不依赖于特定媒体类型的规范。这包括RTP基本规范[RFC3550]和配置文件[RFC3551]、用于会话描述的RTCP带宽修饰符[RFC3556]、及时反馈扩展（RFC 4585）和在源特定多播（SSM）网络上运行RTCP的扩展[RFC5760]。RTCP扩展报告（XRs）[RFC3611]提供的扩展报告机制部分是通用的，部分是特定于特定媒体流的。
We do not discuss RTP-related documents that are orthogonal to RTCP.
The Secure RTP Profile [RFC3711] can be used to secure RTCP in much
the same way it secures RTP data, but otherwise does not affect the
behaviour of RTCP. The transport protocol used also has little
impact, since RTCP remains a group communication protocol even when
running over a unicast transport (such as TCP [RFC4571] or DCCP
[RFC5762]), and is little affected by congestion control due to its
low rate relative to the media. The description of RTP topologies
[RFC5117] is useful knowledge, but is functionally not relevant here.
The various RTP error correction mechanisms (e.g., [RFC2198],
[RFC4588], [RFC5109]) are useful for protecting RTP media streams,
and may be enabled as a result of RTCP feedback, but do not directly
affect RTCP behaviour. Finally, RTP and RTCP may be multiplexed
inside the same transport connection or using the same port number
[RFC5761], but this does not affect the operation of RTCP itself;
distinguishing RTP and RTCP packets is achieved because the code
We do not discuss RTP-related documents that are orthogonal to RTCP.
The Secure RTP Profile [RFC3711] can be used to secure RTCP in much
the same way it secures RTP data, but otherwise does not affect the
behaviour of RTCP. The transport protocol used also has little
impact, since RTCP remains a group communication protocol even when
running over a unicast transport (such as TCP [RFC4571] or DCCP
[RFC5762]), and is little affected by congestion control due to its
low rate relative to the media. The description of RTP topologies
[RFC5117] is useful knowledge, but is functionally not relevant here.
The various RTP error correction mechanisms (e.g., [RFC2198],
[RFC4588], [RFC5109]) are useful for protecting RTP media streams,
and may be enabled as a result of RTCP feedback, but do not directly
affect RTCP behaviour. Finally, RTP and RTCP may be multiplexed
inside the same transport connection or using the same port number
[RFC5761], but this does not affect the operation of RTCP itself;
distinguishing RTP and RTCP packets is achieved because the code
points for RTCP and the payload types for RTP use disjoint number spaces.
RTCP的点和RTP的有效负载类型使用不相交的数字空格。
The RTP/RTCP specifications quoted above provide feedback mechanisms with the following properties, which can be considered as "building blocks" for adaptive real-time applications for IP networks.
上面引用的RTP/RTCP规范提供了具有以下特性的反馈机制，可以将其视为IP网络自适应实时应用程序的“构建块”。
o Sender reports (SRs) indicate to the receivers the total number of packets and octets that have been sent (since the beginning of the session or the last change of the sender's SSRC). These values allow deducing the mean data rate and mean packet size for both the entire session and, if continuously monitored, for every transmission interval. They also allow a receiver to distinguish between breaks in reception caused by network problems, and those due to pauses in transmission.
o 发送方报告（SRs）向接收方指示已发送的数据包和八位字节的总数（自会话开始或发送方SSRC的上次更改以来）。这些值允许推导整个会话的平均数据速率和平均数据包大小，如果连续监控，则可以推导每个传输间隔的平均数据速率和平均数据包大小。它们还允许接收机区分由网络问题引起的接收中断和由传输暂停引起的接收中断。
o Receiver reports (RRs) and SRs indicate reception statistics from each receiver for every sender. These statistics include:
o Receiver reports（RRs）和SRs表示每个发送方的每个接收方的接收统计信息。这些统计数字包括：
* The packet loss rate since the last SR or RR was sent.
* 自上次发送SR或RR以来的数据包丢失率。
* The total number of packets lost since the beginning of the session, which may again be broken down to each reporting period.
* 自会话开始以来丢失的数据包总数，可再次细分到每个报告期。
* The highest sequence number received so far -- which allows a sender to roughly estimate how much data is in flight when used together with the SR and RR timestamps (and also allows observing whether the path still works and at which rate packets are delivered to the receiver).
* 迄今为止接收到的最高序列号——它允许发送方粗略估计与SR和RR时间戳一起使用时有多少数据正在传输（还允许观察路径是否仍然有效以及数据包以何种速率传送到接收方）。
* The moving average of the inter-arrival jitter of media packets. This gives the sender an indirect view of the size of any adaptive playout buffer used at the receiver ([RFC3611] gives precise figures for Voice over IP (VoIP) sessions).
* 媒体数据包到达间抖动的移动平均值。这为发送方提供了在接收方使用的任何自适应播放缓冲区大小的间接视图（[RFC3611]给出了IP语音（VoIP）会话的精确数字）。
o Sender reports also contain NTP and RTP format timestamps. These allow receivers to synchronise multiple RTP streams, and (when used in conjunction with receiver reports) allow the sender to calculate the current round-trip time (RTT) to each receiver. This value can be monitored over time and thus may be used to infer trends at coarse granularity. A similar mechanism is provided by [RFC3611] to allow receivers to calculate the RTT to senders.
o 发送方报告还包含NTP和RTP格式的时间戳。这些允许接收器同步多个RTP流，并且（当与接收器报告一起使用时）允许发送器计算到每个接收器的当前往返时间（RTT）。该值可随时间监控，因此可用于推断粗粒度的趋势。[RFC3611]提供了类似的机制，允许接收方计算发送方的RTT。
RTCP sender reports and receiver reports are sent, and the statistics are sampled, at random intervals chosen uniformly in the range from 0.5 to 1.5 times the deterministic calculated interval, T. The interval T is calculated based on the media bitrate, the mean RTCP packet size, whether the sampling node is a sender or a receiver, and the number of participants in the session, and will remain constant while the number of participants in the session remains constant. The lower bound on the base inter-report interval, T, is five seconds, or 360 seconds divided by the session bandwidth in kilobits/ second (giving an interval smaller than 5 seconds for bandwidths greater than 72 kbits/s) [RFC3550].
发送RTCP发送方报告和接收方报告，并以在确定性计算间隔T的0.5到1.5倍范围内均匀选择的随机间隔对统计数据进行采样。间隔T基于媒体比特率、平均RTCP数据包大小计算，无论采样节点是发送方还是接收方，以及会议参与者的数量，并将保持不变，而会议参与者的数量保持不变。基本报告间间隔T的下限为5秒，或360秒除以会话带宽（单位为千比特/秒）（对于大于72 kbits/s的带宽，给出小于5秒的间隔）[RFC3550]。
This lower limit can be eliminated, allowing more frequent feedback, when using the early feedback profile for RTCP [RFC4585]. In this case, the RTCP frequency is only limited by the available bitrate (usually 5% of the media stream bitrate is allocated for RTCP). If this fraction is insufficient, the RTCP bitrate may be increased in the session description to enable more frequent feedback [RFC3556]. The considerations in [RFC5506] may be used to reduce the mean RTCP packet size, further increasing feedback frequency.
当使用RTCP的早期反馈配置文件[RFC4585]时，可以消除此下限，从而允许更频繁的反馈。在这种情况下，RTCP频率仅受可用比特率的限制（通常为RTCP分配媒体流比特率的5%）。如果该分数不足，则可在会话描述中增加RTCP比特率，以启用更频繁的反馈[RFC3556]。[RFC5506]中的注意事项可用于减少平均RTCP分组大小，进一步增加反馈频率。
The mechanisms defined in [RFC4585] even allow -- statistically -- a receiver to provide close-to-instant feedback to a sender about observed events in the media stream (e.g., picture or slice loss).
[RFC4585]中定义的机制甚至允许——统计上——接收器向发送者提供关于媒体流中观察到的事件（例如，图片或片段丢失）的接近即时的反馈。
RTCP is suitable for unicast and multicast communications. All basic functions are designed with group communications in mind. While traditional (any-source) multicast (ASM) is clearly not available in the Internet at large, source-specific multicast (SSM) and overlay multicast are -- and both are commercially relevant. RTCP extensions have been defined to operate over SSM, and complex topologies may be created by interconnecting RTP mixers and translators. The group communication nature of RTP and RTCP is also essential for the operation of Multipoint Control Units.
RTCP适用于单播和多播通信。所有基本功能的设计都考虑了组通信。虽然传统的（任意源）多播（ASM）显然无法在Internet上广泛使用，但源特定多播（SSM）和覆盖多播是——而且两者都与商业相关。RTCP扩展已定义为在SSM上运行，通过互连RTP混频器和转换器可以创建复杂的拓扑。RTP和RTCP的组通信性质对于多点控制单元的操作也至关重要。
These mechanisms can be used to implement a quite flexible feedback loop and enable short-term reaction to observed events as well as long-term adaptation to changes in the networking environment. Adaptation mechanisms available on the sender side include (but are not limited to) choosing different codecs, different parameters for codecs (spatial or temporal resolution for video, audible quality for audio and voice), and different packet sizes to adjust the bitrate. Furthermore, various forward error correction (FEC) mechanisms and, if RTTs are short and the application permits extra delays, even reactive error control such as retransmissions can be used. Long-term feedback can be provided in regular RTCP reports at configurable
这些机制可用于实现相当灵活的反馈回路，并对观察到的事件做出短期反应，以及长期适应网络环境的变化。发送方侧可用的自适应机制包括（但不限于）选择不同的编解码器、编解码器的不同参数（视频的空间或时间分辨率、音频和语音的音频质量）以及调整比特率的不同分组大小。此外，各种前向纠错（FEC）机制，并且如果rtt短且应用程序允许额外延迟，则甚至可以使用诸如重传之类的反应性差错控制。长期反馈可在定期RTCP报告中随时提供
intervals, whereas (close-to-)instant feedback is available by means of the early feedback profile. Figure 1 below outlines this idea graphically.
间隔，而（接近）即时反馈通过早期反馈配置文件提供。下面的图1以图形方式概述了这一想法。
Long-term adaptation: RTCP sender reports Media processing:
- Codec+parameter choice - Data rate, pkt count - De-jittering
- Packet size - Timing and sync info - Synchronisation
- FEC, interleaving - Traffic characteristics - Error concealment
--------------------------------> - Playout
+---------------+/ \+---------------+
| | RTP media stream (codec, repair) | |
| Media sender |=================================>| Media receiver |
| | | |
+---------------+\ RTCP receiver reports /+---------------+
<--------------------------------
Short-term reaction: - long-term statistics Control functions:
- Retransmissions - event information - RTP monitoring
- Retroactive FEC - media-specific info and reporting
- Adaptive source coding - "congestion info"(*) - Instant event
- Congestion control(*) notifications
Long-term adaptation: RTCP sender reports Media processing:
- Codec+parameter choice - Data rate, pkt count - De-jittering
- Packet size - Timing and sync info - Synchronisation
- FEC, interleaving - Traffic characteristics - Error concealment
--------------------------------> - Playout
+---------------+/ \+---------------+
| | RTP media stream (codec, repair) | |
| Media sender |=================================>| Media receiver |
| | | |
+---------------+\ RTCP receiver reports /+---------------+
<--------------------------------
Short-term reaction: - long-term statistics Control functions:
- Retransmissions - event information - RTP monitoring
- Retroactive FEC - media-specific info and reporting
- Adaptive source coding - "congestion info"(*) - Instant event
- Congestion control(*) notifications
(*) RTCP feedback is insufficient for the purposes of TCP-friendly congestion control due to the infrequent nature of reporting (which should be in the order of once per RTT), but can still be used to adapt to the available bandwidth on slower time-scales.
（*）RTCP反馈不足以实现TCP友好的拥塞控制，因为报告的频率不高（每个RTT报告一次），但仍可以用于适应较慢时间尺度上的可用带宽。
Figure 1: Outline of an RTCP Feedback Loop
图1:RTCP反馈回路的概要
It is important to note that not all information needs to be signalled explicitly -- ever, or upon every RTCP packet -- but can be derived locally from other pieces of information and from the evolution of the information over time.
重要的是要注意，并非所有信息都需要明确地发出信号——无论是在任何时候，还是在每个RTCP数据包上——但可以从其他信息片段以及信息随时间的演变在本地派生。
The design of RTP limits what can meaningfully be done (and hence should be done) with RTCP. In particular, the design favours scalability and loose coupling over tightly controlled feedback loops. Some of these limitations are listed below (they need to be taken into account when designing extensions):
RTP的设计限制了RTCP可以做（因此应该做）的有意义的事情。特别是，与严格控制的反馈回路相比，该设计更倾向于可伸缩性和松耦合。下面列出了其中一些限制（在设计扩展时需要考虑这些限制）：
o RTCP is designed to provide occasional feedback, which is unlike, e.g., TCP ACKs, which can be sent in response to every (other) packet. It does not offer per-packet feedback (even when using [RFC4585] with increased RTCP bandwidth fraction, the feedback guarantees are only statistical in nature).
o RTCP旨在提供偶尔的反馈，这与TCP ACK不同，TCP ACK可以发送以响应每个（其他）数据包。它不提供每包反馈（即使在使用[RFC4585]增加RTCP带宽分数时，反馈保证也只是统计性质的）。
o RTCP is not capable of providing truly instant feedback.
o RTCP无法提供真正的即时反馈。
o RTCP is inherently unreliable and does not guarantee any consistency between the observed state at multiple members of a group.
o RTCP本质上是不可靠的，不能保证在一个组的多个成员处观察到的状态之间的一致性。
It is important to note that these features of RTCP are intentional design choices, and are essential for it to scale to large groups.
需要注意的是，RTCP的这些功能是有意的设计选择，对于它扩展到大型组是必不可少的。
As discussed above, RTCP flows are used to measure, infer, and convey information about the performance of an RTP media stream.
如上所述，RTCP流用于测量、推断和传递有关RTP媒体流性能的信息。
Inference in baseline RTCP is mainly limited to determining the path RTT from pairs of RTCP SR and RR packets. This inference makes the implicit assumption that RTP and RTCP are treated equally: they are routed along the same path, mapped to the same (DiffServ) traffic classes, and treated as part of the same fair queuing classification. This is true in many cases; however, since RTP and RTCP are generally sent using different ports, any flow classification based upon the 5-tuple (of source and destination IP addresses, source and destination port numbers, and the transport protocol) could lead to a differentiation between RTP and RTCP flows, disrupting the statistics.
基线RTCP中的推断主要限于从RTCP SR和RR数据包对中确定路径RTT。这一推论隐含了RTP和RTCP被同等对待的假设：它们沿着相同的路径路由，映射到相同的（区分服务）流量类别，并被视为相同公平排队分类的一部分。这在很多情况下都是正确的；但是，由于RTP和RTCP通常使用不同的端口发送，因此基于5元组（源和目标IP地址、源和目标端口号以及传输协议）的任何流分类都可能导致RTP和RTCP流之间的差异，从而中断统计。
While some networks may wish to intentionally prioritise RTCP over RTP (to provide quicker feedback) or RTP over RTCP (since the media is considered more important than control), we recommend that they be treated identically where possible, to enable this inference of network performance, and hence support application adaptation.
虽然一些网络可能希望有意将RTCP优先于RTP（以提供更快的反馈），或将RTP优先于RTCP（因为媒体被认为比控制更重要），但我们建议尽可能对它们进行相同的处理，以实现对网络性能的推断，从而支持应用程序自适应。
When using reliable transport connections for (RTP and) RTCP [RFC2326] [RFC4571], retransmissions and head-of-line blocking may similarly lead to inaccurate RTT estimates derived by RTCP. (These may, nevertheless, properly reflect the mean RTT for a media packet, including retransmissions.)
当使用（RTP和）RTCP[RFC2326][RFC4571]的可靠传输连接时，重传和线路头阻塞同样可能导致RTCP得出的RTT估计不准确。（然而，这些可以适当地反映媒体分组的平均RTT，包括重传。）
The conveyance of information in RTCP is affected by the above only as soon as the prioritisation leads to a disproportionately high number of RTCP packets being dropped.
只有在优先级排序导致RTCP数据包被丢弃的比例过高时，RTCP中的信息传输才会受到上述影响。
All of this emphasises the unreliable nature of RTCP. Multiplexing on the same port number [RFC5761] or inside the same transport connection might help mitigate some of these effects, but this is limited to speculation at this point and should not be relied upon.
所有这些都强调了RTCP的不可靠性质。在同一端口号[RFC5761]上或在同一传输连接内进行多路复用可能有助于减轻其中一些影响，但这仅限于此时的推测，不应依赖于此。
Issues that have come up in the past with extensions to RTP and RTCP include (but are probably not limited to) the following:
过去在RTP和RTCP扩展中出现的问题包括（但可能不限于）以下方面：
o Defining RTP or RTCP extensions only or primarily for unicast two-party sessions. RTP is inherently a group communication protocol, even when operating on a unicast connection. Extensions may become useful in the future well outside their originally intended area of application, and should consider this. Stating that something works for unicast only is not acceptable, particularly since various flavours of multicast have become relevant again, and as middleboxes such as repair servers, mixers, and RTCP-supporting Multipoint Control Units (MCUs) [RFC5117] become more widely used.
o 仅为单播第二方会话定义RTP或RTCP扩展，或主要为单播第二方会话定义RTP或RTCP扩展。RTP本质上是一种组通信协议，即使在单播连接上操作也是如此。扩展可能会在将来更好地在其最初预期的应用范围之外变得有用，并且应该考虑这一点。声明某些内容仅适用于单播是不可接受的，特别是因为各种类型的多播再次变得相关，并且随着诸如修复服务器、混音器和支持多点控制单元（MCU）的RTCP等中间盒的使用越来越广泛[RFC5117]。
o Assuming reliable (instant) state synchronisation. RTCP reports are sent irregularly and may be lost. Hence, there may be a significant time lag (several seconds) between intending to send a state update to the RTP peer(s) and the packet being received; in some cases, the packet may not be received at all.
o 假设可靠（即时）状态同步。RTCP报告不定期发送，可能会丢失。因此，在打算向RTP对等方发送状态更新和正在接收的分组之间可能存在显著的时间延迟（几秒钟）；在某些情况下，可能根本无法接收数据包。
o Requiring reliable delivery of RTCP reports. While reliability can be implemented on top of RTCP using acknowledgements, this will come at the cost of significant additional delay, which may defeat the purpose of providing the feedback in the first place. Moreover, for scalability reasons due to the group-based nature of RTCP, these ACKs need to be adaptively rate limited or targeted to a subgroup or individual entity to avoid implosion as group sizes increase. RTCP is not intended or suitable for use as a reliable control channel.
o 要求可靠地提交RTCP报告。虽然可以使用确认在RTCP之上实现可靠性，但这将以显著的额外延迟为代价，这可能会首先破坏提供反馈的目的。此外，由于RTCP基于组的性质，出于可扩展性的原因，这些ACK需要自适应地进行速率限制或针对子组或单个实体，以避免在组大小增加时内爆。RTCP不打算或不适合用作可靠的控制通道。
o Issuing commands, rather than giving hints. RTCP is about reporting observations -- in a best-effort manner -- between RTP entities. Causing actions on the remote side requires some form of reliability (see above), and adherence cannot be verified.
o 发出命令，而不是给出提示。RTCP是关于在RTP实体之间以尽最大努力的方式报告观察结果的。在远程端执行操作需要某种形式的可靠性（见上文），并且无法验证是否遵守。
o Expanding RTCP reporting, to use it as a network management tool. RTCP is sensitive to the size of RTCP reports as the latter determines the mean reporting interval given a certain bitrate share for RTCP (yet, RTCP may also be used to report information that has fine-grained temporal characteristics, if summarisation or data reduction by the endpoint would lose essential resolution). The information going into RTCP reports should primarily target the peer(s) (and thus include information that can be meaningfully reacted upon); nevertheless, such reports may
o 扩展RTCP报告，将其用作网络管理工具。RTCP对RTCP报告的大小很敏感，因为后者决定了给定RTCP特定比特率共享的平均报告间隔（但是，如果端点的汇总或数据缩减将失去基本分辨率，RTCP也可用于报告具有细粒度时间特征的信息）。进入RTCP报告的信息应主要针对对等方（因此包括可作出有意义反应的信息）；然而，此类报告可能会
provide useful information to augment other network management tools. Gathering and reporting statistics beyond this is not an RTCP task and should be addressed by out-of-band protocols.
提供有用的信息以增强其他网络管理工具。除此之外，收集和报告统计数据不是RTCP任务，应通过带外协议解决。
o Creating serious complexity. Related to the previous item, RTCP reports that convey all kinds of data need to gather and calculate/infer this information to begin with (which requires very precise specifications). Given that it already seems to be difficult to even implement baseline RTCP, any added complexity can only discourage implementers, may lead to buggy implementations (in which case the reports do not serve their intended purpose), and hinder interoperability.
o 造成严重的复杂性。与前一项相关，传递各种数据的RTCP报告需要首先收集和计算/推断这些信息（这需要非常精确的规范）。考虑到实施基线RTCP似乎已经很困难，任何增加的复杂性都只会阻碍实施者，可能导致错误的实施（在这种情况下，报告无法达到预期目的），并阻碍互操作性。
o Introducing architectural issues. Extensions are written without considering the architectural concepts of RTP. For example, point-to-point communication is assumed, yet third-party monitors are expected to listen in. Besides being a bad idea to rely on eavesdropping entities on the path, this is obviously not possible if Secure RTP (SRTP) is being used with encrypted SRTCP packets.
o 介绍架构问题。编写扩展时没有考虑RTP的体系结构概念。例如，假定使用点对点通信，但第三方监视器将监听。除了依赖路径上的窃听实体是个坏主意之外，如果安全RTP（SRTP）与加密的SRTCP数据包一起使用，这显然是不可能的。
This list is surely not exhaustive. Also, the authors do not claim that the suggested extensions (even if using acknowledgements) would not serve a legitimate purpose. We rather want to draw attention to the fact that the same results may be achievable in a way that is architecturally cleaner and conceptually more RTP/RTCP-compliant. The following section contains a first attempt to provide some guidelines on what to consider when thinking about extensions to RTP and RTCP.
这份清单肯定不是详尽无遗的。此外，作者并没有声称所建议的扩展（即使使用了确认）不会达到合法的目的。我们更希望提请注意这样一个事实，即相同的结果可能以一种架构更清晰、概念上更符合RTP/RTCP的方式实现。下面的部分包含了第一个尝试，在考虑RTP和RTCP扩展时要考虑哪些指导原则。
Designing RTCP extensions requires consideration of a number of issues, as well as in-depth understanding of the operation of RTP mechanisms. While it is expected that there are many aspects not yet covered by RTCP reporting and operation, quite a bit of functionality is readily available for use. Other mechanisms should probably never become part of the RTP family of specifications, despite the existence of their equivalents in other environments. In the following, we provide some guidance to consider when (and before!) developing an extension to RTCP.
设计RTCP扩展需要考虑许多问题，并深入了解RTP机制的操作。虽然预计RTCP报告和操作中有许多方面尚未涵盖，但仍有相当多的功能可供使用。其他机制可能永远不会成为RTP规范系列的一部分，尽管在其他环境中存在它们的等价物。在下文中，我们提供一些指导来考虑何时（以及之前）开发RTCP的扩展。
We begin with a short checklist concerning the applicability of RTCP in the first place:
首先，我们从一份关于RTCP适用性的简短清单开始：
o Check what can be done with the existing mechanisms, exploiting the information that is already available in RTCP. Is the need for an extension only perceived (e.g., due to lazy implementers, or artificial constraints in endpoints), or is the function or
o 利用RTCP中已有的信息，检查现有机制可以做什么。是否只感知到对扩展的需求（例如，由于懒惰的实现者或端点中的人为约束），或者函数或
data really not available (or derivable from existing reports)? It is worthwhile remembering that redundant information supplied by a protocol runs the risk of being inconsistent at some point, and various implementations may handle such situations differently (e.g., give precedence to different values). Similarly, there should be exactly one (well-specified) way of performing every function and operation of the protocol.
数据确实不可用（或无法从现有报告中派生）？值得记住的是，协议提供的冗余信息在某一点上存在不一致的风险，不同的实现可能会以不同的方式处理此类情况（例如，优先考虑不同的值）。同样，应该有一种（明确规定的）方式来执行协议的每个功能和操作。
o Is the extension applicable to RTP entities running anywhere in the Internet, or is it a link- or environment-specific extension? In the latter cases, local extensions (e.g., header compression, or non-RTP protocols) may be preferable. RTCP should not be used to carry information specific to a particular (access) link.
o 该扩展是否适用于运行在Internet上任何位置的RTP实体，或者是特定于链接或环境的扩展？在后一种情况下，本地扩展（例如，报头压缩或非RTP协议）可能是优选的。RTCP不应用于传输特定（访问）链路的特定信息。
o Is the extension applicable in a group communication environment, or is it specific to point-to-point communications? RTP and RTCP are inherently group communication protocols, and extensions must scale gracefully with increasing group sizes.
o 扩展是否适用于组通信环境，还是特定于点对点通信？RTP和RTCP本质上是组通信协议，扩展必须随着组大小的增加而优雅地扩展。
From a conceptual viewpoint, the designer of every RTCP extension should ask -- and answer(!) -- at least the following questions:
从概念的角度来看，每个RTCP扩展的设计者应至少提出并回答以下问题：
o How will this new building block complement and work with the other components of RTCP? Are all interactions fully specified?
o 这个新的构建块将如何补充RTCP的其他组件并与之协同工作？是否所有交互都已完全指定？
o Will this extension work with all different profiles (e.g., the Secure RTP profile [RFC3711], and the extended RTP profile for RTCP-based feedback [RFC4585])? Are any feature interactions expected?
o 此扩展是否适用于所有不同的配置文件（例如，安全RTP配置文件[RFC3711]和基于RTCP的反馈的扩展RTP配置文件[RFC4585]）？是否需要任何功能交互？
o Should this extension be kept in-line with baseline RTP and its existing profiles, or does it deviate so much from the base RTP operation that an incompatible new profile must be defined? Use and definition of incompatible profiles are strongly discouraged, but if they prove necessary, how do nodes using the different profiles interact? What are the failure modes, and how is it ensured that the system fails in a safe manner?
o 该扩展是否应与基线RTP及其现有配置文件保持一致，还是与基本RTP操作的偏差太大，以至于必须定义不兼容的新配置文件？强烈反对使用和定义不兼容的概要文件，但如果它们被证明是必要的，那么使用不同概要文件的节点如何交互？故障模式是什么？如何确保系统以安全的方式发生故障？
o How does this extension interoperate with other nodes when the extension is not understood by the peer(s)?
o 当对等方不理解该扩展时，该扩展如何与其他节点互操作？
o How will the extension deal with different networking conditions (e.g., how does performance degrade with increases in losses and latency, possibly across orders of magnitude)?
o 扩展将如何处理不同的网络条件（例如，性能如何随着损失和延迟的增加而降低，可能是几个数量级）？
o How will this extension work with group communication scenarios, such as multicast? Will the extensions degrade gracefully with increasing group sizes? What will be the impact on the RTCP report frequency and bitrate allocation?
o 此扩展如何处理组通信场景，例如多播？扩展是否会随着组大小的增加而优雅地退化？对RTCP报告频率和比特率分配有何影响？
For the specific design, the following considerations should be taken into account (they're a mixture of common protocol design guidelines, and specifics for RTCP):
对于具体设计，应考虑以下因素（它们是通用协议设计指南和RTCP细节的混合）：
o First of all, if there is (and for RTCP this applies quite often) a mechanism from a different networking environment, don't try to directly recreate this mechanism in RTP/RTCP. The Internet environment is extremely heterogeneous, and will often have drastically different properties and behaviour to other network environments. Instead, ask what the actual semantics and the result required to be perceived by the application or the user are. Then, design a mechanism that achieves this result in a way that is compatible with RTP/RTCP. (And do not forget that every mechanism will break when no packets get through -- the Internet does not guarantee connectivity or performance.)
o 首先，如果存在来自不同网络环境的机制（对于RTCP来说，这种情况非常常见），请不要尝试在RTP/RTCP中直接重新创建该机制。Internet环境是极其异构的，通常与其他网络环境具有截然不同的属性和行为。相反，询问应用程序或用户需要感知的实际语义和结果是什么。然后，设计一种机制，以与RTP/RTCP兼容的方式实现此结果。（不要忘记，当没有数据包通过时，每一种机制都会失效——互联网不能保证连接或性能。）
o Target re-usability of the specification. That is, think broader than a specific use case, and try to solve the general problem in cases where it makes sense to do so. Point solutions need a very good motivation to be dealt with in the IETF in the first place. This essentially suggests developing building blocks whenever possible, allowing them to be combined in different environments than initially considered. Where possible, avoid mechanisms that are specific to particular payload formats, media types, link or network types, etc.
o 以规范的可重用性为目标。也就是说，考虑的范围要比具体的用例更广，并尝试在有意义的情况下解决一般问题。点解决方案首先需要在IETF中处理好的动机。这本质上意味着尽可能开发构建块，允许它们在不同的环境中进行组合，而不是在最初考虑的环境中进行组合。在可能的情况下，避免特定于特定负载格式、媒体类型、链路或网络类型等的机制。
o For everything (packet format, value, procedure, timer, etc.) being defined, make sure that it is defined properly, so that independent interoperable implementation can be built. It is not sufficient that you can implement the feature: it has to be implemented in several years by someone unfamiliar with the working group discussion and industry context. Remember that fields need to be both generated and reacted upon, that mechanisms need to be implemented, etc., and that all of this increases the complexity of an implementation. Features that are too complex won't get implemented (correctly) in the first place.
o 对于定义的所有内容（数据包格式、值、过程、计时器等），请确保已正确定义，以便可以构建独立的可互操作实现。仅仅实现该功能是不够的：它必须在几年内由不熟悉工作组讨论和行业背景的人实现。请记住，字段需要生成和响应，机制需要实现，等等，所有这些都会增加实现的复杂性。过于复杂的功能首先无法（正确）实现。
o Extensions defining new metrics and parameters should reference existing standards whenever possible, rather than try to invent something new and/or proprietary.
o 定义新度量和参数的扩展应尽可能参考现有标准，而不是试图发明新的和/或专有的东西。
o Remember that not every bit or every action must be represented or signalled explicitly. It may be possible to infer the necessary pieces of information from other values or their evolution (a very prominent example is TCP congestion control). As a result, it may be possible to de-couple bits on the wire from local actions and reduce the overhead.
o 请记住，并非每一位或每一个动作都必须明确表示或发出信号。可以从其他值或其演变推断出必要的信息片段（一个非常突出的例子是TCP拥塞控制）。因此，可以将线路上的位与本地操作分离，并减少开销。
o Particularly with media streams, reliability can often be "soft". Rather than implementing explicit acknowledgements, receipt of a hint may also be observed from the altered behaviour (e.g., the reception of a requested intra-frame, or changing the reference frame for video, changing the codec, etc.). The semantics of messages should be idempotent so that the respective message may be sent repeatedly. Requiring hard reliability does not scale with increasing group sizes, and does not degrade gracefully as network performance reduces.
o 特别是对于媒体流，可靠性通常是“软的”。除了实现明确的确认，还可以从改变的行为（例如，接收请求的帧内帧，或者改变视频的参考帧，改变编解码器等）观察到提示的接收。消息的语义应该是幂等的，以便可以重复发送相应的消息。要求硬可靠性不会随着组大小的增加而扩展，也不会随着网络性能的降低而优雅地降低。
o Choose the appropriate extension point. Depending on the type of RTCP extension being developed, new data items can be transported in several different ways:
o 选择适当的扩展点。根据正在开发的RTCP扩展类型，新数据项可以几种不同的方式传输：
* A new RTCP Source Description (SDES) item is appropriate for transporting data that describes the source, or the user represented by the source, rather than the ongoing media transmission. New SDES items may be registered to transport source description information of general interest (see [RFC3550], Section 15), or the PRIV item ([RFC3550], Section 6.5.8) may be used for proprietary extensions.
* 新的RTCP源描述（SDES）项适用于传输描述源或源所代表的用户的数据，而不是正在进行的媒体传输。新SDES项目可注册为一般利益的传输源描述信息（见[RFC3550]，第15节），或PRIV项目（[RFC3550]，第6.5.8节）可用于专有扩展。
* A new RTCP XR block type is appropriate for transporting new metrics regarding media transmission or reception quality (see [RFC3611], Section 6.2).
* 新的RTCP XR块类型适用于传输有关媒体传输或接收质量的新指标（请参阅[RFC3611]，第6.2节）。
* New RTP profiles may define a profile-specific extension to RTCP SR and/or RR packets, to give additional feedback (see [RFC3550], Section 6.4.3). It is important to note that while extensions using this mechanism have low overhead, they are not backwards compatible with other profiles. Where compatibility is needed, it's generally more appropriate to define a new RTCP XR block or a new RTCP packet type instead.
* 新RTP配置文件可定义RTCP SR和/或RR数据包的配置文件特定扩展，以提供额外反馈（见[RFC3550]，第6.4.3节）。需要注意的是，虽然使用这种机制的扩展具有较低的开销，但它们与其他概要文件不向后兼容。在需要兼容性的地方，通常更适合定义新的RTCP XR块或新的RTCP数据包类型。
* New RTCP AVPF (Audio-Visual Profile with Feedback) transport-layer feedback messages should be used to transmit general-purpose feedback information that will be generated and processed by the RTP transport. Examples include (negative)
* 应使用新的RTCP AVPF（带反馈的音频-视频配置文件）传输层反馈消息传输将由RTP传输生成和处理的通用反馈信息。例子包括（否定）
acknowledgements for particular packets, or requests to limit the transmission rate. This information is intended to be independent of the codec or application in use (see [RFC4585], Sections 6.2 and 9).
特定数据包的确认，或限制传输速率的请求。此信息旨在独立于使用的编解码器或应用程序（请参见[RFC4585]，第6.2和9节）。
* New RTCP AVPF payload-specific feedback messages should be used to convey feedback information that is specific to a particular media codec, RTP payload format, or category of RTP payload formats. Examples include video picture loss indication or reference picture selection, which are useful for many video codecs (see [RFC4585], Sections 6.3 and 9).
* 应使用新的RTCP AVPF有效负载特定反馈消息来传递特定于特定媒体编解码器、RTP有效负载格式或RTP有效负载格式类别的反馈信息。示例包括视频图片丢失指示或参考图片选择，这对许多视频编解码器都很有用（请参见[RFC4585]，第6.3和9节）。
* New RTCP AVPF application layer feedback messages should be used to convey higher-level feedback, from one application to another, above the level of codecs or transport (see [RFC4585], Sections 6.4 and 9).
* 新的RTCP AVPF应用层反馈消息应用于在编解码器或传输级别之上，从一个应用程序向另一个应用程序传递更高级别的反馈（见[RFC4585]，第6.4和9节）。
* A new RTCP application-defined, or APP, packet is appropriate for private use by applications that don't need to interoperate with others, or for experimentation before registering a new RTCP packet type ([RFC3550], Section 6.7). It is not appropriate to define a new RTCP APP packet in a standards document: use one of the other extension points, or define a new RTCP packet type instead.
* 定义的新RTCP应用程序或应用程序数据包适用于不需要与他人互操作的应用程序的私人使用，或用于注册新RTCP数据包类型之前的试验（[RFC3550]，第6.7节）。在标准文档中定义新的RTCP应用程序数据包是不合适的：使用其他扩展点之一，或定义新的RTCP数据包类型。
* Finally, new RTCP packet types may be registered with IANA if none of the other RTCP extension points are appropriate (see [RFC3550], Section 15).
* Finally, new RTCP packet types may be registered with IANA if none of the other RTCP extension points are appropriate (see [RFC3550], Section 15).translate error, please retry
The RTP framework was designed following the principle of application level framing with integrated layer processing, proposed by Clark and Tennenhouse [ALF]. Effective use of RTP requires that extensions and implementations be designed and built following the same philosophy. That philosophy differs markedly from many previous systems in this space, and making effective use of RTP requires an understanding of those differences.
RTP框架的设计遵循Clark和Tennenhouse[ALF]提出的集成层处理的应用层框架原则。RTP的有效使用要求按照相同的理念设计和构建扩展和实现。这一理念与该领域的许多以前的系统明显不同，有效利用RTP需要理解这些差异。
This memo does not specify any new protocol mechanisms or procedures, and so raises no explicit security considerations. When designing RTCP extensions, it is important to consider the following points:
此备忘录未指定任何新的协议机制或过程，因此未提出明确的安全注意事项。在设计RTCP扩展时，重要的是考虑以下几点：
o Privacy: RTCP extensions, in particular new Source Description (SDES) items, can potentially reveal information considered to be sensitive by end users. Extensions should carefully consider the uses to which information they release could be put, and should be designed to reveal the minimum amount of additional information needed for their correct operation.
o 隐私：RTCP扩展，特别是新的源代码描述（SDES）项，可能会泄露最终用户认为敏感的信息。扩展应该仔细考虑它们所释放的信息的用途，并且应该被设计为揭示其正确操作所需的最小信息量。
o Congestion control: RTCP transmission timers have been carefully designed such that the total amount of traffic generated by RTCP is a small fraction of the media data rate. One consequence of this is that the individual RTCP reporting interval scales with both the media data rate and the group size. The RTCP timing algorithms have been shown to scale from two-party unicast sessions to groups with tens of thousands of participants, and to gracefully handle flash crowds and sudden departures [TimerRecon]. Proposals that modify the RTCP timer algorithms must be careful to avoid congestion, potentially leading to denial of service, across the full range of environments where RTCP is used.
o 拥塞控制：RTCP传输计时器经过精心设计，使得RTCP产生的总流量只占媒体数据速率的一小部分。这样做的一个结果是，单个RTCP报告间隔随媒体数据速率和组大小而变化。RTCP计时算法已被证明可以从两方单播会话扩展到拥有数万参与者的群组，并且可以优雅地处理突发人群和突然离开[TimerRecon]。修改RTCP计时器算法的建议必须小心，以避免在使用RTCP的所有环境中出现拥塞，从而可能导致拒绝服务。
o Denial of service: RTCP extensions that change the location where feedback is sent must be carefully designed to prevent denial of service attacks against third-party nodes. When such extensions are signalled, for example in the Session Description Protocol (SDP), this typically requires some form of authentication of the signalling messages (e.g., see the security considerations of [RFC5760]).
o 拒绝服务：更改发送反馈位置的RTCP扩展必须仔细设计，以防止针对第三方节点的拒绝服务攻击。当例如在会话描述协议（SDP）中用信号通知此类扩展时，这通常需要对信令消息进行某种形式的认证（例如，参见[RFC5760]的安全注意事项）。
The security considerations of the RTP specification [RFC3550] apply, along with any applicable profile (e.g., [RFC3551]).
RTP规范[RFC3550]的安全注意事项以及任何适用的配置文件（例如[RFC3551]）均适用。
This document has been motivated by many discussions in the AVT WG. The authors would like to acknowledge the active members in the group for providing the inspiration.
本文件受到AVT工作组许多讨论的推动。作者要感谢小组中的积极成员提供了灵感。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[RFC2198]Perkins，C.，Kouvelas，I.，Hodson，O.，Hardman，V.，Handley，M.，Bolot，J.，Vega Garcia，A.，和S.Fosse Parisis，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[RFC3556]Casner，S.，“RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽修饰符”，RFC 3556，2003年7月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]Friedman，T.，Caceres，R.，和A.Clark，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[RFC4571]Lazzaro，J.，“面向连接传输上的帧实时传输协议（RTP）和RTP控制协议（RTCP）数据包”，RFC 4571，2006年7月。
[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, July 2006.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，2006年7月。
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
[RFC5109]Li，A.“通用前向纠错的RTP有效载荷格式”，RFC 5109，2007年12月。
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009.
[RFC5506]Johansson，I.和M.Westerlund，“支持缩小尺寸实时传输控制协议（RTCP）：机会和后果”，RFC 5506，2009年4月。
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, April 1996.
[RFC1925]卡隆，R.，“十二个网络真理”，RFC19251996年4月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117]Westerlund，M.和S.Wenger，“RTP拓扑”，RFC 51172008年1月。
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5760]Ott，J.，Chesterfield，J.，和E.Schooler，“具有单播反馈的单源多播会话的RTP控制协议（RTCP）扩展”，RFC 57602010年2月。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路传输RTP数据和控制数据包”，RFC 5761，2010年4月。
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control Protocol (DCCP)", RFC 5762, April 2010.
[RFC5762]Perkins，C.，“RTP和数据报拥塞控制协议（DCCP）”，RFC 5762，2010年4月。
[ALF] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Proceedings of ACM SIGCOMM 1990, September 1990.
[ALF]Clark，D.和D.Tennenhouse，“新一代协议的架构考虑”，ACM SIGCOMM会议记录，1990年，1990年9月。
[TimerRecon] Schulzrinne, H. and J. Rosenberg, "Timer Reconsideration for Enhanced RTP Scalability", Proceedings of IEEE Infocom 1998, March 1998.
[TimerRecon]Schulzrinne，H.和J.Rosenberg，“增强RTP可扩展性的计时器重新考虑”，IEEE Infocom会议记录，1998年3月。
Authors' Addresses
作者地址
Joerg Ott Aalto University School of Science and Technology Otakaari 5 A Espoo, FIN 02150 Finland
约尔格·奥特·阿尔托大学科技学院奥塔卡里5 A埃斯波，芬兰02150
EMail: jo@netlab.tkk.fi
EMail: jo@netlab.tkk.fi
Colin Perkins University of Glasgow Department of Computing Science Glasgow G12 8QQ United Kingdom
柯林帕金斯格拉斯哥大学计算科学系格拉斯哥G128QQ英国
EMail: csp@csperkins.org
EMail: csp@csperkins.org