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
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
Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件
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) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups.
使用RTP的实时媒体流在某种程度上具有抗数据包丢失的弹性。接收机可以使用实时传输控制协议（RTCP）的基本机制来报告分组接收统计数据，从而允许发送方在中期内调整其传输行为。这是反馈和基于反馈的错误修复的唯一方法（除了一些特定于编解码器的机制）。本文件定义了视听配置文件（AVP）的扩展，该扩展使接收者能够向发送者提供统计上更直接的反馈，从而允许实施短期自适应和基于反馈的高效修复机制。此早期反馈配置文件（AVPF）维护RTCP的AVP带宽约束，并保留对大型组的可扩展性。
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
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
Real-time media streams that use RTP are, to some degree, resilient against packet losses. RTP [1] provides all the necessary mechanisms to restore ordering and timing present at the sender to properly reproduce a media stream at a recipient. RTP also provides continuous feedback about the overall reception quality from all receivers -- thereby allowing the sender(s) in the mid-term (in the order of several seconds to minutes) to adapt their coding scheme and transmission behavior to the observed network quality of service (QoS). However, except for a few payload-specific mechanisms [6], RTP makes no provision for timely feedback that would allow a sender to repair the media stream immediately: through retransmissions, retroactive Forward Error Correction (FEC) control, or media-specific mechanisms for some video codecs, such as reference picture selection.
使用RTP的实时媒体流在某种程度上具有抗数据包丢失的弹性。RTP[1]提供了所有必要的机制来恢复发送方的顺序和定时，以便在接收方正确地再现媒体流。RTP还提供关于所有接收器的总体接收质量的连续反馈，从而允许发送方在中期（几秒到几分钟的顺序）根据观察到的网络服务质量（QoS）调整其编码方案和传输行为。然而，除了一些特定于有效负载的机制[6]，RTP没有提供允许发送者立即修复媒体流的及时反馈：通过重传、追溯前向纠错（FEC）控制，或某些视频编解码器的特定于媒体的机制，例如参考图片选择。
Current mechanisms available with RTP to improve error resilience include audio redundancy coding [13], video redundancy coding [14], RTP-level FEC [11], and general considerations on more robust media streams transmission [12]. These mechanisms may be applied proactively (thereby increasing the bandwidth of a given media stream). Alternatively, in sufficiently small groups with small round-trip times (RTTs), the senders may perform repair on-demand, using the above mechanisms and/or media-encoding-specific approaches. Note that "small group" and "sufficiently small RTT" are both highly application dependent.
RTP目前可用于提高容错能力的机制包括音频冗余编码[13]、视频冗余编码[14]、RTP级FEC[11]以及关于更健壮的媒体流传输的一般考虑[12]。可以主动应用这些机制（从而增加给定媒体流的带宽）。或者，在具有小往返时间（rtt）的足够小的组中，发送者可以使用上述机制和/或媒体编码特定方法按需执行修复。请注意，“小组”和“足够小的RTT”都高度依赖于应用程序。
This document specifies a modified RTP profile for audio and video conferences with minimal control based upon [1] and [2] by means of two modifications/additions: Firstly, to achieve timely feedback, the concept of Early RTCP messages as well as algorithms allowing for low-delay feedback in small multicast groups (and preventing feedback implosion in large ones) are introduced. Special consideration is given to point-to-point scenarios. Secondly, a small number of general-purpose feedback messages as well as a format for codec- and application-specific feedback information are defined for transmission in the RTCP payloads.
本文件通过两种修改/添加方式，在[1]和[2]的基础上，为音频和视频会议指定了一种修改后的RTP配置文件，该配置文件采用最小控制：首先，为了实现及时反馈，早期RTCP消息的概念以及允许在小多播组中进行低延迟反馈的算法（以及防止大型反馈内爆）进行了介绍。特别考虑了点到点场景。其次，定义了少量通用反馈消息以及编解码器和应用程序特定反馈信息的格式，以便在RTCP有效负载中传输。
The definitions from RTP/RTCP [1] and the "RTP Profile for Audio and Video Conferences with Minimal Control" [2] apply. In addition, the following definitions are used in this document:
RTP/RTCP[1]和“用于具有最小控制的音频和视频会议的RTP配置文件”[2]中的定义适用。此外，本文件中使用了以下定义：
Early RTCP mode: The mode of operation in that a receiver of a media stream is often (but not always) capable of reporting events of interest back to the sender close to their occurrence. In Early RTCP mode, RTCP packets are transmitted according to the timing rules defined in this document.
早期RTCP模式：一种操作模式，即媒体流的接收者通常（但并非总是）能够将感兴趣的事件报告给发送者，使其接近事件的发生。在早期RTCP模式下，RTCP数据包根据本文档中定义的定时规则进行传输。
Early RTCP packet: An Early RTCP packet is a packet which is transmitted earlier than would be allowed if following the scheduling algorithm of [1], the reason being an "event" observed by a receiver. Early RTCP packets may be sent in Immediate Feedback and in Early RTCP mode. Sending an Early RTCP packet is also referred to as sending Early Feedback in this document.
早期RTCP数据包：早期RTCP数据包是指在遵循[1]的调度算法的情况下，传输时间早于允许时间的数据包，其原因是接收器观察到的“事件”。早期RTCP数据包可在即时反馈和早期RTCP模式下发送。发送早期RTCP数据包在本文件中也称为发送早期反馈。
Event: An observation made by the receiver of a media stream that is (potentially) of interest to the sender -- such as a packet loss or packet reception, frame loss, etc. -- and thus useful to be reported back to the sender by means of a feedback message.
事件：接收方对发送方（可能）感兴趣的媒体流进行的观察，如数据包丢失或数据包接收、帧丢失等，因此可通过反馈消息向发送方报告。
Feedback (FB) message: An RTCP message as defined in this document is used to convey information about events observed at a receiver -- in addition to long-term receiver status information that is carried in RTCP receiver reports (RRs) -- back to the sender of the media stream. For the sake of clarity, feedback message is referred to as FB message throughout this document.
反馈（FB）消息：本文档中定义的RTCP消息用于向媒体流的发送方传回有关在接收方观察到的事件的信息，以及RTCP接收方报告（RRs）中包含的长期接收方状态信息。为清楚起见，本文件中的反馈信息称为FB信息。
Feedback (FB) threshold: The FB threshold indicates the transition between Immediate Feedback and Early RTCP mode. For a multiparty scenario, the FB threshold indicates the maximum group size at which, on average, each receiver is able to report each event back to the sender(s) immediately, i.e., by means of an Early RTCP packet without having to wait for its regularly scheduled RTCP interval. This threshold is highly dependent on the type of feedback to be provided, network QoS (e.g., packet loss probability and distribution), codec and packetization scheme in use, the session bandwidth, and application requirements. Note that the algorithms do not depend on all senders and receivers agreeing on the same value for this threshold. It is merely intended to provide conceptual guidance to application designers and is not used in any calculations. For the sake of clarity, the term feedback threshold is referred to as FB threshold throughout this document.
反馈（FB）阈值：FB阈值表示即时反馈和早期RTCP模式之间的转换。对于多方场景，FB阈值表示最大组大小，在该最大组大小下，每个接收器平均能够立即向发送者报告每个事件，即，通过早期RTCP数据包，而无需等待其定期计划的RTCP间隔。此阈值在很大程度上取决于要提供的反馈类型、网络QoS（例如，数据包丢失概率和分布）、使用的编解码器和分组方案、会话带宽和应用程序要求。请注意，算法并不依赖于所有发送方和接收方都同意此阈值的相同值。它仅用于向应用程序设计者提供概念指导，不用于任何计算。为清楚起见，在本文件中，术语反馈阈值被称为FB阈值。
Immediate Feedback mode: A mode of operation in which each receiver of a media stream is, statistically, capable of reporting each event of interest immediately back to the media stream sender. In Immediate Feedback mode, RTCP FB messages are transmitted according to the timing rules defined in this document.
即时反馈模式：一种操作模式，其中媒体流的每个接收器在统计上能够立即向媒体流发送者报告每个感兴趣的事件。在即时反馈模式下，RTCP FB消息根据本文件中定义的定时规则传输。
Media packet: A media packet is an RTP packet.
媒体包：媒体包是RTP包。
Regular RTCP mode: Mode of operation in which no preferred transmission of FB messages is allowed. Instead, RTCP messages are sent following the rules of [1]. Nevertheless, such RTCP messages may contain feedback information as defined in this document.
常规RTCP模式：不允许优先传输FB消息的操作模式。相反，RTCP消息是按照[1]的规则发送的。然而，此类RTCP消息可能包含本文件中定义的反馈信息。
Regular RTCP packet: An RTCP packet that is not sent as an Early RTCP packet.
常规RTCP数据包：不作为早期RTCP数据包发送的RTCP数据包。
RTP sender: An RTP sender is an RTP entity that transmits media packets as well as RTCP packets and receives Regular as well as Early RTCP (i.e., feedback) packets. Note that the RTP sender is a logical role and that the same RTP entity may at the same time act as an RTP receiver.
RTP发送方：RTP发送方是一个RTP实体，它传输媒体数据包和RTCP数据包，并接收定期和早期RTCP（即反馈）数据包。请注意，RTP发送方是一个逻辑角色，同一个RTP实体可以同时充当RTP接收方。
RTP receiver: An RTP receiver is an RTP entity that receives media packets as well as RTCP packets and transmits Regular as well as Early RTCP (i.e., feedback) packets. Note that the RTP receiver is a logical role and that the same RTP entity may at the same time act as an RTP sender.
RTP接收器：RTP接收器是一个RTP实体，它接收媒体数据包和RTCP数据包，并传输定期和早期RTCP（即反馈）数据包。请注意，RTP接收方是一个逻辑角色，同一RTP实体可以同时充当RTP发送方。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。
The rules defined in [2] also apply to this profile except for those rules mentioned in the following:
[2]中定义的规则也适用于此配置文件，但以下提到的规则除外：
RTCP packet types: Two additional RTCP packet types are registered and the corresponding FB messages to convey feedback information are defined in Section 6 of this memo.
RTCP数据包类型：注册了两种额外的RTCP数据包类型，并在本备忘录第6节中定义了传递反馈信息的相应FB消息。
RTCP report intervals: This document describes three modes of operation that influence the RTCP report intervals (see Section 3.2 of this memo). In Regular RTCP mode, all rules from [1] apply except for the recommended minimal interval of five seconds between two RTCP reports from the same RTP entity. In both Immediate Feedback and Early RTCP modes, the minimal interval of five seconds between two RTCP reports is dropped and, additionally, the rules specified in Section 3 of this memo apply if RTCP packets containing FB messages (defined in Section 4 of this memo) are to be transmitted.
RTCP报告间隔：本文件描述了影响RTCP报告间隔的三种操作模式（见本备忘录第3.2节）。在常规RTCP模式下，[1]中的所有规则均适用，但来自同一RTP实体的两个RTCP报告之间建议的最小间隔为5秒。在即时反馈和早期RTCP模式下，两个RTCP报告之间的最小间隔为5秒，并且，如果要传输包含FB消息（在本备忘录第4节中定义）的RTCP数据包，则适用本备忘录第3节中规定的规则。
The rules set forth in [1] may be overridden by session descriptions specifying different parameters (e.g., for the bandwidth share assigned to RTCP for senders and receivers, respectively). For sessions defined using the Session Description Protocol (SDP) [3], the rules of [4] apply.
[1]中规定的规则可能会被指定不同参数的会话描述所覆盖（例如，分别为发送方和接收方分配给RTCP的带宽共享）。对于使用会话描述协议（SDP）[3]定义的会话，[4]的规则适用。
Congestion control: The same basic rules as detailed in [2] apply. Beyond this, in Section 7, further consideration is given to the impact of feedback and a sender's reaction to FB messages.
拥塞控制：与[2]中详述的基本规则相同。除此之外，第7节还进一步考虑了反馈的影响和发送者对FB消息的反应。
RTP is intended to be used on top of unreliable transport protocols, including UDP and the Datagram Congestion Control Protocol (DCCP). This section briefly describes the specifics beyond plain RTP operation introduced by RTCP feedback as specified in this memo.
RTP计划用于不可靠的传输协议之上，包括UDP和数据报拥塞控制协议（DCCP）。本节简要介绍了本备忘录中规定的RTCP反馈引入的普通RTP操作以外的细节。
UDP: UDP provides best-effort delivery of datagrams for point-to-point as well as for multicast communications. UDP does not support congestion control or error repair. The RTCP-based feedback defined in this memo is able to provide minimal support for limited error repair. As RTCP feedback is not guaranteed to operate on sufficiently small timescales (in the order of RTT),
UDP:UDP为点到点和多播通信提供尽最大努力的数据报交付。UDP不支持拥塞控制或错误修复。本备忘录中定义的基于RTCP的反馈能够为有限的错误修复提供最低限度的支持。由于RTCP反馈不能保证在足够小的时间范围内运行（以RTT的顺序），
RTCP feedback is not suitable to support congestion control. This memo addresses both unicast and multicast operation.
RTCP反馈不适合支持拥塞控制。此备忘录同时处理单播和多播操作。
DCCP: DCCP [19] provides for congestion-controlled but unreliable datagram flows for unicast communications. With TCP Friendly Rate Control (TFRC)-based [20] congestion control (CCID 3), DCCP is particularly suitable for audio and video communications. DCCP's acknowledgement messages may provide detailed feedback reporting about received and missed datagrams (and thus about congestion).
DCCP:DCCP[19]为单播通信提供拥塞控制但不可靠的数据报流。通过基于TCP友好速率控制（TFRC）的[20]拥塞控制（CCID 3），DCCP特别适用于音频和视频通信。DCCP的确认消息可以提供有关接收和丢失数据报（以及拥塞）的详细反馈报告。
When running RTP over DCCP, congestion control is performed at the DCCP layer and no additional mechanisms are required at the RTP layer. Furthermore, an RTCP-feedback-capable sender may leverage the more frequent DCCP-based feedback and thus a receiver may refrain from using (additional) Generic Feedback messages where appropriate.
在DCCP上运行RTP时，在DCCP层执行拥塞控制，在RTP层不需要额外的机制。此外，具有RTCP反馈能力的发送方可以利用更频繁的基于DCCP的反馈，因此接收方可以在适当的情况下避免使用（额外的）通用反馈消息。
Two components constitute RTCP-based feedback as described in this document:
如本文件所述，两部分构成基于RTCP的反馈：
o Status reports are contained in sender report (SR)/received report (RR) packets and are transmitted at regular intervals as part of compound RTCP packets (which also include source description (SDES) and possibly other messages); these status reports provide an overall indication for the recent reception quality of a media stream.
o 状态报告包含在发送方报告（SR）/接收到的报告（RR）数据包中，并作为复合RTCP数据包的一部分定期发送（其中还包括源描述（SDE）和可能的其他消息）；这些状态报告提供媒体流最近接收质量的总体指示。
o FB messages as defined in this document that indicate loss or reception of particular pieces of a media stream (or provide some other form of rather immediate feedback on the data received). Rules for the transmission of FB messages are newly introduced in this document.
o 本文件中定义的FB消息，表示媒体流的特定片段丢失或接收（或对接收到的数据提供某种其他形式的即时反馈）。本文件新增了FB信息传输规则。
RTCP FB messages are just another RTCP packet type (see Section 4). Therefore, multiple FB messages MAY be combined in a single compound RTCP packet and they MAY also be sent combined with other RTCP packets.
RTCP FB消息只是另一种RTCP数据包类型（参见第4节）。因此，多个FB消息可以组合在单个复合RTCP分组中，并且它们也可以与其他RTCP分组组合发送。
Compound RTCP packets containing FB messages as defined in this document MUST contain RTCP packets in the order defined in [1]:
包含本文档中定义的FB消息的复合RTCP数据包必须按照[1]中定义的顺序包含RTCP数据包：
o OPTIONAL encryption prefix that MUST be present if the RTCP packet(s) is to be encrypted according to Section 9.1 of [1]. o MANDATORY SR or RR.
o 如果要根据[1]第9.1节对RTCP数据包进行加密，则必须提供可选的加密前缀。o强制性SR或RR。
o MANDATORY SDES, which MUST contain the CNAME item; all other SDES items are OPTIONAL. o One or more FB messages.
o 强制性SDE，必须包含CNAME项目；所有其他SDE项目都是可选的。o一条或多条FB消息。
The FB message(s) MUST be placed in the compound packet after RR and SDES RTCP packets defined in [1]. The ordering with respect to other RTCP extensions is not defined.
FB消息必须放在[1]中定义的RR和SDES RTCP数据包之后的复合数据包中。未定义与其他RTCP扩展相关的顺序。
Two types of compound RTCP packets carrying feedback packets are used in this document:
本文件中使用了两种携带反馈数据包的复合RTCP数据包：
a) Minimal compound RTCP feedback packet
a) 最小复合RTCP反馈包
A minimal compound RTCP feedback packet MUST contain only the mandatory information as listed above: encryption prefix if necessary, exactly one RR or SR, exactly one SDES with only the CNAME item present, and the FB message(s). This is to minimize the size of the RTCP packet transmitted to convey feedback and thus to maximize the frequency at which feedback can be provided while still adhering to the RTCP bandwidth limitations.
最小复合RTCP反馈数据包必须仅包含上面列出的强制信息：加密前缀（如有必要）、一个RR或SR、一个SDE（仅存在CNAME项）和FB消息。这是为了最小化传输反馈的RTCP数据包的大小，从而在仍然遵守RTCP带宽限制的情况下最大化可提供反馈的频率。
This packet format SHOULD be used whenever an RTCP FB message is sent as part of an Early RTCP packet. This packet type is referred to as minimal compound RTCP packet in this document.
当RTCP FB消息作为早期RTCP数据包的一部分发送时，应使用此数据包格式。此数据包类型在本文件中称为最小复合RTCP数据包。
b) (Full) compound RTCP feedback packet
b) （完整）复合RTCP反馈数据包
A (full) compound RTCP feedback packet MAY contain any additional number of RTCP packets (additional RRs, further SDES items, etc.). The above ordering rules MUST be adhered to.
（完整）复合RTCP反馈数据包可包含任何额外数量的RTCP数据包（额外RRs、更多SDES项目等）。必须遵守上述订购规则。
This packet format MUST be used whenever an RTCP FB message is sent as part of a Regular RTCP packet or in Regular RTCP mode. It MAY also be used to send RTCP FB messages in Immediate Feedback or Early RTCP mode. This packet type is referred to as full compound RTCP packet in this document.
当RTCP FB消息作为常规RTCP数据包的一部分或在常规RTCP模式下发送时，必须使用此数据包格式。它也可用于以即时反馈或早期RTCP模式发送RTCP FB消息。此数据包类型在本文件中称为完整复合RTCP数据包。
RTCP packets that do not contain FB messages are referred to as non-FB RTCP packets. Such packets MUST follow the format rules in [1].
不包含FB消息的RTCP数据包称为非FB RTCP数据包。此类数据包必须遵循[1]中的格式规则。
FB messages are part of the RTCP control streams and thus subject to the RTCP bandwidth constraints. This means, in particular, that it may not be possible to report an event observed at a receiver immediately back to the sender. However, the value of feedback
FB消息是RTCP控制流的一部分，因此受RTCP带宽约束。这尤其意味着，可能无法立即将在接收者处观察到的事件报告给发送者。然而，反馈的价值
given to a sender typically decreases over time -- in terms of the media quality as perceived by the user at the receiving end and/or the cost required to achieve media stream repair.
发送给发送者的信息通常会随着时间的推移而减少——就用户在接收端感知到的媒体质量和/或实现媒体流修复所需的成本而言。
RTP [1] and the commonly used RTP profile [2] specify rules when compound RTCP packets should be sent. This document modifies those rules in order to allow applications to timely report events (e.g., loss or reception of RTP packets) and to accommodate algorithms that use FB messages.
RTP[1]和常用的RTP配置文件[2]指定了何时应发送复合RTCP数据包的规则。本文档修改了这些规则，以允许应用程序及时报告事件（例如，RTP数据包的丢失或接收），并适应使用FB消息的算法。
The modified RTCP transmission algorithm can be outlined as follows: As long as no FB messages have to be conveyed, compound RTCP packets are sent following the rules of RTP [1] -- except that the five-second minimum interval between RTCP reports is not enforced. Hence, the interval between RTCP reports is only derived from the average RTCP packet size and the RTCP bandwidth share available to the RTP/RTCP entity. Optionally, a minimum interval between Regular RTCP packets may be enforced.
修改后的RTCP传输算法可概述如下：只要不需要传输FB消息，复合RTCP数据包将按照RTP[1]的规则发送——RTCP报告之间的最小间隔为5秒的情况除外。因此，RTCP报告之间的间隔仅由RTP/RTCP实体可用的平均RTCP数据包大小和RTCP带宽共享得出。可选地，可以强制执行常规RTCP数据包之间的最小间隔。
If a receiver detects the need to send an FB message, it may do so earlier than the next regular RTCP reporting interval (for which it would be scheduled following the above regular RTCP algorithm). Feedback suppression is used to avoid feedback implosion in multiparty sessions: The receiver waits for a (short) random dithering interval to check whether it sees a corresponding FB message from any other receiver reporting the same event. Note that for point-to-point sessions there is no such delay. If a corresponding FB message from another member is received, this receiver refrains from sending the FB message and continues to follow the Regular RTCP transmission schedule. In case the receiver has not yet seen a corresponding FB message from any other member, it checks whether it is allowed to send Early feedback. If sending Early feedback is permissible, the receiver sends the FB message as part of a minimal compound RTCP packet. The permission to send Early feedback depends on the type of the previous RTCP packet sent by this receiver and the time the previous Early feedback message was sent.
如果接收器检测到需要发送FB消息，则其可能在下一个常规RTCP报告间隔之前发送FB消息（该间隔将按照上述常规RTCP算法进行安排）。反馈抑制用于避免多方会话中的反馈内爆：接收器等待（短）随机抖动间隔，以检查是否看到来自报告相同事件的任何其他接收器的相应FB消息。请注意，对于点对点会话，没有这种延迟。如果接收到来自另一成员的相应FB消息，则该接收器将禁止发送FB消息，并继续遵循常规RTCP传输计划。如果接收者尚未看到来自任何其他成员的相应FB消息，则检查是否允许其发送早期反馈。如果允许发送早期反馈，则接收器将FB消息作为最小复合RTCP数据包的一部分发送。发送早期反馈的权限取决于此接收器发送的上一个RTCP数据包的类型以及发送上一个早期反馈消息的时间。
FB messages may also be sent as part of full compound RTCP packets, which are transmitted as per [1] (except for the five-second lower bound) in regular intervals.
FB消息也可以作为完整复合RTCP数据包的一部分发送，该数据包按照[1]（五秒下限除外）定期发送。
RTCP-based feedback may operate in one of three modes (Figure 1) as described below. The mode of operation is just an indication of whether or not the receiver will, on average, be able to report all events to the sender in a timely fashion; the mode does not influence the algorithm used for scheduling the transmission of FB messages.
基于RTCP的反馈可在以下三种模式之一（图1）下运行。操作模式只是指示接收者是否平均能够及时向发送者报告所有事件；该模式不影响用于调度FB消息传输的算法。
And, depending on the reception quality and the locally monitored state of the RTP session, individual receivers may not (and do not have to) agree on a common perception on the current mode of operation.
并且，取决于接收质量和RTP会话的本地监控状态，各个接收机可能（并且不必）对当前操作模式的共同感知达成一致。
a) Immediate Feedback mode: In this mode, the group size is below the FB threshold, which gives each receiving party sufficient bandwidth to transmit the RTCP feedback packets for the intended purpose. This means that, for each receiver, there is enough bandwidth to report each event by means of a virtually "immediate" RTCP feedback packet.
a) 即时反馈模式：在该模式下，组大小低于FB阈值，这为每个接收方提供了足够的带宽来传输RTCP反馈数据包以达到预期目的。这意味着，对于每个接收器，都有足够的带宽通过虚拟“即时”RTCP反馈数据包来报告每个事件。
The group size threshold is a function of a number of parameters including (but not necessarily limited to): the type of feedback used (e.g., ACK vs. NACK), bandwidth, packet rate, packet loss probability and distribution, media type, codec, and the (worst case or observed) frequency of events to report (e.g., frame received, packet lost).
组大小阈值是多个参数的函数，这些参数包括（但不一定限于）：使用的反馈类型（例如，ACK vs.NACK）、带宽、分组速率、分组丢失概率和分布、媒体类型、编解码器以及要报告的事件（例如，接收到的帧、分组丢失）的频率（最坏情况或观察到的）。
As a rough estimate, let N be the average number of events to be reported per interval T by a receiver, B the RTCP bandwidth fraction for this particular receiver, and R the average RTCP packet size, then the receiver operates in Immediate Feedback mode as long as N<=B*T/R.
作为粗略估计，假设N是接收机每间隔T要报告的事件的平均数量，B是该特定接收机的RTCP带宽分数，R是平均RTCP数据包大小，则只要N<=B*T/R，接收机就在即时反馈模式下工作。
b) Early RTCP mode: In this mode, the group size and other parameters no longer allow each receiver to react to each event that would be worth reporting (or that needed reporting). But feedback can still be given sufficiently often so that it allows the sender to adapt the media stream transmission accordingly and thereby increase the overall media playback quality.
b) 早期RTCP模式：在此模式下，组大小和其他参数不再允许每个接收器对每个值得报告（或需要报告）的事件作出反应。但是，仍然可以足够频繁地给出反馈，使得其允许发送者相应地调整媒体流传输，从而提高整体媒体播放质量。
Using the above notation, Early RTCP mode can be roughly characterized by N > B*T/R as "lower bound". An estimate for an upper bound is more difficult. Setting N=1, we obtain for a given R and B the interval T = R/B as average interval between events to be reported. This information can be used as a hint to determine whether or not early transmission of RTCP packets is useful.
使用上述表示法，早期RTCP模式的大致特征是N>B*T/R为“下限”。估计上限更为困难。设置N=1，我们获得给定R和B的间隔T=R/B作为要报告事件之间的平均间隔。此信息可用作提示，以确定早期传输RTCP数据包是否有用。
c) Regular RTCP Mode: From some group size upwards, it is no longer useful to provide feedback for individual events from receivers at all -- because of the time scale in which the feedback could be provided and/or because in large groups the sender(s) have no chance to react to individual feedback anymore.
c) 常规RTCP模式：从一些组大小开始，为接收者的个别事件提供反馈不再有用——因为可以提供反馈的时间范围和/或因为在大组中，发送者没有机会对个别反馈作出反应。
No precise group size threshold can be specified at which this mode starts but, obviously, this boundary matches the upper bound of the Early RTCP mode as specified in item b) above.
无法指定此模式开始时的精确组大小阈值，但显然，此边界与上文b）项中规定的早期RTCP模式的上限相匹配。
As the feedback algorithm described in this document scales smoothly, there is no need for an agreement among the participants on the precise values of the respective FB thresholds within the group. Hence, the borders between all these modes are soft.
由于本文件中描述的反馈算法可顺利扩展，因此参与者无需就集团内各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, ...)
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, ...)
Figure 1: Modes of operation
图1：操作模式
As stated before, the respective FB thresholds depend on a number of technical parameters (of the codec, the transport, the type of feedback used, etc.) but also on the respective application scenarios. Section 3.6 provides some useful hints (but no precise calculations) on estimating these thresholds.
如前所述，相应的FB阈值取决于许多技术参数（编解码器、传输、使用的反馈类型等），但也取决于相应的应用场景。第3.6节提供了一些关于估计这些阈值的有用提示（但没有精确的计算）。
The following pieces of state information need to be maintained per receiver (largely taken from [1]). Note that all variables (except in item h) below) are calculated independently at each receiver. Therefore, their local values may differ at any given point in time.
每个接收者需要维护以下状态信息（主要取自[1]）。请注意，所有变量（以下h项除外）均在每个接收器处独立计算。因此，它们的局部值在任何给定时间点都可能不同。
a) Let "senders" be the number of active senders in the RTP session.
a) 让“senders”为RTP会话中的活动发件人数。
b) Let "members" be the current estimate of the number of receivers in the RTP session.
b) 让“成员”为RTP会话中接收器数量的当前估计值。
c) Let tn and tp be the time for the next (last) scheduled RTCP RR transmission calculated prior to timer reconsideration.
c) 让tn和tp为计时器重新考虑之前计算的下一（最后）个计划RTCP RR传输的时间。
d) Let Tmin be the minimal interval between RTCP packets as per [1]. Unlike in [1], the initial Tmin is set to 1 second to allow for some group size sampling before sending the first RTCP packet. After the first RTCP packet is sent, Tmin is set to 0.
d) 根据[1]，设Tmin为RTCP数据包之间的最小间隔。与[1]中不同，初始Tmin设置为1秒，以允许在发送第一个RTCP数据包之前进行一些组大小采样。发送第一个RTCP数据包后，Tmin设置为0。
e) Let T_rr be the interval after which, having just sent a regularly scheduled RTCP packet, a receiver would schedule the transmission of its next Regular RTCP packet. This value is obtained following the rules of [1] but with Tmin as defined in this document: T_rr = T (the "calculated interval" as defined in [1]) with tn = tp + T. T_rr always refers to the last value of T that has been computed (because of reconsideration or to determine tn). T_rr is also referred to as Regular RTCP interval in this document.
e) 设T_rr为间隔，在该间隔之后，刚刚发送了一个定期调度的RTCP数据包，接收器将调度其下一个定期RTCP数据包的传输。该值是根据[1]中的规则获得的，但使用本文件中定义的Tmin:T_rr=T（如[1]中定义的“计算间隔”），tn=tp+T。T_rr始终指已计算的T的最后一个值（由于重新考虑或确定tn）。在本文件中，T_rr也称为常规RTCP间隔。
f) Let t0 be the time at which an event that is to be reported is detected by a receiver.
f) 设t0为接收器检测到要报告的事件的时间。
g) Let T_dither_max be the maximum interval for which an RTCP feedback packet MAY be additionally delayed to prevent implosions in multiparty sessions; the value for T_dither_max is dynamically calculated based upon T_rr (or may be derived by means of another mechanism common across all RTP receivers to be specified in the future). For point-to-point sessions (i.e., sessions with exactly two members with no change in the group size expected, e.g., unicast streaming sessions), T_dither_max is set to 0.
g) 设T_dither_max为RTCP反馈数据包可额外延迟以防止多方会话中内爆的最大间隔；T_抖动_max的值是基于T_rr动态计算的（或者可以通过将来指定的所有RTP接收机中通用的另一种机制来推导）。对于点到点会话（即，仅包含两个成员且组大小预期不变的会话，例如，单播流会话），T_dither_max设置为0。
h) Let T_max_fb_delay be the upper bound within which feedback to an event needs to be reported back to the sender to be useful at all. This value is application specific, and no values are defined in this document.
h) 设T_max_fb_delay为上限，在此上限内，事件的反馈需要反馈给发送方才能发挥作用。此值是特定于应用程序的，本文档中未定义任何值。
i) Let te be the time for which a feedback packet is scheduled.
i) 设te为计划反馈数据包的时间。
j) Let T_fd be the actual (randomized) delay for the transmission of FB message in response to an event at time t0.
j) 设T_fd为响应时间t0处事件的FB消息传输的实际（随机）延迟。
k) Let allow_early be a Boolean variable that indicates whether the receiver currently may transmit FB messages prior to its next regularly scheduled RTCP interval tn. This variable is used to throttle the feedback sent by a single receiver. allow_early is set to FALSE after Early feedback transmission and is set to TRUE as soon as the next Regular RTCP transmission takes place.
k) allow_early是一个布尔变量，指示接收器当前是否可以在其下一个定期计划的RTCP间隔tn之前发送FB消息。该变量用于限制单个接收器发送的反馈。allow_early在早期反馈传输后设置为FALSE，并在下一次常规RTCP传输发生时设置为TRUE。
l) Let avg_rtcp_size be the moving average on the RTCP packet size as defined in [1].
l) 设avg_rtcp_size为[1]中定义的rtcp数据包大小的移动平均值。
m) Let T_rr_interval be an OPTIONAL minimal interval to be used between Regular RTCP packets. If T_rr_interval == 0, then this variable does not have any impact on the overall operation of the RTCP feedback algorithm. If T_rr_interval != 0, then the next Regular RTCP packet will not be scheduled T_rr after the last Regular RTCP transmission (i.e., at tp+T_rr). Instead, the next Regular RTCP packet will be delayed until at least T_rr_interval
m) 设T_rr_interval为常规RTCP数据包之间使用的可选最小间隔。如果T_rr_interval==0，则此变量对RTCP反馈算法的整体操作没有任何影响。如果T_rr_间隔！=0，则在最后一次常规RTCP传输（即，在tp+T_rr）后，下一个常规RTCP数据包将不会被调度到T_rr。相反，下一个常规RTCP数据包将延迟到至少T_rr_间隔
after the last Regular RTCP transmission, i.e., it will be scheduled at or later than tp+T_rr_interval. Note that T_rr_interval does not affect the calculation of T_rr and tp; instead, Regular RTCP packets scheduled for transmission before tp+T_rr_interval will be suppressed if, for example, they do not contain any FB messages. The T_rr_interval does not affect transmission scheduling of Early RTCP packets.
在最后一次常规RTCP传输之后，即计划在tp+T_rr_间隔或之后传输。注意T_rr_间隔不影响T_rr和tp的计算；相反，计划在tp+T_rr_间隔之前传输的常规RTCP数据包将被抑制，例如，如果它们不包含任何FB消息。T_rr_间隔不影响早期RTCP数据包的传输调度。
Note: Providing T_rr_interval as an independent variable is meant to minimize Regular RTCP feedback (and thus bandwidth consumption) as needed by the application while additionally allowing the use of more frequent Early RTCP packets to provide timely feedback. This goal could not be achieved by reducing the overall RTCP bandwidth as RTCP bandwidth reduction would also impact the frequency of Early feedback.
注：提供T_rr_间隔作为自变量意味着根据应用程序的需要最小化常规RTCP反馈（从而减少带宽消耗），同时允许使用更频繁的早期RTCP数据包来提供及时反馈。这一目标无法通过减少RTCP总带宽来实现，因为RTCP带宽的减少也会影响早期反馈的频率。
n) Let t_rr_last be the point in time at which the last Regular RTCP packet has been scheduled and sent, i.e., has not been suppressed due to T_rr_interval.
n) 设t_rr_last为调度和发送最后一个常规RTCP数据包的时间点，即，由于t_rr_间隔未被抑制。
o) Let T_retention be the time window for which past FB messages are stored by an AVPF entity. This is to ensure that feedback suppression also works for entities that have received FB messages from other entities prior to noticing the feedback event itself. T_retention MUST be set to at least 2 seconds.
o) 让T_retention作为AVPF实体存储过去FB消息的时间窗口。这是为了确保反馈抑制也适用于在注意到反馈事件本身之前已从其他实体接收FB消息的实体。T_保留时间必须设置为至少2秒。
p) Let M*Td be the timeout value for a receiver to be considered inactive (as defined in [1]).
p) 设M*Td为被视为非活动接收器的超时值（如[1]中所定义）。
The feedback situation for an event to report at a receiver is depicted in Figure 2 below. At time t0, such an event (e.g., a packet loss) is detected at the receiver. The receiver decides -- based upon current bandwidth, group size, and other application-specific parameters -- that an FB message needs to be sent back to the sender.
下面的图2描述了要在接收者处报告的事件的反馈情况。在时间t0，在接收器处检测到这样的事件（例如，分组丢失）。接收方根据当前带宽、组大小和其他特定于应用程序的参数决定是否需要将FB消息发送回发送方。
To avoid an implosion of feedback packets in multiparty sessions, the receiver MUST delay the transmission of the RTCP feedback packet by a random amount of time T_fd (with the random number evenly distributed in the interval [0, T_dither_max]). Transmission of the compound RTCP packet MUST then be scheduled for te = t0 + T_fd.
为避免反馈数据包在多方会话中内爆，接收器必须将RTCP反馈数据包的传输延迟随机时间T_fd（随机数均匀分布在间隔[0，T_抖动_max]）。然后，复合RTCP数据包的传输必须针对te=t0+T_fd进行调度。
The T_dither_max parameter is derived from the Regular RTCP interval, T_rr, which, in turn, is based upon the group size. A future document may also specify other calculations for T_dither_max (e.g., based upon RTT) if it can be assured that all RTP receivers will use the same mechanism for calculating T_dither_max.
T_dither_max参数是从常规RTCP间隔T_rr中派生出来的，它又基于组大小。如果可以确保所有RTP接收器将使用相同的机制来计算T_抖动_max，则未来的文档还可以指定T_抖动_max的其他计算（例如，基于RTT）。
For a certain application scenario, a receiver may determine an upper bound for the acceptable local delay of FB messages: T_max_fb_delay. If an a priori estimation or the actual calculation of T_dither_max indicates that this upper bound MAY be violated (e.g., because T_dither_max > T_max_fb_delay), the receiver MAY decide not to send any feedback at all because the achievable gain is considered insufficient.
对于特定的应用场景，接收器可以确定FB消息的可接受本地延迟的上限：T_max_FB_delay。如果T_抖动_max的先验估计或实际计算表明可能违反该上限（例如，因为T_抖动_max>T_max_fb_延迟），则接收机可能决定根本不发送任何反馈，因为可实现增益被认为不足。
If an Early RTCP packet is scheduled, the time slot for the next Regular RTCP packet MUST be updated accordingly to have a new tn (tn=tp+2*T_rr) and a new tp (tp=tp+T_rr) afterwards. This is to ensure that the short-term average RTCP bandwidth used with Early feedback does not exceed the bandwidth used without Early feedback.
如果安排了早期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
event to
report
detected
|
| RTCP feedback range
| (T_max_fb_delay)
vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) )
|---+--------+-------------+-----+------------| |--------+--->
| | | | ( ( |
| t0 te |
tp tn
\_______ ________/
\/
T_dither_max
Figure 2: Event report and parameters for Early RTCP scheduling
图2：早期RTCP调度的事件报告和参数
Let S0 be an active sender (out of S senders) and let N be the number of receivers with R being one of these receivers.
设S0为活动发送方（S个发送方中的一个），N为接收方数量，R为其中一个接收方。
Assume that R has verified that using feedback mechanisms is reasonable at the current constellation (which is highly application specific and hence not specified in this document).
假设R已验证在当前星座中使用反馈机制是合理的（这是高度特定于应用程序的，因此本文档中未指定）。
Assume further that T_rr_interval is 0, if no minimal interval between Regular RTCP packets is to be enforced, or T_rr_interval is set to some meaningful value, as given by the application. This value then denotes the minimal interval between Regular RTCP packets.
进一步假设T_rr_interval为0，如果常规RTCP数据包之间没有最小间隔，或者T_rr_interval设置为某个有意义的值，如应用程序所给出的。然后，该值表示常规RTCP数据包之间的最小间隔。
With this, a receiver R MUST use the following rules for transmitting one or more FB messages as minimal or full compound RTCP packet.
因此，接收器R必须使用以下规则将一个或多个FB消息作为最小或完整的复合RTCP数据包传输。
Initially, R MUST set allow_early = TRUE and t_rr_last = NaN (Not-a-Number, i.e., some invalid value that can be distinguished from a valid time).
最初，R必须设置allow_early=TRUE和t_rr_last=NaN（非数字，即可以与有效时间区分的一些无效值）。
Furthermore, the initialization of the RTCP variables as per [1] applies except for the initial value for Tmin. For a point-to-point session, the initial Tmin is set to 0. For a multiparty session, Tmin is initialized to 1.0 seconds.
此外，根据[1]对RTCP变量的初始化适用，Tmin的初始值除外。对于点对点会话，初始Tmin设置为0。对于多方会话，Tmin初始化为1.0秒。
Assume that R had scheduled the last Regular RTCP RR packet for transmission at tp (and sent or suppressed this packet at tp) and has scheduled the next transmission (including possible reconsideration as per [1]) for tn = tp + T_rr. Assume also that the last Regular RTCP packet transmission has occurred at t_rr_last.
假设R已安排最后一个常规RTCP RR数据包在tp传输（并在tp发送或抑制该数据包），并已安排下一次传输（包括根据[1]进行的可能重新考虑），用于tn=tp+T_RR。还假设最后一次常规RTCP数据包传输发生在t_rr_last。
The Early Feedback algorithm then comprises the following steps:
然后，早期反馈算法包括以下步骤：
1. At time t0, R detects the need to transmit one or more FB messages, e.g., because media "units" need to be ACKed or NACKed, and finds that providing the feedback information is potentially useful for the sender.
1. 在时间t0，R检测到需要发送一个或多个FB消息，例如，因为媒体“单元”需要被确认或nacke，并且发现提供反馈信息对发送者潜在有用。
2. R first checks whether there is already a compound RTCP packet containing one or more FB messages scheduled for transmission (either as Early or as Regular RTCP packet).
2. R首先检查是否已经有一个复合RTCP数据包，其中包含一个或多个计划传输的FB消息（尽早或作为常规RTCP数据包）。
2a) If so, the new FB message MUST be included in the scheduled packet; the scheduling of the waiting compound RTCP packet MUST remain unchanged. When doing so, the available feedback information SHOULD be merged to produce as few FB messages as possible. This completes the course of immediate actions to be taken.
2a）如果是，则新的FB消息必须包含在调度数据包中；等待复合RTCP数据包的调度必须保持不变。进行此操作时，应合并可用的反馈信息，以产生尽可能少的FB消息。这就完成了立即采取行动的过程。
2b) If no compound RTCP packet is already scheduled for transmission, a new (minimal or full) compound RTCP packet MUST be created and the minimal interval for T_dither_max MUST be chosen as follows:
2b）如果尚未计划传输复合RTCP数据包，则必须创建新的（最小或完整）复合RTCP数据包，并且必须按如下方式选择T_抖动_max的最小间隔：
i) If the session is a point-to-point session, then
i) 如果会话是点对点会话，则
T_dither_max = 0.
T_抖动_max=0。
ii) If the session is a multiparty session, then
ii）如果会议是多方会议，则
T_dither_max = l * T_rr
抖动最大值=l*T\U rr
with l=0.5.
l=0.5。
The value for T_dither_max MAY be calculated differently (e.g., based upon RTT), which MUST then be specified in a future document. Such a future specification MUST ensure that all RTP receivers use the same mechanism to calculate T_dither_max.
T_dither_max的值可能会以不同方式计算（例如，基于RTT），随后必须在未来的文档中指定。这种未来的规范必须确保所有RTP接收机使用相同的机制来计算T_抖动_max。
The values given above for T_dither_max are minimal values. Application-specific feedback considerations may make it worthwhile to increase T_dither_max beyond this value. This is up to the discretion of the implementer.
上面给出的T_抖动_max的值是最小值。特定于应用程序的反馈考虑可能会使T_抖动_max超过该值。这由实施者自行决定。
3. Then, R MUST check whether its next Regular RTCP packet would be within the time bounds for the Early RTCP packet triggered at t0, i.e., if t0 + T_dither_max > tn.
3. 然后，R必须检查其下一个常规RTCP数据包是否在t0触发的早期RTCP数据包的时间范围内，即，如果t0+T_抖动_max>tn。
3a) If so, an Early RTCP packet MUST NOT be scheduled; instead, the FB message(s) MUST be stored to be included in the Regular RTCP packet scheduled for tn. This completes the course of immediate actions to be taken.
3a）如果是，则不得调度早期RTCP数据包；相反，必须存储FB消息，以便将其包含在为tn计划的常规RTCP数据包中。这就完成了立即采取措施的过程。
3b) Otherwise, the following steps are carried out.
3b）否则，执行以下步骤。
4. R MUST check whether it is allowed to transmit an Early RTCP packet, i.e., allow_early == TRUE, or not.
4. R必须检查是否允许发送早期RTCP数据包，即：allow_Early==TRUE，或not。
4a) If allow_early == FALSE, then R MUST check the time for the next scheduled Regular RTCP packet:
4a）如果allow_early==FALSE，则R必须检查下一个计划的常规RTCP数据包的时间：
1. If tn - t0 < T_max_fb_delay, then the feedback could still be useful for the sender, despite the late reporting. Hence, R MAY create an RTCP FB message to be included in the Regular RTCP packet for transmission at tn.
1. 如果tn-t0<T_max_fb_延迟，那么反馈对于发送者仍然有用，尽管报告延迟。因此，R可以创建要包括在常规RTCP分组中以在tn处传输的RTCP FB消息。
2. Otherwise, R MUST discard the RTCP FB message.
2. 否则，R必须丢弃RTCP FB消息。
This completes the immediate course of actions to be taken.
这就完成了即将采取的行动。
4b) If allow_early == TRUE, then R MUST schedule an Early RTCP packet for te = t0 + RND * T_dither_max with RND being a pseudo random function evenly distributed between 0 and 1.
4b）如果allow_early==TRUE，则R必须为te=t0+RND*T_dither_max安排一个早期RTCP数据包，RND是一个均匀分布在0和1之间的伪随机函数。
5. R MUST detect overlaps in FB messages received from other members of the RTP session and the FB messages R wants to send. Therefore, while a member of the RTP session, R MUST continuously monitor the arrival of (minimal) compound RTCP packets and store each FB message contained in these RTCP packets for at least T_retention. When scheduling the transmission of its own FB message following steps 1 through 4 above, R MUST check each of the stored and newly received FB messages from the RTCP packets received during the interval [t0 - T_retention ; te] and act as follows:
5. R必须检测从RTP会话的其他成员接收的FB消息与R想要发送的FB消息之间的重叠。因此，作为RTP会话的成员，R必须持续监控（最小）复合RTCP数据包的到达，并存储这些RTCP数据包中包含的每个FB消息，以至少保留T_。当按照上述步骤1至4调度其自身FB消息的传输时，R必须检查[t0-T_retention；te]间隔期间接收的RTCP数据包中存储的和新接收的每个FB消息，并按如下方式操作：
5a) If R understands the received FB message's semantics and the message contents is a superset of the feedback R wanted to send, then R MUST discard its own FB message and MUST re-schedule the next Regular RTCP packet transmission for tn (as calculated before).
5a）如果R理解接收到的FB消息的语义，并且消息内容是R想要发送的反馈的超集，则R必须丢弃其自己的FB消息，并且必须为tn重新安排下一个常规RTCP数据包传输（如前所计算）。
5b) If R understands the received FB message's semantics and the message contents is not a superset of the feedback R wanted to send, then R SHOULD transmit its own FB message as scheduled. If there is an overlap between the feedback information to send and the feedback information received, the amount of feedback transmitted is up to R: R MAY leave its feedback information to be sent unchanged, R MAY as well eliminate any redundancy between its own feedback and the feedback received so far from other session members.
5b）如果R理解接收到的FB消息的语义，且消息内容不是R想要发送的反馈的超集，则R应按计划发送其自己的FB消息。如果要发送的反馈信息和接收的反馈信息之间存在重叠，则发送的反馈量最多为R：R可以保持其要发送的反馈信息不变，R还可以消除其自身反馈和从其他会话成员接收的反馈之间的任何冗余。
5c) If R does not understand the received FB message's semantics, R MAY keep its own FB message scheduled as an Early RTCP packet, or R MAY re-schedule the next Regular RTCP packet transmission for tn (as calculated before) and MAY append the FB message to the now regularly scheduled RTCP message.
5c）如果R不理解接收到的FB消息的语义，R可以将其自己的FB消息作为早期RTCP数据包进行调度，或者R可以为tn重新调度下一个常规RTCP数据包传输（如前面计算的），并且可以将FB消息附加到现在定期调度的RTCP消息。
Note: With 5c), receiving unknown FB messages may not lead to feedback suppression at a particular receiver. As a consequence, a given event may cause M different types of FB messages (which are all appropriate but not mutually understood) to be scheduled, so that a "large" receiver group may effectively be partitioned into at most M groups. Among members of each of these M groups, feedback suppression will occur following 5a and 5b but no suppression will happen across groups. As a result, O(M) RTCP FB messages may be received by the sender. Hence, there is a chance for a very limited feedback implosion. However, as sender(s) and all receivers make up the same application using the same (set of) codecs in the same RTP session, only little divergence in semantics for FB messages can safely be assumed and, therefore, M is assumed to be small in the general case.
注：对于5c），接收未知FB消息可能不会导致特定接收器的反馈抑制。因此，给定的事件可能导致调度M种不同类型的FB消息（它们都是适当的，但不能相互理解），因此“大”接收器组可以有效地划分为最多M个组。在这些M组的每个成员中，反馈抑制将在5a和5b之后发生，但不会在各组之间发生。因此，发送方可能会收到O（M）RTCP FB消息。因此，反馈内爆的机会非常有限。然而，由于发送方和所有接收方在同一RTP会话中使用相同的（一组）编解码器组成相同的应用程序，因此可以安全地假设FB消息的语义差异很小，因此，在一般情况下，假设M很小。
Given further that the O(M) FB messages are randomly distributed over a time interval of T_dither_max, we find that the resulting limited number of extra compound RTCP packets (a) is assumed not to overwhelm the sender and (b) should be conveyed as all contain complementary pieces of information.
进一步考虑到O（M）FB消息在T_dither_max的时间间隔内随机分布，我们发现由此产生的有限数量的额外复合RTCP包（a）被假定不会压倒发送方，并且（b）应该被传送，因为所有包都包含互补信息。
6. If R's FB message(s) was not suppressed by other receiver FB messages as per 5, when te is reached, R MUST transmit the (minimal) compound RTCP packet containing its FB message(s). R then MUST set allow_early = FALSE, MUST recalculate tn = tp + 2*T_rr, and MUST set tp to the previous tn. As soon as the newly calculated tn is reached, regardless whether R sends its next Regular RTCP packet or suppresses it because of T_rr_interval, it MUST set allow_early = TRUE again.
6. 如果R的FB消息未根据第5条被其他接收器FB消息抑制，当到达te时，R必须传输包含其FB消息的（最小）复合RTCP数据包。然后R必须将allow_early设置为FALSE，必须重新计算tn=tp+2*T_rr，并且必须将tp设置为前一个tn。一旦达到新计算的tn，无论R是发送其下一个常规RTCP数据包还是由于T_rr_间隔而抑制它，它都必须再次将allow_early设置为TRUE。
Full compound RTCP packets MUST be sent in regular intervals. These packets MAY also contain one or more FB messages. Transmission of Regular RTCP packets is scheduled as follows:
必须定期发送完整的复合RTCP数据包。这些包还可以包含一个或多个FB消息。常规RTCP数据包的传输计划如下：
If T_rr_interval == 0, then the transmission MUST follow the rules as specified in Sections 3.2 and 3.4 of this document and MUST adhere to the adjustments of tn specified in Section 3.5.2 (i.e., skip one regular transmission if an Early RTCP packet transmission has occurred). Timer reconsideration takes place when tn is reached as per [1]. The Regular RTCP packet is transmitted after timer reconsideration. Whenever a Regular RTCP packet is sent or suppressed, allow_early MUST be set to TRUE and tp, tn MUST be updated as per [1]. After the first transmission of a Regular RTCP packet, Tmin MUST be set to 0.
如果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。
If T_rr_interval != 0, then the calculation for the transmission times MUST follow the rules as specified in Sections 3.2 and 3.4 of this document and MUST adhere to the adjustments of tn specified in Section 3.5.2 (i.e., skip one regular transmission if an Early RTCP transmission has occurred). Timer reconsideration takes place when tn is reached as per [1]. After timer reconsideration, the following actions are taken:
如果T_rr_间隔！=0，则传输时间的计算必须遵循本文件第3.2节和第3.4节规定的规则，并且必须遵守第3.5.2节规定的tn调整（即，如果发生早期RTCP传输，则跳过一次常规传输）。当根据[1]达到tn时，计时器重新启动。重新考虑后，将采取以下措施：
1. If no Regular RTCP packet has been sent before (i.e., if t_rr_last == NaN), then a Regular RTCP packet MUST be scheduled. Stored FB messages MAY be included in the Regular RTCP packet. After the scheduled packet has been sent, t_rr_last MUST be set to tn. Tmin MUST be set to 0.
1. 如果之前未发送任何常规RTCP数据包（即，如果t_rr_last==NaN），则必须调度常规RTCP数据包。存储的FB消息可能包含在常规RTCP数据包中。发送计划数据包后，t_rr_last必须设置为tn。Tmin必须设置为0。
2. Otherwise, a temporary value T_rr_current_interval is calculated as follows:
2. 否则，临时值T_rr_current_interval的计算如下：
T_rr_current_interval = RND*T_rr_interval
T_rr_当前_间隔=RND*T_rr_间隔
with RND being a pseudo random function evenly distributed between 0.5 and 1.5. This dithered value is used to determine one of the following alternatives:
RND是一个均匀分布在0.5和1.5之间的伪随机函数。该抖动值用于确定以下备选方案之一：
2a) If t_rr_last + T_rr_current_interval <= tn, then a Regular RTCP packet MUST be scheduled. Stored RTCP FB messages MAY be included in the Regular RTCP packet. After the scheduled packet has been sent, t_rr_last MUST be set to tn.
2a）如果t_rr_last+t_rr_current_interval<=tn，则必须调度常规RTCP数据包。存储的RTCP FB消息可能包含在常规RTCP数据包中。发送计划数据包后，t_rr_last必须设置为tn。
2b) If t_rr_last + T_rr_current_interval > tn and RTCP FB messages have been stored and are awaiting transmission, an RTCP packet MUST be scheduled for transmission at tn. This RTCP packet MAY be a minimal or a Regular RTCP packet (at the discretion of the implementer), and the compound RTCP packet MUST include the stored RTCP FB message(s). t_rr_last MUST remain unchanged.
2b）如果存储了t_rr_last+t_rr_current_interval>tn和RTCP FB消息并等待传输，则必须计划在tn传输RTCP数据包。该RTCP数据包可以是最小的或常规的RTCP数据包（由实施者决定），并且复合RTCP数据包必须包括存储的RTCP FB消息。t_rr_last必须保持不变。
2c) Otherwise (if t_rr_last + T_rr_current_interval > tn but no stored RTCP FB messages are awaiting transmission), the compound RTCP packet MUST be suppressed (i.e., it MUST NOT be scheduled). t_rr_last MUST remain unchanged.
2c）否则（如果t_rr_last+t_rr_current_interval>tn，但没有存储的RTCP FB消息等待传输），则必须抑制复合RTCP数据包（即，不得对其进行调度）。t_rr_last必须保持不变。
In all the four cases above (1, 2a, 2b, and 2c), allow_early MUST be set to TRUE (possibly after sending the Regular RTCP packet) and tp and tn MUST be updated following the rules of [1] except for the five second minimum.
在上述所有四种情况下（1、2a、2b和2c），allow_early必须设置为TRUE（可能在发送常规RTCP数据包之后），tp和tn必须按照[1]的规则更新，但最短5秒的时间除外。
If T_rr_interval != 0, then the timeout calculation for RTP/AVPF entities (Section 6.3.5 of [1]) MUST be modified to use T_rr_interval instead of Tmin for computing Td and thus M*Td for timing out RTP entities.
如果T_rr_间隔！=0，则必须修改RTP/AVPF实体的超时计算（见[1]第6.3.5节），以使用T_rr_间隔代替Tmin来计算Td，从而使用M*Td来计算RTP实体的超时。
Whenever a compound RTCP packet is sent or received -- minimal or full compound, Early or Regular -- the avg_rtcp_size variable MUST be updated accordingly (see [1]) and subsequent computations of tn MUST use the new avg_rtcp_size.
无论何时发送或接收复合RTCP数据包（最小或完整复合、早期或定期），必须相应地更新avg_RTCP_大小变量（参见[1]），并且tn的后续计算必须使用新的avg_RTCP_大小。
This section provides some guidelines to the group sizes at which the various feedback modes may be used.
本节为可使用各种反馈模式的组大小提供了一些指导。
The RTP session MUST have exactly two members and this group size MUST NOT grow, i.e., it MUST be point-to-point communications. Unicast addresses SHOULD be used in the session description.
RTP会话必须正好有两个成员，并且该组大小不得增长，即必须是点对点通信。会话描述中应使用单播地址。
For unidirectional as well as bi-directional communication between two parties, 2.5% of the RTP session bandwidth is available for RTCP traffic from the receivers including feedback. For a 64-kbit/s stream this yields 1,600 bit/s for RTCP. If we assume an average of 96 bytes (=768 bits) per RTCP packet, a receiver can report 2 events per second back to the sender. If acknowledgements for 10 events are collected in each FB message, then 20 events can be acknowledged per second. At 256 kbit/s, 8 events could be reported per second; thus, the ACKs may be sent in a finer granularity (e.g., only combining three ACKs per FB message).
对于双方之间的单向和双向通信，2.5%的RTP会话带宽可用于来自接收器（包括反馈）的RTCP通信。对于64 kbit/s的流，这将为RTCP产生1600 bit/s的速率。如果我们假设每个RTCP数据包的平均值为96字节（=768位），则接收方每秒可以向发送方报告2个事件。如果在每个FB消息中收集10个事件的确认，则每秒可确认20个事件。256kbit/s时，每秒可报告8个事件；因此，可以以更细的粒度发送ack（例如，每个FB消息仅组合三个ack）。
From 1 Mbit/s upwards, a receiver would be able to acknowledge each individual frame (not packet!) in a 30-fps video stream.
从1 Mbit/s以上，接收器将能够确认30 fps视频流中的每个单独帧（不是数据包！）。
ACK strategies MUST be defined to work properly with these bandwidth limitations. An indication whether or not ACKs are allowed for a session and, if so, which ACK strategy should be used, MAY be conveyed by out-of-band mechanisms, e.g., media-specific attributes in a session description using SDP.
必须定义ACK策略，以便在这些带宽限制下正常工作。可通过带外机制（例如，使用SDP的会话描述中的媒体特定属性）来传达是否允许ACK用于会话的指示，以及如果允许，应使用哪种ACK策略。
Negative acknowledgements (and the other types of feedback exhibiting similar reporting characteristics) MUST be used for all sessions with a group size that may grow larger than two. Of course, NACKs MAY be used for point-to-point communications as well.
负面确认（以及表现出类似报告特征的其他类型的反馈）必须用于组规模可能超过两个的所有会话。当然，nack也可用于点对点通信。
Whether or not the use of Early RTCP packets should be considered depends upon a number of parameters including session bandwidth, codec, special type of feedback, and number of senders and receivers.
是否应考虑使用早期RTCP数据包取决于许多参数，包括会话带宽、编解码器、特殊反馈类型以及发送方和接收方的数量。
The most important parameters when determining the mode of operation are the allowed minimal interval between two compound RTCP packets (T_rr) and the average number of events that presumably need reporting per time interval (plus their distribution over time, of course). The minimum interval can be derived from the available RTCP bandwidth and the expected average size of an RTCP packet. The
确定操作模式时最重要的参数是两个复合RTCP数据包（T_rr）之间允许的最小间隔和每个时间间隔内可能需要报告的平均事件数（当然，加上它们随时间的分布）。最小间隔可以从可用RTCP带宽和RTCP数据包的预期平均大小得出。这个
number of events to report (e.g., per second) may be derived from the packet loss rate and sender's rate of transmitting packets. From these two values, the allowable group size for the Immediate Feedback mode can be calculated.
要报告的事件数（例如，每秒）可以从分组丢失率和发送方发送分组的速率导出。根据这两个值，可以计算即时反馈模式的允许组大小。
As stated in Section 3.3:
如第3.3节所述：
Let N be the average number of events to be reported per interval T by a receiver, B the RTCP bandwidth fraction for this particular receiver, and R the average RTCP packet size, then the receiver operates in Immediate Feedback mode as long as N<=B*T/R.
设N为接收器每间隔T报告的平均事件数，B为该特定接收器的RTCP带宽分数，R为平均RTCP数据包大小，则只要N<=B*T/R，接收器就以即时反馈模式运行。
The upper bound for the Early RTCP mode then solely depends on the acceptable quality degradation, i.e., how many events per time interval may go unreported.
早期RTCP模式的上限仅取决于可接受的质量下降，即每个时间间隔可能有多少事件未报告。
As stated in Section 3.3:
如第3.3节所述：
Using the above notation, Early RTCP mode can be roughly characterized by N > B*T/R as "lower bound". An estimate for an upper bound is more difficult. Setting N=1, we obtain for a given R and B the interval T = R/B as average interval between events to be reported. This information can be used as a hint to determine whether or not early transmission of RTCP packets is useful.
使用上述表示法，早期RTCP模式的大致特征是N>B*T/R为“下限”。估计上限更为困难。设置N=1，我们获得给定R和B的间隔T=R/B作为要报告事件之间的平均间隔。此信息可用作提示，以确定早期传输RTCP数据包是否有用。
Example: If a 256-kbit/s video with 30 fps is transmitted through a network with an MTU size of some 1,500 bytes, then, in most cases, each frame would fit in into one packet leading to a packet rate of 30 packets per second. If 5% packet loss occurs in the network (equally distributed, no inter-dependence between receivers), then each receiver will, on average, have to report 3 packets lost each two seconds. Assuming a single sender and more than three receivers, this yields 3.75% of the RTCP bandwidth allocated to the receivers and thus 9.6 kbit/s. Assuming further a size of 120 bytes for the average compound RTCP packet allows 10 RTCP packets to be sent per second or 20 in two seconds. If every receiver needs to report three lost packets per two seconds, this yields a maximum group size of 6-7 receivers if all loss events are reported. The rules for transmission of Early RTCP packets should provide sufficient flexibility for most of this reporting to occur in a timely fashion.
示例：如果通过MTU大小约为1500字节的网络传输256kbit/s、每秒30帧的视频，则在大多数情况下，每个帧都将装入一个数据包中，从而产生每秒30个数据包的数据包速率。如果网络中发生5%的数据包丢失（平均分布，接收器之间没有相互依赖），则每个接收器平均每两秒钟必须报告3个数据包丢失。假设只有一个发送器和三个以上的接收器，这将产生分配给接收器的RTCP带宽的3.75%，因此为9.6 kbit/s。进一步假设平均复合RTCP数据包的大小为120字节，则允许每秒发送10个RTCP数据包或在两秒内发送20个RTCP数据包。如果每个接收器每两秒钟需要报告三个丢失的数据包，那么如果报告了所有丢失事件，则最大组大小为6-7个接收器。早期RTCP数据包的传输规则应提供足够的灵活性，以便及时进行大部分报告。
Extending this example to determine the upper bound for Early RTCP mode could lead to the following considerations: assume that the underlying coding scheme and the application (as well as the tolerant users) allow on the order of one loss without repair per two seconds. Thus, the number of packets to be reported by each receiver decreases to two per two seconds and increases the group size to 10. Assuming further that some number of packet losses are correlated, feedback
扩展此示例以确定早期RTCP模式的上限可能会导致以下考虑事项：假设基础编码方案和应用程序（以及容错用户）允许每两秒一次丢失而不进行修复。因此，每个接收机要报告的分组的数目减少到每两秒两个，并且将组大小增加到10。进一步假设一些数据包丢失是相关的，反馈
traffic is further reduced and group sizes of some 12 to 16 (maybe even 20) can be reasonably well supported using Early RTCP mode. Note that all these considerations are based upon statistics and will fail to hold in some cases.
流量进一步减少，使用早期RTCP模式可以很好地支持大约12到16（甚至可能20）的组大小。请注意，所有这些考虑因素都是基于统计数据，在某些情况下无法成立。
Before even considering whether or not to send RTCP feedback information, an application has to determine whether this mechanism is applicable:
在考虑是否发送RTCP反馈信息之前，应用程序必须确定该机制是否适用：
1) An application has to decide whether -- for the current ratio of packet rate with the associated (application-specific) maximum feedback delay and the currently observed round-trip time (if available) -- feedback mechanisms can be applied at all.
1) 应用程序必须决定是否可以应用反馈机制——对于数据包速率的当前比率以及相关的（特定于应用程序的）最大反馈延迟和当前观察到的往返时间（如果可用）。
This decision may be based upon (and dynamically revised following) RTCP reception statistics as well as out-of-band mechanisms.
此决定可能基于（并在随后动态修订）RTCP接收统计数据以及带外机制。
2) The application has to decide -- for a certain observed error rate, assigned bandwidth, frame/packet rate, and group size -- whether (and which) feedback mechanisms can be applied.
2) 应用程序必须决定——对于某个观察到的错误率、分配的带宽、帧/分组速率和组大小——是否（以及哪些）反馈机制可以应用。
Regular RTCP reception statistics provide valuable input to this step, too.
定期的RTCP接收统计数据也为该步骤提供了有价值的输入。
3) If the application decides to send feedback, the application has to follow the rules for transmitting Early RTCP packets or Regular RTCP packets containing FB messages.
3) 如果应用程序决定发送反馈，应用程序必须遵循传输早期RTCP数据包或包含FB消息的常规RTCP数据包的规则。
4) The type of RTCP feedback sent should not duplicate information available to the sender from a lower layer transport protocol. That is, if the transport protocol provides negative or positive acknowledgements about packet reception (such as DCCP), the receiver should avoid repeating the same information at the RTCP layer (i.e., abstain from sending Generic NACKs).
4) 发送的RTCP反馈类型不应与发送方可从较低层传输协议获得的信息重复。也就是说，如果传输协议提供关于分组接收的否定或肯定确认（例如DCCP），则接收器应避免在RTCP层重复相同的信息（即，避免发送通用nack）。
Media sessions are typically described using out-of-band mechanisms to convey transport addresses, codec information, etc., between sender(s) and receiver(s). Such a mechanism is two-fold: a format used to describe a media session and another mechanism for transporting this description.
媒体会话通常使用带外机制来描述，以在发送方和接收方之间传送传输地址、编解码器信息等。这种机制有两种：一种用于描述媒体会话的格式，另一种用于传输该描述的机制。
In the IETF, the Session Description Protocol (SDP) is currently used to describe media sessions while protocols such as SIP, Session Announcement Protocol (SAP), Real Time Streaming Protocol (RTSP), and HTTP (among others) are used to convey the descriptions.
在IETF中，会话描述协议（SDP）目前用于描述媒体会话，而诸如SIP、会话公告协议（SAP）、实时流协议（RTSP）和HTTP（以及其他协议）等协议用于传达描述。
A media session description format MAY include parameters to indicate that RTCP feedback mechanisms are supported in this session and which of the feedback mechanisms MAY be applied.
媒体会话描述格式可包括参数，以指示此会话中支持RTCP反馈机制以及可应用哪种反馈机制。
To do so, the profile "AVPF" MUST be indicated instead of "AVP". Further attributes may be defined to show which type(s) of feedback are supported.
为此，必须指示配置文件“AVPF”而不是“AVP”。可以定义其他属性以显示支持哪种类型的反馈。
Section 4 contains the syntax specification to support RTCP feedback with SDP. Similar specifications for other media session description formats are outside the scope of this document.
第4节包含支持RTCP与SDP反馈的语法规范。其他媒体会话描述格式的类似规范不在本文档范围内。
This section defines a number of additional SDP parameters that are used to describe a session. All of these are defined as media-level attributes.
本节定义了许多用于描述会话的附加SDP参数。所有这些都定义为媒体级属性。
The AV profile defined in [4] is referred to as "AVP" in the context of, e.g., the Session Description Protocol (SDP) [3]. The profile specified in this document is referred to as "AVPF".
[4]中定义的AV简档在例如会话描述协议（SDP）[3]的上下文中被称为“AVP”。本文件中规定的配置文件称为“AVPF”。
Feedback information following the modified timing rules as specified in this document MUST NOT be sent for a particular media session unless the description for this session indicates the use of the "AVPF" profile (exclusively or jointly with other AV profiles).
除非对该会话的描述表明使用了“AVPF”配置文件（专用或与其他AV配置文件联合使用），否则不得为特定媒体会话发送遵循本文件规定的修改后定时规则的反馈信息。
A new payload format-specific SDP attribute is defined to indicate the capability of using RTCP feedback as specified in this document: "a=rtcp-fb". The "rtcp-fb" attribute MUST only be used as an SDP media attribute and MUST NOT be provided at the session level. The "rtcp-fb" attribute MUST only be used in media sessions for which the "AVPF" is specified.
定义了一个新的有效负载格式特定SDP属性，以指示使用本文档中指定的RTCP反馈的能力：“A=RTCP fb”。“rtcp fb”属性只能用作SDP媒体属性，不得在会话级别提供。“rtcp fb”属性只能在指定了“AVPF”的媒体会话中使用。
The "rtcp-fb" attribute SHOULD be used to indicate which RTCP FB messages MAY be used in this media session for the indicated payload type. A wildcard payload type ("*") MAY be used to indicate that the RTCP feedback attribute applies to all payload types. If several types of feedback are supported and/or the same feedback shall be
“rtcp fb”属性应用于指示哪些rtcp fb消息可在此媒体会话中用于指示的有效负载类型。通配符有效负载类型（“*”）可用于指示RTCP反馈属性适用于所有有效负载类型。如果支持多种类型的反馈和/或应提供相同的反馈
specified for a subset of the payload types, several "a=rtcp-fb" lines MUST be used.
为有效负载类型的子集指定，必须使用多条“a=rtcp fb”行。
If no "rtcp-fb" attribute is specified, the RTP receivers MAY send feedback using other suitable RTCP feedback packets as defined for the respective media type. The RTP receivers MUST NOT rely on the RTP senders reacting to any of the FB messages. The RTP sender MAY choose to ignore some feedback messages.
如果未指定“rtcp fb”属性，RTP接收器可使用为相应媒体类型定义的其他合适rtcp反馈包发送反馈。RTP接收器不得依赖RTP发送器对任何FB消息作出反应。RTP发送方可以选择忽略一些反馈消息。
If one or more "rtcp-fb" attributes are present in a media session description, the RTCP receivers for the media session(s) containing the "rtcp-fb"
如果媒体会话描述中存在一个或多个“rtcp fb”属性，则包含“rtcp fb”的媒体会话的rtcp接收器
o MUST ignore all "rtcp-fb" attributes of which they do not fully understand the semantics (i.e., where they do not understand the meaning of all values in the "a=rtcp-fb" line);
o 必须忽略他们不完全理解语义的所有“rtcp fb”属性（即，他们不理解“a=rtcp fb”行中所有值的含义）；
o SHOULD provide feedback information as specified in this document using any of the RTCP feedback packets as specified in one of the "rtcp-fb" attributes for this media session; and
o 应使用本媒体会话的“RTCP fb”属性之一中规定的任何RTCP反馈数据包提供本文件中规定的反馈信息；和
o MUST NOT use other FB messages than those listed in one of the "rtcp-fb" attribute lines.
o 不得使用“rtcp FB”属性行中列出的FB消息以外的其他FB消息。
When used in conjunction with the offer/answer model [8], the offerer MAY present a set of these AVPF attributes to its peer. The answerer MUST remove all attributes it does not understand as well as those it does not support in general or does not wish to use in this particular media session. The answerer MUST NOT add feedback parameters to the media description and MUST NOT alter values of such parameters. The answer is binding for the media session, and both offerer and answerer MUST only use feedback mechanisms negotiated in this way. Both offerer and answerer MAY independently decide to send RTCP FB messages of only a subset of the negotiated feedback mechanisms, but they SHOULD react properly to all types of the negotiated FB messages when received.
当与要约/应答模型[8]结合使用时，要约人可向其对等方呈现一组AVPF属性。应答者必须删除其不理解的所有属性，以及通常不支持或不希望在此特定媒体会话中使用的属性。回答者不得在媒体描述中添加反馈参数，也不得更改此类参数的值。答案对媒体会议具有约束力，报价人和应答人必须仅使用以这种方式协商的反馈机制。报价人和应答人都可以独立决定只发送协商反馈机制的一个子集的RTCP FB消息，但他们在收到协商FB消息时应对所有类型的消息做出正确反应。
RTP senders MUST be prepared to receive any kind of RTCP FB messages and MUST silently discard all those RTCP FB messages that they do not understand.
RTP发送方必须准备好接收任何类型的RTCP FB消息，并且必须以静默方式丢弃所有他们不理解的RTCP FB消息。
The syntax of the "rtcp-fb" attribute is as follows (the feedback types and optional parameters are all case sensitive):
“rtcp fb”属性的语法如下（反馈类型和可选参数都区分大小写）：
(In the following ABNF, fmt, SP, and CRLF are used as defined in [3].)
（在以下ABNF、fmt、SP和CRLF中使用[3]中的定义。）
rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF
rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF
rtcp-fb-pt = "*" ; wildcard: applies to all formats
/ fmt ; as defined in SDP spec
rtcp-fb-pt = "*" ; wildcard: applies to all formats
/ fmt ; as defined in SDP spec
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-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-id = 1*(alpha-numeric / "-" / "_")
rtcp-fb-param = SP "app" [SP byte-string] / SP token [SP byte-string] / ; empty
rtcp fb param=SP“app”[SP字节字符串]/SP令牌[SP字节字符串]/；空的
rtcp-fb-ack-param = SP "rpsi"
/ 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
rtcp-fb-nack-param = SP "pli"
/ SP "sli"
/ SP "rpsi"
/ SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
The literals of the above grammar have the following semantics:
上述语法的文字具有以下语义：
Feedback type "ack":
反馈类型“确认”：
This feedback type indicates that positive acknowledgements for feedback are supported.
此反馈类型表示支持对反馈的肯定确认。
The feedback type "ack" MUST only be used if the media session is allowed to operate in ACK mode as defined in Section 3.6.1.
仅当允许媒体会话在第3.6.1节定义的ack模式下运行时，才能使用反馈类型“ack”。
Parameters MUST be provided to further distinguish different types of positive acknowledgement feedback.
必须提供参数，以进一步区分不同类型的积极确认反馈。
The parameter "rpsi" indicates the use of Reference Picture Selection Indication feedback as defined in Section 6.3.3.
参数“rpsi”表示使用第6.3.3节中定义的参考图片选择指示反馈。
If the parameter "app" is specified, this indicates the use of application layer feedback. In this case, additional parameters following "app" MAY be used to further differentiate various types of application layer feedback. This document does not define any parameters specific to "app".
如果指定了参数“app”，则表示使用了应用层反馈。在这种情况下，“app”之后的附加参数可用于进一步区分各种类型的应用层反馈。本文档未定义任何特定于“应用程序”的参数。
Further parameters for "ack" MAY be defined in other documents.
“确认”的其他参数可在其他文件中定义。
Feedback type "nack":
反馈类型“nack”：
This feedback type indicates that negative acknowledgements for feedback are supported.
此反馈类型表示支持对反馈的否定确认。
The feedback type "nack", without parameters, indicates use of the Generic NACK feedback format as defined in Section 6.2.1.
无参数的反馈类型“nack”表示使用第6.2.1节中定义的通用nack反馈格式。
The following three parameters are defined in this document for use with "nack" in conjunction with the media type "video":
本文件中定义了以下三个参数，用于与“nack”结合使用的媒体类型“视频”：
o "pli" indicates the use of Picture Loss Indication feedback as defined in Section 6.3.1.
o “pli”表示使用第6.3.1节中定义的图像丢失指示反馈。
o "sli" indicates the use of Slice Loss Indication feedback as defined in Section 6.3.2.
o “sli”表示使用第6.3.2节中定义的切片损失指示反馈。
o "rpsi" indicates the use of Reference Picture Selection Indication feedback as defined in Section 6.3.3.
o “rpsi”表示使用第6.3.3节中定义的参考图片选择指示反馈。
"app" indicates the use of application layer feedback. Additional parameters after "app" MAY be provided to differentiate different types of application layer feedback. No parameters specific to "app" are defined in this document.
“应用”表示应用层反馈的使用。“app”之后可能会提供其他参数，以区分不同类型的应用层反馈。本文档中未定义特定于“应用程序”的参数。
Further parameters for "nack" MAY be defined in other documents.
“nack”的其他参数可在其他文件中定义。
Other feedback types <rtcp-fb-id>:
其他反馈类型<rtcp fb id>：
Other documents MAY define additional types of feedback; to keep the grammar extensible for those cases, the rtcp-fb-id is introduced as a placeholder. A new feedback scheme name MUST to be unique (and thus MUST be registered with IANA). Along with a new name, its semantics, packet formats (if necessary), and rules for its operation MUST be specified.
其他文件可能定义其他类型的反馈；为了保持这些情况下语法的可扩展性，引入了rtcp fb id作为占位符。新的反馈方案名称必须是唯一的（因此必须向IANA注册）。除了新名称外，还必须指定其语义、数据包格式（如有必要）及其操作规则。
Regular RTCP minimum interval "trr-int":
常规RTCP最小间隔“trr int”：
The attribute "trr-int" is used to specify the minimum interval T_rr_interval between two Regular (full compound) RTCP packets in milliseconds for this media session. If "trr-int" is not specified, a default value of 0 is assumed.
属性“trr int”用于指定此媒体会话的两个常规（完整复合）RTCP数据包之间的最小间隔T_rr_interval（毫秒）。如果未指定“trr int”，则假定默认值为0。
Note that it is assumed that more specific information about application layer feedback (as defined in Section 6.4) will be conveyed as feedback types and parameters defined elsewhere. Hence, no further provision for any types and parameters is made in this document.
请注意，假设有关应用层反馈（如第6.4节所定义）的更具体信息将作为其他地方定义的反馈类型和参数传达。因此，本文件未对任何类型和参数作进一步规定。
Further types of feedback as well as further parameters may be defined in other documents.
其他文件中可能会定义更多类型的反馈以及更多参数。
It is up to the recipients whether or not they send feedback information and up to the sender(s) (how) to make use of feedback provided.
这取决于接收者是否发送反馈信息，以及发送者（如何）利用所提供的反馈。
The standard RTCP bandwidth assignments as defined in [1] and [2] MAY be overridden by bandwidth modifiers that explicitly define the maximum RTCP bandwidth. For use with SDP, such modifiers are specified in [4]: "b=RS:<bw>" and "b=RR:<bw>" MAY be used to assign a different bandwidth (measured in bits per second) to RTP senders and receivers, respectively. The precedence rules of [4] apply to determine the actual bandwidth to be used by senders and receivers.
[1]和[2]中定义的标准RTCP带宽分配可能会被明确定义最大RTCP带宽的带宽修饰符覆盖。为了与SDP一起使用，在[4]中指定了此类修饰符：“b=RS:<bw>”和“b=RR:<bw>”可分别用于为RTP发送器和接收器分配不同的带宽（以比特/秒为单位）。[4]中的优先规则适用于确定发送方和接收方使用的实际带宽。
Applications operating knowingly over highly asymmetric links (such as satellite links) SHOULD use this mechanism to reduce the feedback rate for high bandwidth streams to prevent deterministic congestion of the feedback path(s).
有意在高度不对称链路（如卫星链路）上运行的应用程序应使用此机制降低高带宽流的反馈速率，以防止反馈路径的确定性拥塞。
Example 1: The following session description indicates a session made up from audio and DTMF [18] for point-to-point communication in which the DTMF stream uses Generic NACKs. This session description could be contained in a SIP INVITE, 200 OK, or ACK message to indicate that its sender is capable of and willing to receive feedback for the DTMF stream it transmits.
示例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
v=0 o=IP4 host.example.com中的alice 3203093520 s=有反馈的介质t=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
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
This allows sender and receiver to provide reliable transmission of DTMF events in an audio session. Assuming a 64-kbit/s audio stream with one receiver, the receiver has 2.5% RTCP bandwidth available for the negative acknowledgement stream, i.e., 250 bytes per second or some 2 RTCP feedback messages every second. Hence, the receiver can individually communicate up to two missing DTMF audio packets per second.
这允许发送方和接收方在音频会话中提供DTMF事件的可靠传输。假设有一个接收器的64 kbit/s音频流，接收器有2.5%的RTCP带宽可用于否定确认流，即每秒250字节或每秒约2条RTCP反馈消息。因此，接收器每秒可单独通信多达两个缺失的DTMF音频包。
Example 2: The following session description indicates a multicast video-only session (using either H.261 or H.263+) with the video source accepting Generic NACKs for both codecs and Reference Picture Selection for H.263. Such a description may have been conveyed using the Session Announcement Protocol (SAP).
示例2：以下会话描述表示仅多播视频会话（使用H.261或H.263+），视频源接受编解码器的通用NACK和H.263的参考图片选择。这样的描述可能已经使用会话公告协议（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
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
The sender may use an incoming Generic NACK as a hint to send a new intra-frame as soon as possible (congestion control permitting). Receipt of a Reference Picture Selection Indication (RPSI) message allows the sender to avoid sending a large intra-frame; instead it may continue to send inter-frames, however, choosing the indicated frame as new encoding reference.
发送方可以使用传入的通用NACK作为提示，以尽快发送新的帧内帧（拥塞控制允许）。参考图片选择指示（RPSI）消息的接收允许发送方避免发送大帧内帧；然而，它可以继续发送帧间，选择所指示的帧作为新的编码参考。
Example 3: The following session description defines the same media session as example 2 but allows for mixed-mode operation of AVP and AVPF RTP entities (see also next section). Note that both media descriptions use the same addresses; however, two m= lines are needed to convey information about both applicable RTP profiles.
示例3：以下会话描述定义了与示例2相同的媒体会话，但允许AVP和AVPF RTP实体的混合模式操作（另请参见下一节）。请注意，两种媒体描述使用相同的地址；但是，需要两条m=线来传递有关两个适用RTP配置文件的信息。
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
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
Note that these two m= lines SHOULD be grouped by some appropriate mechanism to indicate that both are alternatives actually conveying the same contents. A sample framework by which this can be achieved is defined in [10].
请注意，这两条m=线应通过某种适当的机制进行分组，以表明这两条线实际上都是传输相同内容的备选线。[10]中定义了实现这一点的示例框架。
In this example, the RTCP feedback-enabled receivers will gain an occasional advantage to report events earlier back to the sender (which may benefit the entire group). On average, however, all RTP receivers will provide the same amount of feedback. The interworking between AVP and AVPF entities is discussed in depth in the next section.
在本例中，启用RTCP反馈的接收者偶尔会有机会提前向发送者报告事件（这可能会使整个团队受益）。然而，平均而言，所有RTP接收器将提供相同数量的反馈。下一节将深入讨论AVP和AVPF实体之间的互通。
The AVPF profile defined in this document is an extension of the AVP profile as defined in [2]. Both profiles follow the same basic rules (including the upper bandwidth limit for RTCP and the bandwidth assignments to senders and receivers). Therefore, senders and receivers using either of the two profiles can be mixed in a single session (see Example 3 in Section 4.5).
本文件中定义的AVPF配置文件是[2]中定义的AVP配置文件的扩展。这两个配置文件遵循相同的基本规则（包括RTCP的带宽上限以及发送端和接收端的带宽分配）。因此，使用两个配置文件中的任何一个的发送方和接收方可以在单个会话中混合使用（参见第4.5节中的示例3）。
AVP and AVPF are defined in a way that, from a robustness point of view, the RTP entities do not need to be aware of entities of the respective other profile: they will not disturb each other's functioning. However, the quality of the media presented may suffer.
AVP和AVPF的定义方式是，从健壮性的角度来看，RTP实体不需要知道各自的其他配置文件的实体：它们不会干扰彼此的功能。然而，媒体的质量可能会受到影响。
The following considerations apply to senders and receivers when used in a combined session.
在组合会话中使用时，以下注意事项适用于发送方和接收方。
o AVP entities (senders and receivers)
o AVP实体（发送方和接收方）
AVP senders will receive RTCP feedback packets from AVPF receivers and ignore these packets. They will see occasional closer spacing of RTCP messages (e.g., violating the five-second rule) by AVPF entities. As the overall bandwidth constraints are adhered to by both types of entities, they will still get their share of the RTCP bandwidth. However, while AVP entities are bound by the five-second rule, depending on the group size and session bandwidth, AVPF entities may provide more frequent RTCP reports than AVP ones will. Also, the overall reporting may decrease slightly as AVPF entities may send bigger compound RTCP packets (due to the extra RTCP packets).
AVP发送方将从AVPF接收方接收RTCP反馈数据包，并忽略这些数据包。AVPF实体偶尔会发现RTCP消息间隔更近（例如，违反五秒规则）。由于两种类型的实体都遵守总体带宽限制，因此它们仍将获得各自的RTCP带宽份额。然而，尽管AVP实体受5秒规则的约束，但取决于组大小和会话带宽，AVPF实体可能提供比AVP实体更频繁的RTCP报告。此外，由于AVPF实体可能发送更大的复合RTCP数据包（由于额外的RTCP数据包），因此总体报告可能会略有减少。
If T_rr_interval is used as lower bound between Regular RTCP packets, T_rr_interval is sufficiently large (e.g., T_rr_interval > M*Td as per Section 6.3.5 of [1]), and no Early RTCP packets are sent by AVPF entities, AVP entities may accidentally time out those AVPF group members and hence underestimate the group size. Therefore, if AVP entities may be involved in a media session, T_rr_interval SHOULD NOT be larger than five seconds.
如果T_rr_间隔用作常规RTCP数据包之间的下限，则T_rr_间隔足够大（例如，根据[1]第6.3.5节，T_rr_间隔>M*Td），并且AVPF实体未发送早期RTCP数据包，AVP实体可能会意外超时这些AVPF组成员，从而低估组大小。因此，如果AVP实体可能参与媒体会话，则T_rr_间隔不应大于5秒。
o AVPF entities (senders and receivers)
o AVPF实体（发送方和接收方）
If the dynamically calculated T_rr is sufficiently small (e.g., less than one second), AVPF entities may accidentally time out AVP group members and hence underestimate the group size. Therefore, if AVP entities may be involved in a media session, T_rr_interval SHOULD be used and SHOULD be set to five seconds.
如果动态计算的T_rr足够小（例如，小于1秒），AVPF实体可能会意外超时AVP组成员，从而低估组大小。因此，如果AVP实体可能参与媒体会话，则应使用T_rr_interval，并应将其设置为5秒。
In conclusion, if AVP entities may be involved in a media session and T_rr_interval is to be used, T_rr_interval SHOULD be set to five seconds.
总之，如果AVP实体可能参与媒体会话，并且要使用T_rr_间隔，则T_rr_间隔应设置为5秒。
o AVPF senders
o AVPF发送器
AVPF senders will receive feedback information only from AVPF receivers. If they rely on feedback to provide the target media quality, the quality achieved for AVP receivers may be suboptimal.
AVPF发送方将仅从AVPF接收方接收反馈信息。如果他们依靠反馈来提供目标媒体质量，AVP接收机所获得的质量可能是次优的。
o AVPF receivers
o AVPF接收机
AVPF receivers SHOULD send Early RTCP feedback packets only if all sending entities in the media session support AVPF. AVPF receivers MAY send feedback information as part of regularly scheduled compound RTCP packets following the timing rules of
仅当媒体会话中的所有发送实体都支持AVPF时，AVPF接收器才应发送早期RTCP反馈数据包。AVPF接收机可以按照定时规则发送反馈信息，作为定期调度的复合RTCP分组的一部分
[1] and [2] also in media sessions operating in mixed mode. However, the receiver providing feedback MUST NOT rely on the sender reacting to the feedback at all.
[1] [2]也在混合模式下运行的媒体会话中。然而，提供反馈的接收者绝不能依赖发送者对反馈的反应。
This section defines the format of the low-delay RTCP feedback messages. These messages are classified into three categories as follows:
本节定义了低延迟RTCP反馈消息的格式。这些信息分为以下三类：
- Transport layer FB messages - Payload-specific FB messages - Application layer FB messages
- 传输层FB消息-负载特定FB消息-应用层FB消息
Transport layer FB messages are intended to transmit general purpose feedback information, i.e., information independent of the particular codec or the application in use. The information is expected to be generated and processed at the transport/RTP layer. Currently, only a generic negative acknowledgement (NACK) message is defined.
传输层FB消息旨在传输通用反馈信息，即独立于特定编解码器或正在使用的应用程序的信息。信息预计将在传输/RTP层生成和处理。目前，仅定义了一般否定确认（NACK）消息。
Payload-specific FB messages transport information that is specific to a certain payload type and will be generated and acted upon at the codec "layer". This document defines a common header to be used in conjunction with all payload-specific FB messages. The definition of specific messages is left either to RTP payload format specifications or to additional feedback format documents.
特定于有效负载的FB消息传输特定于特定有效负载类型的信息，并将在编解码器“层”生成和执行。本文档定义了一个与所有特定于有效负载的FB消息一起使用的通用标头。特定消息的定义留给RTP有效负载格式规范或其他反馈格式文档。
Application layer FB messages provide a means to transparently convey feedback from the receiver's to the sender's application. The information contained in such a message is not expected to be acted upon at the transport/RTP or the codec layer. The data to be exchanged between two application instances is usually defined in the application protocol specification and thus can be identified by the application so that there is no need for additional external information. Hence, this document defines only a common header to be used along with all application layer FB messages. From a protocol point of view, an application layer FB message is treated as a special case of a payload-specific FB message.
应用层FB消息提供了一种将接收方的反馈透明地传递给发送方的应用程序的方法。此类消息中包含的信息预计不会在传输/RTP或编解码器层上进行操作。两个应用程序实例之间要交换的数据通常在应用程序协议规范中定义，因此可以由应用程序识别，因此不需要额外的外部信息。因此，本文档仅定义一个与所有应用层FB消息一起使用的公共头。从协议的角度来看，应用层FB消息被视为特定于有效负载的FB消息的特例。
Note: Proper processing of some FB messages at the media sender side may require the sender to know which payload type the FB message refers to. Most of the time, this knowledge can likely be derived from a media stream using only a single payload type. However, if several codecs are used simultaneously (e.g., with audio and DTMF) or when codec changes occur, the payload type information may need to be conveyed explicitly as part of the FB message. This applies to all
注意：在媒体发送方端正确处理某些FB消息可能需要发送方知道FB消息所指的有效负载类型。大多数情况下，这些知识可能仅使用单一有效负载类型从媒体流中获得。然而，如果同时使用多个编解码器（例如，与音频和DTMF一起使用），或者当编解码器发生变化时，可能需要作为FB消息的一部分显式地传送有效负载类型信息。这适用于所有人
payload-specific as well as application layer FB messages. It is up to the specification of an FB message to define how payload type information is transmitted.
特定于负载以及应用层FB消息。如何传输有效负载类型信息取决于FB消息的规范。
This document defines two transport layer and three (video) payload-specific FB messages as well as a single container for application layer FB messages. Additional transport layer and payload-specific FB messages MAY be defined in other documents and MUST be registered through IANA (see Section 9, "IANA Considerations").
本文档定义了两个传输层和三个（视频）特定于负载的FB消息，以及应用层FB消息的单个容器。其他文件中可能会定义额外的传输层和负载特定的FB消息，并且必须通过IANA进行注册（参见第9节“IANA注意事项”）。
The general syntax and semantics for the above RTCP FB message types are described in the following subsections.
以下小节描述了上述RTCP FB消息类型的一般语法和语义。
All FB messages MUST use a common packet format that is depicted in Figure 3:
所有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) :
: :
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) :
: :
Figure 3: Common Packet Format for Feedback Messages
图3：反馈消息的通用数据包格式
The fields V, P, SSRC, and length are defined in the RTP specification [2], the respective meaning being summarized below:
RTP规范[2]中定义了字段V、P、SSRC和长度，其各自含义总结如下：
version (V): 2 bits This field identifies the RTP version. The current version is 2.
版本（V）：2位此字段标识RTP版本。目前的版本是2。
padding (P): 1 bit If set, the padding bit indicates that the packet contains additional padding octets at the end that are not part of the control information but are included in the length field.
padding（P）：1位如果设置，则padding位表示数据包末尾包含额外的padding八位字节，这些八位字节不属于控制信息的一部分，但包含在长度字段中。
Feedback message type (FMT): 5 bits This field identifies the type of the FB message and is interpreted relative to the type (transport layer, payload-specific, or application layer feedback). The values for each of the three feedback types are defined in the respective sections below.
反馈消息类型（FMT）：5位此字段标识FB消息的类型，并根据类型（传输层、特定负载或应用层反馈）进行解释。三种反馈类型中每种类型的值在以下各节中定义。
Payload type (PT): 8 bits This is the RTCP packet type that identifies the packet as being an RTCP FB message. Two values are defined by the IANA:
有效负载类型（PT）：8位这是将数据包标识为RTCP FB消息的RTCP数据包类型。IANA定义了两个值：
Name | Value | Brief Description
----------+-------+------------------------------------
RTPFB | 205 | Transport layer FB message
PSFB | 206 | Payload-specific FB message
Name | Value | Brief Description
----------+-------+------------------------------------
RTPFB | 205 | Transport layer FB message
PSFB | 206 | Payload-specific FB message
Length: 16 bits The length of this packet in 32-bit words minus one, including the header and any padding. This is in line with the definition of the length field used in RTCP sender and receiver reports [3].
长度：16位此数据包的长度（32位字减去1），包括标头和任何填充。这与RTCP发送方和接收方报告中使用的长度字段的定义一致[3]。
SSRC of packet sender: 32 bits The synchronization source identifier for the originator of this packet.
数据包发送方的SSRC：32位此数据包发起方的同步源标识符。
SSRC of media source: 32 bits The synchronization source identifier of the media source that this piece of feedback information is related to.
媒体源SSRC：32位此反馈信息相关的媒体源的同步源标识符。
Feedback Control Information (FCI): variable length The following three sections define which additional information MAY be included in the FB message for each type of feedback: transport layer, payload-specific, or application layer feedback. Note that further FCI contents MAY be specified in further documents.
反馈控制信息（FCI）：可变长度以下三个部分定义了每种反馈类型的FB消息中可能包含的附加信息：传输层、特定负载或应用层反馈。请注意，进一步的FCI内容可能会在进一步的文件中指定。
Each RTCP feedback packet MUST contain at least one FB message in the FCI field. Sections 6.2 and 6.3 define for each FCI type, whether or not multiple FB messages MAY be compressed into a single FCI field. If this is the case, they MUST be of the same type, i.e., same FMT. If multiple types of feedback messages, i.e., several FMTs, need to be conveyed, then several RTCP FB messages MUST be generated and SHOULD be concatenated in the same compound RTCP packet.
每个RTCP反馈数据包必须在FCI字段中至少包含一条FB消息。第6.2节和第6.3节定义了每种FCI类型，是否可以将多条FB消息压缩到单个FCI字段中。如果是这种情况，它们必须是相同类型的，即相同的FMT。如果需要传输多种类型的反馈消息，即多个FMT，则必须生成多个RTCP FB消息，并将其连接在同一复合RTCP数据包中。
Transport layer FB messages are identified by the value RTPFB as RTCP message type.
传输层FB消息由值RTPFB标识为RTCP消息类型。
A single general purpose transport layer FB message is defined in this document: Generic NACK. It is identified by means of the FMT parameter as follows:
本文档中定义了一条通用传输层FB消息：通用NACK。FMT通过以下参数进行识别：
0: unassigned 1: Generic NACK 2-30: unassigned 31: reserved for future expansion of the identifier number space
0:unassigned 1:Generic NACK 2-30:unassigned 31:保留用于将来扩展标识符编号空间
The following subsection defines the formats of the FCI field for this type of FB message. Further generic feedback messages MAY be defined in the future.
以下小节定义了此类FB消息的FCI字段格式。将来可能会定义更多的通用反馈消息。
The Generic NACK message is identified by PT=RTPFB and FMT=1.
通用NACK消息由PT=RTPFB和FMT=1标识。
The FCI field MUST contain at least one and MAY contain more than one Generic NACK.
FCI字段必须至少包含一个，并且可以包含多个通用NACK。
The Generic NACK is used to indicate the loss of one or more RTP packets. The lost packet(s) are identified by the means of a packet identifier and a bit mask.
通用NACK用于指示一个或多个RTP分组的丢失。丢失的分组通过分组标识符和位掩码来识别。
Generic NACK feedback SHOULD NOT be used if the underlying transport protocol is capable of providing similar feedback information to the sender (as may be the case, e.g., with DCCP).
如果基础传输协议能够向发送方提供类似的反馈信息，则不应使用通用NACK反馈（如DCCP）。
The Feedback Control Information (FCI) field has the following Syntax (Figure 4):
反馈控制信息（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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Syntax for the Generic NACK message
图4：通用NACK消息的语法
Packet ID (PID): 16 bits The PID field is used to specify a lost packet. The PID field refers to the RTP sequence number of the lost packet.
数据包ID（PID）：16位PID字段用于指定丢失的数据包。PID字段是指丢失数据包的RTP序列号。
bitmask of following lost packets (BLP): 16 bits The BLP allows for reporting losses of any of the 16 RTP packets immediately following the RTP packet indicated by the PID. The BLP's definition is identical to that given in [6]. Denoting the BLP's least significant bit as bit 1, and its most significant bit as bit 16, then bit i of the bit mask is set to 1 if the receiver has not received RTP packet number (PID+i) (modulo 2^16) and indicates this packet is lost; bit i is set to 0 otherwise. Note that the sender MUST NOT assume that a receiver has received a packet because its bit mask was set to 0. For example, the least significant bit of the BLP would be set to 1 if the packet corresponding to the PID and the following packet have been lost. However, the sender cannot infer that packets PID+2 through PID+16 have been received simply because bits 2 through 15 of the BLP are 0; all the sender knows is that the receiver has not reported them as lost at this time.
以下丢失数据包的位掩码（BLP）：16位BLP允许在PID指示的RTP数据包之后立即报告16个RTP数据包中的任何一个的丢失。BLP的定义与[6]中给出的定义相同。将BLP的最低有效位表示为位1，将其最高有效位表示为位16，然后，如果接收器未接收到RTP分组号（PID+i）（模2^16）并指示该分组丢失，则将位掩码的位i设置为1；否则，位i设置为0。请注意，发送方不能因为其位掩码设置为0而假设接收方已收到数据包。例如，如果与PID对应的分组和以下分组已经丢失，则BLP的最低有效位将被设置为1。然而，发送方不能仅仅因为BLP的比特2到15为0而推断已经接收到分组PID+2到PID+16；发送者只知道接收者此时没有将其报告为丢失。
The length of the FB message MUST be set to 2+n, with n being the number of Generic NACKs contained in the FCI field.
FB消息的长度必须设置为2+n，n是FCI字段中包含的通用NACK数。
The Generic NACK message implicitly references the payload type through the sequence number(s).
通用NACK消息通过序列号隐式引用有效负载类型。
Payload-Specific FB messages are identified by the value PT=PSFB as RTCP message type.
有效负载特定的FB消息由值PT=PSFB标识为RTCP消息类型。
Three payload-specific FB messages are defined so far plus an application layer FB message. They are identified by means of the FMT parameter as follows:
到目前为止，定义了三条特定于有效负载的FB消息以及一条应用层FB消息。它们通过FMT参数识别，如下所示：
0: unassigned 1: Picture Loss Indication (PLI) 2: Slice Loss Indication (SLI) 3: Reference Picture Selection Indication (RPSI) 4-14: unassigned 15: Application layer FB (AFB) message 16-30: unassigned 31: reserved for future expansion of the sequence number space
0:未分配1:图片丢失指示（PLI）2:切片丢失指示（SLI）3:参考图片选择指示（RPSI）4-14:未分配15:应用层FB（AFB）消息16-30:未分配31:保留用于序列号空间的未来扩展
The following subsections define the FCI formats for the payload-specific FB messages, Section 6.4 defines FCI format for the application layer FB message.
以下小节定义了有效负载特定FB消息的FCI格式，第6.4节定义了应用层FB消息的FCI格式。
The PLI FB message is identified by PT=PSFB and FMT=1.
PLI FB消息由PT=PSFB和FMT=1标识。
There MUST be exactly one PLI contained in the FCI field.
FCI字段中必须正好包含一个PLI。
With the Picture Loss Indication message, a decoder informs the encoder about the loss of an undefined amount of coded video data belonging to one or more pictures. When used in conjunction with any video coding scheme that is based on inter-picture prediction, an encoder that receives a PLI becomes aware that the prediction chain may be broken. The sender MAY react to a PLI by transmitting an intra-picture to achieve resynchronization (making this message effectively similar to the FIR message as defined in [6]); however, the sender MUST consider congestion control as outlined in Section 7, which MAY restrict its ability to send an intra frame.
利用图片丢失指示消息，解码器将属于一个或多个图片的未定义量的编码视频数据的丢失通知编码器。当与基于画面间预测的任何视频编码方案结合使用时，接收PLI的编码器意识到预测链可能被中断。发送方可通过发送帧内图片对PLI作出反应以实现再同步（使该消息有效地类似于[6]中定义的FIR消息）；然而，发送方必须考虑如第7节所述的拥塞控制，这可能限制其发送帧内的能力。
Other RTP payload specifications such as RFC 2032 [6] already define a feedback mechanism for some for certain codecs. An application supporting both schemes MUST use the feedback mechanism defined in this specification when sending feedback. For backward compatibility reasons, such an application SHOULD also be capable to receive and react to the feedback scheme defined in the respective RTP payload format, if this is required by that payload format.
其他RTP有效负载规范（如RFC 2032[6]）已经为某些特定编解码器定义了反馈机制。支持这两种方案的应用程序在发送反馈时必须使用本规范中定义的反馈机制。出于向后兼容性的原因，如果有效载荷格式需要，这样的应用程序还应该能够接收在各自的RTP有效载荷格式中定义的反馈方案并对其作出反应。
PLI does not require parameters. Therefore, the length field MUST be 2, and there MUST NOT be any Feedback Control Information.
PLI不需要参数。因此，长度字段必须为2，并且不得有任何反馈控制信息。
The semantics of this FB message is independent of the payload type.
此FB消息的语义与有效负载类型无关。
The timing follows the rules outlined in Section 3. In systems that employ both PLI and other types of feedback, it may be advisable to follow the Regular RTCP RR timing rules for PLI, since PLI is not as delay critical as other FB types.
时间安排遵循第3节中概述的规则。在同时采用PLI和其他类型反馈的系统中，建议遵循PLI的常规RTCP RR定时规则，因为PLI不像其他FB类型那样对延迟至关重要。
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
PLI消息通常触发完整帧内图片的发送。帧内图片比预测（帧间）图片大几倍。它们的大小与生成它们的时间无关。在大多数环境中，特别是在使用带宽有限的链路时，使用帧内图片意味着允许的延迟，即
significant multitude of the typical frame duration. An example: If the sending frame rate is 10 fps, and an intra-picture is assumed to be 10 times as big as an inter-picture, then a full second of latency has to be accepted. In such an environment, there is no need for a particular short delay in sending the FB message. Hence, waiting for the next possible time slot allowed by RTCP timing rules as per [2] with Tmin=0 does not have a negative impact on the system performance.
大量的典型帧持续时间。例如：如果发送帧速率为10 fps，并且假设帧内图片是帧间图片的10倍大，则必须接受整整一秒的延迟。在这种环境中，发送FB消息时不需要特定的短延迟。因此，根据[2]，在Tmin=0的情况下等待RTCP定时规则允许的下一个可能的时隙不会对系统性能产生负面影响。
The SLI FB message is identified by PT=PSFB and FMT=2.
SLI FB消息由PT=PSFB和FMT=2标识。
The FCI field MUST contain at least one and MAY contain more than one SLI.
FCI字段必须至少包含一个，并且可以包含多个SLI。
With the Slice Loss Indication, a decoder can inform an encoder that it has detected the loss or corruption of one or several consecutive macroblock(s) in scan order (see below). This FB message MUST NOT be used for video codecs with non-uniform, dynamically changeable macroblock sizes such as H.263 with enabled Annex Q. In such a case, an encoder cannot always identify the corrupted spatial region.
利用片丢失指示，解码器可以通知编码器它已检测到一个或多个连续宏块按扫描顺序丢失或损坏（见下文）。此FB消息不得用于具有非统一、动态可变宏块大小的视频编解码器，如启用附录Q的H.263。在这种情况下，编码器无法始终识别损坏的空间区域。
The Slice Loss Indication uses one additional FCI field, the content of which is depicted in Figure 6. The length of the FB message MUST be set to 2+n, with n being the number of SLIs contained in the FCI field.
切片丢失指示使用一个额外的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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Syntax of the Slice Loss Indication (SLI)
图6：切片丢失指示（SLI）的语法
First: 13 bits The macroblock (MB) address of the first lost macroblock. The MB numbering is done such that the macroblock in the upper left corner of the picture is considered macroblock number 1 and the number for each macroblock increases from left to right and then from top to bottom in raster-scan order (such that if there is a total of N macroblocks in a picture, the bottom right macroblock is considered macroblock number N).
第一：13位第一个丢失宏块的宏块（MB）地址。进行MB编号，使得图片左上角的宏块被视为宏块编号1，并且每个宏块的编号按照光栅扫描顺序从左到右然后从上到下增加（这样，如果图片中总共有N个宏块，则右下宏块被视为宏块编号N）。
Number: 13 bits The number of lost macroblocks, in scan order as discussed above.
数字：13位丢失宏块的数量，按上面讨论的扫描顺序。
PictureID: 6 bits The six least significant bits of the codec-specific identifier that is used to reference the picture in which the loss of the macroblock(s) has occurred. For many video codecs, the PictureID is identical to the Temporal Reference.
PictureID:6位编解码器特定标识符的六个最低有效位，用于引用发生宏块丢失的图片。对于许多视频编解码器，PictureID与时间参考相同。
The applicability of this FB message is limited to a small set of video codecs; therefore, no explicit payload type information is provided.
此FB消息的适用性仅限于一小部分视频编解码器；因此，没有提供明确的有效负载类型信息。
The efficiency of algorithms using the Slice Loss Indication is reduced greatly when the Indication is not transmitted in a timely fashion. Motion compensation propagates corrupted pixels that are not reported as being corrupted. Therefore, the use of the algorithm discussed in Section 3 is highly recommended.
当指示没有及时传输时，使用切片丢失指示的算法的效率大大降低。运动补偿传播未报告为损坏的损坏像素。因此，强烈建议使用第3节中讨论的算法。
The term Slice is defined and used here in the sense of MPEG-1 -- a consecutive number of macroblocks in scan order. More recent video coding standards sometimes have a different understanding of the term Slice. In H.263 (1998), for example, a concept known as "rectangular slice" exists. The loss of one rectangular slice may lead to the necessity of sending more than one SLI in order to precisely identify the region of lost/damaged MBs.
术语Slice在这里是按照MPEG-1定义和使用的，MPEG-1是按扫描顺序的连续宏块数。最近的视频编码标准有时对术语切片有不同的理解。例如，在H.263（1998）中，存在一个称为“矩形切片”的概念。一个矩形切片的丢失可能导致需要发送多个SLI，以便准确识别丢失/损坏MBs的区域。
The first field of the FCI defines the first macroblock of a picture as 1 and not, as one could suspect, as 0. This was done to align this specification with the comparable mechanism available in ITU-T Rec. H.245 [24]. The maximum number of macroblocks in a picture (2**13 or 8192) corresponds to the maximum picture sizes of most of the ITU-T and ISO/IEC video codecs. If future video codecs offer larger picture sizes and/or smaller macroblock sizes, then an additional FB message has to be defined. The six least significant bits of the Temporal Reference field are deemed to be sufficient to indicate the picture in which the loss occurred.
FCI的第一个字段将图片的第一个宏块定义为1，而不是人们可能怀疑的0。这样做是为了使本规范与ITU-T Rec.H.245[24]中提供的类似机制保持一致。图片中的最大宏块数（2**13或8192）对应于大多数ITU-T和ISO/IEC视频编解码器的最大图片大小。如果未来的视频编解码器提供更大的图片大小和/或更小的宏块大小，则必须定义额外的FB消息。时间参考场的六个最低有效位被认为足以指示发生丢失的画面。
The reaction to an SLI is not part of this specification. One typical way of reacting to an SLI is to use intra refresh for the affected spatial region.
对SLI的反应不属于本规范的一部分。对SLI作出反应的一种典型方式是对受影响的空间区域使用帧内刷新。
Algorithms were reported that keep track of the regions affected by motion compensation, in order to allow for a transmission of Intra macroblocks to all those areas, regardless of the timing of the FB (see H.263 (2000) Appendix I [17] and [15]). Although the timing of the FB is less critical when those algorithms are used than if they are not, it has to be observed that those algorithms correct large parts of the picture and, therefore, have to transmit much higher data volume in case of delayed FBs.
报告了跟踪受运动补偿影响的区域的算法，以便允许将帧内宏块传输到所有这些区域，而与FB的定时无关（见H.263（2000）附录I[17]和[15]）。尽管当使用这些算法时，FB的定时比不使用这些算法时不那么关键，但必须观察到，这些算法校正了图片的大部分，因此，在FB延迟的情况下，必须传输更高的数据量。
The RPSI FB message is identified by PT=PSFB and FMT=3.
RPSI FB消息由PT=PSFB和FMT=3标识。
There MUST be exactly one RPSI contained in the FCI field.
FCI字段中必须正好包含一个RPSI。
Modern video coding standards such as MPEG-4 visual version 2 [16] or H.263 version 2 [17] allow using older reference pictures than the most recent one for predictive coding. Typically, a first-in-first-out queue of reference pictures is maintained. If an encoder has learned about a loss of encoder-decoder synchronicity, a known-as-correct reference picture can be used. As this reference picture is temporally further away then usual, the resulting predictively coded picture will use more bits.
现代视频编码标准，如MPEG-4 visual version 2[16]或H.263 version 2[17]，允许使用比最新参考图片更旧的参考图片进行预测编码。通常，保持参考图片的先进先出队列。如果编码器了解到编码器-解码器同步性丢失，则可以使用称为正确参考图片的图像。由于该参考图片在时间上比平常更远，因此产生的预测编码图片将使用更多比特。
Both MPEG-4 and H.263 define a binary format for the "payload" of an RPSI message that includes information such as the temporal ID of the damaged picture and the size of the damaged region. This bit string is typically small (a couple of dozen bits), of variable length, and self-contained, i.e., contains all information that is necessary to perform reference picture selection.
MPEG-4和H.263都为RPSI消息的“有效载荷”定义了二进制格式，该RPSI消息包括诸如受损图片的时间ID和受损区域的大小之类的信息。该位串通常很小（几十位）、长度可变且自包含，即包含执行参考图片选择所需的所有信息。
Both MPEG-4 and H.263 allow the use of RPSI with positive feedback information as well. That is, pictures (or Slices) are reported that were decoded without error. Note that any form of positive feedback MUST NOT be used when in a multiparty session (reporting positive feedback about individual reference pictures at RTCP intervals is not expected to be of much use anyway).
MPEG-4和H.263都允许使用带有正反馈信息的RPSI。也就是说，报告的图片（或切片）解码无误。请注意，在多方会话中，不得使用任何形式的正反馈（以RTCP间隔报告有关单个参考图片的正反馈无论如何都不会有多大用处）。
The FCI for the RPSI message follows the format depicted in Figure 7:
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Syntax of the Reference Picture Selection Indication (RPSI)
图7：参考图片选择指示（RPSI）的语法
PB: 8 bits The number of unused bits required to pad the length of the RPSI message to a multiple of 32 bits.
PB:8位将RPSI消息长度填充为32位的倍数所需的未使用位数。
0: 1 bit MUST be set to zero upon transmission and ignored upon reception.
0:1位必须在传输时设置为零，在接收时忽略。
Payload Type: 7 bits Indicates the RTP payload type in the context of which the native RPSI bit string MUST be interpreted.
有效负载类型：7位表示必须在其上下文中解释本机RPSI位字符串的RTP有效负载类型。
Native RPSI bit string: variable length The RPSI information as natively defined by the video codec.
本机RPSI位字符串：可变长度视频编解码器本机定义的RPSI信息。
Padding: #PB bits A number of bits set to zero to fill up the contents of the RPSI message to the next 32-bit boundary. The number of padding bits MUST be indicated by the PB field.
填充：#PB位设置为零的位数，用于将RPSI消息的内容填充到下一个32位边界。填充位数必须由PB字段指示。
RPSI is even more critical to delay than algorithms using SLI. This is because the older the RPSI message is, the more bits the encoder has to spend to re-establish encoder-decoder synchronicity. See [15] for some information about the overhead of RPSI for certain bit rate/frame rate/loss rate scenarios.
RPSI比使用SLI的算法对延迟更为关键。这是因为RPSI消息越老，编码器需要花费的比特数就越多，以重新建立编码器-解码器的同步性。有关特定比特率/帧速率/丢失率情况下RPSI开销的一些信息，请参见[15]。
Therefore, RPSI messages should typically be sent as soon as possible, employing the algorithm of Section 3.
因此，通常应使用第3节的算法尽快发送RPSI消息。
Application layer FB messages are a special case of payload-specific messages and are identified by PT=PSFB and FMT=15. There MUST be exactly one application layer FB message contained in the FCI field, unless the application layer FB message structure itself allows for stacking (e.g., by means of a fixed size or explicit length indicator).
应用层FB消息是特定于有效负载的消息的特例，由PT=PSFB和FMT=15标识。FCI字段中必须仅包含一条应用层FB消息，除非应用层FB消息结构本身允许堆叠（例如，通过固定大小或显式长度指示器）。
These messages are used to transport application-defined data directly from the receiver's to the sender's application. The data that is transported is not identified by the FB message. Therefore, the application MUST be able to identify the message payload.
这些消息用于将应用程序定义的数据直接从接收方的应用程序传输到发送方的应用程序。FB消息未识别传输的数据。因此，应用程序必须能够识别消息负载。
Usually, applications define their own set of messages, e.g., NEWPRED messages in MPEG-4 [16] (carried in RTP packets according to RFC 3016 [23]) or FB messages in H.263/Annex N, U [17] (packetized as per RFC 2429 [14]). These messages do not need any additional information from the RTCP message. Thus, the application message is simply placed into the FCI field as follows and the length field is set accordingly.
通常，应用程序定义自己的消息集，例如，MPEG-4[16]中的NEWPRED消息（根据RFC 3016[23]在RTP包中携带）或H.263/附录N，U[17]中的FB消息（根据RFC 2429[14]打包）。这些消息不需要来自RTCP消息的任何附加信息。因此，应用程序消息被简单地放置到FCI字段中，如下所示，并且相应地设置长度字段。
Application Message (FCI): variable length This field contains the original application message that should be transported from the receiver to the source. The format is application dependent. The length of this field is variable. If the application data is not 32-bit aligned, padding bits and bytes MUST be added to achieve 32-bit alignment. Identification of padding is up to the application layer and not defined in this specification.
应用程序消息（FCI）：可变长度此字段包含应从接收方传输到源的原始应用程序消息。格式取决于应用程序。此字段的长度是可变的。如果应用程序数据未32位对齐，则必须添加填充位和字节以实现32位对齐。填充标识由应用层决定，本规范中未定义。
The application layer FB message specification MUST define whether or not the message needs to be interpreted specifically in the context of a certain codec (identified by the RTP payload type). If a reference to the payload type is required for proper processing, the application layer FB message specification MUST define a way to communicate the payload type information as part of the application layer FB message itself.
应用层FB消息规范必须定义是否需要在特定编解码器（由RTP有效负载类型标识）的上下文中专门解释消息。如果正确处理需要对有效负载类型的引用，则应用层FB消息规范必须定义将有效负载类型信息作为应用层FB消息本身的一部分进行通信的方式。
In the previous sections, the FB messages were defined as well as the timing rules according to which to send these messages. The way to react to the feedback received depends on the application using the feedback mechanisms and hence is beyond the scope of this document.
在前面的章节中，定义了FB消息以及发送这些消息所依据的定时规则。对收到的反馈作出反应的方式取决于使用反馈机制的应用程序，因此超出了本文档的范围。
However, across all applications, there is a common requirement for (TCP-friendly) congestion control on the media stream as defined in [1] and [2] when operating in a best-effort network environment.
但是，在所有应用程序中，当在尽力而为的网络环境中运行时，对[1]和[2]中定义的媒体流有一个共同的（TCP友好的）拥塞控制要求。
It should be noted that RTCP feedback itself is insufficient for congestion control purposes as it is likely to operate at much slower timescales than other transport layer feedback mechanisms (that usually operate in the order of RTT). Therefore, additional mechanisms are required to perform proper congestion control.
应该注意的是，RTCP反馈本身不足以用于拥塞控制目的，因为它可能比其他传输层反馈机制（通常按照RTT的顺序运行）运行得慢得多。因此，需要额外的机制来执行适当的拥塞控制。
A congestion control algorithm that shares the available bandwidth reasonably fairly with competing TCP connections, e.g., TFRC [7], MUST be used to determine the data rate for the media stream within the bounds of the RTP sender's and the media session's capabilities if the RTP/AVPF session is transmitted in a best-effort environment.
如果在尽力而为的环境中传输RTP/AVPF会话，则必须使用与竞争TCP连接合理公平地共享可用带宽的拥塞控制算法（例如TFRC[7]）来确定RTP发送方和媒体会话能力范围内的媒体流数据速率。
RTP packets transporting information with the proposed payload format are subject to the security considerations discussed in the RTP specification [1] and in the RTP/AVP profile specification [2]. This profile does not specify any additional security services.
使用提议的有效载荷格式传输信息的RTP数据包受RTP规范[1]和RTP/AVP配置文件规范[2]中讨论的安全考虑的约束。此配置文件未指定任何其他安全服务。
This profile modifies the timing behavior of RTCP and eliminates the minimum RTCP interval of five seconds and allows for earlier feedback to be provided by receivers. Group members of the associated RTP session (possibly pretending to represent a large number of entities) may disturb the operation of RTCP by sending large numbers of RTCP packets thereby reducing the RTCP bandwidth available for Regular RTCP reporting as well as for Early FB messages. (Note that an entity need not be a member of a multicast group to cause these effects.) Similarly, malicious members may send very large RTCP messages, thereby increasing the avg_rtcp_size variable and reducing the effectively available RTCP bandwidth.
此配置文件修改RTCP的定时行为，并消除5秒的最小RTCP间隔，并允许接收机提供早期反馈。相关RTP会话的组成员（可能假装代表大量实体）可能通过发送大量RTCP数据包来干扰RTCP的操作，从而减少可用于常规RTCP报告以及早期FB消息的RTCP带宽。（请注意，实体不必是多播组的成员即可造成这些影响。）类似地，恶意成员可能会发送非常大的RTCP消息，从而增加avg_RTCP_大小变量并减少有效可用的RTCP带宽。
Feedback information may be suppressed if unknown RTCP feedback packets are received. This introduces the risk of a malicious group member reducing Early feedback by simply transmitting payload-specific RTCP feedback packets with random contents that are not recognized by any receiver (so they will suppress feedback) or by the sender (so no repair actions will be taken).
如果接收到未知RTCP反馈数据包，则可能会抑制反馈信息。这引入了恶意组成员通过简单地传输特定于有效负载的RTCP反馈数据包来减少早期反馈的风险，该数据包包含任何接收方（因此它们将抑制反馈）或发送方（因此不会采取修复措施）无法识别的随机内容。
A malicious group member can also report arbitrary high loss rates in the feedback information to make the sender throttle the data transmission and increase the amount of redundancy information or take other action to deal with the pretended packet loss (e.g., send fewer frames or decrease audio/video quality). This may result in a degradation of the quality of the reproduced media stream.
恶意组成员还可以报告反馈信息中的任意高丢失率，以使发送方限制数据传输并增加冗余信息量，或采取其他措施来处理假装的数据包丢失（例如，发送更少的帧或降低音频/视频质量）。这可能导致再现媒体流的质量降低。
Finally, a malicious group member can act as a large number of group members and thereby obtain an artificially large share of the Early feedback bandwidth and reduce the reactivity of the other group members -- possibly even causing them to no longer operate in Immediate or Early feedback mode and thus undermining the whole purpose of this profile.
最后恶意的组成员可以充当大量的组成员，从而人为地获得早期反馈带宽的很大份额，并降低其他组成员的反应性——甚至可能导致他们不再以即时或早期反馈模式运行，从而破坏此配置文件的整体用途。
Senders as well as receivers SHOULD behave conservatively when observing strange reporting behavior. For excessive failure reporting from one or a few receivers, the sender MAY decide to no longer consider this feedback when adapting its transmission behavior for the media stream. In any case, senders and receivers SHOULD still adhere to the maximum RTCP bandwidth but make sure that they are capable of transmitting at least regularly scheduled RTCP packets. Senders SHOULD carefully consider how to adjust their transmission bandwidth when encountering strange reporting behavior; they MUST NOT increase their transmission bandwidth even if ignoring suspicious feedback.
当观察到奇怪的报告行为时，发送者和接收者都应该谨慎行事。对于来自一个或几个接收器的过度失败报告，发送者可能决定在考虑其对媒体流的传输行为时不再考虑该反馈。在任何情况下，发送方和接收方仍应遵守最大RTCP带宽，但应确保它们至少能够传输定期调度的RTCP数据包。发送者应仔细考虑如何在遇到奇怪的报告行为时调整其传输带宽；即使忽略可疑反馈，他们也不得增加传输带宽。
Attacks using false RTCP packets (Regular as well as Early ones) can be avoided by authenticating all RTCP messages. This can be achieved by using the AVPF profile together with the Secure RTP profile as defined in [22]; as a prerequisite, an appropriate combination of those two profiles (an "SAVPF") is being specified [21]. Note that, when employing group authentication (as opposed to source authentication), the aforementioned attacks may be carried out by malicious or malfunctioning group members in possession of the right keying material.
通过验证所有RTCP消息，可以避免使用错误RTCP数据包（常规数据包和早期数据包）的攻击。这可以通过使用AVPF配置文件和[22]中定义的安全RTP配置文件来实现；作为一个先决条件，正在指定这两个配置文件的适当组合（“SAVPF”）[21]。注意，当采用组身份验证（与源身份验证相反）时，上述攻击可能由拥有正确密钥材料的恶意或故障组成员执行。
The following contact information shall be used for all registrations included here:
以下联系信息应用于此处包含的所有注册：
Contact: Joerg Ott
mailto:jo@acm.org
tel:+358-9-451-2460
Contact: Joerg Ott
mailto:jo@acm.org
tel:+358-9-451-2460
The feedback profile as an extension to the profile for audio-visual conferences with minimal control has been registered for the Session Description Protocol (specifically the type "proto"): "RTP/AVPF".
反馈配置文件作为具有最小控制的视听会议配置文件的扩展已注册为会话描述协议（特别是类型“proto”）：“RTP/AVPF”。
SDP Protocol ("proto"):
SDP协议（“协议”）：
Name: RTP/AVPF Long form: Extended RTP Profile with RTCP-based Feedback Type of name: proto Type of attribute: Media level only Purpose: RFC 4585 Reference: RFC 4585
名称：RTP/AVPF长格式：基于RTCP的反馈的扩展RTP配置文件名称类型：属性原型：仅媒体级别用途：RFC 4585参考：RFC 4585
SDP Attribute ("att-field"):
SDP属性（“att字段”）：
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长格式：rtcp反馈参数名称类型：att字段属性类型：仅符合字符集的媒体级别：无用途：RFC 4585参考：RFC 4585值：请参阅以下文档和注册
A new registry has been set up for the "rtcp-fb" attribute, with the following registrations created initially: "ack", "nack", "trr-int", and "app" as defined in this document.
已为“rtcp fb”属性设置了一个新的注册表，初始创建了以下注册表：“ack”、“nack”、“trr int”和“app”，如本文件所定义。
Initial value registration for the attribute "rtcp-fb"
属性“rtcp fb”的初始值注册
Value name: ack Long name: Positive acknowledgement Reference: RFC 4585.
值名称：确认长名称：肯定确认参考：RFC 4585。
Value name: nack Long name: Negative Acknowledgement Reference: RFC 4585.
值名称：nack长名称：否定确认参考：RFC 4585。
Value name: trr-int Long name: Minimal receiver report interval Reference: RFC 4585.
值名称：trr int Long名称：最小接收器报告间隔参考：RFC 4585。
Value name: app Long name: Application-defined parameter Reference: RFC 4585.
值名称：应用程序长名称：应用程序定义的参数引用：RFC 4585。
Further entries may be registered on a first-come first-serve basis. Each new registration needs to indicate the parameter name and the syntax of possible additional arguments. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter, the syntax and semantics of its parameters as well as
其他参赛作品可按先到先得的原则登记。每个新注册都需要指明参数名和可能的附加参数的语法。对于每个新注册，必须存在一个永久、稳定且可公开访问的文档，该文档指定注册参数的语义、其参数的语法和语义以及
corresponding feedback packet formats (if needed). The general registration procedures of [3] apply.
相应的反馈数据包格式（如果需要）。[3]中的一般注册程序适用。
For use with both "ack" and "nack", a joint sub-registry has been set up that initially registers the following values:
为了与“ack”和“nack”一起使用，已建立一个联合子注册表，该注册表最初注册以下值：
Initial value registration for the attribute values "ack" and "nack":
属性值“ack”和“nack”的初始值注册：
Value name: sli Long name: Slice Loss Indication Usable with: nack Reference: RFC 4585.
值名称：sli长名称：切片丢失指示可用于：nack参考：RFC 4585。
Value name: pli Long name: Picture Loss Indication Usable with: nack Reference: RFC 4585.
值名称：pli长名称：图像丢失指示可用于：nack参考：RFC 4585。
Value name: rpsi Long name: Reference Picture Selection Indication Usable with: ack, nack Reference: RFC 4585.
值名称：rpsi长名称：参考图片选择指示可用于：ack，nack参考：RFC 4585。
Value name: app Long name: Application layer feedback Usable with: ack, nack Reference: RFC 4585.
值名称：应用程序长名称：应用程序层反馈可用：ack，nack参考：RFC 4585。
Further entries may be registered on a first-come first-serve basis. Each registration needs to indicate the parameter name, the syntax of possible additional arguments, and whether the parameter is applicable to "ack" or "nack" feedback or both or some different "rtcp-fb" attribute parameter. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter, the syntax and semantics of its parameters as well as corresponding feedback packet formats (if needed). The general registration procedures of [3] apply.
其他参赛作品可按先到先得的原则登记。每次注册都需要指明参数名称、可能的附加参数的语法，以及该参数是否适用于“ack”或“nack”反馈或两者或某些不同的“rtcp fb”属性参数。对于每个新注册，必须存在一个永久、稳定且可公开访问的文档，该文档指定注册参数的语义、其参数的语法和语义以及相应的反馈数据包格式（如果需要）。[3]中的一般注册程序适用。
Two RTCP Control Packet Types: for the class of transport layer FB messages ("RTPFB") and for the class of payload-specific FB messages ("PSFB"). Per Section 6, RTPFB=205 and PSFB=206 have been added to the RTCP registry.
两种RTCP控制数据包类型：传输层FB消息类（“RTPFB”）和负载特定FB消息类（“PSFB”）。根据第6节，RTPFB=205和PSFB=206已添加到RTCP注册表中。
RTP RTCP Control Packet types (PT):
RTP RTCP控制数据包类型（PT）：
Name: RTPFB Long name: Generic RTP Feedback Value: 205 Reference: RFC 4585.
名称：RTPFB长名称：通用RTP反馈值：205参考：RFC 4585。
Name: PSFB Long name: Payload-specific Value: 206 Reference: RFC 4585.
名称：PSFB长名称：有效负载特定值：206参考：RFC 4585。
As AVPF defines additional RTCP payload types, the corresponding "reserved" RTP payload type space (72-76, as defined in [2]), has been expanded accordingly.
由于AVPF定义了额外的RTCP有效负载类型，相应的“保留”RTP有效负载类型空间（72-76，如[2]中所定义）已相应扩展。
A new sub-registry has been set up for the FMT values for both the RTPFB payload type and the PSFB payload type, with the following registrations created initially:
已为RTPFB有效负载类型和PSFB有效负载类型的FMT值建立了一个新的子注册表，最初创建了以下注册表：
Within the RTPFB range, the following two format (FMT) values are initially registered:
在RTPFB范围内，最初注册以下两个格式（FMT）值：
Name: Generic NACK Long name: Generic negative acknowledgement Value: 1 Reference: RFC 4585.
名称：通用NACK长名称：通用否定确认值：1参考：RFC 4585。
Name: Extension Long name: Reserved for future extensions Value: 31 Reference: RFC 4585.
名称：扩展长名称：为将来的扩展保留值：31引用：RFC 4585。
Within the PSFB range, the following five format (FMT) values are initially registered:
在PSFB范围内，最初注册以下五个格式（FMT）值：
Name: PLI Long name: Picture Loss Indication Value: 1 Reference: RFC 4585.
名称：PLI长名称：图像丢失指示值：1参考：RFC 4585。
Name: SLI Long name: Slice Loss Indication Value: 2 Reference: RFC 4585.
名称：SLI长名称：切片丢失指示值：2参考：RFC 4585。
Name: RPSI Long name: Reference Picture Selection Indication Value: 3 Reference: RFC 4585.
名称：RPSI长名称：参考图片选择指示值：3参考：RFC 4585。
Name: AFB Long name: Application Layer Feedback Value: 15 Reference: RFC 4585.
名称：AFB长名称：应用层反馈值：15参考：RFC 4585。
Name: Extension Long name: Reserved for future extensions. Value: 31 Reference: RFC 4585.
名称：扩展名长名称：为将来的扩展保留。值：31参考：RFC 4585。
Further entries may be registered following the "Specification Required" rules as defined in RFC 2434 [9]. Each registration needs to indicate the FMT value, if there is a specific FB message to go into the FCI field, and whether or not multiple FB messages may be stacked in a single FCI field. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter as well as the syntax and semantics of the associated FB message (if any). The general registration procedures of [3] apply.
可按照RFC 2434[9]中定义的“所需规范”规则注册更多条目。如果有特定的FB消息进入FCI字段，以及是否可以在单个FCI字段中堆叠多个FB消息，则每次注册都需要指示FMT值。对于每个新注册，必须存在一个永久、稳定且可公开访问的文档，该文档指定注册参数的语义以及相关FB消息（如果有）的语法和语义。[3]中的一般注册程序适用。
This document is a product of the Audio-Visual Transport (AVT) Working Group of the IETF. The authors would like to thank Steve Casner and Colin Perkins for their comments and suggestions as well as for their responsiveness to numerous questions. The authors would also like to particularly thank Magnus Westerlund for his review and his valuable suggestions and Shigeru Fukunaga for the contributions on FB message formats and semantics.
本文件是IETF视听传输（AVT）工作组的产品。作者要感谢Steve Casner和Colin Perkins的评论和建议，以及他们对众多问题的回应。作者还要特别感谢Magnus Westerlund的评论和宝贵的建议，以及Shigeru Fukunaga对FB消息格式和语义的贡献。
We would also like to thank Andreas Buesching and people at Panasonic for their simulations and the first independent implementations of the feedback profile.
我们还要感谢Andreas Buesching和松下的人员进行了模拟，并首次独立实现了反馈配置文件。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[2] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[3] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[4] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[4] Casner，S.，“RTP控制协议（RTCP）带宽的会话描述协议（SDP）带宽修饰符”，RFC 3556，2003年7月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 Video Streams", RFC 2032, October 1996.
[6] Turletti，T.和C.Huitema，“H.261视频流的RTP有效载荷格式”，RFC 2032，1996年10月。
[7] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[7] Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[9] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[10] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[10] Camarillo，G.，Eriksson，G.，Holler，J.，和H.Schulzrinne，“会话描述协议（SDP）中媒体线路的分组”，RFC 3388，2002年12月。
[11] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998.
[11] Perkins，C.和O.Hodson，“修复流媒体的选项”，RFC 2354，1998年6月。
[12] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[12] Rosenberg，J.和H.Schulzrinne，“通用前向纠错的RTP有效载荷格式”，RFC 2733，1999年12月。
[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.
[13] 帕金斯，C.，库维拉斯，I.，霍德森，O.，哈德曼，V.，汉德利，M.，博洛特，J.，维加·加西亚，A.，和S.福斯·帕里斯，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[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.
[14] Bormann，C.，Cline，L.，Deisher，G.，Gardos，T.，Maciocco，C.，Newell，D.，Ott，J.，Sullivan，G.，Wenger，S.，和C.Zhu，“1998版ITU-T Rec.H.263视频（H.263+）的RTP有效载荷格式”，RFC 24291998年10月。
[15] B. Girod, N. Faerber, "Feedback-based error control for mobile video transmission", Proceedings IEEE, Vol. 87, No. 10, pp. 1707 - 1723, October, 1999.
[15] B.Girod，N.Faerber，“基于反馈的移动视频传输差错控制”，《IEEE学报》，第87卷，第10期，第1707-1723页，1999年10月。
[16] ISO/IEC 14496-2:2001/Amd.1:2002, "Information technology - Coding of audio-visual objects - Part2: Visual", 2001.
[16] ISO/IEC 14496-2:2001/Amd.1:2002，“信息技术-视听对象的编码-第2部分：视觉”，2001年。
[17] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate Communication", November 2000.
[17] ITU-T建议H.263，“低比特率通信的视频编码”，2000年11月。
[18] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[18] Schulzrinne，H.和S.Petrack，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 28332000年5月。
[19] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[19] Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC4340，2006年3月。
[20] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[20] Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
[21] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", Work in Progress, December 2005.
[21] Ott，J.和E.Carrara，“基于RTCP的反馈的扩展安全RTP配置文件（RTP/SAVPF）”，正在进行的工作，2005年12月。
[22] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[22] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[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.
[23] Kikuchi，Y.，Nomura，T.，Fukunaga，S.，Matsui，Y.，和H.Kimata，“MPEG-4音频/视频流的RTP有效载荷格式”，RFC3016，2000年11月。
[24] ITU-T Recommendation H.245, "Control protocol for multimedia communication", May 2006.
[24] ITU-T建议H.245，“多媒体通信控制协议”，2006年5月。
Authors' Addresses
作者地址
Joerg Ott Helsinki University of Technology (TKK) Networking Laboratory PO Box 3000 FIN-02015 TKK Finland
赫尔辛基工业大学（TKK）网络实验室PO盒3000 FIN 02015 TKK芬兰
EMail: jo@acm.org
EMail: jo@acm.org
Stephan Wenger Nokia Research Center P.O. Box 100 33721 Tampere Finland
斯蒂芬·温格诺基亚研究中心芬兰坦佩雷邮政信箱100 33721
EMail: stewe@stewe.org
EMail: stewe@stewe.org
Noriyuki Sato Oki Electric Industry Co., Ltd. 1-16-8 Chuo, Warabi-city, Saitama 335-8510 Japan
Noriyuki Sato Oki电气工业有限公司，地址：日本柴达木市瓦拉比市中环1-16-8号，邮编：335-8510
Phone: +81 48 431 5932
Fax: +81 48 431 9115
EMail: sato652@oki.com
Phone: +81 48 431 5932
Fax: +81 48 431 9115
EMail: sato652@oki.com
Carsten Burmeister Panasonic R&D Center Germany GmbH
Carsten Burmeister松下研发中心德国有限公司
EMail: carsten.burmeister@eu.panasonic.com
EMail: carsten.burmeister@eu.panasonic.com
Jose Rey Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
Jose Rey Panasonic研发中心德国有限公司Monzastr。4c D-63225兰根，德国
EMail: jose.rey@eu.panasonic.com
EMail: jose.rey@eu.panasonic.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。