Network Working Group                                       I. Johansson
Request for Comments: 5506                                 M. Westerlund
Updates: 3550, 3711, 4585                                    Ericsson AB
Category: Standards Track                                     April 2009
Network Working Group                                       I. Johansson
Request for Comments: 5506                                 M. Westerlund
Updates: 3550, 3711, 4585                                    Ericsson AB
Category: Standards Track                                     April 2009

Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences


Status of This Memo


This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice


Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2009 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document ( Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束( 请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.




This memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed. Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). This document updates RFC 3550, RFC 3711, and RFC 4585.

本备忘录讨论了允许以较小尺寸传输实时传输协议(RTCP)数据包时产生的好处和问题。如果删除或更改RFC3550中概述的关于如何创建复合数据包的规则,则可以减小大小。基于该分析,本备忘录定义了对规则的某些更改,以允许在使用RTP/AVPF(实时传输协议/带反馈的音频视频配置文件)配置文件(RFC 4585)时,在特定条件下将反馈消息作为缩小的RTCP数据包发送。本文档更新了RFC 3550、RFC 3711和RFC 4585。

Table of Contents


   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Use Cases and Design Rationale ..................................4
      3.1. RTCP Compound Packets (Background) .........................4
      3.2. Use Cases for Reduced-Size RTCP ............................6
      3.3. Benefits of Reduced-Size RTCP ..............................7
      3.4. Issues with Reduced-Size RTCP ..............................8
           3.4.1. Middle Boxes ........................................9
           3.4.2. Packet Validation ...................................9
           3.4.3. Encryption/Authentication ..........................10
           3.4.4. RTP and RTCP Multiplex on the Same Port ............10
           3.4.5. Header Compression .................................11
   4. Use of Reduced-Size RTCP with AVPF .............................11
      4.1. Definition of Reduced-Size RTCP ...........................12
      4.2. Algorithm Considerations ..................................12
           4.2.1. Verification of Delivery ...........................12
           4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP .....13
           4.2.3. Enforcing Compound RTCP ............................13
           4.2.4. Immediate Feedback Mode ............................14
   5. Signaling ......................................................14
   6. Security Considerations ........................................14
   7. IANA Considerations ............................................14
   8. Acknowledgements ...............................................15
   9. References .....................................................15
      9.1. Normative References ......................................15
      9.2. Informative References ....................................16
   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Use Cases and Design Rationale ..................................4
      3.1. RTCP Compound Packets (Background) .........................4
      3.2. Use Cases for Reduced-Size RTCP ............................6
      3.3. Benefits of Reduced-Size RTCP ..............................7
      3.4. Issues with Reduced-Size RTCP ..............................8
           3.4.1. Middle Boxes ........................................9
           3.4.2. Packet Validation ...................................9
           3.4.3. Encryption/Authentication ..........................10
           3.4.4. RTP and RTCP Multiplex on the Same Port ............10
           3.4.5. Header Compression .................................11
   4. Use of Reduced-Size RTCP with AVPF .............................11
      4.1. Definition of Reduced-Size RTCP ...........................12
      4.2. Algorithm Considerations ..................................12
           4.2.1. Verification of Delivery ...........................12
           4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP .....13
           4.2.3. Enforcing Compound RTCP ............................13
           4.2.4. Immediate Feedback Mode ............................14
   5. Signaling ......................................................14
   6. Security Considerations ........................................14
   7. IANA Considerations ............................................14
   8. Acknowledgements ...............................................15
   9. References .....................................................15
      9.1. Normative References ......................................15
      9.2. Informative References ....................................16
1. Introduction
1. 介绍

In RTP [RFC3550] it is currently mandatory to send RTP Control Protocol (RTCP) packets as compound packets containing at least a sender report (SR) or receiver report (RR), followed by a source description (SDES) packet containing at least the CNAME item. There are good reasons for this, as discussed below (see Section 3.1); however, it does result in the minimal RTCP packets being quite large.


The RTP/AVPF profile [RFC4585] specifies new RTCP packet types for feedback messages. Some of these feedback messages would benefit from being transmitted with minimal delay. AVPF provides some mechanisms to support this; however, for environments with low-bitrate links, these messages can still consume a large amount of resources and can introduce extra delay in the time it takes to completely send the compound packet in the network. It is therefore desirable to send just the feedback, without the other parts of a compound RTCP packet. This memo proposes such a mechanism for this and other use cases, as discussed in Section 3.2.


There are a number of benefits with Reduced-Size RTCP; these are discussed in Section 3.3.


The use of Reduced-Size RTCP is not without issues. This is discussed in Section 3.4. These issues need to be considered and are part of the motivation for this document.


Finally, this document defines how AVPF is updated to allow for the transmission of Reduced-Size RTCP in a way that would not substantially affect the mechanisms that compound packets provide; see Section 4 for more details. The connection to AVPF (or SAVPF [RFC5124]) is motivated by the fact that Reduced-Size RTCP is mainly beneficial for event-driven feedback purposes and that the AVPF Early RTCP and Immediate Feedback modes make this possible.


This document updates [RFC3550], [RFC3711], and [RFC4585].


2. Terminology
2. 术语

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].


