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

支持小型实时传输控制协议(RTCP):机会和后果

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 (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

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

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

本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下,不得在IETF标准流程之外修改本文件,也不得在IETF标准流程之外创建其衍生作品,除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。

Abstract

摘要

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.

在RTP[RFC3550]中,当前必须将RTP控制协议(RTCP)数据包作为至少包含发送方报告(SR)或接收方报告(RR)的复合数据包发送,然后是至少包含CNAME项的源描述(SDES)数据包。如下文所述,这有充分的理由(见第3.1节);但是,它确实会导致最小RTCP数据包相当大。

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.

RTP/AVPF配置文件[RFC4585]为反馈消息指定新的RTCP数据包类型。其中一些反馈信息将受益于以最小的延迟传输。AVPF提供了一些机制来支持这一点;但是,对于具有低比特率链路的环境,这些消息仍然会消耗大量资源,并且会在网络中完全发送复合数据包所需的时间内引入额外的延迟。因此,希望只发送反馈,而不发送复合RTCP数据包的其他部分。如第3.2节所述,本备忘录为本用例和其他用例提出了这样一种机制。

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

减小RTCP的规模有许多好处;第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.

使用缩小的RTCP并非没有问题。第3.4节对此进行了讨论。这些问题需要考虑,也是本文件动机的一部分。

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.

最后,本文件定义了如何更新AVPF,以允许以不会实质性影响复合数据包提供的机制的方式传输缩小的RTCP;详见第4节。连接到AVPF(或SAVPF[RFC5124])的动机是,缩小的RTCP主要有利于事件驱动反馈,AVPF早期RTCP和即时反馈模式使这成为可能。

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

本文件更新了[RFC3550]、[RFC3711]和[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].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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的命名约定常常令人困惑。下面列出了RTCP术语及其含义。详见[RFC3550]第6.1节和[RFC4585]第3.1节。

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

RTCP数据包:可以是不同的类型,包含一个固定的报头部分,后面跟着结构元素,具体取决于RTCP数据包类型。

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

下层数据报:可以解释为UDP有效负载。然而,根据传输情况,它可能是TCP或数据报拥塞控制协议(DCCP)负载或其他负载。与[RFC3550]第3节中定义的“基础协议”同义。

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.

(完整)复合RTCP数据包:符合最小复合RTCP数据包要求并包含更多RTCP数据包的复合RTCP数据包。

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.

缩小的RTCP数据包:可能包含一个或多个RTCP数据包,但不遵循[RFC3550]第6.1节中定义的复合RTCP规则,因此既不是最小复合RTCP,也不是完全复合RTCP。完整定义见第4.1节。

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.

[RFC3550]中的第6.1节规定,RTCP数据包必须作为复合RTCP数据包发送,该数据包至少由两个单独的RTCP数据包组成,首先是发送方报告(SR)或接收方报告(RR),然后是附加数据包,包括包含传输源标识符CNAME项的强制SDES数据包。下面是这些RTCP数据包类型的简要说明。

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.

他们可以很快建立一个很好的团队规模估计。否则将导致RTCP发送方占用太多带宽。

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.

综上所述,显而易见,SR/RR和CNAME都非常重要,以便新的会话参与者能够利用任何接收到的媒体,避免RTCP报告充斥网络。此外,所提供信息的动态性将使其在不定期发送的情况下变得不那么有用。

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

以下章节将描述缩小RTCP有益的情况,并说明必须考虑的可能问题。

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

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

下面列出了一些缩小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].

编解码器控制信令:可与缩小的RTCP一起使用的示例是,例如,[RFC5104]中规定的临时最大媒体流比特率请求(TMMBR)消息,该消息表示编解码器比特率的更改请求。这些消息得益于在不良信道条件下使用缩小的RTCP,因为缩小的RTCP比较大的复合RTCP更可能成功传输。这是至关重要的,因为这些消息可能在通道条件较差时发生。[MTSI-3GPP]中还提供了用于缩小RTCP的编解码器控制的其他示例。

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.

反馈:反馈场景的一个示例是具有通用NACK的视频流,它将从减小的RTCP中获益。在RTT短于接收机缓冲区深度的情况下,通用NACK可用于请求丢失分组的重传,从而显著提高播放质量。如果通用NACK数据包作为缩小的RTCP传输,RTCP的带宽需求将是最小的,从而实现更频繁的反馈。在编解码器控制的情况下,重要的是这些数据包可以以尽可能少的延迟传输。缩小RTCP的另一个有趣用途是在需要定期反馈的情况下,如第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

状态报告:一个提议的想法是在缩小的RTCP中传输小型测量或状态报告,并拆分最小复合RTCP,分别传输单个RTCP。状态报告可以由端点使用,也可以由其他端点使用

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.

