Network Working Group J. Ott
Request for Comments: 4585 Helsinki University of Technology
Category: Standards Track S. Wenger
Nokia
N. Sato
Oki
C. Burmeister
J. Rey
Matsushita
July 2006
基于实时传输控制协议(RTCP)反馈的扩展RTP(RTP/AVPF)配置文件
本备忘录的状态
本文档为Internet社区指定了Internet标准跟踪协议，并请求讨论和改进建议。有关本协议
的标准化程度和文档状态，请参阅当前版本的“Internet官方协议标准”（STD 1）。本备忘
录的发布是无限制的。
版权声明
版权所有（C）互联网协会（2006年）。
摘要
使用RTP的实时媒体流在某种程度上可以抵御分组丢失。接收器可以使用实时传输控制协议
（RTCP）的基本机制来报告分组接收统计，从而允许发送者在中期调整其传输行为。这是反馈
和基于反馈的错误修复的唯一手段（除了一些特定于编解码器的机制）。该文档定义了音视频配
置文件（AVP）的扩展，使得接收器能够在统计上向发送者提供更即时的反馈，从而允许实现短
期适应和更有效的基于反馈的修复机制。这种早期反馈配置文件（AVPF）维护了RTCP的AVP带
宽限制，并保留了大型组的可扩展性。
Ott, et al. Standards Track [Page 1]
RFC 4585 RTP/AVPF July 2006
Table of Contents
1. Introduction ....................................................3
1.1. Definitions ................................................3
1.2. Terminology ................................................5
2. RTP and RTCP Packet Formats and Protocol Behavior ...............6
2.1. RTP ........................................................6
2.2. Underlying Transport Protocols .............................6
3. Rules for RTCP Feedback .........................................7
3.1. Compound RTCP Feedback Packets .............................7
3.2. Algorithm Outline ..........................................8
3.3. Modes of Operation .........................................9
3.4. Definitions and Algorithm Overview ........................11
3.5. AVPF RTCP Scheduling Algorithm ............................14
3.5.1. Initialization .....................................15
3.5.2. Early Feedback Transmission ........................15
3.5.3. Regular RTCP Transmission ..........................18
3.5.4. Other Considerations ...............................19
3.6. Considerations on the Group Size ..........................20
3.6.1. ACK Mode ...........................................20
3.6.2. NACK Mode ..........................................20
3.7. Summary of Decision Steps .................................22
3.7.1. General Hints ......................................22
3.7.2. Media Session Attributes ...........................22
4. SDP Definitions ................................................23
4.1. Profile Identification ....................................23
4.2. RTCP Feedback Capability Attribute ........................23
4.3. RTCP Bandwidth Modifiers ..................................27
4.4. Examples ..................................................27
5. Interworking and Coexistence of AVP and AVPF Entities ..........29
6. Format of RTCP Feedback Messages ...............................31
6.1. Common Packet Format for Feedback Messages ................32
6.2. Transport Layer Feedback Messages .........................34
6.2.1. Generic NACK .......................................34
6.3. Payload-Specific Feedback Messages ........................35
6.3.1. Picture Loss Indication (PLI) ......................36
6.3.2. Slice Loss Indication (SLI) ........................37
6.3.3. Reference Picture Selection Indication (RPSI) ......39
6.4. Application Layer Feedback Messages .......................41
7. Early Feedback and Congestion Control ..........................41
8. Security Considerations ........................................42
9. IANA Considerations ............................................43
10. Acknowledgements ..............................................47
11. References ....................................................48
11.1. Normative References .....................................48
11.2. Informative References ...................................48
Ott, et al. Standards Track [Page 2]
RFC 4585 RTP/AVPF July 2006
1. 介绍
使用RTP的实时媒体流在某种程度上可以抵御数据包丢失。RTP [1]提供了所有必要的机制来恢
复发送者处的顺序和时序，以便在接收者处正确地再现媒体流。RTP还提供所有相关接收器的整
体接收质量的连续反馈，从而允许发送器在中途（大约几秒到几分钟）将其编码方案和传输行为
与观察到的网络服务质量（QoS）相适配。但是，除少数特定于有效载荷的机制[6]外，RTP没
有规定允许发送者立即修复媒体流的及时反馈：如通过重传，追溯前向纠错（FEC）控制或对于
某些视频编解码器的特定媒体机制，例如参考图像选择等。
当前可用于RTP的提高错误恢复能力的机制包括音频冗余编码[13]，视频冗余编码[14]，RTP级
FEC [11]，以及为实现更稳定的媒体流传输的一般注意事项[12]。可以主动应用这些机制（从
而增加给定媒体流的带宽）。或者，在具有小往返时间（RTT）的足够小的组中，发送者可以使
用上述机制和/或媒体编码特定方法按需执行修复。请注意，“小组”和“足够小的RTT”都是高度
依赖于应用的。
本文档通过两个修改和补充，为基于[1]和[2]的最小控制规定了音视频会议的改进版RTP配置
文件：首先，为了实现及时反馈，引入早期RTCP消息的概念，以及在小型组播组中实现低延迟
反馈（并防止在大型组中发生反馈消息内爆）的算法。特别考虑了点对点场景。其次，定义少量
通用反馈消息，以及用于编解码器和特定于应用的反馈信息格式，以在RTCP有效载荷中进行传
输。
1.1. 定义
在RTP/RTCP [1]协议文档和”具有最小控制的音视频会议RTP配置文件”[2]中的定义适用于本
文。此外，本文档中使用了以下定义：
Ott, et al. Standards Track [Page 3]
RFC 4585 RTP/AVPF July 2006
早期RTCP模式：
媒体流的接收者通常（但不总是）能够将感兴趣的事件在接近其发生时间内报告给发送者的
操作模式。在早期RTCP模式下，RTCP分组根据本文档中定义的时序规则进行传输。
早期RTCP分组：
早期RTCP分组是指比在遵循参考文档[1]的调度算法允许的时间更早发送的分组，其原因是
接收方观察到的“事件”。早期RTCP分组可以以即时反馈模式和以早期RTCP模式发送。发送
早期RTCP分组在本文档中也称为发送早期反馈。
事件：
媒体流的接收者对发送者（可能）感兴趣的事件的观察，例如丢包、分组接收或者丢帧等等，
因此通过反馈信息手段向发送者报告是有用的。
反馈（FB）消息：
本文档中定义的RTCP消息用于将除了在RTCP接收方报告（RR）中携带的接收方长期状态信
息之外的，在接收方观察到的事件的相关信息传送回媒体流发送方。为清楚起见，反馈消息
在本文档中称为FB消息。
反馈（FB）阈值：
FB阈值表示在立即反馈模式和早期RTCP模式之间的切换点。对于多方会话场景，FB阈值表
示平均每个接收器能够立即将每个事件报告给发送方的最大组大小，即通过早期RTCP分组
而不必等待其安排的定期RTCP时间间隔。该阈值高度依赖于提供的反馈的类型，网络QoS
（例如，分组丢失概率和分布），使用的编解码器和分组方案，会话带宽和应用需求。请注
意，算法不依赖于所有发送方和接收方同意相同的阈值。它仅用于向应用程序设计者提供概
念性指导，不用于任何计算。为清楚起见，术语反馈阈值在本文档中称为FB阈值。
Ott, et al. Standards Track [Page 4]
RFC 4585 RTP/AVPF July 2006
即时反馈模式：
一种操作模式，其中媒体流的每个接收器在统计上能够立即将每个感兴趣的事件报告回媒体
流发送器。在即时反馈模式下，RTCP FB消息根据本文档中定义的时序规则进行传输。
媒体分组：
媒体分组是RTP分组。
常规RTCP模式：
不允许优先传输FB消息的操作模式。相反地，RTCP消息是按照参考文档[1]的规则发送的，
虽然此类RTCP消息可能包含本文档中定义的反馈信息。
常规RTCP分组：
不作为早期RTCP分组发送的RTCP分组。
RTP发送方：
RTP发送方是RTP实体，其发送媒体分组以及RTCP分组，并接收常规分组以及早期RTCP（即，
反馈）分组。注意，RTP发送方是逻辑角色，并且同一RTP实体可以同时充当RTP接收方。
RTP接收方：
RTP接收方是RTP实体，其接收媒体分组以及RTCP分组，并发送常规分组以及早期RTCP（即，
反馈）分组。注意，RTP接收方是逻辑角色，并且相同的RTP实体可以同时充当RTP发送方。
1.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 RFC 2119 [5].
Ott, et al. Standards Track [Page 5]
RFC 4585 RTP/AVPF July 2006
2. RTP和RTCP分组格式和协议行为
2.1. RTP
参考文献[2]中定义的规则也适用于此配置文件，但以下提到的规则除外：
RTCP分组类型：
本备忘录的第6节中注册了两个附加的RTCP分组类型，并定义了传输反馈信息的相应FB消息。
RTCP报告间隔：
本文档描述了影响RTCP报告间隔的三种操作模式（参见本备忘录的第3.2节）。 在常规RTCP
模式中，除了来自同一RTP实体的两个RTCP报告之间的建议最小间隔5秒之外，参考文献[1]
中的所有规则都适用。在立即反馈和早期RTCP模式中，两个RTCP报告之间的最小间隔为5秒
的规则被去除，此外，如果传输的RTCP分组包含FB消息（如本备忘录的第4节中所定义），
本备忘录第3节中指定的规则也适用。
参考文献[1]中提出的规则可以被指定不同参数（例如，分别分配发送者和接收者的RTCP的
带宽份额）的会话描述覆盖。对于使用会话描述协议（SDP）[3]定义的会话，适用参考文献
[4]的规则。
拥塞控制：
在参考文献[2]中详述的相同的基本规则也适用。除此之外，在第7节中，进一步考虑了反馈
的影响以及发送方对FB消息的反应。
2.2. 基础传输协议
RTP旨在用于不可靠的传输协议，包括UDP协议和数据报拥塞控制协议（DCCP）。本节简要介绍
本备忘录中规定的RTCP反馈引入的普通RTP操作之外的细节。
UDP: UDP为点对点和多播通信提供尽力传输数据报。UDP不支持拥塞控制或错误修复。本备忘
录中定义的基于RTCP的反馈能够为有限的错误修复提供最小的支持。由于RTCP反馈不能保
证在足够小的时间尺度上运行（按RTT的顺序），因此RTCP反馈不适合支持拥塞控制。此备
忘录同时处理单播和多播操作。
Ott, et al. Standards Track [Page 6]
RFC 4585 RTP/AVPF July 2006
DCCP: DCCP [19]为单播通信提供了拥塞控制但不可靠的数据报流。使用基于TCP友好速率控
制（TFRC）的[20]拥塞控制（CCID 3），DCCP特别适用于音视频通信。DCCP的确认消息
可以提供关于接收和丢失的数据报（以及因此关于拥塞）的详细反馈报告。
当在DCCP上运行RTP时，在DCCP层执行拥塞控制，不需要RTP层提供额外的机制。此外，
具有RTCP反馈能力的发送方可以利用更频繁的基于DCCP的反馈，因此接收方可以在适当的
情况下避免使用（附加的）通用反馈消息。
3. RTCP反馈规则
3.1. 复合RTCP反馈分组
如本文档所述，两个组件构成基于RTCP的反馈：
o 状态报告包含在发送方报告（SR）和接收报告（RR）数据包中，并作为复合RTCP数据包
（也包括源描述（SDES）和可能的其他消息）的一部分定期发送; 这些状态报告提供了媒体
流最近接收质量的总体情况。
o 本文档中定义的FB消息表示媒体流特定分片的丢失或接收（或者对所接收的数据提供其他形
式的相当即时的反馈）。本文档中新引入了FB消息传输规则。
RTCP FB消息只是某种RTCP分组类型（参见第4节）。因此，可以将多个FB消息组合在单个复合
RTCP分组中，并且它们也可以与其他RTCP分组复合一起发送。
包含本文档中定义的FB消息的复合RTCP数据包必须按照[1]中定义的顺序包含RTCP数据包：
o 如果要根据[1]的第9.1节加密RTCP分组，必须存在可选的加密前缀。
o 必须包含SR或者RR.
Ott, et al. Standards Track [Page 7]
RFC 4585 RTP/AVPF July 2006
o 必须包含SDES, 必须包含CNAME项目; 所有其他SDES项目都是可选的。
o 一条或多条FB消息。
在复合分组中FB消息必须放在参考文献[1]中定义的RR和SDES RTCP分组之后。关于其他相关
的RTCP扩展的顺序未定义。
本文档中使用了两种携带反馈分组的复合RTCP分组：
a) 最小复合RTCP反馈分组
一个最小复合RTCP反馈分组必须仅包含上面列出的强制信息：必要时加密前缀，恰好一个
RR或SR，恰好只有一个存在CNAME项的SDES，以及一个或者多个FB消息。这是为了最小化
传输的传送反馈的RTCP分组的大小，从而最大化可以提供反馈的频率，同时仍然遵守RTCP
带宽限制。
当RTCP FB消息作为早期RTCP分组的一部分发送时，应该使用这种分组格式。此分组类型在
本文档中称为最小复合RTCP分组。
b) （完整）复合RTCP反馈分组
（完整）复合RTCP反馈分组可以包含任何额外数量的RTCP分组（额外的RR，还有SDES项
等）。必须遵守上述订购规则。
只要RTCP FB消息是作为常规RTCP分组的一部分发送，或者是在常规RTCP模式中发送，就
必须使用此分组格式。它还可用于在立即反馈或早期RTCP模式下发送RTCP FB消息。此分
组类型在本文档中称为完整复合RTCP分组。
不包含FB消息的RTCP分组被称为非FB RTCP分组。这些分组必须遵循参考文献[1]中的格式规
则。
3.2. 算法概述
FB消息是RTCP控制流的一部分，因此受RTCP带宽限制。这尤其意味着可能无法将在接收者处观
察到的事件立即报告给发送者。然而，给予发送者的反馈的价值通常随着时间的推移而降低，就
用户在接收端感知的媒体质量和/或实现媒体流修复所需的成本而言。
Ott, et al. Standards Track [Page 8]
RFC 4585 RTP/AVPF July 2006
RTP [1]和常用的RTP配置文件[2]指定发送复合RTCP分组的规则。该文档修改了这些规则，
以便允许应用程序及时报告事件（例如，丢失或接收RTP数据包），并适应使用FB消息的算法。
修改后的RTCP传输算法概述如下：只要不传送FB消息，复合RTCP数据包就按照RTP [1]的规则
发送，除了不强制要求RTCP报告之间的最小间隔为5秒。因此，RTCP报告之间的间隔仅来自RTP
/RTCP实体可用的平均RTCP分组大小和RTCP带宽分配。可选地，可以强行规定常规RTCP分组之
间的最小时间间隔。
如果接收器检测到需要发送FB消息，则它可以比下一常规RTCP报告间隔（遵循上述常规RTCP算
法排期）更早地进行。反馈抑制用于避免多方会话中的反馈内爆：接收器等待（短）随机抖动间
隔，以检查它是否从任何其他接收器看到报告相同事件的相应FB消息。请注意，对于点对点会话，
没有这样的延迟。如果接收到来自另一成员的相应FB消息，则该接收器避免发送FB消息并继续遵
循常规RTCP传输调度。如果接收方尚未看到来自任何其他成员的相应FB消息，则它检查是否允许
发送早期反馈。如果允许发送早期反馈，则接收器将FB消息作为最小复合RTCP分组的一部分发送。
发送早期反馈的权限取决于此接收器先前发送的RTCP分组的类型，以及发送上一个早期反馈消息
的时间。
FB消息也可以作为完整复合RTCP分组的一部分发送，其按照参考文档[1]（除了5秒下限规则）
以规定间隔发送。
3.3. 运作模式
基于RTCP的反馈可以以三种模式之一（图1）操作，如下所述。操作模式仅表示接收方在一般情
况下是否能够及时向发送方报告所有事件; 该模式不影响用于调度FB消息传输的算法。
Ott, et al. Standards Track [Page 9]
RFC 4585 RTP/AVPF July 2006
并且，取决于接收质量和RTP会话的本地监视状态，各个接收器可能不会（也不必）就当前操作
模式达成一致。
a) 立即反馈模式：在此模式下，组大小低于FB阈值，这为每个接收方提供足够的带宽，以便为
预期目的传输RTCP反馈分组。这意味着，对于每个接收方，有足够的带宽通过虚拟的“即时”
RTCP反馈分组报告每个事件。
组大小阈值是许多参数的函数，包括（但不限于）：所使用的反馈类型（例如，ACK与NACK），
带宽，分组速率，分组丢失概率和分布，媒体类型，编解码类型，和（最坏情况下或观察到
的）报告事件的发生频率（例如，接收帧，分组丢失）。
作为粗略估计，令N是接收器每个间隔T报告的平均事件数，B是该特定接收器的RTCP带宽分
数，R是平均RTCP分组大小，那么只要N<=B*T/R，接收器以立即反馈模式操作。
b) 早期RTCP模式：在此模式下，组大小和其他参数不再允许每个接收器对每个值得报告（或需
要报告）的事件做出反应。但是仍然可以充分地给出反馈，以便它允许发送者相应地调整媒
体流传输，从而提高整体媒体播放质量。
使用上述表示法，早期RTCP模式可粗略地表征为以 N > B*T/R 为“下限”。 对上限的估
计更加困难。 使N = 1，即可得到对于给定的R和B，间隔 T = R/B 作为要报告的事件之
间的平均间隔。该信息可用于提示以确定是否采用RTCP分组的早期传输。
c) 常规RTCP模式：当组的大小超出某个值时，根据接收器的个别事件提供反馈不再有用。因为
可以提供反馈的时间有限，还有在大组中发送者没有机会对个体反馈做出反应。
此模式不能指定精确的组大小阈值，但显然，此边界与上面b）项中指定的早期RTCP模式的
上限匹配。
Ott, et al. Standards Track [Page 10]
RFC 4585 RTP/AVPF July 2006
由于本文档中描述的反馈算法可以平滑地扩展，因此不需要参与者之间就组内各个FB阈值的精
确值达成一致。 因此，所有这些模式之间的边界是软的。
ACK
feedback
V
:<- - - - NACK feedback - - - ->//
:
: Immediate ||
: Feedback mode ||Early RTCP mode Regular RTCP mode
:<=============>||<=============>//<=================>
: ||
-+---------------||---------------//------------------> group size
2 ||
Application-specific FB Threshold
= f(data rate, packet loss, codec, ...)
图1：操作模式
如前所述，相应的FB阈值取决于许多技术参数（编解码器，传输，所使用的反馈的类型等），但
也取决于相应的应用场景。第3.6节提供了估算这些阈值的一些有用的提示（但没有精确的计算）。
3.4. 定义和算法概述
每个接收器需要维护以下状态信息（主要取自[1]）。请注意，所有变量（下面的项目h除外）都
是在每个接收器上独立计算的。因此，它们的本地值可能在任何给定的时间点都不同。
a) 令“发送方”为RTP会话中活动的发送器的数量。
b) 令“成员”为当前RTP会话中接收者数量的估计。
c) 令tn和tp为下一个（最后一个）调度的RTCP RR传输的时间，该传输时间在计时器重新考虑
之前计算。
d) 令Tmin为RTCP包之间的最小间隔[1]。与[1]不同，初始Tmin设置为1秒，以允许在发送第
一个RTCP数据包之前进行某些组大小采样。发送第一个RTCP数据包后，Tmin设置为0。
Ott, et al. Standards Track [Page 11]
RFC 4585 RTP/AVPF July 2006
e) 令T_rr为在刚发送了定期调度的RTCP分组之后，接收器将调度其下一个常规RTCP分组的传
输的时间间隔。该值是按照[1]的规则获得的，但是使用本文件中定义的Tmin：T_rr = T
（[1]中定义的“计算间隔”），tn = tp + T。T_rr总是指已计算的T的最后一个值（由
于重新考虑或确定tn）。T_rr在本文档中也称为常规RTCP间隔。
f) 令 t0 为接收器检测到要报告的事件的时间。
g) 令T_dither_max是可以额外延迟RTCP反馈包以防止多方会话发生内爆的最大间隔;
T_dither_max的值是基于T_rr动态计算的（或者可以通过将来要指定的所有RTP接收器共
用的另一种机制来导出）。对于点对点会话（即，具有恰好两个成员而没有预期的组大小改
变的会话，如，单播流会话），T_dither_max被设置为0。
h) 令T_max_fb_delay是一个上限，需要在该时间上限内将对事件的反馈报告给发送方以使其
有价值。此值是特定于应用程序的，并且在本文档中未作任何定义。
i) 令te是排期发送反馈分组的时间。
j) 令T_fd是响应时间t0发生的事件而发送FB消息的实际（随机）延迟。
k) 令allow_early为布尔变量，指示接收器当前是否可以在其下一个定期调度的RTCP间隔tn
之前发送FB消息。此变量用于限制单个接收器发送的反馈。在早期反馈传输之后，
allow_early设置为FALSE，并在下一次常规RTCP传输发生后立即设置为TRUE。
l) 令avg_rtcp_size为[1]中定义的RTCP数据包大小的移动平均值。
m) 令T_rr_interval为常规RTCP数据包之间使用的可选最小间隔。
如果T_rr_interval == 0，则该变量对RTCP反馈算法的整体操作没有任何影响。
如果T_rr_interval != 0，则在最后一次常规RTCP传输的T_rr时间之后
（即，在tp + T_rr），将不调度下一个常规RTCP分组。相反，下一个常规RTCP分组将
被延迟，直到最后一次常规RTCP传输之后至少T_rr_interval，即，它将被安排在
tp + T_rr_interval或之后。注意，T_rr_interval不影响T_rr和tp的计算; 相反，
如果例如它们不包含任何FB消息，则将抑制在tp + T_rr_interval之前调度传输的常规
RTCP分组。 T_rr_interval不影响早期RTCP分组的传输调度。
Ott, et al. Standards Track [Page 12]
RFC 4585 RTP/AVPF July 2006
注意：将T_rr_interval作为独立变量提供意味着根据应用程序的需要最小化常规RTCP反
馈（以及带宽消耗），同时另外允许使用更频繁的早期RTCP分组来提供及时反馈。由于RTCP
带宽减少也会影响早期反馈的频率，因此无法通过降低整体RTCP带宽来实现此目标。
n) 令t_rr_last为最后一个常规RTCP包被调度和发送的时间点，即未由于T_rr_interval
而被抑制。
o) 设T_retention是AVPF实体存储过去FB消息的时间窗口。这是为了确保反馈抑制也适用于
在注意到反馈事件本身之前已从其他实体接收到FB消息的实体。T_retention必须设置为
至少2秒。
p) 令M * Td为接收器被视为无效的超时值（如[1]中所定义）。
在接收器处报告事件的反馈情况如下图2所示。在时间t0，在接收器处检测到这样的事件（例如，
分组丢失）。接收器根据当前带宽，组大小和其他特定于应用程序的参数决定需要发送FB消息
回发送方。
为了避免多方会话中反馈分组的内爆，接收方必须将RTCP反馈分组的传输延迟随机时间量T_fd
（随机数均匀分布在区间[0，T_dither_max]中）。然后必须在te = t0 + T_fd调度复合
RTCP分组的传输。
T_dither_max参数是从常规RTCP间隔T_rr导出的，而T_rr又基于组大小。如果可以确保所
有RTP接收器将使用相同的机制来计算T_dither_max，则未来文档可能指定T_dither_max
的其他计算方式（例如，基于RTT）。
Ott, et al. Standards Track [Page 13]
RFC 4585 RTP/AVPF July 2006
对于某种应用场景，接收器可以确定FB消息的可接受的本地延迟的上限：T_max_fb_delay。
如果先验估计或T_dither_max的实际计算指示可以违反该上限（例如，因为
T_dither_max> T_max_fb_delay），则接收器可以决定不发送任何反馈，因为可实现的增
益被认为是不足的。
如果调度了早期RTCP分组，则必须相应地更新下一个常规RTCP分组的时隙，以便之后具有新的
tn（tn = tp + 2 * T_rr）和新的tp（tp = tp + T_rr）。这是为了确保早期反馈使用
的短期平均RTCP带宽不超过没有早期反馈的带宽。
event to
report
detected
|
| RTCP feedback range
| (T_max_fb_delay)
vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) )
|---+--------+-------------+-----+------------| |--------+--->
| | | | ( ( |
| t0 te |
tp tn
\_______ ________/
/
T_dither_max
图2：早期RTCP调度的事件报告和参数
3.5. AVPF RTCP调度算法
设S0为某一活动发送方（S个发送方中的一个），并且设N为接收方的数量，其中R为这些接收方
之一。
假设R已经证实在当前环境中使用反馈机制是合理的（这是高度特定于应用的，因此在本文档中
没有指定）。
进一步假设T_rr_interval为0，如果没有设置执行常规RTCP分组之间的最小间隔，或者
T_rr_interval设置为某个有意义的值，如应用程序所给出的。那么，该值表示常规RTCP分组
之间的最小间隔。
由此，接收机R必须使用以下规则来传输一个或多个FB消息，以最小或完全符合RTCP分组的形式。
Ott, et al. Standards Track [Page 14]
RFC 4585 RTP/AVPF July 2006
3.5.1. 初始化
最初，R必须设置allow_early = TRUE和t_rr_last = NaN（非数字的意思，即可以与有效
时间值区分的某个无效值）。
此外，除了Tmin的初始值之外，按照[1]初始化RTCP变量。对于点对点会话，初始Tmin设置为0。
对于多方会话，Tmin初始化为1.0秒。
3.5.2. 早期反馈传输
假设R已经调度了最后的常规RTCP RR分组以便在tp发送（并且在tp发送或抑制该分组），并且
已经安排下一次发送时间 tn= tp+T_rr（包括根据[1]的可能重新考虑）。还假设最后的常规
RTCP分组传输发生在t_rr_last。
然后，早期反馈算法包括以下步骤：
1. 在时间t0，R检测到需要发送一个或多个FB消息，例如，因为媒体“单元”需要被ACK或NACK，
并且发现提供反馈信息对于发送者可能是有用的。
2. R首先检查是否已经存在包含一个或多个调度用于传输的FB消息的复合RTCP分组（作为早期
或常规RTCP分组）。
2a) 如果是这样，新的FB消息必须包含在调度的分组中; 等待复合RTCP分组的调度必须保
持不变。这样做时，应该合并可用的反馈信息以产生尽可能少的FB消息。这样就达成了
立即采取的行动。
2b) 如果没有调度复合RTCP分组进行传输，则必须创建一个新的（最小或完整）复合RTCP
分组，并且必须按如下方式选择T_dither_max的最小间隔：
i) 如果会话是点对点会话，那么
T_dither_max = 0.
Ott, et al. Standards Track [Page 15]
RFC 4585 RTP/AVPF July 2006
ii) 如果会话是多方会话，那么
T_dither_max = l * T_rr
其中 l=0.5.
T_dither_max的值可以不同地计算（例如，基于RTT），然后必须在未来的文档中指
定。这样的未来规范必须确保所有RTP接收器使用相同的机制来计算T_dither_max。
上面给出的T_dither_max值是最小值。特定于应用程序的反馈计算可能使得
T_dither_max增加到超过此值。这取决于实施者的决定。
3. 然后，R必须对在t0触发的早期RTCP分组，检查其下一个常规RTCP分组是否将在时间范围内
发出，即，是否 t0 + T_dither_max > tn。
3a) 如果是这样，则不得安排早期RTCP数据分组; 相反，必须将FB消息存储在于tn调度的
常规RTCP分组中。 这样就完成了立即执行的行为。
3b) 否则，执行以下步骤。
4. R务必检查是否允许发送早期RTCP数据分组，即allow_early == TRUE。
4a) 如果allow_early == FALSE，则R必须检查调度下一个常规RTCP分组的时间：
1. 如果tn -t0 <T_max_fb_delay，那么尽管报告迟到，反馈对于发送者仍然有
用。因此，R可以创建一个RTCP FB消息，将其包含在常规RTCP数据包中，以便
在tn进行传输。
2. 否则，R必须丢弃RTCP FB消息。
这样就完成了即将采取的行动。
4b) 如果allow_early == TRUE，则R必须为te = t0 + RND * T_dither_max调度
早期RTCP分组，其中RND是均匀分布在0和1之间的伪随机函数。
Ott, et al. Standards Track [Page 16]
RFC 4585 RTP/AVPF July 2006
5. R必须检测从RTP会话的其他成员发来的FB消息与R想要发送的FB消息之间的重叠。因此，作
为RTP会话的成员，R必须持续监视（最小）复合RTCP分组的到达，并将这些RTCP分组中包
含的每个FB消息存储至少T_retention时间。当按照上面的步骤1到4调度其自身的FB消息
的传输时，R必须检查在 [t0 - T_retention; te] 间隔期间接收到的每个RTCP分组中
存储的和新接收的FB消息，并采取以下行动：
5a) 如果R理解收到的FB消息的语义，并且消息内容是R想要发送的反馈的超集，则R必须丢
弃其自己的FB消息，并且必须将在时间tn（如之前计算的）传输的下一个常规RTCP分
组重新排期。
5b) 如果R理解收到的FB消息的语义，并且消息内容不是R想要发送的反馈的超集，那么R应
该按计划发送它自己的FB消息。如果要发送的反馈信息与收到的反馈信息之间存在重叠，
则发送反馈的数量取决于R：R可以保持不变发送其反馈信息，R也可以消除其自身的反
馈与到目前为止收到的其他会员的反馈之间的任何冗余。
5c) 如果R不理解收到的FB消息的语义，则R可以将其自己的FB消息调度为早期RTCP分组，
或者R可以重新调度tn的下一个常规RTCP分组传输（如前文所计算），并且可以将FB
消息附加到现在定期调度的RTCP消息。
注意：对于5c），接收未知的FB消息可能不会导致特定接收器的反馈抑制。作为结果，
给定事件可能导致M个不同类型的FB消息（它们都是适当的但是相互之间不能理解）被
调度，使得”大型”接收器组可以事实上被划分为最多M个组。在这些M组中的每一组的
成员中，根据5a和5b反馈抑制将会发生，但是不会在组之间发生抑制。结果，发送者
可以接收O(M)个RTCP FB消息。因此，反馈内爆的可能性非常有限。但是，由于组成
同一应用程序的发送方和所有接收方在同一个RTP会话中使用相同的（一组）编解码器，
因此可以安全地假设FB消息的语义差异很小，因此假设M在一般情况下很小。
Ott, et al. Standards Track [Page 17]
RFC 4585 RTP/AVPF July 2006
进一步假设O(M) FB消息在T_dither_max的时间间隔内随机分布，我们发现产生的
有限数量的额外复合RTCP分组 (a) 被认为不会使发送者不堪重负，并且 (b) 应该
被作为全包含补充信息传输。
6. 如参考文献[5]，如果R的FB消息没有被其他接收器FB消息抑制，则当到时间te时，R必须
发送包含其FB消息的（最小）复合分组。然后R必须设置allow_early = FALSE，必须
重新计算tn = tp + 2*T_rr，并且必须将tp设置为前一个tn。一旦到新计算的时间tn，
无论R是否由于T_rr_interval而发送其下一个常规RTCP分组或抑制它，它必须再次设置
allow_early = TRUE。
3.5.3. 定期RTCP传输
必须定期发送完整的复合RTCP分组。这些分组可能包含一个或多个FB消息。常规RTCP分组的
传输安排如下：
如果T_rr_interval == 0，则传输必须遵循本文档第3.2和3.4节中规定的规则，并且必须遵
守第3.5.2节中规定的tn的调整（即，如果已经传输过早期RTCP分组，则跳过一次常规分组的传
输）。根据参考文档[1]，时间到tn时进行定时器重新计算。定时器重新计算之后发送常规RTCP
分组。每当发送或抑制常规RTCP分组时，allow_early必须设置为TRUE，并且必须根据参考文
档[1]更新tp和tn。在第一次传输常规RTCP分组之后，Tmin必须设置为0。
如果T_rr_interval != 0，那么传输时间的计算必须遵循本文第3.2和3.4节中规定的规则，
并且必须遵守第3.5.2节中规定的对tn的调整（即如果已经传输过早期的RTCP分组，则跳过一个
常规分组传输）。根据参考文档[1]，时间到tn时进行定时器重新计算。重新计算计时器后，将
采取以下措施：
1. 如果之前没有发送常规RTCP分组（即，如果t_rr_last == NaN），则必须调度常规RTCP
分组。存储的FB消息可以包含在常规RTCP分组中。在发送定期的分组之后，必须将
t_rr_last设置为tn。Tmin必须设置为0。
Ott, et al. Standards Track [Page 18]
RFC 4585 RTP/AVPF July 2006
2. 否则，临时值T_rr_current_interval计算如下：
T_rr_current_interval = RND*T_rr_interval
RND是一个均匀分布在0.5和1.5之间的伪随机函数。此抖动值用于确定以下备选方案之一：
2a) 如果t_rr_last + T_rr_current_interval <= tn，则必须调度常规RTCP分
组。存储的RTCP FB消息可以包含在常规RTCP分组中。在发送预定的分组之后，必须
将t_rr_last设置为tn。
2b) 如果t_rr_last + T_rr_current_interval> tn，并已经存储RTCP FB消息正在
等待传输，则必须安排在tn传输RTCP分组。该RTCP分组可以是最小或常规RTCP分组
（由实现者决定），并且复合RTCP分组必须包括存储的RTCP FB消息。 t_rr_last
必须保持不变。
2c) 否则（如果t_rr_last + T_rr_current_interval> tn但没有正在等待传输的存
储的RTCP FB消息），则必须抑制复合RTCP分组（即不能调度它）。t_rr_last必须
保持不变。
在上述四种情况（1，2a，2b和2c）中，allow_early必须设置为TRUE（可能在发送常规RTCP
分组之后），并且必须按照[1]的规则更新tp和tn，除了最小5秒规则。
3.5.4. 其他考虑因素
如果T_rr_interval != 0，则必须修改RTP/AVPF实体的超时计算（文档[1]的第6.3.5节），
以使用T_rr_interval而不是Tmin来计算Td，从而使用M*Td来计时输出RTP实体。
每当发送或接收复合RTCP分组 - 最小或完全复合，早期或常规 - 必须相应地更新
avg_rtcp_size变量（参见[1]），并且tn的后续计算必须使用新的avg_rtcp_size。
Ott, et al. Standards Track [Page 19]
RFC 4585 RTP/AVPF July 2006
3.6. 会话组大小考虑因素
本节提供了可以使用各种反馈模式的组大小的一些指导。
3.6.1. ACK 模式
RTP会话必须只有两个成员，且这个组大小不得增长，即它必须是点对点通信。应该在会话描述
中使用单播地址。
对于双方之间的单向和双向通信，2.5％的RTP会话带宽可用于来自接收器的RTCP流量，包括反
馈。对于64 kbit/s的流，RTCP占用1,600 bit/s。如果我们假设平均每个RTCP分组有96个
字节（= 768 bits），则接收方可以每秒向发送方报告2次事件。如果在每个FB消息中收集了
10次事件的确认，则每秒可以确认20次事件。在256 kbit/s时，每秒可报告8次事件; 因此，
可以以更精细的粒度发送ACK（例如，每个FB消息仅符合三个ACK）。
从1 Mbit/s以上，接收器将能够在30 fps视频流中确认每个帧（而不是每个分组！）。
必须定义ACK策略以正常使用这些带宽限制。是否允许在会话中使用ACK，如果是，应该使用哪
种ACK策略，可以通过带外机制来传达，例如，使用SDP的会话描述中的媒体特定属性。
3.6.2. NACK 模式
否定确认（以及表现出类似报告特征的其他类型的反馈）必须用于组大小可能大于2的所有会话。
当然，NACK也可以用于点对点通信。
是否应该考虑使用早期RTCP分组取决于许多参数，包括会话带宽，编解码器，特殊类型的反馈，
以及发送器和接收器的数量。
确定操作模式时最重要的参数，是两个复合RTCP分组之间允许的最小间隔（T_rr），和每个时
间间隔可能需要报告的平均事件数（当然还有它们随时间的分布）。最小间隔可以从可用的RTCP
带宽和RTCP分组的预期平均大小导出。要报告的事件的数量（例如，每秒）可以从分组丢失率
和发送者的分组传输速率导出。根据这两个值，可以计算立即反馈模式允许的组大小。
Ott, et al. Standards Track [Page 20]
RFC 4585 RTP/AVPF July 2006
如第3.3节所述：
设N是接收器每个间隔T报告的平均事件数，B是该特定接收器的RTCP带宽分数，R是平均
RTCP分组大小，然后只要N <= B*T/R，接收器就以立即反馈模式工作。
那么，早期RTCP模式的上限仅取决于可接受的质量降级，即，每个时间间隔允许的未报告事件
数量。
如第3.3节所述：
使用上述表示法，早期RTCP模式可粗略地表征为以 N > B*T/R 为“下限”。对上限的估计
更加困难。设置N = 1，我们为给定的R和B获得间隔 T = R/B 为要报告的事件之间的平
均时间间隔。该信息可用作确定RTCP分组的早期传输是否有用的提示。
示例：如果通过MTU大小约为1,500字节的网络传输30 fps的256 kbit/s视频，则在大多数
情况下，每个帧适配一个分组，从而导致分组速率达到30个分组每秒。如果在网络中发生5％的
分组丢失（均匀分布，接收器之间没有相互依赖性），那么每个接收器平均必须每2秒报告丢失
3个分组。假设一个发送器和三个以上的接收器，这导致3.75％的RTCP带宽分配给接收器，也
就是9.6kbit/s。假设平均复合RTCP分组的大小为120字节，则允许每秒发送10个RTCP分组
或在两秒内发送20个RTCP分组。如果每个接收器需要每2秒报告3个丢失的分组，则推导出如果
要报告所有丢失事件，最大组大小为6-7个接收器。传输早期RTCP分组的规则应该提供足够的
灵活性，以便及时发生大多数报告。
扩展此示例以确定早期RTCP模式的上限可能会导致以下考量：假设底层编码方案和应用程序
（以及容错用户）每两秒允许丢失一次分组而不修复。因此，每个接收器报告的分组数量减少到
每2秒2个，并且组大小增加到10。假设进一步某些数量的分组丢失是相互相关的，则反馈流量进
一步减少，使用早期RTCP模式可以相当好地支持的组大小可以增进到12至16 （甚至20）。请
注意，所有这些考虑都基于统计数据，并且在某些情况下将不成立。
Ott, et al. Standards Track [Page 21]
RFC 4585 RTP/AVPF July 2006
3.7. 决策步骤总结
3.7.1. 一般提示
在考虑是否发送RTCP反馈信息之前，应用程序必须确定此机制是否适用：
1) 应用程序必须决定是否可以应用反馈机制，基于当前分组速率与相关（特定于应用程序的）
最大反馈延迟的比率，以及当前观察到的网络往返时间（如果可用） 。
该决定可以基于（并且随后动态地修改）RTCP接收统计以及带外机制。
2) 应用程序必须决定是否可以应用（和哪些）反馈机制，基于观察到的错误率，分配的带宽，
帧/分组速率，和组大小 。
常规RTCP接收统计信息也为此步骤提供了有价值的输入。
3) 如果应用程序决定发送反馈，则应用程序必须遵循发送早期RTCP分组或包含FB消息的常规
RTCP分组的规则。
4) 发送的RTCP反馈类型不应与发送方从下层传输协议可获得的信息重复。也就是说，如果传
输协议能够提供关于分组是否接收的确认（例如DCCP），则接收器应避免在RTCP层重复相
同的信息（即，避免发送通用NACK）。
3.7.2. 媒体会话属性
通常使用带外机制来描述媒体会话，以在发送者和接收者之间传送传输地址，编解码器等信息。
这种机制包含两层：一个格式用于描述媒体会话，另一个机制用于传输该描述。
Ott, et al. Standards Track [Page 22]
RFC 4585 RTP/AVPF July 2006
在IETF中，会话描述协议（SDP）当前用于描述媒体会话，而诸如SIP，会话通告协议（SAP），
实时流协议（RTSP）和HTTP（以及其他）之类的协议用于传送描述。
媒体会话描述格式可以包括用于指示在该会话中支持RTCP反馈机制以及可以应用哪些反馈机制
的参数。
为此，必须指示配置文件“AVPF”而不是“AVP”。可以定义其他属性以表示支持哪种类型的反馈。
第4节包含SDP协议支持RTCP反馈的语法规范。其他媒体会话描述格式的类似规范超出了本文
档的范围。
4. SDP 定义
本节定义了许多用于描述会话的附加SDP参数。所有这些都被定义为媒体级属性。
4.1. 配置文件标识
在[4]中定义的AV配置文件在会话描述协议（SDP）[3]的环境中称为“AVP”。本文档中指定的
配置文件称为“AVPF”。
除非此会话的描述表明使用“AVPF”配置文件（独占或与其他AV配置文件一起使用），否则不得
为特定媒体会话发送遵循本文档中指定的修改时序规则的反馈信息。
4.2. RTCP 反馈能力属性
定义一个新的特定有效载荷格式SDP属性以表示使用本文档指定的RTCP反馈能力:
“a = rtcp-fb”。“rtcp-fb”属性必须仅用作SDP媒体属性，不得在会话级别提供。
“rtcp-fb”属性必须仅用于指定了“AVPF”的媒体会话。
“rtcp-fb”属性应该用于指示哪个RTCP FB消息可以在该媒体会话中用于指定的有效载荷类型。
有效负载类型通配符（“*”）可用于指示RTCP反馈属性适用于所有有效负载类型。如果支持多种
类型的反馈，和/或应为有效载荷类型的子集指定相同的反馈，则必须使用多个“a = rtcp-fb”
行。
Ott, et al. Standards Track [Page 23]
RFC 4585 RTP/AVPF July 2006
如果没有指定“rtcp-fb”属性，则RTP接收器可以使用为相应媒体类型定义的其他合适的RTCP
反馈分组来发送反馈。RTP接收器绝不能依赖RTP发送器对任何FB消息作出反应。RTP发送方可
能选择忽略某些反馈消息。
如果媒体会话描述中存在一个或多个“rtcp-fb”属性，则包含“rtcp-fb”的媒体会话的RTCP
接收器
o 必须忽略他们不能完全理解语义的所有“rtcp-fb”属性（即，他们不理解“a=rtcp-fb”
行中所有值的含义）;
o 应该使用本媒体会话的“rtcp-fb”属性之中指定的任何RTCP反馈分组提供本文档中指定的
反馈信息；和
o 不得使用除“rtcp-fb”属性行之中列出的FB消息之外的其他FB消息。
当与offer/answer模型[8]结合使用时，询问者可以向其对端提供这样一组AVPF属性。应答
者必须删除它不理解的所有属性，以及它一般不支持或不希望在此特定媒体会话中使用的属性。
应答者不得将反馈参数添加到媒体描述中，并且不得改变这些参数的值。应答是对媒体会话的约
束，并且询问者和应答者必须仅使用以这种方式协商的反馈机制。询问者和应答者可以独立决定
仅发送协商反馈机制子集的RTCP FB消息，但是他们应该对接收到的所有类型的协商FB消息做
出适当的反应。
RTP发送者必须准备接收任何类型的RTCP FB消息，并且必须静默地丢弃所有他们不理解的RTCP
FB消息。
“rtcp-fb”属性的语法如下（反馈类型和可选参数都区分大小写）：
（在下面的ABNF中，fmt，SP和CRLF按照[3]中的定义使用。）
Ott, et al. Standards Track [Page 24]
RFC 4585 RTP/AVPF July 2006
rtcp-fb-句法 = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF
rtcp-fb-pt = "*" ; 通配符：适用于所有格式
/ fmt ; 如SDP规范中所定义
rtcp-fb-val = "ack" rtcp-fb-ack-param
/ "nack" rtcp-fb-nack-param
/ "trr-int" SP 1*DIGIT
/ rtcp-fb-id rtcp-fb-param
rtcp-fb-id = 1*(alpha-numeric / "-" / "_")
rtcp-fb-param = SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
rtcp-fb-ack-param = SP "rpsi"
/ SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
rtcp-fb-nack-param = SP "pli"
/ SP "sli"
/ SP "rpsi"
/ SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
上述语法的文字具有以下语义：
反馈类型 “ack”:
此反馈类型表示支持反馈的肯定确认。
只有在允许媒体会话在第3.6.1节中定义的ACK模式下操作时，才能使用反馈类型 “ack”。
必须提供参数以进一步区分不同类型的肯定确认反馈。
参数 “rpsi” 表示使用6.3.3节中定义的参考图像选择指示反馈。
Ott, et al. Standards Track [Page 25]
RFC 4585 RTP/AVPF July 2006
如果指定参数 “app”，则表示使用应用程序层反馈。 在这种情况下，“app” 之后的附加
参数可用于进一步区分各种类型的应用层反馈。本文档未定义特定于 “app” 的任何参数。
“ack” 的其他参数可以在其他文件中定义。
反馈类型 "nack":
此反馈类型表示支持反馈的否定确认。
不带参数的反馈类型 “nack” 表示使用6.2.1节中定义的一般NACK反馈格式。
本文档中定义了以下三个参数，以便 “nack” 与媒体类型 “video” 结合使用：
o “pli” 表示使用6.3.1节中定义的图像丢失指示反馈。
o "sli" 表示使用第6.3.2节中定义的切片丢失指示反馈。
o "rpsi" 表示使用6.3.3节中定义的参考图片选择指示反馈。
“app” 表示使用应用层反馈。“app” 后面可以提供附加参数以区分不同类型的应用层反
馈。本文档中未定义特定于 “app” 的参数。
“nack” 的其他参数可以在其他文档中定义。
其他反馈类型 <rtcp-fb-id>:
可以在其他文件中定义其他类型的反馈; 为了保持语法对这些情况的可扩展性，引入
rtcp-fb-id作为占位符。新的反馈方案名称必须是唯一的（因此必须在IANA注册）。除了
新名称外，还必须指定其语义，分组格式（如果需要），以及其操作规则。
Ott, et al. Standards Track [Page 26]
RFC 4585 RTP/AVPF July 2006
定期RTCP最小间隔 "trr-int":
属性 “trr-int” 用于指定此媒体会话的两个常规（完全复合）RTCP分组之间的最小间隔
T_rr_interval（以毫秒为单位）。如果未指定 “trr-int”，则假定默认值为0。
请注意，假设有关应用层反馈的更具体信息（如第6.4节中所定义）将作为反馈类型和参数在其
他地方定义。因此，本文件不再对任何类型和参数作出规定。
可以在其他文档中定义其他类型的反馈和参数。
是否发送反馈信息取决于接收者，（如何）使用所提供的反馈取决于发送者。
4.3. RTCP 带宽修改器
[1]和[2]中定义的标准RTCP带宽分配可以被明确定义最大RTCP带宽的带宽修改器覆盖。为了与
SDP一起使用，在[4]中指定了这些修饰符："b=RS:<bw>" 和 "b=RR:<bw>" 可用于给发送者
和接收者分配不同的RTP带宽（以每秒位数为单位） 。[4]的优先规则适用于确定发送者和接收
者使用的实际带宽。
故意在高度不对称链路（例如卫星链路）上运行的应用程序应该使用这种机制来降低高带宽流的
反馈速率，以防止反馈路径的确定性拥塞。
4.4. 例子
例1: 以下会话描述表示由音频和DTMF [18]组成的用于点对点通信的会话，其中DTMF流使用
通用NACK。该会话描述可以包含在SIP INVITE，200 OK或ACK消息中，以指示其发送方
能够并且愿意接收其发送的DTMF流的反馈。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/AVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
Ott, et al. Standards Track [Page 27]
RFC 4585 RTP/AVPF July 2006
这允许发送器和接收器在音频会话中提供DTMF事件的可靠传输。 假设一个接收器具有64kbit/s
的音频流，接收器有2.5％RTCP带宽可用于否定确认流，即每秒250字节或每秒2个RTCP反馈消
息。因此，接收器每秒可以个别传达最多两个丢失的DTMF音频分组。
例2: 以下会话描述表示多播视频会话（使用H.261或H.263 +），视频源接受编解码器和
H.263的参考图像选择两种通用NACK。可以使用会话通告协议（SAP）来传达这样的描述。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
m=audio 49170 RTP/AVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi
发送方可以使用传入的通用NACK作为提示，以尽快发送新的帧内帧（拥塞控制允许）。接收参
考图片选择指示（RPSI）消息允许发送者避免发送大的帧内帧; 相反，它可以继续发送帧间帧，
然而，选择所指示的帧作为新的编码参考。
例3: 以下会话描述定义了与示例2相同的媒体会话，但允许AVP RTP实体和AVPF RTP实体的
混合模式运行（另请参见下一节）。请注意，两个媒体描述都使用相同的地址; 但是，需要
两个 m= 行来传达它们俩适用的相关RTP配置文件信息。
Ott, et al. Standards Track [Page 28]
RFC 4585 RTP/AVPF July 2006
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
m=audio 49170 RTP/AVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
m=video 51372 RTP/AVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi
请注意，这两个 m= 行应该通过一些适当的机制进行分组，以指示两者都是实际传达相同内容的
替代方案。可以实现这一目标的示例框架在[10]中定义。
在此示例中，启用RTCP反馈的接收器将偶尔获得将事件更早地报告给发送方的优势（这可能使整
个组受益）。但是，平均而言，所有RTP接收器都将提供相同数量的反馈。AVP和AVPF实体之间
的互通将在下一节中深入讨论。
5. AVP和AVPF实体的互通和共存
本文档中定义的AVPF配置文件是[2]中定义的AVP配置文件的扩展。两个配置文件遵循相同的基
本规则（包括RTCP的带宽上限和发送器与接收器的带宽分配）。因此，使用两个配置文件中的任
何一个的发送器与接收器可以在一个会话中混合（参见第4.5节中的示例3）。
AVP和AVPF以这样的方式定义：从鲁棒性的观点来看，RTP实体不需要知道相应的使用其他配置
文件的实体：它们不会干扰彼此的功能。但是，所呈现的媒体质量可能会受到影响。
在组合会话中使用时，以下注意事项适用于发送器与接收器。
Ott, et al. Standards Track [Page 29]
RFC 4585 RTP/AVPF July 2006
o AVP实体（发送者和接收者）
AVP发送器将从AVPF接收器接收RTCP反馈分组并忽略这些分组。他们将发现AVPF实体偶尔
以更密的时间间隔发送RTCP消息（例如，违反5秒规则）。由于两种类型的实体都遵守总体
带宽限制，因此它们仍然可以获得RTCP带宽份额。然而，虽然AVP实体受到5秒规则的约束，
但是取决于组大小和会话带宽，AVPF实体可能提供比AVP实体更频繁的RTCP报告。此外，
整体报告可能会略微减少，因为AVPF实体可能会发送更大的复合RTCP分组（由于额外的
RTCP分组）。
如果T_rr_interval用作常规RTCP分组之间的下限，且T_rr_interval足够大（例如，
根据[1]的第6.3.5节，T_rr_interval> M*Td），并且AVPF实体不发送早期RTCP分组，
AVP实体可能意外地将那些AVPF小组成员超时，并因此低估小组的规模。因此，如果媒体会
话可能涉及AVP实体，T_rr_interval不应大于5秒。
o AVPF实体（发送者和接收者）
如果动态计算的T_rr足够小（例如，小于一秒），则AVPF实体可能意外地将AVP组成员超时，
并因此低估组大小。因此，如果媒体会话可能涉及AVP实体，则应该使用T_rr_interval，
并且应该将其设置为5秒。
总之，如果媒体会话可能涉及AVP实体并且要使用T_rr_interval，则T_rr_interval应
该设置为五秒。
o AVPF 发送者
AVPF发送器将仅从AVPF接收器接收反馈信息。如果他们依靠反馈来提供目标媒体质量，则
AVP接收器实现的质量可能不是最理想的。
o AVPF 接收者
只有当媒体会话中的所有发送实体都支持AVPF时，AVPF接收器才应该发送早期RTCP反馈分
组。AVPF接收器可以按照[1]和[2]的时序规则，也可以在混合模式下运行的媒体会话中，
发送反馈信息作为定期调度的复合RTCP分组的一部分。但是，提供反馈的接收器绝不能依赖
发送器对反馈做出的反应。
Ott, et al. Standards Track [Page 30]
RFC 4585 RTP/AVPF July 2006
6. RTCP反馈消息的格式
本节定义了低延迟RTCP反馈消息的格式。 这些消息分为以下三类：
- 传输层FB消息
- 特定有效负载的FB消息
- 应用层FB消息
传输层FB消息旨在传输通用反馈信息，即独立于特定编解码器或使用中的应用的信息。预计信
息将在传输层/RTP层生成和处理。目前，仅定义了通用否定确认（NACK）消息。
特定于有效载荷的FB消息传输特定于某种有效载荷类型的信息，并且将在编解码“层”处生成并
作用。本文档定义了与所有特定于有效负载的FB消息一起使用的公共标头。特定消息的定义留
给RTP有效载荷格式规范或其他反馈格式文档。
应用层FB消息提供了一种方法，可以透明地将反馈从接收方传送到发送方的应用程序。这种消
息中包含的信息不是预期在传输层/RTP层或者编解码器层上起作用的。要在两个应用程序实例
之间交换的数据通常在应用程序协议规范中定义，因此可以由应用程序识别，因此不需要额外
的外部信息。因此，该文档仅定义了与所有应用层FB消息一起使用的公共标头。从协议的角度
来看，应用层FB消息被视为特定于有效负载的FB消息的特殊情况。
注意：在媒体发送方正确处理某些FB消息可能需要发送方知道FB消息所指的有效负载类型。
大多数情况下，这个信息很可能可以从仅使用单一有效载荷类型媒体流中获得。然而，如果
同时使用多个编解码器（例如，同时使用音频和DTMF）或者当发生编解码器改变时，有效
载荷类型信息可能需要作为FB消息的一部分被明确地传送。这适用于所有特定于有效负载
FB消息以及应用层FB消息。由FB消息的规范来定义如何传输有效载荷类型信息。
Ott, et al. Standards Track [Page 31]
RFC 4585 RTP/AVPF July 2006
本文档定义了两个传输层FB消息和三个特定于（视频）有效负载的FB消息，以及应用层FB消
息的单独容器。其他传输层和特定于有效负载的FB消息可以在其他文档中定义，并且必须通过
IANA注册（参见第9节“IANA注意事项”）。
上述RTCP FB消息类型的一般语法和语义在以下小节中描述。
6.1. 反馈消息的通用分组格式
所有FB消息必须使用如图3所示的通用分组格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
图3：反馈消息的通用分组格式
字段V，P，SSRC和length在RTP规范[2]中定义，各自的含义总结如下：
版本 (V): 2 bits
该字段标识RTP版本。目前的版本是2。
填充 (P): 1 bit
如果置位，则填充位指示该分组在末尾包含不属于控制信息的一部分但包括在长度字段中的
附加填充8位字节。
Ott, et al. Standards Track [Page 32]
RFC 4585 RTP/AVPF July 2006
反馈消息类型 (FMT): 5 bits
此字段标识FB消息的类型，并根据类型（传输层，特定于有效负载或应用程序层反馈）进行
解释。三种反馈类型中的值在下面的相应部分中定义。
有效载荷类型 (PT): 8 bits
T这是RTCP分组类型，将分组标识为RTCP FB消息。 IANA定义了两个值：
Name | Value | 简要描述
----------+-------+------------------------------------
RTPFB | 205 | 传输层FB消息
PSFB | 206 | 有效负载特定的FB消息
长度: 16 bits
该分组的长度为32位word减去1，包括协议头和填充字节。这与RTCP发送器和接收器报告中
使用的长度字段的定义一致[3]。
分组发送方的SSRC: 32 bits
此分组发送者的同步源标识符。
媒体来源的SSRC: 32 bits
该段反馈信息所涉及的媒体源的同步源标识符。
反馈控制信息 (FCI): 可变长度
以下三节定义了FB消息中可以包含哪些附加信息，用于每种类型的反馈：传输层反馈，特定
于有效负载的反馈，或应用层反馈。请注意，可以在其他文档中指定其他FCI内容。
每个RTCP反馈分组必须在FCI字段中包含至少一个FB消息。第6.2和6.3节定义了每种FCI类型，
无论是否可以将多个FB消息压缩到单个FCI字段中。如果是这种情况，它们必须是相同的类型，
即相同的FMT。如果需要传送多种类型的反馈消息，即几个FMT，则必须生成若干RTCP FB消息，
并且应该在同一复合RTCP分组中连接。
Ott, et al. Standards Track [Page 33]
RFC 4585 RTP/AVPF July 2006
6.2. 传输层反馈消息
传输层FB消息由值RTPFB标识为RTCP消息类型。
本文档中定义了单个通用传输层FB消息：通用NACK。它通过FMT参数识别如下：
0: 未分配
1: 通用 NACK
2-30: 未分配
31: 保留用于将来扩展标识符号空间
以下小节定义了此类FB消息的FCI字段的格式。可以在将来进一步定义通用反馈消息。
6.2.1. 通用 NACK
通用NACK消息由 PT=RTPFB 和 FMT=1 标识。
FCI字段必须至少包含一个，并且可以包含多个通用NACK。
通用NACK用于指示一个或多个RTP分组的丢失。通过分组标识符和比特掩码来识别丢失的分组。
如果底层传输协议能够向发送方提供类似的反馈信息，则不应使用通用NACK反馈（例如，可能是
使用DCCP的情况）。
反馈控制信息（FCI）字段具有以下语法（图4）:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图4：通用NACK消息的语法
分组标识 (PID): 16 bits
PID字段用于表示丢失的分组。PID字段指的是丢失分组的RTP序列号。
Ott, et al. Standards Track [Page 34]
RFC 4585 RTP/AVPF July 2006
后继丢失分组的位掩码 (BLP): 16 bits
BLP允许在PID指示的RTP分组之后立即报告16个RTP分组中的任何一个的丢失。BLP的定
义与[6]中给出的定义相同。将BLP的最低有效位表示为位1，将其最高有效位表示为位16，
如果接收器未接收到RTP分组序号(PID+i) (模2^16)，则将位掩码的位i设置为1表示此
分组丢失; 否则，将位i 设置为0。请注意，发送方不得因为其位掩码设置为0而假设接收
方已收到数据包。例如，BLP的最低有效位将设置为1，如果PID对应的和后续分组丢失。
然而，发送者不能仅仅因为BLP的位2到位15是0而推断PID+2到PID+16分组已经被接收;
此时所有发送者都知道是，接收者还没有报告它们丢失。
FB消息的长度必须设置为 2+n，其中n是FCI字段中包含的通用NACK的数量。
通用NACK消息通过序列号隐式地引用有效载荷类型。
6.3. 有效负载反馈消息
有效负载特定的FB消息由值 PT=PSFB 标识为RTCP消息类型。
到目前为止，定义了三个特定于有效负载的FB消息以及应用层FB消息。它们通过如下FMT参数
识别：
0: 未分配
1: 图像丢失指示 (Picture Loss Indication, PLI)
2: 切片丢失指示 (Slice Loss Indication, SLI)
3: 参考图片选择指示 (Reference Picture Selection Indication, RPSI)
4-14: 未分配
15: 应用层FB (Application layer FB, AFB) message
16-30: 未分配
31: 保留用于将来扩展序列号空间
以下小节定义了特定于有效负载的FB消息的FCI格式，第6.4节定义了应用层FB消息的FCI格式。
Ott, et al. Standards Track [Page 35]
RFC 4585 RTP/AVPF July 2006
6.3.1. 图像丢失指示 (Picture Loss Indication, PLI)
PLI FB消息由 PT=PSFB 和 FMT=1 标识。
FCI字段中必须只包含一个PLI。
6.3.1.1. 语义
利用图像丢失指示消息，解码器通知编码器属于一个或多个图像的未定义数量的编码视频数据丢
失。当与基于图片间预测的任何视频编码方案结合使用时，接收到PLI的编码器知道预测链可能
被破坏。发送方可以通过发送一个帧内图像来对PLI作出反应以实现重新同步（该消息相当类似
于[6]中定义的FIR消息）; 但是，发送方必须考虑第7节中描述的拥塞控制，这可能会限制其
发送帧内帧的能力。
其他RTP有效载荷规范（如RFC 2032 [6]）已经为某些编解码器定义了一些反馈机制。支持两
种方案的应用程序在发送反馈时必须使用本规范中定义的反馈机制。出于向后兼容性的原因，如
果有效载荷格式需要，这样的应用程序也应该能够接收并响应在相应RTP有效载荷格式中定义的
反馈方案。
6.3.1.2. 消息格式
PLI不需要参数。因此，长度字段必须是2，并且不得有任何反馈控制信息。
此FB消息的语义与有效负载类型无关。
6.3.1.3. 时序规则
时序遵循第3节中概述的规则。在采用PLI和其他类型反馈的系统中，建议PLI遵循常规的RTCP
RR时序规则，因为PLI不像其他FB类型那样具有延迟关键性。
6.3.1.4. 备注
PLI messages typically trigger the sending of full intra-pictures.
Intra-pictures are several times larger then predicted (inter-)
pictures. Their size is independent of the time they are generated.
In most environments, especially when employing bandwidth-limited
links, the use of an intra-picture implies an allowed delay that is a
Ott, et al. Standards Track [Page 36]
RFC 4585 RTP/AVPF July 2006
PLI消息通常触发发送完整的帧内图像。帧内图像比预测（帧间）图像大几倍。它们的大小与它
们产生的时间无关。在大多数环境中，特别是当采用带宽受限的链路时，使用帧内图像意味着允
许延迟是典型帧持续时间的几倍。例如：如果发送帧率是10 fps，并且假设帧内图像是帧间图
像的10倍，则必须接受整整一秒的延迟。在这样的环境中，发送FB消息不需要特别短的延迟。
因此，如[2]所示设置Tmin=0等待RTCP时序规则允许的下一个可能的时隙，不会对系统性能产
生负面影响。
6.3.2. 切片丢失指示 (Slice Loss Indication, SLI)
SLI FB消息由 PT=PSFB 和 FMT=2 标识。
FCI字段必须包含至少一个并且可以包含多个SLI。
6.3.2.1. 语义
利用切片丢失指示，解码器可以通知编码器它已经以扫描顺序检测到一个或多个连续宏块的丢失
或损坏（见下文）。该FB消息不得用于具有非均匀、动态可变宏块大小的视频编解码器，例如
启用Annex Q的H.263。在这种情况下，编码器不能保证总能识别损坏的空间区域。
6.3.2.2. 格式
切片丢失指示使用一个额外的FCI字段，其内容如图6所示。FB消息的长度必须设置为 2+n，其
中n是FCI字段中包含的SLI数。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First | Number | PictureID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图6：切片丢失指示（SLI）的语法
First: 13 bits
第一个丢失宏块的宏块（MB）地址。进行MB编号，使图片左上角的宏块为是宏块编号1，并
且宏块的编号按光栅扫描顺序从左到右然后从上到下增加（如果在图片中总共有N个宏块，
右下角的宏块被认为是宏块编号N）。
Ott, et al. Standards Track [Page 37]
RFC 4585 RTP/AVPF July 2006
Number: 13 bits
丢失宏块的数量，按照上面讨论的扫描顺序。
PictureID: 6 bits
编解码器特定标识符的6个最低有效位，用于引用已发生宏块丢失的图像。对于许多视频编
解码器，PictureID与时间参考相同。
该FB消息的适用性仅限于一小组视频编解码器; 因此，未提供明确的有效载荷类型信息。
6.3.2.3. 时间规则
当指示未及时传输时，使用切片丢失指示的算法的效率大大降低。运动补偿放大了未报告为已损
坏的已损坏像素。因此，强烈建议使用第3节中讨论的算法。
6.3.2.4. 备注
术语“切片”按其在MPEG-1中的意义在此处定义并使用——按扫描顺序排列的一定数量的连续宏块。
最新的视频编码标准有时对术语切片（Slice）有不同的理解。例如，在H.263（1998）中，存
在称为“矩形切片”的概念。一个矩形切片的丢失可能导致必须发送多于一个SLI以便精确地识别
丢失/损坏的MB（宏块）的区域。
FCI的第一个字段将图像的第一个宏块定义为1，而不像人们可能猜测的那样将其定义为0。这样
做是为了使该规范与ITU-T Rec. H.245 [24]中可用的可比机制保持一致。图像中的最大宏
块数（2 ** 13或8192）对应于大多数ITU-T和ISO/IEC视频编解码器的最大图像尺寸。如果
未来的视频编解码器提供更大的图像尺寸和/或更小的宏块尺寸，则必须定义补充的FB消息。时
间参考字段的6个最低有效位被认为足以指示发生丢失的图像。
对SLI的反应不是本规范的一部分。对SLI作出反应的一种典型方式是对受影响的空间区域使用
帧内刷新。
Ott, et al. Standards Track [Page 38]
RFC 4585 RTP/AVPF July 2006
报告的算法是跟踪受运动补偿影响的区域，以便允许将帧内宏块传输到所有这些区域，而不管
FB的时间安排如何（见H.263（2000）附录I [17]和[15]）。尽管使用这些算法时FB的时间
不那么重要，但必须注意到这些算法可以纠正图像的大部分，因此必须在FB延迟的情况下传输
更高的数据量。
6.3.3. 参考图片选择指示（RPSI）
RPSI FB消息由 PT=PSFB 和 FMT=3 标识。
FCI字段中必须只包含一个RPSI。
6.3.3.1. 语义
诸如 MPEG-4 visual version 2 [16]或H.263版本2 [17]的现代视频编码标准允许使用
比最近的参考图像更早的参考图像进行预测编码。通常，维持一个参考图像的先进先出队列。如
果编码器已经了解到编解码器同步性的丢失，则可以使用已知正确的参考图像。由于该参考图像
的使用在时间上比通常更久，所得到的预测编码图像将使用更多比特。
MPEG-4和H.263都定义了RPSI消息的“有效载荷”的二进制格式，其包括诸如损坏图像的时间ID
和损坏区域的大小之类的信息。该比特串通常很小（几十比特），具有可变长度和自包含性，即
包含执行参考图像选择所需的所有信息。
MPEG-4和H.263都允许使用具有正反馈信息的RPSI。也就是报告解码无错误的图像（或切片）。
请注意，在多方会话中不得使用任何形式的正反馈（随RTCP间隔报告各参考图像的正反馈预计不
会有太大用处）。
Ott, et al. Standards Track [Page 39]
RFC 4585 RTP/AVPF July 2006
6.3.3.2. 格式
RPSI消息的FCI遵循图7中描述的格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB |0| Payload Type| Native RPSI bit string |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined per codec ... | Padding (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图7：参考图片选择指示（RPSI）的语法
PB: 8 bits
将RPSI消息的长度填充到32位的倍数需要的未使用位数。
0: 1 bit
传输时必须设置为零，在接收时忽略。
有效负载类型: 7 bits
指示RTP有效载荷类型，原生RPSI位串必须在其环境中解释。
原生RPSI位串: 长度可变
由视频编解码器原生定义的RPSI信息。
填充位: #PB bits
设置为零的多个位，以将RPSI消息的内容填充到下一个32位边界。填充位的数量必须由PB
字段指示。
6.3.3.3. 时序规则
与使用SLI的算法相比，RPSI对延迟更为重要。这是因为RPSI消息越旧，编码器必须花费更多
的比特来重新建立编码器与解码器的同步。有关某些比特率/帧速率/丢失率情况下RPSI开销的
一些信息，请参见[15]。
因此，通常应使用第3节的算法尽快发送RPSI消息。
Ott, et al. Standards Track [Page 40]
RFC 4585 RTP/AVPF July 2006
6.4. 应用层反馈消息
应用层FB消息是特定于有效负载的消息的特殊情况，由 PT=PSFB 和 FMT=15 标识。除非应
用层FB消息结构本身允许堆叠（例如，通过固定大小或显式长度指示符），否则FCI字段中必须
包含恰好一个应用层FB消息。
这些消息用于将应用程序定义的数据直接从接收方传输到发送方的应用程序。FB消息不识别传输
的数据。因此，应用程序必须能够识别消息的有效负载。
通常，应用程序定义它们自己的消息集，例如，MPEG-4 [16]中的NEWPRED消息（根据RFC
3016 [23]在RTP数据包中携带）或H.263/附件N，U [17]中的FB消息（按照RFC 2429 [14]
进行打包）。这些消息不需要RTCP消息中的任何其他信息。因此，应用消息简单地如下放入FCI
字段中，并相应地设置长度字段。
应用程序消息 (FCI): 可变长度
该字段包含应从接收器传输到源的原始应用程序消息。格式取决于应用程序。 该字段的长度
是可变的。如果应用程序数据不是32位对齐，则必须添加填充位和字节以实现32位对齐。填
充的标识取决于应用层，并且未在本规范中定义。
应用层FB消息规范必须定义是否需要在某个编解码器的上下文中特别地解释消息（由RTP有效载
荷类型标识）。如果正确处理需要引用有效载荷类型，则应用层FB消息规范必须定义一种将有效
载荷类型信息作为应用层FB消息本身的一部分进行通信的方法。
7. 早期反馈和拥塞控制
在前面的部分中，定义了FB消息，以及发送这些消息的时间规则。对收到的反馈做出反应的方式，
取决于使用反馈机制的应用程序，因此超出了本文档的范围。但是，所有应用程序，当在尽力而
为的网络环境中操作时，在[1]和[2]中定义的媒体流上存在对（TCP友好的）拥塞控制的共同要
求。
Ott, et al. Standards Track [Page 41]
RFC 4585 RTP/AVPF July 2006
应当注意，RTCP反馈本身不足以用于拥塞控制目的，因为它可能在比其他传输层反馈机制（通
常以RTT的顺序操作）慢得多的时间尺度下操作。因此，需要额外的机制来执行适当的拥塞控制。
与竞争TCP连接合理公平地共享可用带宽的拥塞控制算法，例如TFRC [7]，必须在RTP发送方
和媒体会话的能力范围之内，用于确定媒体流的数据速率，如果RTP/AVPF会话在尽力而为的环
境中传输。
8. 安全考虑因素
以建议的有效载荷格式传输信息的RTP分组受RTP规范[1]和RTP/AVP配置文件规范[2]中讨论
的安全考虑因素的影响。此配置文件未指定任何其他安全服务。
此配置文件修改了RTCP的时序行为，并消除了5秒的最小RTCP间隔，并允许接收器提供更早的
反馈。相关联的RTP会话的组成员（可能假装代表大量实体）可能通过发送大量RTCP分组来干
扰RTCP的操作，从而减少可用于常规RTCP报告以及早期FB消息的RTCP带宽。（请注意，实体
不必是多播组的成员就会产生这些影响。）同样，恶意成员可能会发送非常大的RTCP消息，从
而增加avg_rtcp_size变量并减少可用的有效RTCP带宽。
如果接收到未知的RTCP反馈分组，则可以抑制反馈信息。这引入了这样的风险，恶意组成员可
以通过简单地发送具有任何接收器（因此它们将抑制反馈）或发送者（因此不会采取修复操作）
都无法识别的、内容随机的特定有效负载RTCP反馈分组，来减少早期反馈。
恶意组成员还可以在反馈信息中报告任意高的丢失率，以使发送方限制数据传输并增加冗余信
息量，或采取其他措施来处理假装的丢包（例如，发送更少帧或降低音视频质量）。这可能导
致再现媒体流的质量下降。
Ott, et al. Standards Track [Page 42]
RFC 4585 RTP/AVPF July 2006
最后，恶意组成员可以充当大量的组成员，从而人为地获得大部分早期反馈带宽，并降低其他
组成员的反应——甚至可能导致他们不再以立即模式或早期反馈模式运作，从而破坏此配置文件
的整个目的。
在观察奇怪的报告行为时，发送者和接收者应该谨慎行事。对于来自一个或几个接收器的过度
故障报告，发送者可以决定在调整其媒体流的传输行为时不再考虑该反馈。在任何情况下，发
送者和接收者应该仍然遵守最大RTCP带宽，但要确保它们至少能够发送定期调度的RTCP分组。
发送者应该在遇到奇怪的报告行为时仔细考虑如何调整传输带宽；即使忽略了可疑的反馈，他
们也不能增加传输带宽。
通过验证所有RTCP消息，可以避免通过使用错误的RTCP分组（常规分组和早期分组）进行的攻
击。这可以通过将AVPF配置文件与[22]中定义的安全RTP配置文件一起使用来实现；作为必须
条件，正在指定这两个配置文件（名为SAVPF）的适当组合[21]。注意，当采用组认证（与源
认证相反）时，上述攻击可以由拥有正确密钥资料的恶意或故障组成员执行。
9. IANA注意事项
以下联系信息应被用于所有此处包含的注册：
联系人: Joerg Ott
电子邮件:jo@acm.org
电话:+358-9-451-2460
反馈简档作为对具有最小控制的音视频会议的简档的扩展已经为会话描述协议（特别是类型
“proto”）注册为：RTP/AVPF。
Ott, et al. Standards Track [Page 43]
RFC 4585 RTP/AVPF July 2006
SDP 协议 ("proto"):
名称: RTP/AVPF
完整形式: 基于RTCP的反馈扩展RTP简档
名称类型: proto
属性类型: 仅限媒体级别
目的: RFC 4585
参考: RFC 4585
SDP 属性 ("att-field"):
Attribute name: rtcp-fb
Long form: RTCP Feedback parameter
Type of name: att-field
Type of attribute: Media level only
Subject to charset: No
Purpose: RFC 4585
Reference: RFC 4585
Values: See this document and registrations below
已为 rtcp-fb 属性设置了一个新的记录，创建了以下几个最初注册：
ack，nack，trr-int和本文档中定义的app。
属性 rtcp-fb 的初始值注册
Value name: ack
Long name: Positive acknowledgement
Reference: RFC 4585.
Value name: nack
Long name: Negative Acknowledgement
Reference: RFC 4585.
Value name: trr-int
Long name: Minimal receiver report interval
Reference: RFC 4585.
Value name: app
Long name: Application-defined parameter
Reference: RFC 4585.
可以按先到先得的原则注册更多的条目。每个新的注册都需要指明参数名称和可能的附加参数的
语法。对于每个新的注册，必须存在永久、稳定且可公开访问的文档，指定其注册参数的语义、
其参数的语法和语义，以及相应的反馈分组格式（如果需要）。适用[3]的通用注册流程。
Ott, et al. Standards Track [Page 44]
RFC 4585 RTP/AVPF July 2006
为了与 ack 和 nack 一起使用，已经建立了一个联合子记录，它最初注册了以下值：
属性值 ack 和 nack 的初始值注册：
Value name: sli
Long name: Slice Loss Indication
Usable with: nack
Reference: RFC 4585.
Value name: pli
Long name: Picture Loss Indication
Usable with: nack
Reference: RFC 4585.
Value name: rpsi
Long name: Reference Picture Selection Indication
Usable with: ack, nack
Reference: RFC 4585.
Value name: app
Long name: Application layer feedback
Usable with: ack, nack
Reference: RFC 4585.
可以按先到先得的原则注册更多的条目。每个注册需要指明参数名称，可能的附加参数的语法，
以及参数是否适用于 ack 或 nack 反馈之一，或者同时适用于两者，或某些不同的rtcp-fb
属性参数。对于每个新注册，必须存在永久、稳定且可公开访问的文档，其指定注册参数的语
义，其参数的语法和语义，以及相应的分组格式（如果需要）。适用[3]的通用注册流程。
有两种RTCP控制分组类型：用于传输层FB消息类（RTPFB），和用于特定于有效负载的FB消息
类（PSFB）。根据第6节，RTCP注册表中已添加了 RTPFB=205 和 PSFB=206。
Ott, et al. Standards Track [Page 45]
RFC 4585 RTP/AVPF July 2006
RTP RTCP Control Packet types (PT):
Name: RTPFB
Long name: Generic RTP Feedback
Value: 205
Reference: RFC 4585.
Name: PSFB
Long name: Payload-specific
Value: 206
Reference: RFC 4585.
由于AVPF定义了额外的RTCP有效载荷类型，因此相应地扩展了对应的“保留”RTP有效载荷类型
空间（72-76，如[2]中所定义）。
已为 RTPFB 有效载荷类型和 PSFB 有效载荷类型的 FMT 值设置了新的子注册表，最初创建
了以下注册：
在 RTPFB 范围内，最初注册以下两种格式（FMT）值：
Name: Generic NACK
Long name: Generic negative acknowledgement
Value: 1
Reference: RFC 4585.
Name: Extension
Long name: Reserved for future extensions
Value: 31
Reference: RFC 4585.
在 PSFB 范围内，最初注册以下五种格式（FMT）值：
Name: PLI
Long name: Picture Loss Indication
Value: 1
Reference: RFC 4585.
Name: SLI
Long name: Slice Loss Indication
Value: 2
Reference: RFC 4585.
Ott, et al. Standards Track [Page 46]
RFC 4585 RTP/AVPF July 2006
Name: RPSI
Long name: Reference Picture Selection Indication
Value: 3
Reference: RFC 4585.
Name: AFB
Long name: Application Layer Feedback
Value: 15
Reference: RFC 4585.
Name: Extension
Long name: Reserved for future extensions.
Value: 31
Reference: RFC 4585.
可以遵从RFC 2434 [9]中定义的“规范要求”的规则注册更多条目。每个注册需要指明FMT值，
如果要在FCI字段存放的特定FB消息，并且不论是否可以在单个FCI字段中堆叠多个FB消息。对
于每个新的注册条目，必须存在永久、稳定且可公开访问的文档，该文档指定已注册参数的语义，
以及关联FB消息（如果有）的语法和语义。适用[3]的通用注册程序。
10. 致谢
本文档是IETF的音视频传输（AVT）工作组的作品。作者要感谢Steve Casner和Colin
Perkins的意见和建议，以及他们对众多问题的回应。作者还要特别感谢Magnus Westerlund
的评论和他的宝贵建议，以及Shigeru Fukunaga对FB消息格式和语义的贡献。
我们还要感谢Andreas Buesching和Panasonic的工作人员进行模拟以及首次独立实现反馈
配置文件。
Ott, et al. Standards Track [Page 47]
RFC 4585 RTP/AVPF July 2006
11. 参考
11.1. 规范性参考文献
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[4] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 Video
Streams", RFC 2032, October 1996.
[7] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly
Rate Control (TFRC): Protocol Specification", RFC 3448, January
2003.
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
11.2. 信息参考
[10] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.
[11] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998.
[12] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
Ott, et al. Standards Track [Page 48]
RFC 4585 RTP/AVPF July 2006
[13] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data", RFC 2198, September 1997.
[14] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, C.,
Newell, D., Ott, J., Sullivan, G., Wenger, S., and C. Zhu, "RTP
Payload Format for the 1998 Version of ITU-T Rec. H.263 Video
(H.263+)", RFC 2429, October 1998.
[15] B. Girod, N. Faerber, "Feedback-based error control for mobile
video transmission", Proceedings IEEE, Vol. 87, No. 10, pp.
1707 - 1723, October, 1999.
[16] ISO/IEC 14496-2:2001/Amd.1:2002, "Information technology -
Coding of audio-visual objects - Part2: Visual", 2001.
[17] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate
Communication", November 2000.
[18] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[19] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006.
[20] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly
Rate Control (TFRC): Protocol Specification", RFC 3448, January
2003.
[21] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-
based Feedback (RTP/SAVPF)", Work in Progress, December 2005.
[22] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[23] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H.
Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Streams",
RFC 3016, November 2000.
[24] ITU-T Recommendation H.245, "Control protocol for multimedia
communication", May 2006.
Ott, et al. Standards Track [Page 49]
RFC 4585 RTP/AVPF July 2006
Authors' Addresses
Joerg Ott
Helsinki University of Technology (TKK)
Networking Laboratory
PO Box 3000
FIN-02015 TKK
Finland
EMail: jo@acm.org
Stephan Wenger
Nokia Research Center
P.O. Box 100
33721 Tampere
Finland
EMail: stewe@stewe.org
Noriyuki Sato
Oki Electric Industry Co., Ltd.
1-16-8 Chuo, Warabi-city, Saitama 335-8510
Japan
Phone: +81 48 431 5932
Fax: +81 48 431 9115
EMail: sato652@oki.com
Carsten Burmeister
Panasonic R&D Center Germany GmbH
EMail: carsten.burmeister@eu.panasonic.com
Jose Rey
Panasonic R&D Center Germany GmbH
Monzastr. 4c
D-63225 Langen, Germany
EMail: jose.rey@eu.panasonic.com
Ott, et al. Standards Track [Page 50]
RFC 4585 RTP/AVPF July 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Ott, et al. Standards Track [Page 51]