The naming convention for RTCP is often confusing. Below is a list of RTCP terms and what they mean. See also Section 6.1 in [RFC3550] and Section 3.1 in [RFC4585] for details.


RTCP packet: Can be of different types, contains a fixed header part followed by structured elements depending on RTCP packet type.


Lower layer datagram: Can be interpreted as the UDP payload. It may however, depending on the transport, be a TCP or Datagram Congestion Control Protocol (DCCP) payload or something else. Synonymous to the "underlying protocol" defined in Section 3 in [RFC3550].


Compound RTCP packet: A collection of two or more RTCP packets. A compound RTCP packet is transmitted in a lower-layer datagram. It must contain at least an RTCP RR or SR packet and an SDES packet with the CNAME item. Often "compound" is left out, the interpretation of RTCP packet is therefore dependent on the context.

复合RTCP数据包:两个或多个RTCP数据包的集合。复合RTCP数据包在较低层数据报中传输。它必须至少包含一个RTCP RR或SR数据包和一个带有CNAME项的SDES数据包。通常忽略“复合”,因此RTCP数据包的解释取决于上下文。

Minimal compound RTCP packet: A compound RTCP packet that contains the RTCP RR or SR packet and the SDES packet with the CNAME item with a specified ordering.

最小复合RTCP数据包:包含RTCP RR或SR数据包和SDES数据包的复合RTCP数据包,其中包含具有指定顺序的CNAME项。

(Full) compound RTCP packet: A compound RTCP packet that conforms to the requirements on minimal compound RTCP packets and contains more RTCP packets.


Reduced-Size RTCP packet: May contain one or more RTCP packets but does not follow the compound RTCP rules defined in Section 6.1 in [RFC3550] and is thus neither a minimal nor a full compound RTCP. See Section 4.1 for a full definition.


3. Use Cases and Design Rationale
3. 用例和设计原理
3.1. RTCP Compound Packets (Background)
3.1. RTCP复合数据包(背景)

Section 6.1 in [RFC3550] specifies that an RTCP packet must be sent as a compound RTCP packet consisting of at least two individual RTCP packets, first a sender report (SR) or receiver report (RR), followed by additional packets including a mandatory SDES packet containing a CNAME item for the transmitting source identifier. Below is a short description of what these RTCP packet types are used for.


1. The sender and receiver reports (see Section 6.4 of [RFC3550]) provide the RTP session participant with the synchronization source (SSRC) identifier of all RTP session participants. Having all participants send these packets periodically allows everyone to determine the current number of participants. This information is used in the transmission scheduling algorithm. Thus, this is particularly important for new participants so that

1. 发送方和接收方报告(见[RFC3550]第6.4节)向RTP会话参与者提供所有RTP会话参与者的同步源(SSRC)标识符。让所有参与者定期发送这些数据包可以让每个人确定当前参与者的数量。该信息用于传输调度算法。因此,这对新参与者来说尤为重要,以便

they can quickly establish a good estimate of the group size. Failure to do this would result in RTCP senders consuming too much bandwidth.


2. Before a new session participant has sent any RTP or RTCP packet, it can also avoid SSRC collisions with all the SSRCs it sees prior to that transmission. So the possibility to see a substantial proportion of the participating sources minimizes the risk of any collision when selecting SSRC.

2. 在新会话参与者发送任何RTP或RTCP数据包之前,它还可以避免与传输之前看到的所有SSRC发生SSRC冲突。因此,在选择SSRC时,看到大部分参与源的可能性将任何碰撞的风险降至最低。

3. The sender and receiver reports contain some basic statistics usable for monitoring of the transport and thus enable adaptation. These reports become more useful if sent regularly, as the receiver of a report can perform analyses to find trends between the individual reports. When used for media transmission adaptation, the information becomes more useful the more frequently it is received, at least until one report per round-trip time (RTT) is achieved. Therefore, there is, in most cases, no reason not to include the sender or receiver report in all RTCP packets.

3. 发送方和接收方报告包含一些可用于监控传输的基本统计信息,从而实现自适应。如果定期发送,这些报告将变得更有用,因为报告的接收者可以进行分析,以发现各个报告之间的趋势。当用于媒体传输适配时,接收信息的频率越高,信息就变得越有用,至少直到达到每往返时间(RTT)一次报告为止。因此,在大多数情况下,没有理由不在所有RTCP数据包中包含发送方或接收方报告。

4. The CNAME SDES item (see Section 6.5.1 of [RFC3550]) exists to allow receivers to determine which media flows should be synchronized with each other, both within an RTP session and between different RTP sessions carrying different media types. Thus, it is important to quickly receive this for each media sender in the session when joining an RTP session.

4. CNAME SDES项(见[RFC3550]第6.5.1节)的存在允许接收方确定哪些媒体流应在RTP会话内以及承载不同媒体类型的不同RTP会话之间相互同步。因此,在加入RTP会话时,为会话中的每个媒体发送者快速接收此消息非常重要。