网络中的网络监控框。其好处是,在某些无线接入技术中,小数据包比大数据包对恶劣的无线条件更具鲁棒性。此外,对于小(报告)数据包,报告数据包影响其报告的通道的风险较小。另一个好处是,通过减小RTCP的大小,可以允许(例如)匿名状态报告不加密地传输。这可能是有益的,例如,用于网络监视目的。

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.

如果减小的RTCP承载重要且对时间敏感的反馈,则更短的序列化时间和更低的丢失概率对于实现最佳功能都很重要。当尝试执行媒体适配以例如处理蜂窝系统中的小区边界处存在的改变的性能时,对于反馈分组具有比媒体分组高得多的分组丢失率是有害的。

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.

在需要定期反馈的情况下,例如针对RTP[TCP-FRIEND]的TCP友好速率控制(TFRC)开发的配置文件,如果往返时间短,复合RTCP的大小可能会导致非常高的带宽要求。对于这个特定的应用程序,缩小的RTCP提供了非常实质性的改进。

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.

本节介绍了缩小RTCP的已知问题,并简要分析了其影响和缓解措施。

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.

第4.2.1节讨论了小型RTCP交付的验证。

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:

[RFC3550]附录A中的数据包验证代码将丢弃减小的RTCP数据包。这有几个影响:

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.

弱化的数据包验证:需要重写数据包验证代码以接受缩小的RTCP。特别是,这影响了[RFC3550]中的第9.1节,即报头验证必须考虑下层数据报中(第一个)RTCP的有效负载类型编号可能不同于200或201(SR或RR)。这一变化的一个潜在影响是,接收到的数据包实际上是RTCP,而不是错误传递的其他类型的数据包的验证要弱得多。因此,应考虑确保提供最佳验证,例如,限制缩小的RTCP仅包含某些特定的RTCP数据包类型,这些数据包类型最好在每个会话的基础上发送信号。然而,在数据包上应用源身份验证的安全机制将提供更强的保护。

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.

旧RTP接收器:没有更新数据包验证码的任何RTCP接收器将丢弃缩小的RTCP,这意味着接收器将看不到所包含的反馈消息。其效果取决于反馈信息的类型和接收者的角色。例如,在使用[RFC4588]定义的重传方案的会话中,如果试图向未更新的媒体发送方发送减小大小的NACK消息(参见[RFC4585]第6.2.1节),这可能会导致功能完全丧失。这种类型的丢弃也会影响AVPF中定义的反馈抑制。结果将是会话中的接收器分区,旧的接收器只看到复合RTCP反馈消息,新的接收器同时看到这两个消息。在这种情况下,旧接收器可能会发送已在缩小的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.

带宽注意事项:丢弃缩小的RTCP将影响RTCP传输计算,因为avg_RTCP_大小值将大于此计算中排除缩小的RTCP的RTP接收器(假设缩小的RTCP小于复合RTCP)。因此,这些发送方将低于可用比特率,并以比更新的接收方更长的间隔发送。对于大多数会议来说,这不应该是一个问题。然而,对于具有大部分缩减的RTCP的会话,更新的接收器可能会提前超时未更新的发送器。但是,这种情况不太可能发生,因为复合RTCP传输之间的时间间隔需要是减小的RTCP发送方使用的时间间隔的5倍。

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.

avg_rtcp_大小的计算:复合rtcp之间的长时间间隔以及其间的许多缩减rtcp可能导致avg_rtcp_大小的计算值随时间变化很大。调查表明,尽管各不相同,但这还不足以保证RTCP调度算法的进一步更改或复杂性。

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

安全实时传输协议(SRTP)为精简的RTCP提出了一个问题。[RFC3711]第3.4节规定,“必须根据该要求向SRTCP提供数据包,即第一部分必须是发送方报告或接收方报告”。

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.

在检查SRTP如何处理数据包后,很明显SRTP对第一个数据包是SR还是RR数据包没有真正的依赖性。需要的是通用RTCP数据包头,它存在于所有数据包类型中,并带有源SSRC。因此,结论是,可以将缩小尺寸的RTCP与SRTP一起使用。然而,由于这意味着对[RFC3711]中的规则进行了更改,因此可能需要对SRTP实现进行更改。

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.

在多路传输RTP和RTCP位于同一端口的应用中,如[MULTI-RTP]中所定义,必须注意确保即使RTCP数据包的大小减小,也能正确地进行多路传输。减小RTCP大小的缺点是存在更多表示RTCP数据包的值,从而减少了可用RTP有效负载类型空间。然而,[MULTI-RTP]中的第4节已经要求在执行此多路复用时不使用相应的RTP有效负载类型范围。

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:

基于上述分析,在某些限制条件下,允许传输缩小的RTCP似乎是可行的:

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.

这意味着复合RTCP的定期传输必须在整个RTP会话中保持。缩小的RTCP应限制用作额外RTCP(例如,反馈),在常规复合RTCP数据包无法发送的情况下发送。

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