5. Sender reports (SR) are used in combination with the above SDES CNAME mechanism to synchronize multiple RTP streams, such as audio and video. After having determined which media streams should be synchronized using the CNAME field, the receiver uses the sender report's NTP and RTP timestamp fields to establish synchronization.

5. 发送方报告(SR)与上述SDES CNAME机制结合使用,以同步多个RTP流,如音频和视频。在使用CNAME字段确定应该同步哪些媒体流之后,接收方使用发送方报告的NTP和RTP时间戳字段来建立同步。

6. The CNAME SDES item also allows a session participant to detect SSRC collisions and separate them from routing loops. The 32- bit, randomly selected SSRC has some probability of collision. The CNAME is used as the longer canonical identifier of a particular endpoint instance that is bound to an SSRC. If that binding isn't received and kept current, the receiver may not detect an SSRC collision, i.e., two different CNAMEs using the same SSRC. It also can't detect an RTP-level routing loop, with the result that the same SSRC and CNAME arrive from multiple lower-layer source addresses.

6. CNAME SDES项还允许会话参与者检测SSRC冲突并将其与路由循环分离。随机选择的32位SSRC具有一定的冲突概率。CNAME用作绑定到SSRC的特定端点实例的较长规范标识符。如果未接收到该绑定并保持当前状态,则接收器可能检测不到SSRC冲突,即,两个不同的CNAME使用相同的SSRC。它也无法检测RTP级路由循环,结果是相同的SSRC和CNAME从多个较低层源地址到达。

Reviewing the above, it is obvious that both SR/RR and the CNAME are very important in order for new session participants to be able to utilize any received media and to avoid flooding the network with RTCP reports. In addition, the dynamic nature of the information provided would make it less useful if not sent regularly.


The following sections will describe the cases when Reduced-Size RTCP is beneficial and will also show the possible issues that must be considered.


3.2. Use Cases for Reduced-Size RTCP
3.2. 缩小尺寸RTCP的用例

Below are listed a few use cases for Reduced-Size RTCP.


Control Plane Signaling: The Open Mobile Alliance (OMA) Push-to-talk over Cellular (PoC) [OMA-PoC] makes use of Reduced-Size RTCP when transmitting certain events. The OMA PoC service is primarily used over cellular links capable of IP transport, such as the Global System for Mobile Connections (GSM) General Packet Radio Service (GPRS).

控制平面信令:开放移动联盟(OMA)蜂窝式一键通(PoC)[OMA PoC]在传输某些事件时使用缩小的RTCP。OMA PoC服务主要通过能够进行IP传输的蜂窝链路使用,例如全球移动连接系统(GSM)通用分组无线业务(GPRS)。

Codec Control Signaling: An example that can be used with Reduced-Size RTCP is, e.g., Temporary Maximum Media Stream Bitrate Request (TMMBR) messages as specified in [RFC5104], which signal a request for a change in codec bitrate. These messages benefit from the usage of Reduced-Size RTCP in bad channel conditions, as Reduced-Size RTCP are much more likely to be successfully transmitted than larger compound RTCP. This is critical, as these messages are likely to occur when channel conditions are poor. Other examples of codec control usage for Reduced-Size RTCP are found in [MTSI-3GPP].


Feedback: An example of a feedback scenario that would benefit from Reduced-Size RTCP is Video streams with generic NACK. In cases where the RTT is shorter than the receiver buffer depth, generic NACK can be used to request retransmission of missing packets, thus improving playout quality considerably. If the generic NACK packets are transmitted as Reduced-Size RTCP, the bandwidth requirement for RTCP will be minimal, enabling more frequent feedback. As in the codec control case, it is important that these packets can be transmitted with as little delay as possible. Another interesting use for Reduced-Size RTCP is in cases when regular feedback is needed, as described in Section 3.3.


Status Reports: One proposed idea is to transmit small measurement or status reports in Reduced-Size RTCP, and to split the minimal compound RTCP and transmit the individual RTCP separately. The status reports can be used either by the endpoints or by other


network monitoring boxes in the network. The benefit is that, with some radio access technologies, small packets are more robust to poor radio conditions than large packets. Additionally, with small (report) packets, there is a smaller risk that the report packets will affect the channel upon which they report. Another benefit is that it is possible, with Reduced-Size RTCP, to allow, for example, anonymous status reporting to be transmitted unencrypted. This is something that may be beneficial, for instance, for network monitoring purposes.


3.3. Benefits of Reduced-Size RTCP
3.3. 缩小RTCP的好处

As mentioned in the introduction, most advantages of using Reduced-Size RTCP packets exist in cases when the available RTCP bitrate is limited. This is because they can become substantially smaller than compound packets. A compound packet is forced to contain both an RR or an SR and the CNAME SDES item. The RR containing a report block for a single source is 32 bytes, an SR is 52 bytes. Both may be larger if they contain report blocks for multiple sources. The SDES packet containing a CNAME item will be 10 bytes plus the CNAME string length. Here, it is reasonable that the CNAME string is at least 10 bytes to get a decent collision resistance. If the recommended form of user@host is used, then most strings will be longer than 20 characters. Thus, a Reduced-Size RTCP can become at least 70-80 bytes smaller than the compound packet.

如引言中所述,在可用RTCP比特率有限的情况下,使用减小大小的RTCP数据包的大多数优势都存在。这是因为它们可以大大小于复合数据包。复合数据包必须同时包含RR或SR和CNAME SDES项。包含单个源的报告块的RR为32字节,SR为52字节。如果它们包含多个源的报告块,则两者都可能更大。包含CNAME项的SDES数据包将为10个字节加上CNAME字符串长度。在这里,CNAME字符串至少为10个字节以获得良好的抗冲突性是合理的。如果建议的user@host如果使用,则大多数字符串将超过20个字符。因此,减小大小的RTCP可以比复合分组小至少70-80字节。

For low bitrate links, the benefits of this reduction in size are as follows:


o For links where the packet-loss rate grows with the packet size, smaller packets are less likely to be dropped. Radio links are an example of such links. In the cellular world, there exist links that are optimized to handle RTP packets sized for carrying compressed speech. This increases the capacity and coverage for voice services in a given wireless network. Minimal compound RTCP packets are commonly 2-3 times the size of an RTP packet carrying compressed speech. If the speech packet over such a bearer has a packet-loss probability of p, then the RTCP packet will experience a loss probability of 1-(1-p)^x, where x is the number of fragments the compound packet will be split into on the link layer, i.e., commonly into 2 or 3 fragments.

o 对于丢包率随数据包大小而增加的链路,较小的数据包被丢弃的可能性较小。无线电链路就是这种链路的一个例子。在蜂窝世界中,存在经过优化的链路,以处理用于承载压缩语音的RTP数据包。这增加了给定无线网络中语音服务的容量和覆盖范围。最小复合RTCP数据包通常是承载压缩语音的RTP数据包大小的2-3倍。如果这种承载上的语音分组具有p的分组丢失概率,则RTCP分组将经历1-(1-p)^x的丢失概率,其中x是复合分组将在链路层上分割成的片段数,即,通常分成2或3个片段。

o There is a shorter serialization time, i.e., the time it takes the link to transmit the packet. For slower links, this time can be substantial. For example, transmitting 120 bytes over a link interface capable of 30 kbps takes 32 milliseconds (ms), assuming uniform transmission rate.

o 序列化时间较短,即链路传输数据包所需的时间。对于较慢的链接,这一时间可能是相当长的。例如,假设传输速率一致,则通过能够达到30 kbps的链路接口传输120字节需要32毫秒(ms)。

In cases when Reduced-Size RTCP carries important and time-sensitive feedback, both shorter serialization time and the lower loss probability are important to enable the best possible functionality. Having a packet-loss rate that is much higher for the feedback packets than the media packets hurts when trying to perform media adaptation to, for example, handle the changed performance present at the cell border in a cellular system.


For high-bitrate applications, there is usually no problem to supply RTCP with sufficient bitrates. When using AVPF, one can use the "trr-int" parameter to restrict the regular reporting interval to approximately once per RTT or less often. As in most cases, there is little reason to provide regular reports of higher density than this; any additional bandwidth can then be used for feedback messages. The benefit of Reduced-Size RTCP in this case is limited, but exists. One typical example is video using generic NACK in cases where the RTT is low. Using Reduced-Size RTCP would reduce the total amount of bits used for RTCP. This is primarily applicable if the number of reports is large. This would also result in lower processing delay and less complexity for the feedback packets, as they do not need to query the RTCP database to construct the right messages.

对于高比特率应用,向RTCP提供足够的比特率通常没有问题。使用AVPF时,可以使用“trr int”参数将常规报告间隔限制为大约每RTT一次或更少的频率。在大多数情况下,没有理由提供比这更高密度的定期报告;任何额外的带宽都可以用于反馈消息。在这种情况下,缩小RTCP的好处是有限的,但仍然存在。一个典型的例子是在RTT较低的情况下使用通用NACK的视频。使用较小的RTCP将减少RTCP使用的总比特数。这主要适用于报告数量较大的情况。这还将降低反馈数据包的处理延迟和复杂性,因为它们不需要查询RTCP数据库来构造正确的消息。

As message size is generally a smaller issue at higher bitrates, it is also possible to transmit multiple RTCP in each lower-layer datagram in these cases. The motivation behind Reduced-Size RTCP in this case is not size, rather it is to avoid the extra overhead caused by inclusion of the SR/RR and SDES CNAME items in each transmitted RTCP.

由于消息大小在较高比特率下通常是一个较小的问题,因此在这些情况下,在每个较低层数据报中传输多个RTCP也是可能的。在这种情况下,缩减大小RTCP背后的动机不是大小,而是为了避免在每个传输的RTCP中包含SR/RR和SDES CNAME项所造成的额外开销。