只有在AVPF[RFC4585]或SAVPF[RFC5124]早期RTCP或即时反馈模式下运行的RTP会话中,才能使用缩小的RTCP。在至少发送一个复合RTCP之前,不得发送缩小的RTCP。在即时反馈模式下,所有反馈消息可作为缩小的RTCP发送。在早期RTCP模式下,一种按计划作为

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

早期RTCP,即非常规RTCP,可作为缩小的RTCP发送。计划作为常规RTCP传输的所有RTCP应作为复合RTCP发送,如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]:

缩小的RTCP数据包是具有以下属性的RTCP数据包,这些属性使其偏离[RFC3550]第6.1节中给出的复合RTCP数据包定义:

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.

如果应用程序要使用缩减大小的RTCP,则必须验证缩减大小的RTCP数据包是否实际到达会话参与者。如上文第3.4.1节和第3.4.2节所述,可沿路径或在端点丢弃数据包。

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:

建议使用一些验证规则,以确保RTCP传输和接收的可靠性,并解决使用缩小尺寸RTCP时发现的问题:

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.

无法检测到成功传递的RTCP数据包类型不应作为缩小的RTCP数据包传输,除非它们与另一个可以检测到成功传递的RTCP数据包类型在同一下层数据报中传输。

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.

第4.1节中定义的结果可能是,缩小的RTCP的最终大小可能会大于定期调度的复合RTCP数据包。对于使用对数据包大小敏感的访问类型的应用程序(见第3.3节第2段),强烈建议使用减小大小的RTCP仅限于在每个较低层数据报中传输单个RTCP数据包。确定是否需要的方法不在本文件的范围内。

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.

一般来说,由于大型缩减大小RTCP数据包的好处非常有限,因此强烈建议将大型缩减大小RTCP数据包作为复合RTCP数据包传输。

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

如前所述,复合RTCP的传输必须定期进行。但是,只要RTCP发送方遵循AVPF调度算法,就会发生这种情况

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.

定义见[RFC4585]第3.5节。如下所示,所有常规RTCP必须为完全复合RTCP。请注意,还需要以即时反馈模式发送定期RTCP。

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.

[RFC4585]第3.3节给出了使用AVPF立即反馈模式的选项,只要组大小低于某个限制。由于使用减小尺寸的RTCP的传输可以减少带宽需求,因此这种传输还提供了更自由地使用即时反馈模式的可能性。

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.

在SDP的声明性使用中,例如实时流协议(RTSP)[RFC2326]和会话公告协议(SAP)[RFC2974],该属性的存在表示会话参与者可以在其RTCP传输中使用减小大小的RTCP数据包。

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

RTP[RFC3550]和AVPF[RFC4585]的安全注意事项也适用于缩小的RTCP。RTCP端口上接收到的数据包的验证强度降低可能会导致伪数据作为真实RTCP被更高程度地接受。该漏洞主要可以通过使用任何提供身份验证的安全机制来解决;其中一种机制是SRTP[RFC3711]。

7. IANA Considerations
7. IANA考虑

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

按照[RFC4566]中的指南,IANA已注册了一个新的SDP属性:

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.

本文档还包含从[RFC3550]、[RFC4585]和[RFC3711]复制的一些文本。我们借此机会感谢上述文件的作者。

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), http://www.3gpp.org/ftp/Specs/html-info/ 26-series.htm", March 2007.

[MTSI-3GPP]3GPP,“规格:3GPP TS 26.114(v8.2.0或更高版本),http://www.3gpp.org/ftp/Specs/html-info/ 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.

[MULTI-RTP]Perkins,C.和M.Westerlund,“在单个端口上多路复用RTP数据和控制数据包”,正在进行的工作,2007年8月。

[OMA-PoC] Open Mobile Alliance, "Specification : Push to talk Over Cellular User Plane, http:// member.openmobilealliance.org/ftp/public_documents/poc/ Permanent_documents/ OMA-TS-PoC_UserPlane-V2_0-20080507-C.zip", November 2006.

[OMA PoC]开放式移动联盟,“规范:通过蜂窝用户平面进行按键通话,http://member.openmobilealliance.org/ftp/public_documents/PoC/Permanent_documents/OMA-TS-PoC_UserPlane-V2_0-20080507-C.zip”,2006年11月。

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

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

[RFC4566]Handley,M.,Jacobson,V.,和C.Perkins,“SDP:会话描述协议”,RFC4566,2006年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月。

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

[TCP-FRIEND]Gharai,L.,“具有TCP友好速率控制的RTP”,正在进行的工作,2007年7月。

Authors' Addresses

作者地址

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

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

   Phone: +46 73 0783289
   EMail: ingemar.s.johansson@ericsson.com
        
   Phone: +46 73 0783289
   EMail: ingemar.s.johansson@ericsson.com
        

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

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

   Phone: +46 10 7148287
   EMail: magnus.westerlund@ericsson.com
        
   Phone: +46 10 7148287
   EMail: magnus.westerlund@ericsson.com