Independently of the link type, there are additional benefits with sending feedback in small Reduced-Size RTCP. Applications that use RTCP AVPF in Early RTCP or Immediate Feedback mode need to send frequent event-driven feedback. Under these circumstances, the risk is reduced that the RTCP bandwidth becomes too high during periods of heavy feedback signaling.

与链路类型无关,在小型RTCP中发送反馈还有其他好处。在早期RTCP或即时反馈模式下使用RTCP AVPF的应用程序需要频繁发送事件驱动反馈。在这些情况下,RTCP带宽在重反馈信令期间变得过高的风险降低。

In cases when regular feedback is needed, such as the profile under development for TCP friendly rate control (TFRC) for RTP [TCP-FRIEND], the size of compound RTCPs can result in very high bandwidth requirements if the round-trip time is short. For this particular application, Reduced-Size RTCP gives a very substantial improvement.


3.4. Issues with Reduced-Size RTCP
3.4. 减小RTCP大小的问题

This section describes the known issues with Reduced-Size RTCP and also provides a brief analysis of their effects and mitigation.


3.4.1. Middle Boxes
3.4.1. 中间盒

Middle boxes in the network may discard RTCP that do not follow the rules outlined in Section 6.1 of RFC 3550. Newer report types may be interpreted as unknown by the middle box. For instance, if the payload type number is 207 instead of 200 or 201, it may be treated as unknown. The effect of this might, for instance, be that compound RTCP would get through while the Reduced-Size RTCP would be lost.

网络中的中间框可能会丢弃不符合RFC 3550第6.1节所述规则的RTCP。中间框可能会将较新的报告类型解释为未知。例如,如果有效载荷类型号是207而不是200或201,则可以将其视为未知。例如,这样做的效果可能是,复合RTCP将通过,而减小的RTCP将丢失。

Verification of the delivery of Reduced-Size RTCP is discussed in Section 4.2.1.


3.4.2. Packet Validation
3.4.2. 数据包验证

A Reduced-Size RTCP packet will be discarded by the packet validation code in Appendix A of [RFC3550]. This has several impacts:


Weakened Packet Validation: The packet validation code needs to be rewritten to accept Reduced-Size RTCP. In particular, this affects Section 9.1 in [RFC3550] in the sense that the header verification must take into account that the payload type numbers for the (first) RTCP in the lower-layer datagram may differ from 200 or 201 (SR or RR). One potential effect of this change is much weaker validation that received packets actually are RTCP and not packets of some other type being wrongly delivered. Thus, some consideration should be given to ensure the best possible validation is available, for example, restricting Reduced-Size RTCP to contain only some specific RTCP packet types that are preferably signalled on a per-session basis. However, the application of a security mechanism for source authentication on the packets will provide much stronger protection.


Old RTP Receivers: Any RTCP receiver without an updated packet validation code will discard the Reduced-Size RTCP, which means that the receiver will not see e.g., the contained feedback messages. The effect of this depends on the type of feedback message and the role of the receiver. For example, this may cause complete function loss in the case of attempting to send a Reduced-Size NACK message (see Section 6.2.1 of [RFC4585]) to a non-updated media sender in a session using the retransmission scheme defined by [RFC4588]. This type of discarding would also affect the feedback suppression defined in AVPF. The result would be a partitioning of the receivers within the session, with the old receivers only seeing the compound RTCP feedback messages and the newer ones seeing both. In this case, the old receivers may send feedback messages for events already reported on in Reduced-Size RTCP.


Bandwidth Considerations: The discarding of Reduced-Size RTCP would affect the RTCP transmission calculation in that the avg_rtcp_size value would become larger than for RTP receivers that exclude the Reduced-Size RTCP in this calculation (assuming that Reduced-Size RTCP are smaller than compound ones). Therefore, these senders would under-utilize the available bitrate and send with a longer interval than updated receivers. For most sessions, this should not be an issue. However, for sessions with a large portion of Reduced-Size RTCP, the updated receivers may time out non-updated senders prematurely. This is, however, not likely to occur, as the time between compound RTCP transmissions needs to become 5 times that used by the Reduced-Size RTCP senders for it to happen.


Computation of avg_rtcp_size: Long intervals between compound RTCP with many Reduced-Size RTCP in between may lead to a computation of a value for avg_rtcp_size that varies greatly over time. Investigation shows that although it varies, this is not enough of a problem to warrant further changes or complexities to the RTCP scheduling algorithm.


3.4.3. Encryption/Authentication
3.4.3. 加密/认证

The Secure Real-time Transport Protocol (SRTP) presents a problem for Reduced-Size RTCP. Section 3.4 of [RFC3711] states, "SRTCP MUST be given packets according to that requirement in the sense that the first part MUST be a sender report or a receiver report".


Upon examination of how SRTP processes packets, it becomes obvious that SRTP has no real dependency on whether the first packet is an SR or an RR packet. What is needed is the common RTCP packet header, which is present in all the packet types, with a source SSRC. The conclusion is therefore that it is possible to use Reduced-Size RTCP with SRTP. Nevertheless, as this implies a change to the rules in [RFC3711], changes in SRTP implementations MAY become necessary.


3.4.4. RTP and RTCP Multiplex on the Same Port
3.4.4. 同一端口上的RTP和RTCP多路复用

In applications in which multiplex RTP and RTCP are on the same port, as defined in [MULTI-RTP], care must be taken to ensure that de-multiplexing is done properly even though the RTCP packets are reduced size. The downside of Reduced-Size RTCP is that more values representing RTCP packets exist, reducing the available RTP payload type space. However, Section 4 in [MULTI-RTP] already requires the corresponding RTP payload type range not be used when performing this multiplexing.


3.4.5. Header Compression
3.4.5. 头部压缩

Two issues are related to header compression. Possible changes are left for future work:


o Payload type number identification: The Robust Header Compression (RoHC) algorithm [RFC3095] needs to create different compression contexts for RTP and RTCP for optimum performance. If RTP and RTCP are multiplexed on the same port, the classification may be based on payload type numbers. The classification algorithm must here acknowledge the fact that the payload type number for (the first) RTCP may differ from 200 or 201.

o 有效负载类型编号识别:鲁棒报头压缩(RoHC)算法[RFC3095]需要为RTP和RTCP创建不同的压缩上下文,以获得最佳性能。如果RTP和RTCP在同一端口上多路传输,则分类可能基于有效负载类型编号。在此,分类算法必须确认(第一个)RTCP的有效负载类型编号可能不同于200或201。

o Compression of RTCP: No IETF-defined header compression method compress RTCP; however, if such methods are developed in the future, these methods must take Reduced-Size RTCP in account.

o RTCP压缩:没有IETF定义的头压缩方法压缩RTCP;但是,如果将来开发此类方法,则这些方法必须考虑减小尺寸的RTCP。

4. Use of Reduced-Size RTCP with AVPF
4. 使用带有AVPF的缩小尺寸RTCP

Based on the above analysis, it seems feasible to allow transmission of Reduced-Size RTCP under some restrictions:


o First of all, it is important that compound RTCPs are transmitted at regular intervals to ensure that the mechanisms maintained by the compound packets, like feedback reporting, work. The tracking of session size and number of participants warrants mentioning again, as this ensures that the RTCP bandwidth remains bounded independent of the number of session participants.

o 首先,必须定期传输复合RTCP,以确保由复合数据包维护的机制(如反馈报告)正常工作。对会话大小和参与者数量的跟踪值得再次提及,因为这确保RTCP带宽保持有界,与会话参与者的数量无关。

o Second, as the compound RTCP packets are also used to establish and maintain synchronization between media, any newly joining participant in a session would need to receive compound RTCP from the media sender(s).

o 其次,由于复合RTCP数据包还用于建立和维护媒体之间的同步,会话中任何新加入的参与者都需要从媒体发送方接收复合RTCP。

This implies that the regular transmission of compound RTCP MUST be maintained throughout an RTP session. Reduced-Size RTCP SHOULD be restricted to be used as extra RTCP (e.g., feedback), sent in cases when a regular compound RTCP packet would not otherwise have been sent.


The usage of Reduced-Size RTCP SHALL only be done in RTP sessions operating in AVPF [RFC4585] or SAVPF [RFC5124] Early RTCP or Immediate Feedback mode. Reduced-Size RTCP SHALL NOT be sent until at least one compound RTCP has been sent. In Immediate Feedback mode, all feedback messages MAY be sent as Reduced-Size RTCP. In Early RTCP mode, a feedback message scheduled for transmission as an


Early RTCP, i.e., not a Regular RTCP, MAY be sent as Reduced-Size RTCP. All RTCP that are scheduled for transmission as Regular RTCP SHALL be sent as compound RTCP as indicated by AVPF [RFC4585].


4.1. Definition of Reduced-Size RTCP
4.1. 缩小尺寸RTCP的定义

A Reduced-Size RTCP packet is an RTCP packet with the following properties that make it deviate from the compound RTCP packet definition given in Section 6.1 in [RFC3550]:


o contains one or more RTCP packet(s)

o 包含一个或多个RTCP数据包

o allows any RTCP packet type; however, see Section 4.2.1

o 允许任何RTCP数据包类型;但是,请参见第4.2.1节

o MUST NOT be used for Regular (scheduled) RTCP report purposes

o 不得用于常规(计划)RTCP报告目的

o MUST NOT be used with the RTP/AVP profile [RFC3551] or the RTP/SAVP profile [RFC3711]

o 不得与RTP/AVP配置文件[RFC3551]或RTP/SAVP配置文件[RFC3711]一起使用

4.2. Algorithm Considerations
4.2. 算法考虑
4.2.1. Verification of Delivery
4.2.1. 交货核查

If an application is to use Reduced-Size RTCP, it is important to verify that the Reduced-Size RTCP packets actually reach the session participants. As outlined above in Section 3.4.1 and Section 3.4.2, packets may be discarded along the path or in the endpoint.


A few verification rules are RECOMMENDED to ensure robust RTCP transmission and reception and to solve the identified issues when Reduced-Size RTCP is used:


o The endpoint issue can be solved by introducing signaling that informs if all session participants are capable of Reduced-Size RTCP. See Section 5.

o 端点问题可以通过引入通知所有会话参与者是否能够缩减RTCP大小的信令来解决。见第5节。

o The middle box issue is more difficult, and here one will be required to use heuristics to determine whether or not the Reduced-Size RTCP packets are delivered. The method used to detect successful delivery of Reduced-Size RTCP packets depends on the packet type. The RTCP packet types for which successful delivery can be detected are:

o 中间盒问题更为困难,在这里,需要使用启发式方法来确定是否传递了减小大小的RTCP数据包。用于检测大小减小的RTCP数据包的成功传递的方法取决于数据包类型。可以检测到成功传递的RTCP数据包类型有:

* Sender reports (SR): Successful transmission of a sender report can be verified by inspection of the echoed timestamp in the received receiver report (RR). This can also be used as a method to verify if Reduced-Size RTCP can be used at all.

* 发送方报告(SR):发送方报告的成功传输可以通过检查接收方报告(RR)中的回显时间戳来验证。这也可以用作验证是否可以使用缩小的RTCP的方法。

* Feedback RTCP packets: In many cases, the feedback messages sent using Reduced-Size RTCP will result in either explicit or implicit indications that they have been received. An example of this is the RTP retransmission [RFC4588] that results from a NACK message [RFC4585]. Another example is the Temporary Maximum Media Stream Bitrate Notification (TMMBN) message resulting from a Temporary Maximum Media Stream Bitrate Request (TMMBR) [RFC5104]. A third example is the presence of a decoder refresh point [RFC5104] in the video media stream resulting from the Full Intra Request that was sent.

* 反馈RTCP数据包:在许多情况下,使用减小大小的RTCP发送的反馈消息将导致显式或隐式指示它们已被接收。这方面的一个例子是由NACK消息[RFC4585]产生的RTP重传[RFC4588]。另一个示例是由临时最大媒体流比特率请求(TMMBR)[RFC5104]产生的临时最大媒体流比特率通知(TMMBN)消息。第三个示例是由于发送的完整帧内请求而在视频媒体流中存在解码器刷新点[RFC5104]。

RTCP packet types for which it is not possible to detect successful delivery SHOULD NOT be transmitted as Reduced-Size RTCP packets unless they are transmitted in the same lower-layer datagram as another RTCP packet type for which successful delivery can be detected.


o An algorithm to detect consistent failure of delivery of Reduced-Size RTCP MUST be used by any application using Reduced-Size RTCP. The details of this algorithm are application dependent and therefore outside the scope of this document.

o 任何使用精简RTCP的应用程序都必须使用一种算法来检测精简RTCP交付的一致性失败。此算法的详细信息取决于应用程序,因此不在本文档的范围内。

If the verification fails, it is strongly RECOMMENDED that only compound RTCP, according to the rules outlined in RFC 3550, is transmitted.

如果验证失败,强烈建议根据RFC 3550中概述的规则,仅传输复合RTCP。

4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP
4.2.2. 缩小的RTCP中的单个与多个RTCP

The result of the definition in Section 4.1 may be that the resulting size of Reduced-Size RTCP can become larger than a regularly scheduled compound RTCP packet. For applications that use access types that are sensitive to packet size (see Paragraph 2 in Section 3.3), it is strongly RECOMMENDED that the use of Reduced-Size RTCP is limited to the transmission of a single RTCP packet in each lower-layer datagram. The method to determine the need for this is outside the scope of this document.


In general, as the benefit with large Reduced-Size RTCP packets is very limited, it is strongly RECOMMENDED to transmit large Reduced-Size RTCP packets as compound RTCP packets instead.


4.2.3. Enforcing Compound RTCP
4.2.3. 强制复合RTCP

As discussed earlier, it is important that the transmission of compound RTCP occurs at regular intervals. However, this will occur as long as the RTCP senders follow the AVPF scheduling algorithm


defined in Section 3.5 of [RFC4585]. This follows as all Regular RTCP MUST be full compound RTCP. Note that there is also a requirement on sending Regular RTCP in Immediate Feedback mode.


4.2.4. Immediate Feedback Mode
4.2.4. 即时反馈模式

Section 3.3 of [RFC4585] gives the option to use AVPF Immediate Feedback mode as long as the group size is below a certain limit. As transmissions using Reduced-Size RTCP may reduce the bandwidth demand, such transmissions also open up the possibility of a more liberal use of Immediate Feedback mode.


5. Signaling
5. 信号

This document defines the "a=rtcp-rsize" Session Description Protocol (SDP) [RFC4566] attribute to indicate if the session participant is capable of supporting Reduced-Size RTCP for applications that use SDP for configuration of RTP sessions. It is REQUIRED that a participant that proposes the use of Reduced-Size RTCP shall itself support the reception of Reduced-Size RTCP.

本文档定义了“a=rtcp rsize”会话描述协议(SDP)[RFC4566]属性,以指示会话参与者是否能够为使用SDP配置RTP会话的应用程序支持缩减大小的rtcp。要求提议使用小型RTCP的参与者本身应支持接收小型RTCP。

An offering client that wishes to use Reduced-Size RTCP MUST include the attribute "a=rtcp-rsize" in the SDP offer. If "a=rtcp-rsize" is present in the offer SDP, the answerer that supports Reduced-Size RTCP and wishes to use it SHALL include the "a=rtcp-rsize" attribute in the answer.

希望使用精简RTCP的产品客户端必须在SDP产品中包含属性“a=RTCP rsize”。如果报价SDP中存在“a=rtcp rsize”,则支持缩小rtcp并希望使用它的应答者应在应答中包含“a=rtcp rsize”属性。

In declarative usage of SDP, such as the Real Time Streaming Protocol (RTSP) [RFC2326] and the Session Announcement Protocol (SAP) [RFC2974], the presence of the attribute indicates that the session participant MAY use Reduced-Size RTCP packets in its RTCP transmissions.


6. Security Considerations
6. 安全考虑

The security considerations of RTP [RFC3550] and AVPF [RFC4585] will apply also to Reduced-Size RTCP. The reduction in validation strength for received packets on the RTCP port may result in a higher degree of acceptance of spurious data as real RTCP. This vulnerability can mostly be addressed by usage of any security mechanism that provides authentication; one such mechanism is SRTP [RFC3711].


7. IANA Considerations
7. IANA考虑

Following the guidelines in [RFC4566], the IANA has registered a new SDP attribute:


o Contact name, email address, and telephone number: Authors of RFC 5506

o 联系人姓名、电子邮件地址和电话号码:RFC 5506的作者

o Attribute-name: rtcp-rsize

o 属性名称:rtcp rsize

o Long-form attribute name: Reduced-Size RTCP

o 长格式属性名称:缩减大小RTCP

o Type of attribute: media-level

o 属性类型:媒体级别

o Subject to charset: no

o 以字符集为准:否

This attribute defines the support for Reduced-Size RTCP, i.e., the possibility to transmit RTCP that does not conform to the rules for compound RTCP defined in RFC 3550. It is a property attribute, which does not take a value.

此属性定义了对精简RTCP的支持,即传输不符合RFC 3550中定义的复合RTCP规则的RTCP的可能性。它是一个属性属性,不接受值。

8. Acknowledgements
8. 致谢

The authors would like to thank all the people who gave feedback on this document. Special thanks go to Colin Perkins.


This document also contains some text copied from [RFC3550], [RFC4585], and [RFC3711]. We take this opportunity to thank the authors of said documents.


9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[RFC3550]Schulzrinne,H.,Casner,S.,Frederick,R.,和V.Jacobson,“RTP:实时应用的传输协议”,STD 64,RFC 35502003年7月。

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

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

[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008.

[RFC5124]Ott,J.和E.Carrara,“基于实时传输控制协议(RTCP)的反馈扩展安全RTP配置文件(RTP/SAVPF)”,RFC 51242008年2月。

9.2. Informative References
9.2. 资料性引用

[MTSI-3GPP] 3GPP, "Specification : 3GPP TS 26.114 (v8.2.0 or later), 26-series.htm", March 2007.

[MTSI-3GPP]3GPP,“规格:3GPP TS 26.114(v8.2.0或更高版本), 26 series.htm”,2007年3月。

[MULTI-RTP] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", Work in Progress, August 2007.


[OMA-PoC] Open Mobile Alliance, "Specification : Push to talk Over Cellular User Plane, http:// Permanent_documents/", November 2006.

[OMA PoC]开放式移动联盟,“规范:通过蜂窝用户平面进行按键通话,”,2006年11月。

[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.


[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.

[RFC2974]Handley,M.,Perkins,C.,和E.Whelan,“会话公告协议”,RFC 2974,2000年10月。

[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.

[RFC3095]Bormann,C.,Burmeister,C.,Degermark,M.,Fukushima,H.,Hannu,H.,Jonsson,L-E.,Hakenberg,R.,Koren,T.,Le,K.,Liu,Z.,Martenson,A.,Miyazaki,A.,Svanbro,K.,Wiebke,T.,Yoshimura,T.,和H.Zheng,“鲁棒头压缩(ROHC):框架和四个配置文件:RTP,UDP,ESP,和未压缩”,RFC 3095,2001年7月。

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

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.


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

[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008.

[RFC5104]Wenger,S.,Chandra,U.,Westerlund,M.,和B.Burman,“带反馈的RTP视听配置文件(AVPF)中的编解码器控制消息”,RFC 5104,2008年2月。

[TCP-FRIEND] Gharai, L., "RTP with TCP Friendly Rate Control", Work in Progress, July 2007.


Authors' Addresses


Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Lulea SWEDEN

英格玛·约翰逊·爱立信AB实验室和瑞典卢利亚11 SE-971 28

   Phone: +46 73 0783289
   Phone: +46 73 0783289

Magnus Westerlund Ericsson AB Faeroegatan 6 SE-164 80 Stockholm SWEDEN

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

   Phone: +46 10 7148287
   Phone: +46 10 7148287