Network Working Group S. Wenger
Request for Comments: 5104 U. Chandra
Category: Standards Track Nokia
M. Westerlund
B. Burman
Ericsson
February 2008
Network Working Group S. Wenger
Request for Comments: 5104 U. Chandra
Category: Standards Track Nokia
M. Westerlund
B. Burman
Ericsson
February 2008
Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
RTP视听配置文件中带反馈的编解码器控制消息（AVPF）
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）。本备忘录的分发不受限制。
Abstract
摘要
This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.
本文档指定了对“带反馈的视听配置文件”（AVPF）中定义的消息的一些扩展。它们主要在使用集中多点功能的会话多媒体场景中有用。但是，有些也可用于较小的多播环境和点对点调用。
The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off.
讨论的扩展是与ITU-T Rec.H.271视频反向信道、完整帧内请求、临时最大媒体流比特率和时空权衡相关的消息。
Table of Contents
目录
1. Introduction ....................................................4
2. Definitions .....................................................5
2.1. Glossary ...................................................5
2.2. Terminology ................................................5
2.3. Topologies .................................................8
3. Motivation ......................................................8
3.1. Use Cases ..................................................9
3.2. Using the Media Path ......................................11
3.3. Using AVPF ................................................11
3.3.1. Reliability ........................................12
3.4. Multicast .................................................12
3.5. Feedback Messages .........................................12
3.5.1. Full Intra Request Command .........................12
3.5.1.1. Reliability ...............................13
3.5.2. Temporal-Spatial Trade-off Request and
Notification .......................................14
3.5.2.1. Point-to-Point ............................15
3.5.2.2. Point-to-Multipoint Using
Multicast or Translators ..................15
3.5.2.3. Point-to-Multipoint Using RTP Mixer .......15
3.5.2.4. Reliability ...............................16
3.5.3. H.271 Video Back Channel Message ...................16
3.5.3.1. Reliability ...............................19
3.5.4. Temporary Maximum Media Stream Bit Rate
Request and Notification ...........................19
3.5.4.1. Behavior for Media Receivers Using TMMBR ..21
3.5.4.2. Algorithm for Establishing Current
Limitations ...............................23
3.5.4.3. Use of TMMBR in a Mixer-Based
Multipoint Operation ......................29
3.5.4.4. Use of TMMBR in Point-to-Multipoint Using
Multicast or Translators ..................30
3.5.4.5. Use of TMMBR in Point-to-Point Operation ..31
3.5.4.6. Reliability ...............................31
4. RTCP Receiver Report Extensions ................................32
4.1. Design Principles of the Extension Mechanism ..............32
4.2. Transport Layer Feedback Messages .........................33
4.2.1. Temporary Maximum Media Stream Bit Rate
Request (TMMBR) ....................................34
4.2.1.1. Message Format ............................34
4.2.1.2. Semantics .................................35
4.2.1.3. Timing Rules ..............................39
4.2.1.4. Handling in Translators and Mixers ........39
4.2.2. Temporary Maximum Media Stream Bit Rate
Notification (TMMBN) ...............................39
4.2.2.1. Message Format ............................39
1. Introduction ....................................................4
2. Definitions .....................................................5
2.1. Glossary ...................................................5
2.2. Terminology ................................................5
2.3. Topologies .................................................8
3. Motivation ......................................................8
3.1. Use Cases ..................................................9
3.2. Using the Media Path ......................................11
3.3. Using AVPF ................................................11
3.3.1. Reliability ........................................12
3.4. Multicast .................................................12
3.5. Feedback Messages .........................................12
3.5.1. Full Intra Request Command .........................12
3.5.1.1. Reliability ...............................13
3.5.2. Temporal-Spatial Trade-off Request and
Notification .......................................14
3.5.2.1. Point-to-Point ............................15
3.5.2.2. Point-to-Multipoint Using
Multicast or Translators ..................15
3.5.2.3. Point-to-Multipoint Using RTP Mixer .......15
3.5.2.4. Reliability ...............................16
3.5.3. H.271 Video Back Channel Message ...................16
3.5.3.1. Reliability ...............................19
3.5.4. Temporary Maximum Media Stream Bit Rate
Request and Notification ...........................19
3.5.4.1. Behavior for Media Receivers Using TMMBR ..21
3.5.4.2. Algorithm for Establishing Current
Limitations ...............................23
3.5.4.3. Use of TMMBR in a Mixer-Based
Multipoint Operation ......................29
3.5.4.4. Use of TMMBR in Point-to-Multipoint Using
Multicast or Translators ..................30
3.5.4.5. Use of TMMBR in Point-to-Point Operation ..31
3.5.4.6. Reliability ...............................31
4. RTCP Receiver Report Extensions ................................32
4.1. Design Principles of the Extension Mechanism ..............32
4.2. Transport Layer Feedback Messages .........................33
4.2.1. Temporary Maximum Media Stream Bit Rate
Request (TMMBR) ....................................34
4.2.1.1. Message Format ............................34
4.2.1.2. Semantics .................................35
4.2.1.3. Timing Rules ..............................39
4.2.1.4. Handling in Translators and Mixers ........39
4.2.2. Temporary Maximum Media Stream Bit Rate
Notification (TMMBN) ...............................39
4.2.2.1. Message Format ............................39
4.2.2.2. Semantics .................................40
4.2.2.3. Timing Rules ..............................41
4.2.2.4. Handling by Translators and Mixers ........41
4.3. Payload-Specific Feedback Messages ........................41
4.3.1. Full Intra Request (FIR) ...........................42
4.3.1.1. Message Format ............................42
4.3.1.2. Semantics .................................43
4.3.1.3. Timing Rules ..............................44
4.3.1.4. Handling of FIR Message in Mixers and
Translators ...............................44
4.3.1.5. Remarks ...................................44
4.3.2. Temporal-Spatial Trade-off Request (TSTR) ..........45
4.3.2.1. Message Format ............................46
4.3.2.2. Semantics .................................46
4.3.2.3. Timing Rules ..............................47
4.3.2.4. Handling of Message in Mixers and
Translators ...............................47
4.3.2.5. Remarks ...................................47
4.3.3. Temporal-Spatial Trade-off Notification (TSTN) .....48
4.3.3.1. Message Format ............................48
4.3.3.2. Semantics .................................49
4.3.3.3. Timing Rules ..............................49
4.3.3.4. Handling of TSTN in Mixers and
Translators ...............................49
4.3.3.5. Remarks ...................................49
4.3.4. H.271 Video Back Channel Message (VBCM) ............50
4.3.4.1. Message Format ............................50
4.3.4.2. Semantics .................................51
4.3.4.3. Timing Rules ..............................52
4.3.4.4. Handling of Message in Mixers or
Translators ...............................52
4.3.4.5. Remarks ...................................52
5. Congestion Control .............................................52
6. Security Considerations ........................................53
7. SDP Definitions ................................................54
7.1. Extension of the rtcp-fb Attribute ........................54
7.2. Offer-Answer ..............................................55
7.3. Examples ..................................................56
8. IANA Considerations ............................................58
9. Contributors ...................................................60
10. Acknowledgements ..............................................60
11. References ....................................................60
11.1. Normative References .....................................60
11.2. Informative References ...................................61
4.2.2.2. Semantics .................................40
4.2.2.3. Timing Rules ..............................41
4.2.2.4. Handling by Translators and Mixers ........41
4.3. Payload-Specific Feedback Messages ........................41
4.3.1. Full Intra Request (FIR) ...........................42
4.3.1.1. Message Format ............................42
4.3.1.2. Semantics .................................43
4.3.1.3. Timing Rules ..............................44
4.3.1.4. Handling of FIR Message in Mixers and
Translators ...............................44
4.3.1.5. Remarks ...................................44
4.3.2. Temporal-Spatial Trade-off Request (TSTR) ..........45
4.3.2.1. Message Format ............................46
4.3.2.2. Semantics .................................46
4.3.2.3. Timing Rules ..............................47
4.3.2.4. Handling of Message in Mixers and
Translators ...............................47
4.3.2.5. Remarks ...................................47
4.3.3. Temporal-Spatial Trade-off Notification (TSTN) .....48
4.3.3.1. Message Format ............................48
4.3.3.2. Semantics .................................49
4.3.3.3. Timing Rules ..............................49
4.3.3.4. Handling of TSTN in Mixers and
Translators ...............................49
4.3.3.5. Remarks ...................................49
4.3.4. H.271 Video Back Channel Message (VBCM) ............50
4.3.4.1. Message Format ............................50
4.3.4.2. Semantics .................................51
4.3.4.3. Timing Rules ..............................52
4.3.4.4. Handling of Message in Mixers or
Translators ...............................52
4.3.4.5. Remarks ...................................52
5. Congestion Control .............................................52
6. Security Considerations ........................................53
7. SDP Definitions ................................................54
7.1. Extension of the rtcp-fb Attribute ........................54
7.2. Offer-Answer ..............................................55
7.3. Examples ..................................................56
8. IANA Considerations ............................................58
9. Contributors ...................................................60
10. Acknowledgements ..............................................60
11. References ....................................................60
11.1. Normative References .....................................60
11.2. Informative References ...................................61
When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was developed, the main emphasis lay in the efficient support of point-to-point and small multipoint scenarios without centralized multipoint control. However, in practice, many small multipoint conferences operate utilizing devices known as Multipoint Control Units (MCUs). Long-standing experience of the conversational video conferencing industry suggests that there is a need for a few additional feedback messages, to support centralized multipoint conferencing efficiently. Some of the messages have applications beyond centralized multipoint, and this is indicated in the description of the message. This is especially true for the message intended to carry ITU-T Rec. H.271 [H.271] bit strings for Video Back Channel messages.
当开发带反馈的视听配置文件（AVPF）[RFC4585]时，主要重点在于在没有集中多点控制的情况下有效支持点对点和小型多点场景。然而，在实践中，许多小型多点会议使用称为多点控制单元（MCU）的设备进行操作。对话视频会议行业的长期经验表明，需要一些额外的反馈信息，以有效地支持集中式多点会议。有些消息的应用程序超出了集中式多点，这在消息的描述中有所说明。这对于打算携带ITU-T Rec.H.271[H.271]位串用于视频反向通道消息的消息尤其如此。
In Real-time Transport Protocol (RTP) [RFC3550] terminology, MCUs comprise mixers and translators. Most MCUs also include signaling support. During the development of this memo, it was noticed that there is considerable confusion in the community related to the use of terms such as mixer, translator, and MCU. In response to these concerns, a number of topologies have been identified that are of practical relevance to the industry, but are not documented in sufficient detail in [RFC3550]. These topologies are documented in [RFC5117], and understanding this memo requires previous or parallel study of [RFC5117].
在实时传输协议（RTP）[RFC3550]术语中，MCU包括混频器和转换器。大多数MCU还包括信号支持。在编写本备忘录的过程中，注意到社区中存在大量与混音器、翻译器和MCU等术语的使用相关的混淆。针对这些问题，已经确定了许多与行业实际相关的拓扑，但在[RFC3550]中没有足够详细的记录。这些拓扑结构记录在[RFC5117]中，理解本备忘录需要事先或平行研究[RFC5117]。
Some of the messages defined here are forward only, in that they do not require an explicit notification to the message emitter that they have been received and/or indicating the message receiver's actions. Other messages require a response, leading to a two-way communication model that one could view as useful for control purposes. However, it is not the intention of this memo to open up RTP Control Protocol (RTCP) to a generalized control protocol. All mentioned messages have relatively strict real-time constraints, in the sense that their value diminishes with increased delay. This makes the use of more traditional control protocol means, such as Session Initiation Protocol (SIP) [RFC3261], undesirable when used for the same purpose. That is why this solution is recommended instead of "XML Schema for Media Control" [XML-MC], which uses SIP Info to transfer XML messages with similar semantics to what are defined in this memo. Furthermore, all messages are of a very simple format that can be easily processed by an RTP/RTCP sender/receiver. Finally, and most importantly, all messages relate only to the RTP stream with which they are associated, and not to any other property of a communication system. In particular, none of them relate to the properties of the access links traversed by the session.
此处定义的某些消息仅为转发消息，因为它们不需要向消息发射器发出已接收消息的明确通知和/或指示消息接收器的操作。其他消息需要响应，从而产生一个双向通信模型，人们可以将其视为对控制有用。然而，本备忘录的目的不是将RTP控制协议（RTCP）开放为通用控制协议。所有提到的消息都有相对严格的实时约束，即它们的值随着延迟的增加而减少。这使得在用于相同目的时不希望使用更传统的控制协议手段，例如会话发起协议（SIP）[rfc326]。这就是为什么建议使用此解决方案而不是“用于媒体控制的XML模式”[XML-MC]，后者使用SIP Info传输语义与本备忘录中定义的类似的XML消息。此外，所有消息的格式都非常简单，RTP/RTCP发送方/接收方可以轻松处理这些消息。最后，也是最重要的，所有消息仅与它们关联的RTP流相关，而不与通信系统的任何其他属性相关。特别是，它们都与会话所遍历的访问链路的属性无关。
AIMD - Additive Increase Multiplicative Decrease AVPF - The extended RTP profile for RTCP-based feedback FCI - Feedback Control Information [RFC4585] FEC - Forward Error Correction FIR - Full Intra Request MCU - Multipoint Control Unit MPEG - Moving Picture Experts Group PLI - Picture Loss Indication PR - Packet rate QP - Quantizer Parameter RTT - Round trip time SSRC - Synchronization Source TMMBN - Temporary Maximum Media Stream Bit Rate Notification TMMBR - Temporary Maximum Media Stream Bit Rate Request TSTN - Temporal-Spatial Trade-off Notification TSTR - Temporal-Spatial Trade-off Request VBCM - Video Back Channel Message
AIMD-加法增加乘法减少AVPF-基于RTCP的反馈FCI的扩展RTP配置文件-反馈控制信息[RFC4585]FEC-前向纠错FIR-全帧请求MCU-多点控制单元MPEG-运动图像专家组PLI-图像丢失指示PR-包速率QP-量化器参数RTT-往返时间SSRC-同步源TMMBN-临时最大媒体流比特率通知TMMBR-临时最大媒体流比特率请求TSTN-时空权衡通知TSTR-时空权衡请求VBCM-视频反向通道消息
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Message: An RTCP feedback message [RFC4585] defined by this specification, of one of the following types:
消息：本规范定义的RTCP反馈消息[RFC4585]，属于以下类型之一：
Request: Message that requires acknowledgement
请求：需要确认的消息
Command: Message that forces the receiver to an action
命令：迫使接收者采取行动的消息
Indication: Message that reports a situation
指示：报告情况的消息
Notification: Message that provides a notification that an event has occurred. Notifications are commonly generated in response to a Request.
通知：提供事件已发生通知的消息。通知通常是响应请求而生成的。
Note that, with the exception of "Notification", this terminology is in alignment with ITU-T Rec. H.245 [H245].
请注意，除“通知”外，该术语与ITU-T Rec.H.245[H245]一致。
Decoder Refresh Point: A bit string, packetized in one or more RTP packets, that completely resets the decoder to a known state.
解码器刷新点：一个位字符串，打包在一个或多个RTP数据包中，将解码器完全重置为已知状态。
Examples for "hard" decoder refresh points are Intra pictures in H.261, H.263, MPEG-1, MPEG-2, and MPEG-4 part 2, and Instantaneous Decoder Refresh (IDR) pictures in H.264. "Gradual" decoder refresh points may also be used; see for example [AVC]. While both "hard" and "gradual" decoder refresh points are acceptable in the scope of this specification, in most cases the user experience will benefit from using a "hard" decoder refresh point.
“硬”解码器刷新点的示例是H.261、H.263、MPEG-1、MPEG-2和MPEG-4第2部分中的帧内图片，以及H.264中的瞬时解码器刷新（IDR）图片。也可以使用“渐进”解码器刷新点；例如参见[AVC]。虽然“硬”和“渐进”解码器刷新点在本规范的范围内都是可接受的，但在大多数情况下，用户体验将受益于使用“硬”解码器刷新点。
A decoder refresh point also contains all header information above the picture layer (or equivalent, depending on the video compression standard) that is conveyed in-band. In H.264, for example, a decoder refresh point contains parameter set Network Adaptation Layer (NAL) units that generate parameter sets necessary for the decoding of the following slice/data partition NAL units (and that are not conveyed out of band).
解码器刷新点还包含在频带内传送的图片层（或等效物，取决于视频压缩标准）之上的所有报头信息。例如，在H.264中，解码器刷新点包含参数集网络适配层（NAL）单元，该参数集网络适配层（NAL）单元生成解码以下片/数据分区NAL单元（且不在带外传送）所需的参数集。
Decoding: The operation of reconstructing the media stream.
解码：重建媒体流的操作。
Rendering: The operation of presenting (parts of) the reconstructed media stream to the user.
呈现：将重建的媒体流（部分）呈现给用户的操作。
Stream thinning: The operation of removing some of the packets from a media stream. Stream thinning, preferably, is media-aware, implying that media packets are removed in the order of increasing relevance to the reproductive quality. However, even when employing media-aware stream thinning, most media streams quickly lose quality when subjected to increasing levels of thinning. Media-unaware stream thinning leads to even worse quality degradation. In contrast to transcoding, stream thinning is typically seen as a computationally lightweight operation.
流细化：从媒体流中删除部分数据包的操作。优选地，流细化是媒体感知的，这意味着媒体分组按照与生殖质量的相关性增加的顺序被移除。然而，即使在采用媒体感知流细化时，大多数媒体流在受到越来越高的细化级别时也会很快失去质量。媒体不知道流变薄会导致更严重的质量下降。与转码相比，流细化通常被视为计算量较小的操作。
Media: Often used (sometimes in conjunction with terms like bit rate, stream, sender, etc.) to identify the content of the forward RTP packet stream (carrying the codec data), to which the codec control message applies.
媒体：通常用于（有时与诸如比特率、流、发送方等术语结合使用）识别编解码器控制消息适用的前向RTP数据包流（承载编解码器数据）的内容。
Media Stream: The stream of RTP packets labeled with a single Synchronization Source (SSRC) carrying the media (and also in some cases repair information such as retransmission or Forward Error Correction (FEC) information).
媒体流：带有单个同步源（SSRC）标记的RTP数据包流，该同步源承载媒体（在某些情况下还包括修复信息，如重传或前向纠错（FEC）信息）。
Total media bit rate: The total bits per second transferred in a media stream, measured at an observer-selected protocol layer and averaged over a reasonable timescale, the length of which depends on the application. In general, a media sender and a media receiver will observe different total media bit rates for the same stream, first because they may have selected different reference protocol layers, and second, because of changes in per-packet overhead along the transmission path. The goal with bit rate averaging is to be able to ignore any burstiness on very short timescales (e.g., below 100 ms) introduced by scheduling or link layer packetization effects.
总媒体比特率：媒体流中每秒传输的总比特数，在观察者选择的协议层测量，并在合理的时间尺度上平均，其长度取决于应用程序。通常，媒体发送器和媒体接收器将观察到相同流的不同总媒体比特率，首先是因为它们可能选择了不同的参考协议层，其次是因为沿传输路径的每个分组开销的变化。比特率平均的目标是能够忽略由调度或链路层分组效应引入的非常短的时间尺度（例如，低于100 ms）上的任何突发性。
Maximum total media bit rate: The upper limit on total media bit rate for a given media stream at a particular receiver and for its selected protocol layer. Note that this value cannot be measured on the received media stream. Instead, it needs to be calculated or determined through other means, such as quality of service (QoS) negotiations or local resource limitations. Also note that this value is an average (on a timescale that is reasonable for the application) and that it may be different from the instantaneous bit rate seen by packets in the media stream.
最大总媒体比特率：特定接收器处给定媒体流及其所选协议层的总媒体比特率上限。请注意，无法在接收的媒体流上测量该值。相反，它需要通过其他方式计算或确定，例如服务质量（QoS）协商或本地资源限制。还要注意，该值是平均值（在对应用合理的时间尺度上），并且它可能不同于媒体流中的分组所看到的瞬时比特率。
Overhead: All protocol header information required to convey a packet with media data from sender to receiver, from the application layer down to a pre-defined protocol level (for example, down to, and including, the IP header). Overhead may include, for example, IP, UDP, and RTP headers, any layer 2 headers, any Contributing Sources (CSRCs), RTP padding, and RTP header extensions. Overhead excludes any RTP payload headers and the payload itself.
开销：将包含媒体数据的数据包从发送方传送到接收方所需的所有协议头信息，从应用层传送到预定义的协议级别（例如，传送到并包括IP头）。开销可能包括，例如，IP、UDP和RTP头、任何第2层头、任何贡献源（CSRC）、RTP填充和RTP头扩展。开销不包括任何RTP负载头和负载本身。
Net media bit rate: The bit rate carried by a media stream, net of overhead. That is, the bits per second accounted for by encoded media, any applicable payload headers, and any directly associated meta payload information placed in the RTP packet. A typical example of the latter is redundancy data provided by the use of RFC 2198 [RFC2198]. Note that, unlike the total media bit
净媒体比特率：媒体流承载的比特率，减去开销。即，由编码媒体、任何适用的有效负载报头和放置在RTP分组中的任何直接相关元有效负载信息所占的每秒比特数。后者的一个典型示例是使用RFC 2198[RFC2198]提供的冗余数据。请注意，与总媒体位不同
rate, the net media bit rate will have the same value at the media sender and at the media receiver unless any mixing or translating of the media has occurred.
速率，除非媒体发生任何混合或转换，否则净媒体比特率在媒体发送方和媒体接收方将具有相同的值。
For a given observer, the total media bit rate for a media stream is equal to the sum of the net media bit rate and the per-packet overhead as defined above multiplied by the packet rate.
对于给定的观察者，媒体流的总媒体比特率等于净媒体比特率和如上定义的每分组开销之和乘以分组速率。
Feasible region: The set of all combinations of packet rate and net media bit rate that do not exceed the restrictions in maximum media bit rate placed on a given media sender by the Temporary Maximum Media Stream Bit Rate Request (TMMBR) messages it has received. The feasible region will change as new TMMBR messages are received.
可行区域：数据包速率和净媒体比特率的所有组合的集合，这些组合不超过其接收到的临时最大媒体流比特率请求（TMMBR）消息对给定媒体发送方施加的最大媒体比特率限制。当接收到新的TMMBR消息时，可行区域将发生变化。
Bounding set: The set of TMMBR tuples, selected from all those received at a given media sender, that define the feasible region for that media sender. The media sender uses an algorithm such as that in section 3.5.4.2 to determine or iteratively approximate the current bounding set, and reports that set back to the media receivers in a Temporary Maximum Media Stream Bit Rate Notification (TMMBN) message.
边界集：TMMBR元组的集合，从给定媒体发送方接收的所有元组中选择，用于定义该媒体发送方的可行区域。媒体发送方使用第3.5.4.2节中的算法确定或迭代近似当前边界集，并在临时最大媒体流比特率通知（TMMBN）消息中向媒体接收方报告该边界集。
Please refer to [RFC5117] for an in-depth discussion. The topologies referred to throughout this memo are labeled (consistently with [RFC5117]) as follows:
请参考[RFC5117]进行深入讨论。本备忘录中提及的拓扑标记如下（与[RFC5117]一致）：
Topo-Point-to-Point . . . . . Point-to-point communication
Topo-Multicast . . . . . . . Multicast communication
Topo-Translator . . . . . . . Translator based
Topo-Mixer . . . . . . . . . Mixer based
Topo-RTP-switch-MCU . . . . . RTP stream switching MCU
Topo-RTCP-terminating-MCU . . Mixer but terminating RTCP
Topo-Point-to-Point . . . . . Point-to-point communication
Topo-Multicast . . . . . . . Multicast communication
Topo-Translator . . . . . . . Translator based
Topo-Mixer . . . . . . . . . Mixer based
Topo-RTP-switch-MCU . . . . . RTP stream switching MCU
Topo-RTCP-terminating-MCU . . Mixer but terminating RTCP
This section discusses the motivation and usage of the different video and media control messages. The video control messages have been under discussion for a long time, and a requirement document was drawn up [Basso]. That document has expired; however, we quote relevant sections of it to provide motivation and requirements.
本节讨论不同视频和媒体控制消息的动机和用法。视频控制信息已经讨论了很长时间，并起草了一份需求文件[Basso]。该文件已过期；然而，我们引用其中的相关章节来提供动机和要求。
There are a number of possible usages for the proposed feedback messages. Let us begin by looking through the use cases Basso et al. [Basso] proposed. Some of the use cases have been reformulated and comments have been added.
建议的反馈消息有许多可能的用法。让我们先看看Basso等人提出的用例。一些用例已经重新制定，并添加了注释。
1. An RTP video mixer composes multiple encoded video sources into a single encoded video stream. Each time a video source is added, the RTP mixer needs to request a decoder refresh point from the video source, so as to start an uncorrupted prediction chain on the spatial area of the mixed picture occupied by the data from the new video source.
1. RTP视频混合器将多个编码视频源合成单个编码视频流。每次添加视频源时，RTP混合器需要从视频源请求解码器刷新点，以便在由来自新视频源的数据占据的混合图片的空间区域上启动未损坏的预测链。
2. An RTP video mixer receives multiple encoded RTP video streams from conference participants, and dynamically selects one of the streams to be included in its output RTP stream. At the time of a bit stream change (determined through means such as voice activation or the user interface), the mixer requests a decoder refresh point from the remote source, in order to avoid using unrelated content as reference data for inter picture prediction. After requesting the decoder refresh point, the video mixer stops the delivery of the current RTP stream and monitors the RTP stream from the new source until it detects data belonging to the decoder refresh point. At that time, the RTP mixer starts forwarding the newly selected stream to the receiver(s).
2. RTP视频混合器从会议参与者接收多个编码的RTP视频流，并动态地选择要包括在其输出RTP流中的一个流。在比特流改变时（通过诸如语音激活或用户界面之类的手段确定），混频器从远程源请求解码器刷新点，以避免使用不相关的内容作为用于画面间预测的参考数据。在请求解码器刷新点之后，视频混合器停止当前RTP流的传送并监视来自新源的RTP流，直到它检测到属于解码器刷新点的数据为止。此时，RTP混合器开始将新选择的流转发给接收机。
3. An application needs to signal to the remote encoder that the desired trade-off between temporal and spatial resolution has changed. For example, one user may prefer a higher frame rate and a lower spatial quality, and another user may prefer the opposite. This choice is also highly content dependent. Many current video conferencing systems offer in the user interface a mechanism to make this selection, usually in the form of a slider. The mechanism is helpful in point-to-point, centralized multipoint and non-centralized multipoint uses.
3. 应用程序需要向远程编码器发出信号，表明时间和空间分辨率之间的预期权衡已经改变。例如，一个用户可能更喜欢较高的帧速率和较低的空间质量，而另一个用户可能更喜欢相反的帧速率和较低的空间质量。这种选择也高度依赖于内容。许多当前的视频会议系统在用户界面中提供了一种进行选择的机制，通常是以滑块的形式。该机制有助于点对点、集中式多点和非集中式多点使用。
4. Use case 4 of the Basso document applies only to Picture Loss Indication (PLI) as defined in AVPF [RFC4585] and is not reproduced here.
4. Basso文档的用例4仅适用于AVPF[RFC4585]中定义的图像丢失指示（PLI），此处不进行复制。
5. Use case 5 of the Basso document relates to a mechanism known as "freeze picture request". Sending freeze picture requests over a non-reliable forward RTCP channel has been identified as problematic. Therefore, no freeze picture request has been included in this memo, and the use case discussion is not reproduced here.
5. Basso文档的用例5涉及一种称为“冻结图片请求”的机制。通过不可靠的前向RTCP通道发送冻结图片请求已被确定为有问题。因此，本备忘录中未包含冻结图片请求，此处不复制用例讨论。
6. A video mixer dynamically selects one of the received video streams to be sent out to participants and tries to provide the highest bit rate possible to all participants, while minimizing stream trans-rating. One way of achieving this is to set up sessions with endpoints using the maximum bit rate accepted by each endpoint, and accepted by the call admission method used by the mixer. By means of commands that reduce the maximum media stream bit rate below what has been negotiated during session set up, the mixer can reduce the maximum bit rate sent by endpoints to the lowest of all the accepted bit rates. As the lowest accepted bit rate changes due to endpoints joining and leaving or due to network congestion, the mixer can adjust the limits at which endpoints can send their streams to match the new value. The mixer then requests a new maximum bit rate, which is equal to or less than the maximum bit rate negotiated at session setup for a specific media stream, and the remote endpoint can respond with the actual bit rate that it can support.
6. 视频混合器动态地选择要发送给参与者的一个接收视频流，并尝试向所有参与者提供尽可能高的比特率，同时最小化流传输。实现这一点的一种方法是使用每个端点接受的最大比特率和混合器使用的呼叫允许方法接受的最大比特率与端点建立会话。通过将最大媒体流比特率降低到会话设置期间协商的比特率以下的命令，混频器可以将端点发送的最大比特率降低到所有可接受比特率中的最低值。当最低可接受比特率由于端点加入和离开或由于网络拥塞而改变时，混频器可以调整端点可以发送其流的限制以匹配新值。然后，混合器请求一个新的最大比特率，该比特率等于或小于特定媒体流在会话设置时协商的最大比特率，远程端点可以使用其支持的实际比特率进行响应。
The picture Basso, et al., draw up covers most applications we foresee. However, we would like to extend the list with two additional use cases:
Basso等人绘制的图片涵盖了我们预见的大多数应用。但是，我们希望通过两个额外的用例扩展列表：
7. Currently deployed congestion control algorithms (AIMD and TCP Friendly Rate Control (TFRC) [RFC3448]) probe for additional available capacity as long as there is something to send. With congestion control algorithms using packet loss as the indication for congestion, this probing generally results in reduced media quality (often to a point where the distortion is large enough to make the media unusable), due to packet loss and increased delay.
7. 当前部署的拥塞控制算法（AIMD和TCP友好速率控制（TFRC）[RFC3448]）探测额外的可用容量，只要有东西要发送。对于使用数据包丢失作为拥塞指示的拥塞控制算法，由于数据包丢失和延迟增加，这种探测通常会导致媒体质量降低（通常失真到足以使媒体无法使用的程度）。
In a number of deployment scenarios, especially cellular ones, the bottleneck link is often the last hop link. That cellular link also commonly has some type of QoS negotiation enabling the cellular device to learn the maximal bit rate available over this last hop. A media receiver behind this link can, in most (if not all) cases, calculate at least an upper bound for the bit rate available for each media stream it presently receives. How this is done is an implementation detail and not discussed herein. Indicating the maximum available bit rate to the transmitting party for the various media streams can be beneficial to prevent that party from probing for bandwidth for this stream in excess of a known hard limit. For cellular or other mobile devices, the known available bit rate for each stream (deduced from the link bit rate) can change quickly, due to handover to another transmission technology, QoS renegotiation due to congestion, etc. To enable minimal disruption of service, quick convergence is necessary, and therefore media path signaling is desirable.
在许多部署场景中，尤其是蜂窝部署场景中，瓶颈链路通常是最后一跳链路。该蜂窝链路通常还具有某种类型的QoS协商，使得蜂窝设备能够在该最后一跳中学习可用的最大比特率。在大多数（如果不是所有）情况下，该链路后面的媒体接收器至少可以计算其当前接收的每个媒体流的可用比特率的上限。如何做到这一点是一个实现细节，本文不讨论。向发送方指示各种媒体流的最大可用比特率有利于防止该方探测该流的带宽超过已知硬限制。对于蜂窝或其他移动设备，每个流的已知可用比特率（从链路比特率推导）可以快速变化，这是由于切换到另一个传输技术、由于拥塞导致的QoS重新协商等。为了使服务中断最小化，需要快速收敛，因此，需要媒体路径信令。
8. The use of reference picture selection (RPS) as an error resilience tool was introduced in 1997 as NEWPRED [NEWPRED], and is now widely deployed. When RPS is in use, simplistically put, the receiver can send a feedback message to the sender, indicating a reference picture that should be used for future prediction. ([NEWPRED] mentions other forms of feedback as well.) AVPF contains a mechanism for conveying such a message, but did not specify for which codec and according to which syntax the message should conform. Recently, the ITU-T finalized Rec. H.271, which (among other message types) also includes a feedback message. It is expected that this feedback message will fairly quickly enjoy wide support. Therefore, a mechanism to convey feedback messages according to H.271 appears to be desirable.
8. 参考图片选择（RPS）作为错误恢复工具的使用于1997年作为NEWPRED[NEWPRED]引入，现在已广泛部署。简单地说，当使用RPS时，接收方可以向发送方发送反馈消息，指示应用于未来预测的参考图片。（[NEWPRED]也提到了其他形式的反馈。）AVPF包含一种传递此类消息的机制，但没有指定消息应符合的编解码器和语法。最近，ITU-T最终确定了建议H.271，其中（在其他消息类型中）还包括反馈消息。预计这一反馈信息将很快得到广泛支持。因此，根据H.271传送反馈消息的机制似乎是可取的。
There are two reasons why we use the media path for the codec control messages.
我们使用编解码器控制消息的媒体路径有两个原因。
First, systems employing MCUs often separate the control and media processing parts. As these messages are intended for or generated by the media part rather than the signaling part of the MCU, having them on the media path avoids transmission across interfaces and unnecessary control traffic between signaling and processing. If the MCU is physically decomposed, the use of the media path avoids the need for media control protocol extensions (e.g., in media gateway control (MEGACO) [RFC3525]).
首先，采用MCU的系统通常将控制和媒体处理部分分开。由于这些消息旨在由媒体部分而不是MCU的信令部分生成，因此将它们置于媒体路径上可避免跨接口传输以及信令和处理之间不必要的控制通信量。如果MCU被物理分解，则使用介质路径可避免介质控制协议扩展的需要（例如，在介质网关控制（MEGACO）[RFC3525]中）。
Secondly, the signaling path quite commonly contains several signaling entities, e.g., SIP proxies and application servers. Avoiding going through signaling entities avoids delay for several reasons. Proxies have less stringent delay requirements than media processing, and due to their complex and more generic nature may result in significant processing delay. The topological locations of the signaling entities are also commonly not optimized for minimal delay, but rather towards other architectural goals. Thus, the signaling path can be significantly longer in both geographical and delay sense.
其次，信令路径通常包含几个信令实体，例如SIP代理和应用服务器。避免通过信令实体可以避免延迟，原因有几个。代理的延迟要求不如媒体处理严格，并且由于其复杂和更通用的性质，可能会导致显著的处理延迟。信令实体的拓扑位置通常也不是针对最小延迟进行优化，而是针对其他架构目标进行优化。因此，信令路径在地理和延迟意义上都可以显著更长。
The AVPF feedback message framework [RFC4585] provides the appropriate framework to implement the new messages. AVPF implements rules controlling the timing of feedback messages to avoid congestion through network flooding by RTCP traffic. We re-use these rules by referencing AVPF.
AVPF反馈消息框架[RFC4585]提供了实现新消息的适当框架。AVPF实现控制反馈消息定时的规则，以避免RTCP流量通过网络洪泛造成拥塞。我们通过引用AVPF重复使用这些规则。
The signaling setup for AVPF allows each individual type of function to be configured or negotiated on an RTP session basis.
AVPF的信令设置允许在RTP会话的基础上配置或协商每种单独类型的功能。
The use of RTCP messages implies that each message transfer is unreliable, unless the lower layer transport provides reliability. The different messages proposed in this specification have different requirements in terms of reliability. However, in all cases, the reaction to an (occasional) loss of a feedback message is specified.
使用RTCP消息意味着每个消息传输都不可靠，除非较低层传输提供可靠性。本规范中提出的不同消息在可靠性方面有不同的要求。但是，在所有情况下，都会指定对（偶尔）丢失反馈消息的反应。
The codec control messages might be used with multicast. The RTCP timing rules specified in [RFC3550] and [RFC4585] ensure that the messages do not cause overload of the RTCP connection. The use of multicast may result in the reception of messages with inconsistent semantics. The reaction to inconsistencies depends on the message type, and is discussed for each message type separately.
编解码器控制消息可能与多播一起使用。[RFC3550]和[RFC4585]中指定的RTCP定时规则确保消息不会导致RTCP连接过载。使用多播可能会导致接收语义不一致的消息。对不一致的反应取决于消息类型，并针对每种消息类型分别进行讨论。
This section describes the semantics of the different feedback messages and how they apply to the different use cases.
本节描述了不同反馈消息的语义，以及它们如何应用于不同的用例。
A Full Intra Request (FIR) Command, when received by the designated media sender, requires that the media sender sends a Decoder Refresh Point (see section 2.2) at the earliest opportunity. The evaluation of such an opportunity includes the current encoder coding strategy and the current available network resources.
当指定的媒体发送方收到完整的内部请求（FIR）命令时，要求媒体发送方尽早发送解码器刷新点（见第2.2节）。这种机会的评估包括当前编码器编码策略和当前可用网络资源。
FIR is also known as an "instantaneous decoder refresh request", "fast video update request" or "video fast update request".
FIR也称为“即时解码器刷新请求”、“快速视频更新请求”或“视频快速更新请求”。
Using a decoder refresh point implies refraining from using any picture sent prior to that point as a reference for the encoding process of any subsequent picture sent in the stream. For predictive media types that are not video, the analogue applies. For example, if in MPEG-4 systems scene updates are used, the decoder refresh point consists of the full representation of the scene and is not delta-coded relative to previous updates.
使用解码器刷新点意味着避免使用在该点之前发送的任何图片作为流中发送的任何后续图片的编码过程的参考。对于非视频的预测媒体类型，模拟适用。例如，如果在MPEG-4系统中使用场景更新，则解码器刷新点由场景的完整表示组成，并且不是相对于先前更新的增量编码。
Decoder refresh points, especially Intra or IDR pictures, are in general several times larger in size than predicted pictures. Thus, in scenarios in which the available bit rate is small, the use of a decoder refresh point implies a delay that is significantly longer than the typical picture duration.
解码器刷新点，尤其是帧内或IDR图片，通常比预测图片大几倍。因此，在可用比特率小的场景中，解码器刷新点的使用意味着显著长于典型图片持续时间的延迟。
Usage in multicast is possible; however, aggregation of the commands is recommended. A receiver that receives a request closely after sending a decoder refresh point -- within 2 times the longest round trip time (RTT) known, plus any AVPF-induced RTCP packet sending delays -- should await a second request message to ensure that the media receiver has not been served by the previously delivered decoder refresh point. The reason for the specified delay is to avoid sending unnecessary decoder refresh points. A session participant may have sent its own request while another participant's request was in-flight to them. Suppressing those requests that may have been sent without knowledge about the other request avoids this issue.
在多播中使用是可能的；但是，建议聚合命令。在发送解码器刷新点（在已知的最长往返时间（RTT）的2倍内，加上任何AVPF引起的RTCP数据包发送延迟）后，接收请求的接收器应等待第二条请求消息，以确保媒体接收器未被先前交付的解码器刷新点服务。指定延迟的原因是为了避免发送不必要的解码器刷新点。会话参与者可能已经发送了自己的请求，而另一个参与者的请求正在发送中。抑制那些可能在不知道其他请求的情况下发送的请求可以避免此问题。
Using the FIR command to recover from errors is explicitly disallowed, and instead the PLI message defined in AVPF [RFC4585] should be used. The PLI message reports lost pictures and has been included in AVPF for precisely that purpose.
明确禁止使用FIR命令从错误中恢复，而应使用AVPF[RFC4585]中定义的PLI消息。PLI消息报告丢失的图片，并已包含在AVPF中，正是出于此目的。
Full Intra Request is applicable in use-cases 1 and 2.
完整的内部请求适用于用例1和用例2。
The FIR message results in the delivery of a decoder refresh point, unless the message is lost. Decoder refresh points are easily identifiable from the bit stream. Therefore, there is no need for protocol-level notification, and a simple command repetition mechanism is sufficient for ensuring the level of reliability required. However, the potential use of repetition does require a mechanism to prevent the recipient from responding to messages already received and responded to.
FIR消息将导致解码器刷新点的交付，除非消息丢失。解码器刷新点很容易从比特流中识别。因此，不需要协议级别的通知，简单的命令重复机制足以确保所需的可靠性级别。然而，重复的潜在用途确实需要一种机制来防止收件人对已经收到和响应的消息做出响应。
To ensure the best possible reliability, a sender of FIR may repeat the FIR until the desired content has been received. The repetition interval is determined by the RTCP timing rules applicable to the session. Upon reception of a complete decoder refresh point or the detection of an attempt to send a decoder refresh point (which got damaged due to a packet loss), the repetition of the FIR must stop. If another FIR is necessary, the request sequence number must be increased. A FIR sender shall not have more than one FIR (different request sequence number) outstanding at any time per media sender in the session.
为了确保尽可能好的可靠性，FIR的发送者可以重复FIR，直到接收到所需的内容。重复间隔由适用于会话的RTCP定时规则确定。在接收到完整的解码器刷新点或检测到试图发送解码器刷新点（由于数据包丢失而损坏）时，必须停止重复FIR。如果需要另一个FIR，则必须增加请求序列号。FIR发送方在会话中的每个媒体发送方在任何时候都不得有超过一个FIR（不同的请求序列号）。
The receiver of FIR (i.e., the media sender) behaves in complementary fashion to ensure delivery of a decoder refresh point. If it receives repetitions of the FIR more than 2*RTT after it has sent a decoder refresh point, it shall send a new decoder refresh point. Two round trip times allow time for the decoder refresh point to arrive back to the requestor and for the end of repetitions of FIR to reach and be detected by the media sender.
FIR的接收器（即，媒体发送器）以互补方式工作，以确保解码器刷新点的交付。如果在发送解码器刷新点后收到的FIR重复次数超过2*RTT，则应发送新的解码器刷新点。两个往返时间允许解码器刷新点返回请求者，并允许媒体发送者到达和检测FIR重复的结束时间。
An RTP mixer or RTP switching MCU that receive a FIR from a media receiver is responsible to ensure that a decoder refresh point is delivered to the requesting receiver. It may be necessary for the mixer/MCU to generate FIR commands. From a reliability perspective, the two legs (FIR-requesting endpoint to mixer/MCU, and mixer/MCU to decoder refresh point generating endpoint) are handled independently from each other.
从媒体接收器接收FIR的RTP混频器或RTP切换MCU负责确保解码器刷新点被传送到请求接收器。混频器/MCU可能需要生成FIR命令。从可靠性的角度来看，这两个分支（FIR请求端点到混频器/MCU，以及混频器/MCU到解码器刷新点生成端点）是相互独立处理的。
The Temporal-Spatial Trade-off Request (TSTR) instructs the video encoder to change its trade-off between temporal and spatial resolution. Index values from 0 to 31 indicate monotonically a desire for higher frame rate. That is, a requester asking for an index of 0 prefers a high quality and is willing to accept a low frame rate, whereas a requester asking for 31 wishes a high frame rate, potentially at the cost of low spatial quality.
时空权衡请求（TSTR）指示视频编码器改变其在时间和空间分辨率之间的权衡。从0到31的索引值单调地表示对更高帧速率的渴望。也就是说，请求索引为0的请求者更喜欢高质量，并且愿意接受低帧速率，而请求索引为31的请求者希望高帧速率，可能以低空间质量为代价。
In general, the encoder reaction time may be significantly longer than the typical picture duration. See use case 3 for an example. The encoder decides whether and to what extent the request results in a change of the trade-off. It returns a Temporal-Spatial Trade-off Notification (TSTN) message to indicate the trade-off that it will use henceforth.
通常，编码器的反应时间可能比典型的图片持续时间长得多。有关示例，请参见用例3。编码器决定请求是否以及在多大程度上导致权衡的改变。它返回一个时空权衡通知（TSTN）消息，以指示今后将使用的权衡。
TSTR and TSTN have been introduced primarily because it is believed that control protocol mechanisms, e.g., a SIP re-invite, are too heavyweight and too slow to allow for a reasonable user experience. Consider, for example, a user interface where the remote user selects the temporal/spatial trade-off with a slider. An immediate feedback to any slider movement is required for a reasonable user experience. A SIP re-INVITE [RFC3261] would require at least two round-trips more (compared to the TSTR/TSTN mechanism) and may involve proxies and other complex mechanisms. Even in a well-designed system, it could take a second or so until the new trade-off is finally selected. Furthermore, the use of RTCP solves the multicast use case very efficiently.
引入TSTR和TSTN的主要原因是，人们认为控制协议机制（例如SIP重新邀请）太重，太慢，无法提供合理的用户体验。例如，考虑一个用户界面，其中远程用户用滑块选择时间/空间权衡。为了获得合理的用户体验，需要对任何滑块移动进行即时反馈。SIP重新邀请[RFC3261]至少需要两次往返（与TSTR/TSTN机制相比），并且可能涉及代理和其他复杂机制。即使在一个设计良好的系统中，也可能需要一秒钟左右的时间，直到最终选择新的折衷方案。此外，RTCP的使用非常有效地解决了多播用例。
The use of TSTR and TSTN in multipoint scenarios is a non-trivial subject, and can be achieved in many implementation-specific ways.
在多点场景中使用TSTR和TSTN是一个非常重要的主题，可以通过许多特定于实现的方式来实现。
Problems stem from the fact that TSTRs will typically arrive unsynchronized, and may request different trade-off values for the same stream and/or endpoint encoder. This memo does not specify a translator's, mixer's, or endpoint's reaction to the reception of a suggested trade-off as conveyed in the TSTR. We only require the receiver of a TSTR message to reply to it by sending a TSTN, carrying the new trade-off chosen by its own criteria (which may or may not be based on the trade-off conveyed by the TSTR). In other words, the trade-off sent in a TSTR is a non-binding recommendation, nothing more.
问题源于这样一个事实，即TSTR通常会以不同步的方式到达，并且可能会为相同的流和/或端点编码器请求不同的折衷值。本备忘录未规定译者、混音员或端点对TSTR中传达的建议权衡的反应。我们只要求TSTR消息的接收者通过发送TSTN来回复该消息，该TSTN包含由其自己的标准选择的新权衡（可能基于TSTR传达的权衡，也可能不基于TSTR传达的权衡）。换言之，TSTR中发送的权衡是一项无约束力的建议，仅此而已。
Three TSTR/TSTN scenarios need to be distinguished, based on the topologies described in [RFC5117]. The scenarios are described in the following subsections.
根据[RFC5117]中描述的拓扑结构，需要区分三种TSTR/TSTN场景。以下小节描述了这些场景。
In this most trivial case (Topo-Point-to-Point), the media sender typically adjusts its temporal/spatial trade-off based on the requested value in TSTR, subject to its own capabilities. The TSTN message conveys back the new trade-off value (which may be identical to the old one if, for example, the sender is not capable of adjusting its trade-off).
在这种最简单的情况下（拓扑点对点），媒体发送方通常根据其自身的能力，根据TSTR中的请求值调整其时间/空间权衡。TSTN消息传回新的折衷值（例如，如果发送方无法调整其折衷值，则该值可能与旧值相同）。
RTCP Multicast is used either with media multicast according to Topo-Multicast, or following RFC 3550's translator model according to Topo-Translator. In these cases, unsynchronized TSTR messages from different receivers may be received, possibly with different requested trade-offs (because of different user preferences). This memo does not specify how the media sender tunes its trade-off. Possible strategies include selecting the mean or median of all trade-off requests received, giving priority to certain participants, or continuing to use the previously selected trade-off (e.g., when the sender is not capable of adjusting it). Again, all TSTR messages need to be acknowledged by TSTN, and the value conveyed back has to reflect the decision made.
RTCP多播可以根据Topo多播与媒体多播一起使用，也可以根据Topo translator遵循RFC 3550的转换器模型。在这些情况下，可能接收来自不同接收器的非同步TSTR消息，可能具有不同的请求权衡（因为不同的用户偏好）。此备忘录未指定媒体发件人如何调整其权衡。可能的策略包括选择收到的所有权衡请求的平均值或中位数，优先考虑某些参与者，或继续使用先前选择的权衡（例如，当发送者无法调整时）。同样，TSTN需要确认所有TSTR消息，并且传回的值必须反映做出的决定。
In this scenario (Topo-Mixer), the RTP mixer receives all TSTR messages, and has the opportunity to act on them based on its own criteria. In most cases, the mixer should form a "consensus" of potentially conflicting TSTR messages arriving from different participants, and initiate its own TSTR message(s) to the media sender(s). As in the previous scenario, the strategy for forming
在该场景（Topo Mixer）中，RTP Mixer接收所有TSTR消息，并有机会根据自己的标准对其采取行动。在大多数情况下，混合器应形成来自不同参与者的潜在冲突TSTR消息的“共识”，并向媒体发送者发起自己的TSTR消息。与前面的场景一样，形成
this "consensus" is up to the implementation, and can, for example, encompass averaging the participants' request values, giving priority to certain participants, or using session default values.
这种“共识”取决于实现，例如，可以包括平均参与者的请求值、给予某些参与者优先级或使用会话默认值。
Even if a mixer or translator performs transcoding, it is very difficult to deliver media with the requested trade-off, unless the content the mixer or translator receives is already close to that trade-off. Thus, if the mixer changes its trade-off, it needs to request the media sender(s) to use the new value, by creating a TSTR of its own. Upon reaching a decision on the used trade-off, it includes that value in the acknowledgement to the downstream requestors. Only in cases where the original source has substantially higher quality (and bit rate) is it likely that transcoding alone can result in the requested trade-off.
即使混音器或翻译器执行转码，也很难按照所请求的折衷方案交付媒体，除非混音器或翻译器接收的内容已经接近折衷方案。因此，如果混音器改变了它的折衷方案，它需要通过创建自己的TSTR来请求媒体发送器使用新值。在对所使用的权衡做出决定后，它将该值包含在对下游请求者的确认中。只有在原始源具有实质上更高的质量（和比特率）的情况下，单独转码才可能导致请求的权衡。
A request and reception acknowledgement mechanism is specified. The Temporal-Spatial Trade-off Notification (TSTN) message informs the requester that its request has been received, and what trade-off is used henceforth. This acknowledgement mechanism is desirable for at least the following reasons:
指定了请求和接收确认机制。时间-空间权衡通知（TSTN）消息通知请求者其请求已被接收，以及此后将使用何种权衡。至少出于以下原因，这种确认机制是可取的：
o A change in the trade-off cannot be directly identified from the media bit stream. o User feedback cannot be implemented without knowing the chosen trade-off value, according to the media sender's constraints. o Repetitive sending of messages requesting an unimplementable trade-off can be avoided.
o 不能直接从媒体比特流中识别权衡的变化。o根据媒体发送者的限制，如果不知道所选的折衷值，就无法实现用户反馈。o可以避免重复发送要求不可实现权衡的消息。
ITU-T Rec. H.271 defines syntax, semantics, and suggested encoder reaction to a Video Back Channel Message. The structure defined in this memo is used to transparently convey such a message from media receiver to media sender. In this memo, we refrain from an in-depth discussion of the available code points within H.271 and refer to the specification text [H.271] instead.
ITU-T Rec.H.271定义了语法、语义和编码器对视频反向通道消息的建议反应。本备忘录中定义的结构用于将此类信息从媒体接收者透明地传达给媒体发送者。在本备忘录中，我们不再深入讨论H.271中的可用代码点，而是参考规范文本[H.271]。
However, we note that some H.271 messages bear similarities with native messages of AVPF and this memo. Furthermore, we note that some H.271 message are known to require caution in multicast environments -- or are plainly not usable in multicast or multipoint scenarios. Table 1 provides a brief, simplified overview of the messages currently defined in H.271, their roughly corresponding AVPF or Codec Control Messages (CCMs) (the latter as specified in this memo), and an indication of our current knowledge of their multicast safety.
然而，我们注意到一些H.271消息与AVPF和本备忘录的本机消息具有相似性。此外，我们注意到，已知一些H.271消息在多播环境中需要小心，或者在多播或多点场景中显然不可用。表1简要概述了H.271中当前定义的消息、其大致对应的AVPF或编解码器控制消息（CCM）（本备忘录中规定的后者），并说明了我们目前对其多播安全性的了解。
H.271 msg type AVPF/CCM msg type multicast-safe
--------------------------------------------------------------------
0 (when used for
reference picture
selection) AVPF RPSI No (positive ACK of pictures)
1 picture loss AVPF PLI Yes
2 partial loss AVPF SLI Yes
3 one parameter CRC N/A Yes (no required sender action)
4 all parameter CRC N/A Yes (no required sender action)
5 refresh point CCM FIR Yes
H.271 msg type AVPF/CCM msg type multicast-safe
--------------------------------------------------------------------
0 (when used for
reference picture
selection) AVPF RPSI No (positive ACK of pictures)
1 picture loss AVPF PLI Yes
2 partial loss AVPF SLI Yes
3 one parameter CRC N/A Yes (no required sender action)
4 all parameter CRC N/A Yes (no required sender action)
5 refresh point CCM FIR Yes
Table 1: H.271 messages and their AVPF/CCM equivalents
表1:H.271消息及其AVPF/CCM等价物
Note: H.271 message type 0 is not a strict equivalent to AVPF's Reference Picture Selection Indication (RPSI); it is an indication of known-as-correct reference picture(s) at the decoder. It does not command an encoder to use a defined reference picture (the form of control information envisioned to be carried in RPSI). However, it is believed and intended that H.271 message type 0 will be used for the same purpose as AVPF's RPSI -- although other use forms are also possible.
注：H.271消息类型0并不严格等同于AVPF的参考图片选择指示（RPSI）；它是解码器处已知的正确参考图片的指示。它不会命令编码器使用定义的参考图片（RPSI中预期携带的控制信息的形式）。然而，人们相信并打算将H.271消息类型0用于与AVPF的RPSI相同的目的——尽管也可以使用其他形式。
In response to the opaqueness of the H.271 messages, especially with respect to the multicast safety, the following guidelines MUST be followed when an implementation wishes to employ the H.271 video back channel message:
为了响应H.271消息的不透明性，特别是在多播安全方面，当实现希望使用H.271视频反向通道消息时，必须遵循以下准则：
1. Implementations utilizing the H.271 feedback message MUST stay in compliance with congestion control principles, as outlined in section 5.
1. 使用H.271反馈消息的实施必须遵守拥塞控制原则，如第5节所述。
2. An implementation SHOULD utilize the IETF-native messages as defined in [RFC4585] and in this memo instead of similar messages defined in [H.271]. Our current understanding of similar messages is documented in Table 1 above. One good reason to divert from the SHOULD statement above would be if it is clearly understood that, for a given application and video compression standard, the aforementioned "similarity" is not given, in contrast to what the table indicates.
2. 实施应使用[RFC4585]和本备忘录中定义的IETF本机消息，而不是[H.271]中定义的类似消息。我们目前对类似信息的理解记录在上面的表1中。如果清楚地了解到，对于给定的应用程序和视频压缩标准，与表中所示相反，没有给出上述“相似性”，则有一个很好的理由不使用上述“应”语句。
3. It has been observed that some of the H.271 code points currently in existence are not multicast-safe. Therefore, the sensible thing to do is not to use the H.271 feedback message type in multicast environments. It MAY be used only when all the issues mentioned later are fully understood by the implementer, and properly taken into account by all endpoints. In all other cases, the H.271 message type MUST NOT be used in conjunction with multicast.
3. 据观察，目前存在的一些H.271代码点不是多播安全的。因此，明智的做法是不要在多播环境中使用H.271反馈消息类型。只有当实现者完全理解了后面提到的所有问题，并且所有端点都正确地考虑了这些问题时，才可以使用它。在所有其他情况下，H.271消息类型不得与多播一起使用。
4. It has been observed that even in centralized multipoint environments, where the mixer should theoretically be able to resolve issues as documented below, the implementation of such a mixer and cooperative endpoints is a very difficult and tedious task. Therefore, H.271 messages MUST NOT be used in centralized multipoint scenarios, unless all the issues mentioned below are fully understood by the implementer, and properly taken into account by both mixer and endpoints.
4. 已经观察到，即使在集中式多点环境中，混频器理论上应该能够解决如下所述的问题，这种混频器和协作端点的实现也是一项非常困难和繁琐的任务。因此，H.271消息不得用于集中式多点场景，除非实现者完全理解下面提到的所有问题，并且混合器和端点都适当地考虑了这些问题。
Issues to be taken into account when considering the use of H.271 in multipoint environments:
考虑在多点环境中使用H.271时应考虑的问题：
1. Different state on different receivers. In many environments, it cannot be guaranteed that the decoder state of all media receivers is identical at any given point in time. The most obvious reason for such a possible misalignment of state is a loss that occurs on the path to only one of many media receivers. However, there are other not so obvious reasons, such as recent joins to the multipoint conference (be it by joining the multicast group or through additional mixer output). Different states can lead the media receivers to issue potentially contradicting H.271 messages (or one media receiver issuing an H.271 message that, when observed by the media sender, is not helpful for the other media receivers). A naive reaction of the media sender to these contradicting messages can lead to unpredictable and annoying results.
1. 不同的接收器上有不同的状态。在许多环境中，无法保证所有媒体接收器的解码器状态在任何给定时间点都是相同的。造成这种可能的状态偏差的最明显原因是，在多个媒体接收器中只有一个的路径上发生丢失。然而，还有其他不太明显的原因，例如最近加入多点会议（通过加入多播组或通过额外的混音器输出）。不同的状态可能导致媒体接收器发出可能相互矛盾的H.271消息（或一个媒体接收器发出H.271消息，当媒体发送者观察到该消息时，该消息对其他媒体接收器没有帮助）。媒体发送者对这些相互矛盾的消息的天真反应可能导致不可预测和恼人的结果。
2. Combining messages from different media receivers in a media sender is a non-trivial task. As reasons, we note that these messages may be contradicting each other, and that their transport is unreliable (there may well be other reasons). In case of many H.271 messages (i.e., types 0, 2, 3, and 4), the algorithm for combining must be aware both of the network/protocol environment (i.e., with respect to congestion) and of the media codec employed, as H.271 messages of a given type can have different semantics for different media codecs.
2. 将来自不同媒体接收者的消息合并到媒体发送者中是一项非常重要的任务。作为原因，我们注意到这些消息可能相互矛盾，并且它们的传输不可靠（很可能还有其他原因）。在许多H.271消息（即类型0、2、3和4）的情况下，用于组合的算法必须了解网络/协议环境（即，关于拥塞）和所采用的媒体编解码器，因为给定类型的H.271消息对于不同的媒体编解码器可以具有不同的语义。
3. The suppression of requests may need to go beyond the basic mechanisms described in AVPF (which are driven exclusively by timing and transport considerations on the protocol level). For example, a receiver is often required to refrain from (or delay) generating requests, based on information it receives from the media stream. For instance, it makes no sense for a receiver to issue a FIR when a transmission of an Intra/IDR picture is ongoing.
3. 对请求的抑制可能需要超出AVPF中描述的基本机制（仅由协议级别的定时和传输考虑因素驱动）。例如，通常要求接收机基于从媒体流接收到的信息来避免（或延迟）生成请求。例如，当帧内/IDR图片的传输正在进行时，接收机发出FIR是没有意义的。
4. When using the non-multicast-safe messages (e.g., H.271 type 0 positive ACK of received pictures/slices) in larger multicast groups, the media receiver will likely be forced to delay or even omit sending these messages. For the media sender, this looks like data has not been properly received (although it was received properly), and a naively implemented media sender reacts to these perceived problems where it should not.
4. 当在较大的多播组中使用非多播安全消息（例如，H.271 type 0接收到的图片/片段的肯定ACK）时，媒体接收器可能会被迫延迟甚至忽略发送这些消息。对于媒体发送者来说，这看起来像是数据没有被正确接收（尽管它被正确接收），而一个天真地实现的媒体发送者会在不应该的地方对这些感知到的问题做出反应。
H.271 Video Back Channel Messages do not require reliable transmission, and confirmation of the reception of a message can be derived from the forward video bit stream. Therefore, no specific reception acknowledgement is specified.
H.271视频后向信道消息不需要可靠传输，并且可以从前向视频比特流导出消息接收的确认。因此，没有指定特定的接收确认。
With respect to re-sending rules, section 3.5.1.1 applies.
关于重新发送规则，第3.5.1.1节适用。
A receiver, translator, or mixer uses the Temporary Maximum Media Stream Bit Rate Request (TMMBR, "timber") to request a sender to limit the maximum bit rate for a media stream (see section 2.2) to, or below, the provided value. The Temporary Maximum Media Stream Bit Rate Notification (TMMBN) contains the media sender's current view of the most limiting subset of the TMMBR-defined limits it has received, to help the participants to suppress TMMBRs that would not further restrict the media sender. The primary usage for the TMMBR/TMMBN messages is in a scenario with an MCU or mixer (use case 6), corresponding to Topo-Translator or Topo-Mixer, but also to Topo-Point-to-Point.
接收机、翻译器或混音器使用临时最大媒体流比特率请求（TMMBR，“timber”）来请求发送方将媒体流的最大比特率（见第2.2节）限制在或低于提供的值。临时最大媒体流比特率通知（TMMBN）包含媒体发送者对其收到的TMMBR定义限制的最有限子集的当前视图，以帮助参与者抑制不会进一步限制媒体发送者的TMMBR。TMMBR/TMMBN消息的主要用途是在具有MCU或混合器（用例6）的场景中，对应于Topo Translator或Topo mixer，但也对应于Topo点对点。
Each temporary limitation on the media stream is expressed as a tuple. The first component of the tuple is the maximum total media bit rate (as defined in section 2.2) that the media receiver is currently prepared to accept for this media stream. The second component is the per-packet overhead that the media receiver has observed for this media stream at its chosen reference protocol layer.
媒体流上的每个临时限制都表示为元组。元组的第一个组成部分是媒体接收器当前准备接受该媒体流的最大总媒体比特率（如第2.2节所定义）。第二部分是媒体接收器在其选择的参考协议层上观察到此媒体流的每分组开销。
As indicated in section 2.2, the overhead as observed by the sender of the TMMBR (i.e., the media receiver) may differ from the overhead observed at the receiver of the TMMBR (i.e., the media sender) due to use of a different reference protocol layer at the other end or due to the intervention of translators or mixers that affect the amount of per packet overhead. For example, a gateway in between the two that converts between IPv4 and IPv6 affects the per-packet overhead by 20 bytes. Other mechanisms that change the overhead include tunnels. The problem with varying overhead is also discussed in
如第2.2节所述，TMMBR发送方（即媒体接收方）观察到的开销可能不同于TMMBR接收方（即媒体发送方）观察到的开销由于在另一端使用不同的参考协议层，或者由于影响每个数据包开销量的转换器或混频器的干预。例如，介于IPv4和IPv6之间的网关在IPv4和IPv6之间进行转换，会对每个数据包的开销产生20字节的影响。其他改变架空的机制包括隧道。本文还讨论了开销变化的问题
[RFC3890]. As will be seen in the description of the algorithm for use of TMMBR, the difference in perceived overhead between the sending and receiving ends presents no difficulty because calculations are carried out in terms of variables that have the same value at the sender as at the receiver -- for example, packet rate and net media rate.
[RFC3890]。从TMMBR使用算法的描述中可以看出，发送端和接收端之间感知开销的差异并不困难，因为计算是根据发送方和接收方具有相同值的变量进行的——例如，分组速率和净媒体速率。
Reporting both maximum total media bit rate and per-packet overhead allows different receivers to provide bit rate and overhead values for different protocol layers, for example, at the IP level, at the outer part of a tunnel protocol, or at the link layer. The protocol level a peer reports on depends on the level of integration the peer has, as it needs to be able to extract the information from that protocol level. For example, an application with no knowledge of the IP version it is running over cannot meaningfully determine the overhead of the IP header, and hence will not want to include IP overhead in the overhead or maximum total media bit rate calculation.
报告最大总媒体比特率和每包开销允许不同的接收器为不同的协议层提供比特率和开销值，例如，在IP级别、隧道协议的外部或链路层。对等方报告的协议级别取决于对等方的集成级别，因为它需要能够从该协议级别提取信息。例如，不知道正在运行的IP版本的应用程序无法有意义地确定IP头的开销，因此不希望在开销或最大总媒体比特率计算中包括IP开销。
It is expected that most peers will be able to report values at least for the IP layer. In certain implementations, it may be advantageous to also include information pertaining to the link layer, which in turn allows for a more precise overhead calculation and a better optimization of connectivity resources.
预计大多数对等方至少能够报告IP层的值。在某些实现中，还包括关于链路层的信息可能是有利的，这反过来允许更精确的开销计算和更好地优化连接资源。
The Temporary Maximum Media Stream Bit Rate messages are generic messages that can be applied to any RTP packet stream. This separates them from the other codec control messages defined in this specification, which apply only to specific media types or payload formats. The TMMBR functionality applies to the transport, and the requirements the transport places on the media encoding.
临时最大媒体流比特率消息是可应用于任何RTP分组流的通用消息。这将它们与本规范中定义的其他编解码器控制消息分开，后者仅适用于特定的媒体类型或有效负载格式。TMMBR功能适用于传输以及传输对媒体编码的要求。
The reasoning below assumes that the participants have negotiated a session maximum bit rate, using a signaling protocol. This value can be global, for example, in case of point-to-point, multicast, or translators. It may also be local between the participant and the peer or mixer. In either case, the bit rate negotiated in signaling is the one that the participant guarantees to be able to handle (depacketize and decode). In practice, the connectivity of the participant also influences the negotiated value -- it does not make much sense to negotiate a total media bit rate that one's network interface does not support.
下面的推理假设参与者已使用信令协议协商会话最大比特率。例如，在点对点、多播或转换器的情况下，此值可以是全局值。它也可以是参与者与对等者或混音者之间的本地。在任何一种情况下，信令中协商的比特率都是参与者保证能够处理的比特率（解包和解码）。实际上，参与者的连通性也会影响协商值——协商网络接口不支持的总媒体比特率没有多大意义。
It is also beneficial to have negotiated a maximum packet rate for the session or sender. RFC 3890 provides an SDP [RFC4566] attribute that can be used for this purpose; however, that attribute is not usable in RTP sessions established using offer/answer [RFC3264]. Therefore, an optional maximum packet rate signaling parameter is specified in this memo.
协商会话或发送方的最大数据包速率也是有益的。RFC 3890提供可用于此目的的SDP[RFC4566]属性；但是，该属性在使用提供/应答[RFC3264]建立的RTP会话中不可用。因此，本备忘录中指定了可选的最大分组速率信令参数。
An already established maximum total media bit rate may be changed at any time, subject to the timing rules governing the sending of feedback messages. The limit may change to any value between zero and the session maximum, as negotiated during session establishment signaling. However, even if a sender has received a TMMBR message allowing an increase in the bit rate, all increases must be governed by a congestion control mechanism. TMMBR indicates known limitations only, usually in the local environment, and does not provide any guarantees about the full path. Furthermore, any increases in TMMBR-established bit rate limits are to be executed only after a certain delay from the sending of the TMMBN message that notifies the world about the increase in limit. The delay is specified as at least twice the longest RTT as known by the media sender, plus the media sender's calculation of the required wait time for the sending of another TMMBR message for this session based on AVPF timing rules. This delay is introduced to allow other session participants to make known their bit rate limit requirements, which may be lower.
根据控制反馈消息的发送的定时规则，可以随时改变已经建立的最大媒体总比特率。如在会话建立信令期间协商的，该限制可以改变为零和会话最大值之间的任何值。然而，即使发送方已收到允许比特率增加的TMMBR消息，所有增加都必须由拥塞控制机制控制。TMMBR仅表示已知的限制，通常在本地环境中，并且不提供关于完整路径的任何保证。此外，TMMBR确定的比特率限制的任何增加仅在发送TMMBN消息（该消息通知世界限制的增加）的一定延迟后执行。延迟被指定为媒体发送方已知的最长RTT的至少两倍，加上媒体发送方根据AVPF定时规则计算的该会话发送另一条TMMBR消息所需的等待时间。引入此延迟是为了允许其他会话参与者告知他们的比特率限制要求，该要求可能更低。
If it is likely that the new value indicated by TMMBR will be valid for the remainder of the session, the TMMBR sender is expected to perform a renegotiation of the session upper limit using the session signaling protocol.
如果TMMBR指示的新值可能在会话的剩余时间内有效，则TMMBR发送方应使用会话信令协议重新协商会话上限。
This section is an informal description of behaviour described more precisely in section 4.2.
本节是对第4.2节中更精确描述的行为的非正式描述。
A media sender begins the session limited by the maximum media bit rate and maximum packet rate negotiated in session signaling, if any. Note that this value may be negotiated for another protocol layer than the one the participant uses in its TMMBR messages. Each media receiver selects a reference protocol layer, forms an estimate of the overhead it is observing (or estimating it if no packets has been seen yet) at that reference level, and determines the maximum total media bit rate it can accept, taking into account its own limitations and any transport path limitations of which it may be aware. In case the current limitations are more restricting than what was agreed on in the session signaling, the media receiver reports its initial estimate of these two quantities to the media sender using a TMMBR message. Overall message traffic is reduced by the possibility of including tuples for multiple media senders in the same TMMBR message.
媒体发送方开始由会话信令中协商的最大媒体比特率和最大分组率（如果有）限制的会话。请注意，此值可以为参与者在其TMMBR消息中使用的协议层之外的另一个协议层进行协商。每个媒体接收器选择一个参考协议层，形成其在该参考级别上观察到的开销的估计值（或者，如果还没有看到分组，则对其进行估计），并确定其可以接受的最大总媒体比特率，同时考虑其自身的限制和它可能知道的任何传输路径限制。如果当前限制比会话信令中约定的限制更大，则媒体接收器使用TMMBR消息向媒体发送者报告其对这两个量的初始估计。通过在同一TMMBR消息中包含多个媒体发送者的元组，可以减少总体消息流量。
The media sender applies an algorithm such as that specified in section 3.5.4.2 to select which of the tuples it has received are most limiting (i.e., the bounding set as defined in section 2.2). It modifies its operation to stay within the feasible region (as defined
媒体发送方应用第3.5.4.2节中规定的算法来选择其接收到的元组中哪一个最具限制性（即第2.2节中定义的边界集）。它修改其操作以保持在可行区域内（如定义
in section 2.2), and also sends out a TMMBN to the media receivers indicating the selected bounding set. That notification also indicates who was responsible for the tuples in the bounding set, i.e., the "owner"(s) of the limitation. A session participant that owns no tuple in the bounding set is called a "non-owner".
在第2.2节中），并向媒体接收器发送TMMBN，指示选定的边界集。该通知还指示谁负责边界集中的元组，即限制的“所有者”。在边界集中不拥有元组的会话参与者称为“非所有者”。
If a media receiver does not own one of the tuples in the bounding set reported by the TMMBN, it applies the same algorithm as the media sender to determine if its current estimated (maximum total media bit rate, overhead) tuple would enter the bounding set if known to the media sender. If so, it issues a TMMBR reporting the tuple value to the sender. Otherwise, it takes no action for the moment. Periodically, its estimated tuple values may change or it may receive a new TMMBN. If so, it reapplies the algorithm to decide whether it needs to issue a TMMBR.
如果媒体接收器不拥有TMMBN报告的边界集中的元组之一，它将应用与媒体发送器相同的算法来确定其当前估计（最大媒体总比特率，开销）元组是否将进入边界集（如果媒体发送器已知）。如果是这样，它将发出一个TMMBR，向发送方报告元组值。否则，它暂时不采取行动。周期性地，其估计的元组值可能改变，或者它可能接收新的TMMBN。如果是这样，它将重新应用算法以决定是否需要发出TMMBR。
If, alternatively, a media receiver owns one of the tuples in the reported bounding set, it takes no action until such time as its estimate of its own tuple values changes. At that time, it sends a TMMBR to the media sender to report the changed values.
或者，如果媒体接收器拥有报告的边界集中的一个元组，则在其对自身元组值的估计发生变化之前，它不会采取任何行动。此时，它会向媒体发送器发送一个TMMBR，以报告更改的值。
A media receiver may change status between owner and non-owner of a bounding tuple between one TMMBN message and the next. Thus, it must check the contents of each TMMBN to determine its subsequent actions.
媒体接收器可以在一个TMMBN消息和下一个TMMBN消息之间的边界元组的所有者和非所有者之间改变状态。因此，它必须检查每个TMMBN的内容，以确定其后续操作。
Implementations may use other algorithms of their choosing, as long as the bit rate limitations resulting from the exchange of TMMBR and TMMBN messages are at least as strict (at least as low, in the bit rate dimension) as the ones resulting from the use of the aforementioned algorithm.
只要由TMMBR和TMMBN消息交换产生的比特率限制至少与使用上述算法产生的比特率限制一样严格（至少在比特率维度上一样低），实现可以使用它们选择的其他算法。
Obviously, in point-to-point cases, when there is only one media receiver, this receiver becomes "owner" once it receives the first TMMBN in response to its own TMMBR, and stays "owner" for the rest of the session. Therefore, when it is known that there will always be only a single media receiver, the above algorithm is not required. Media receivers that are aware they are the only ones in a session can send TMMBR messages with bit rate limits both higher and lower than the previously notified limit, at any time (subject to the AVPF [RFC4585] RTCP RR send timing rules). However, it may be difficult for a session participant to determine if it is the only receiver in the session. Because of this, any implementation of TMMBR is required to include the algorithm described in the next section or a stricter equivalent.
显然，在点对点的情况下，当只有一个媒体接收器时，该接收器在收到第一个TMMBN以响应其自身的TMMBR后即成为“所有者”，并在会话的其余部分保持“所有者”。因此，当知道始终只有一个媒体接收器时，不需要上述算法。知道自己是会话中唯一一个的媒体接收器可以随时发送比特率限制高于或低于先前通知限制的TMMBR消息（根据AVPF[RFC4585]RTCP RR发送定时规则）。但是，会话参与者可能很难确定自己是否是会话中的唯一接收者。因此，TMMBR的任何实现都需要包含下一节中描述的算法或更严格的等效算法。
This section introduces an example algorithm for the calculation of a session limit. Other algorithms can be employed, as long as the result of the calculation is at least as restrictive as the result that is obtained by this algorithm.
本节介绍计算会话限制的示例算法。可以使用其他算法，只要计算结果至少与通过该算法获得的结果具有同样的限制性。
First, it is important to consider the implications of using a tuple for limiting the media sender's behavior. The bit rate and the overhead value result in a two-dimensional solution space for the calculation of the bit rate of media streams. Fortunately, the two variables are linked. Specifically, the bit rate available for RTP payloads is equal to the TMMBR reported bit rate minus the packet rate used, multiplied by the TMMBR reported overhead converted to bits. As a result, when different bit rate/overhead combinations need to be considered, the packet rate determines the correct limitation. This is perhaps best explained by an example:
首先，重要的是考虑使用元组限制媒体发送者的行为的影响。比特率和开销值产生用于计算媒体流比特率的二维解空间。幸运的是，这两个变量是相互关联的。具体而言，RTP有效负载的可用比特率等于TMMBR报告的比特率减去使用的分组速率，再乘以TMMBR报告的转换为比特的开销。因此，当需要考虑不同的比特率/开销组合时，分组速率确定正确的限制。这也许可以用一个例子来最好地解释：
Example:
例子：
Receiver A: TMMBR_max total BR = 35 kbps, TMMBR_OH = 40 bytes
Receiver B: TMMBR_max total BR = 40 kbps, TMMBR_OH = 60 bytes
Receiver A: TMMBR_max total BR = 35 kbps, TMMBR_OH = 40 bytes
Receiver B: TMMBR_max total BR = 40 kbps, TMMBR_OH = 60 bytes
For a given packet rate (PR), the bit rate available for media payloads in RTP will be:
对于给定的分组速率（PR），RTP中媒体有效负载的可用比特率为：
Max_net media_BR_A =
TMMBR_max total BR_A - PR * TMMBR_OH_A * 8 ... (1)
Max_net media_BR_A =
TMMBR_max total BR_A - PR * TMMBR_OH_A * 8 ... (1)
Max_net media_BR_B =
TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ... (2)
Max_net media_BR_B =
TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ... (2)
For a PR = 20, these calculations will yield a Max_net media_BR_A = 28600 bps and Max_net media_BR_B = 30400 bps, which suggests that receiver A is the limiting one for this packet rate. However, at a certain PR there is a switchover point at which receiver B becomes the limiting one. The switchover point can be identified by setting Max_media_BR_A equal to Max_media_BR_B and breaking out PR:
对于PR=20，这些计算将产生Max_net media_BR_a=28600 bps和Max_net media_BR_B=30400 bps，这表明接收器a是该分组速率的限制。然而，在特定PR处存在切换点，在该切换点处接收器B成为限制点。切换点可以通过将Max_media设置为Max_media_BR_B并断开PR来识别：
TMMBR_max total BR_A - TMMBR_max total BR_B
PR = ------------------------------------------- ... (3)
8*(TMMBR_OH_A - TMMBR_OH_B)
TMMBR_max total BR_A - TMMBR_max total BR_B
PR = ------------------------------------------- ... (3)
8*(TMMBR_OH_A - TMMBR_OH_B)
which, for the numbers above, yields 31.25 as the switchover point between the two limits. That is, for packet rates below 31.25 per second, receiver A is the limiting receiver, and for higher packet rates, receiver B is more limiting. The implications of this behavior have to be considered by implementations that are going to
对于上述数字，产生31.25作为两个极限之间的转换点。也就是说，对于低于每秒31.25的分组速率，接收机A是限制接收机，而对于更高的分组速率，接收机B更具限制性。这一行为的含义必须由即将发布的实现来考虑
control media encoding and its packetization. As exemplified above, multiple TMMBR limits may apply to the trade-off between net media bit rate and packet rate. Which limitation applies depends on the packet rate being considered.
控制媒体编码及其打包。如上所示，多个TMMBR限制可应用于净媒体比特率和分组速率之间的权衡。应用哪种限制取决于所考虑的数据包速率。
This also has implications for how the TMMBR mechanism needs to work. First, there is the possibility that multiple TMMBR tuples are providing limitations on the media sender. Secondly, there is a need for any session participant (media sender and receivers) to be able to determine if a given tuple will become a limitation upon the media sender, or if the set of already given limitations is stricter than the given values. In the absence of the ability to make this determination, the suppression of TMMBRs would not work.
这也影响了TMMBR机制需要如何工作。首先，有可能是多个TMMBR元组对媒体发送方提供了限制。其次，任何会话参与者（媒体发送者和接收者）都需要能够确定给定的元组是否会成为对媒体发送者的限制，或者已经给定的限制集是否比给定的值更严格。在没有能力作出这一决定的情况下，TMMBR的抑制将不起作用。
The basic idea of the algorithm is as follows. Each TMMBR tuple can be viewed as the equation of a straight line (cf. equations (1) and (2)) in a space where packet rate lies along the X-axis and net bit rate along the Y-axis. The lower envelope of the set of lines corresponding to the complete set of TMMBR tuples, together with the X and Y axes, defines a polygon. Points lying within this polygon are combinations of packet rate and bit rate that meet all of the TMMBR constraints. The highest feasible packet rate within this region is the minimum of the rate at which the bounding polygon meets the X-axis or the session maximum packet rate (SMAXPR, measured in packets per second) provided by signaling, if any. Typically, a media sender will prefer to operate at a lower rate than this theoretical maximum, so as to increase the rate at which actual media content reaches the receivers. The purpose of the algorithm is to distinguish the TMMBR tuples constituting the bounding set and thus delineate the feasible region, so that the media sender can select its preferred operating point within that region
该算法的基本思想如下。每个TMMBR元组可被视为空间中的直线方程（参见方程（1）和（2）），其中分组速率沿X轴，净比特率沿Y轴。与TMMBR元组的完整集合相对应的线集合的下封套，以及X和Y轴，定义了一个多边形。位于该多边形内的点是满足所有TMMBR约束的数据包速率和比特率的组合。该区域内的最高可行分组速率是边界多边形满足X轴的速率或信令提供的会话最大分组速率（SMAXPR，以每秒分组数为单位，如果有）中的最小值。通常，媒体发送者将倾向于以低于该理论最大值的速率操作，以便增加实际媒体内容到达接收器的速率。该算法的目的是区分构成边界集的TMMBR元组，从而描绘可行区域，以便媒体发送者可以在该区域内选择其首选操作点
Figure 1 below shows a bounding polygon formed by TMMBR tuples A and B. A third tuple C lies outside the bounding polygon and is therefore irrelevant in determining feasible trade-offs between media rate and packet rate. The line labeled ss..s represents the limit on packet rate imposed by the session maximum packet rate (SMAXPR) obtained by signaling during session setup. In Figure 1, the limit determined by tuple B happens to be more restrictive than SMAXPR. The situation could easily be the reverse, meaning that the bounding polygon is terminated on the right by the vertical line representing the SMAXPR constraint.
下图1显示了由TMMBR元组a和B组成的边界多边形。第三个元组C位于边界多边形之外，因此在确定媒体速率和数据包速率之间的可行权衡时不相关。标记为ss..s的行表示会话设置期间通过信令获得的会话最大分组速率（SMAXPR）对分组速率施加的限制。在图1中，元组B确定的限制恰好比SMAXPR更严格。情况很容易相反，这意味着边界多边形在右侧由表示SMAXPR约束的垂直线终止。
Net ^
Media|a c b s
Bit | a c b s
Rate | a c b s
| a cb s
| a c s
| a bc s
| a b c s
| ab c s
| Feasible b c s
| region ba s
| b a s c
| b s c
| b s a
| bs
+------------------------------>
Net ^
Media|a c b s
Bit | a c b s
Rate | a c b s
| a cb s
| a c s
| a bc s
| a b c s
| ab c s
| Feasible b c s
| region ba s
| b a s c
| b s c
| b s a
| bs
+------------------------------>
Packet rate
包速率
Figure 1 - Geometric Interpretation of TMMBR Tuples
图1-TMMBR元组的几何解释
Note that the slopes of the lines making up the bounding polygon are increasingly negative as one moves in the direction of increasing packet rate. Note also that with slight rearrangement, equations (1) and (2) have the canonical form:
请注意，随着数据包速率的增加，构成边界多边形的线的斜率越来越负。还请注意，通过轻微的重新排列，等式（1）和（2）具有标准形式：
y = mx + b
y=mx+b
where m is the slope and has value equal to the negative of the tuple overhead (in bits), and b is the y-intercept and has value equal to the tuple maximum total media bit rate.
其中m是斜率，其值等于元组开销的负值（以位为单位），b是y截距，其值等于元组最大总媒体比特率。
These observations lead to the conclusion that when processing the TMMBR tuples to select the initial bounding set, one should sort and process the tuples by order of increasing overhead. Once a particular tuple has been added to the bounding set, all tuples not already selected and having lower overhead can be eliminated, because the next side of the bounding polygon has to be steeper (i.e., the corresponding TMMBR must have higher overhead) than the latest added tuple.
这些观察结果表明，在处理TMMBR元组以选择初始边界集时，应按开销增加的顺序对元组进行排序和处理。将特定元组添加到边界集中后，可以消除所有尚未选择且开销较低的元组，因为边界多边形的下一侧必须比最新添加的元组更陡峭（即，相应的TMMBR必须具有更高的开销）。
Line cc..c in Figure 1 illustrates another principle. This line is parallel to line aa..a, but has a higher Y-intercept. That is, the corresponding TMMBR tuple contains a higher maximum total media bit rate value. Since line cc..c is outside the bounding polygon, it
图1中的cc..c行说明了另一个原理。这条线与线aa..a平行，但具有较高的Y截距。也就是说，相应的TMMBR元组包含更高的最大媒体总比特率值。由于线cc..c位于边界多边形之外，因此
illustrates the conclusion that if two TMMBR tuples have the same overhead value, the one with higher maximum total media bit rate value cannot be part of the bounding set and can be set aside.
说明了这样一个结论：如果两个TMMBR元组具有相同的开销值，则最大媒体总比特率值较高的元组不能成为边界集的一部分，并且可以将其放在一边。
Two further observations complete the algorithm. Obviously, moving from the left, the successive corners of the bounding polygon (i.e., the intersection points between successive pairs of sides) lie at successively higher packet rates. On the other hand, again moving from the left, each successive line making up the bounding set crosses the X-axis at a lower packet rate.
两个进一步的观察完成了算法。显然，从左侧移动，边界多边形的连续角（即，连续对边之间的交点）处于连续较高的分组速率。另一方面，再次从左侧移动，构成边界集的每个连续行以较低的分组速率穿过X轴。
The complete algorithm can now be specified. The algorithm works with two lists of TMMBR tuples, the candidate list X and the selected list Y, both ordered by increasing overhead value. The algorithm terminates when all members of X have been discarded or removed for processing. Membership of the selected list Y is probationary until the algorithm is complete. Each member of the selected list is associated with an intersection value, which is the packet rate at which the line corresponding to that TMMBR tuple intersects with the line corresponding to the previous TMMBR tuple in the selected list. Each member of the selected list is also associated with a maximum packet rate value, which is the lesser of the session maximum packet rate SMAXPR (if any) and the packet rate at which the line corresponding to that tuple crosses the X-axis.
现在可以指定完整的算法。该算法使用两个TMMBR元组列表，候选列表X和选定列表Y，它们都是通过增加开销值排序的。当X的所有成员被丢弃或移除以进行处理时，该算法终止。在算法完成之前，所选列表Y的成员资格是暂时的。所选列表的每个成员都与一个交集值相关联，该交集值是与该TMMBR元组对应的行与所选列表中前一个TMMBR元组对应的行相交时的数据包速率。所选列表的每个成员还与最大分组速率值相关联，最大分组速率值是会话最大分组速率SMAXPR（如果有）和对应于该元组的线穿过X轴的分组速率中的较小者。
When the algorithm terminates, the selected list is equal to the bounding set as defined in section 2.2.
当算法终止时，所选列表等于第2.2节中定义的边界集。
Initial Algorithm
初始算法
This algorithm is used by the media sender when it has received one or more TMMBRs and before it has determined a bounding set for the first time.
当媒体发送方收到一个或多个TMMBR并且在第一次确定边界集之前，该算法由媒体发送方使用。
1. Sort the TMMBR tuples by order of increasing overhead. This is the initial candidate list X.
1. 按开销增加的顺序对TMMBR元组进行排序。这是初始候选列表X。
2. When multiple tuples in the candidate list have the same overhead value, discard all but the one with the lowest maximum total media bit rate value.
2. 当候选列表中的多个元组具有相同的开销值时，除了具有最低最大媒体总比特率值的元组外，放弃所有元组。
3. Select and remove from the candidate list the TMMBR tuple with the lowest maximum total media bit rate value. If there is more than one tuple with that value, choose the one with the highest overhead value. This is the first member of the selected list Y. Set its intersection value equal to zero. Calculate its maximum
3. 从候选列表中选择并删除具有最低最大媒体总比特率值的TMMBR元组。如果有多个元组具有该值，请选择开销值最高的元组。这是所选列表Y的第一个成员。将其交点值设置为零。计算其最大值
packet rate as the minimum of SMAXPR (if available) and the value obtained from the following formula, which is the packet rate at which the corresponding line crosses the X-axis.
数据包速率为SMAXPR（如果可用）的最小值，以及从以下公式中获得的值，该值是对应线穿过X轴时的数据包速率。
Max PR = TMMBR max total BR / (8 * TMMBR OH) ... (4)
Max PR = TMMBR max total BR / (8 * TMMBR OH) ... (4)
4. Discard from the candidate list all tuples with a lower overhead value than the selected tuple.
4. 从候选列表中放弃开销值低于所选元组的所有元组。
5. Remove the first remaining tuple from the candidate list for processing. Call this the current candidate.
5. 从候选列表中删除剩余的第一个元组以进行处理。称之为当前候选人。
6. Calculate the packet rate PR at the intersection of the line generated by the current candidate with the line generated by the last tuple in the selected list Y, using equation (3).
6. 使用等式（3）计算当前候选生成的线与所选列表Y中最后一个元组生成的线的交点处的分组速率PR。
7. If the calculated value PR is equal to or lower than the intersection value stored for the last tuple of the selected list, discard the last tuple of the selected list and go back to step 6 (retaining the same current candidate).
7. 如果计算值PR等于或低于为所选列表的最后一个元组存储的交集值，则放弃所选列表的最后一个元组并返回步骤6（保留相同的当前候选值）。
Note that the choice of the initial member of the selected list Y in step 3 guarantees that the selected list will never be emptied by this process, meaning that the algorithm must eventually (if not immediately) fall through to step 8.
注意，在步骤3中选择所选列表Y的初始成员可确保所选列表不会被该过程清空，这意味着算法必须最终（如果不是立即）进入步骤8。
8. (This step is reached when the calculated PR value of the current candidate is greater than the intersection value of the current last member of the selected list Y.) If the calculated value PR of the current candidate is lower than the maximum packet rate associated with the last tuple in the selected list, add the current candidate tuple to the end of the selected list. Store PR as its intersection value. Calculate its maximum packet rate as the lesser of SMAXPR (if available) and the maximum packet rate calculated using equation (4).
8. （当当前候选的计算PR值大于所选列表Y的当前最后一个成员的交集值时，达到该步骤。）如果当前候选的计算值PR低于与所选列表中最后一个元组相关联的最大分组速率，将当前候选元组添加到所选列表的末尾。将PR存储为其交点值。将其最大分组速率计算为SMAXPR（如果可用）和使用等式（4）计算的最大分组速率中的较小者。
9. If any tuples remain in the candidate list, go back to step 5.
9. 如果候选列表中还有任何元组，请返回步骤5。
Incremental Algorithm
增量算法
The previous algorithm covered the initial case, where no selected list had previously been created. It also applied only to the media sender. When a previously created selected list is available at either the media sender or media receiver, two other cases can be considered:
以前的算法涵盖了初始情况，在此情况下，以前没有创建选定列表。它也仅适用于媒体发件人。当先前创建的选定列表在媒体发送方或媒体接收方可用时，可以考虑以下两种情况：
o when a TMMBR tuple not currently in the selected list is a candidate for addition;
o 当前不在所选列表中的TMMBR元组是添加的候选元组时；
o when the values change in a TMMBR tuple currently in the selected list.
o 当前选定列表中的TMMBR元组中的值更改时。
At the media receiver, these cases correspond, respectively, to those of the non-owner and owner of a tuple in the TMMBN-reported bounding set.
在媒体接收器处，这些情况分别对应于TMMBN报告的边界集中元组的非所有者和所有者的情况。
In either case, the process of updating the selected list to take account of the new/changed tuple can use the basic algorithm described above, with the modification that the initial candidate set consists only of the existing selected list and the new or changed tuple. Some further optimization is possible (beyond starting with a reduced candidate set) by taking advantage of the following observations.
在任何一种情况下，更新所选列表以考虑新的/改变的元组的过程可以使用上述基本算法，并且修改为初始候选集仅包括现有的所选列表和新的或改变的元组。通过利用以下观察结果，可以进行进一步优化（除了从减少的候选集开始）。
The first observation is that if the new/changed candidate becomes part of the new selected list, the result may be to cause zero or more other tuples to be dropped from the list. However, if more than one other tuple is dropped, the dropped tuples will be consecutive. This can be confirmed geometrically by visualizing a new line that cuts off a series of segments from the previously existing bounding polygon. The cut-off segments are connected one to the next, the geometric equivalent of consecutive tuples in a list ordered by overhead value. Beyond the dropped set in either direction all of the tuples that were in the earlier selected list will be in the updated one. The second observation is that, leaving aside the new candidate, the order of tuples remaining in the updated selected list is unchanged because their overhead values have not changed.
第一个观察结果是，如果新的/更改的候选者成为新选择列表的一部分，结果可能会导致从列表中删除零个或多个其他元组。但是，如果删除了多个其他元组，则删除的元组将是连续的。这可以通过可视化一条新线从先前存在的边界多边形上切断一系列线段来从几何上确认。截断段一个接一个地连接，这是按开销值排序的列表中连续元组的几何等价物。在任一方向上除去的集合之外，先前选择的列表中的所有元组都将位于更新的元组中。第二个观察结果是，撇开新的候选元组不谈，更新后的选定列表中剩余元组的顺序保持不变，因为它们的开销值没有改变。
The consequence of these two observations is that, once the placement of the new candidate and the extent of the dropped set of tuples (if any) has been determined, the remaining tuples can be copied directly from the candidate list into the selected list, preserving their order. This conclusion suggests the following modified algorithm:
这两个观察的结果是，一旦确定了新候选元组的位置和丢弃的元组集（如果有的话）的范围，剩余的元组就可以直接从候选列表复制到所选列表中，保留它们的顺序。该结论提出了以下改进算法：
o Run steps 1-4 of the basic algorithm.
o 运行基本算法的步骤1-4。
o If the new candidate has survived steps 2 and 4 and has become the new first member of the selected list, run steps 5-9 on subsequent candidates until another candidate is added to the selected list. Then move all remaining candidates to the selected list, preserving their order.
o 如果新候选者在步骤2和4中幸存，并成为所选列表的第一个新成员，则对后续候选者运行步骤5-9，直到将另一个候选者添加到所选列表中。然后将所有剩余的候选对象移动到选定列表中，保留其顺序。
o If the new candidate has survived steps 2 and 4 and has not become the new first member of the selected list, start by moving all tuples in the candidate list with lower overhead values than that of the new candidate to the selected list, preserving their order. Run steps 5-9 for the new candidate,
o 如果新候选已通过步骤2和4，并且未成为选定列表的第一个新成员，则首先将候选列表中开销值低于新候选的所有元组移动到选定列表中，并保留它们的顺序。为新候选人运行步骤5-9，
with the modification that the intersection values and maximum packet rates for the tuples on the selected list have to be calculated on the fly because they were not previously stored. Continue processing only until a subsequent tuple has been added to the selected list, then move all remaining candidates to the selected list, preserving their order.
修改后，所选列表上元组的交集值和最大数据包速率必须动态计算，因为它们以前没有存储。仅在将后续元组添加到选定列表之前继续处理，然后将所有剩余的候选元组移动到选定列表，保留它们的顺序。
Note that the new candidate could be added to the selected list only to be dropped again when the next tuple is processed. It can easily be seen that in this case the new candidate does not displace any of the earlier tuples in the selected list. The limitations of ASCII art make this difficult to show in a figure. Line cc..c in Figure 1 would be an example if it had a steeper slope (tuple C had a higher overhead value), but still intersected line aa..a beyond where line aa..a intersects line bb..b.
请注意，新的候选对象可以添加到所选列表中，但在处理下一个元组时会再次删除。很容易看出，在这种情况下，新的候选元组不会替换所选列表中的任何早期元组。ASCII art的局限性使其难以在图中显示。图1中的线cc..c具有更陡的斜率（元组c具有更高的开销值），但仍然与线aa..a相交，超出线aa..a与线bb..b相交的位置。
The algorithm just described is approximate, because it does not take account of tuples outside the selected list. To see how such tuples can become relevant, consider Figure 1 and suppose that the maximum total media bit rate in tuple A increases to the point that line aa..a moves outside line cc..c. Tuple A will remain in the bounding set calculated by the media sender. However, once it issues a new TMMBN, media receiver C will apply the algorithm and discover that its tuple C should now enter the bounding set. It will issue a TMMBR to the media sender, which will repeat its calculation and come to the appropriate conclusion.
刚才描述的算法是近似的，因为它不考虑所选列表之外的元组。要查看这些元组如何变得相关，请考虑图1，假设元组A中的最大总媒体比特率增加到线AA的点。元组A将保留在媒体发送方计算的边界集中。然而，一旦发布新的TMMBN，媒体接收器C将应用该算法，并发现其元组C现在应该进入边界集。它将向媒体发送方发出TMMBR，该发送方将重复其计算并得出适当的结论。
The rules of section 4.2 require that the media sender refrain from raising its sending rate until media receivers have had a chance to respond to the TMMBN. In the example just given, this delay ensures that the relaxation of tuple A does not actually result in an attempt to send media at a rate exceeding the capacity at C.
第4.2节的规则要求媒体发送者在媒体接收者有机会响应TMMBN之前不要提高其发送速率。在刚刚给出的示例中，此延迟确保元组A的松弛实际上不会导致尝试以超过C的容量的速率发送媒体。
Assume a small mixer-based multiparty conference is ongoing, as depicted in Topo-Mixer of [RFC5117]. All participants have negotiated a common maximum bit rate that this session can use. The conference operates over a number of unicast paths between the participants and the mixer. The congestion situation on each of these paths can be monitored by the participant in question and by the mixer, utilizing, for example, RTCP receiver reports (RRs) or the transport protocol, e.g., Datagram Congestion Control Protocol (DCCP) [RFC4340]. However, any given participant has no knowledge of the congestion situation of the connections to the other participants. Worse, without mechanisms similar to the ones discussed in this document, the mixer (which is aware of the congestion situation on
假设正在进行基于小型混音器的多方会议，如[RFC5117]的Topo mixer中所述。所有参与者都协商了此会话可以使用的通用最大比特率。会议在参与者和混合器之间的许多单播路径上运行。这些路径中的每个路径上的拥塞情况可由相关参与者和混频器监控，例如利用RTCP接收器报告（RRs）或传输协议，例如数据报拥塞控制协议（DCCP）[RFC4340]。然而，任何给定的参与者都不知道与其他参与者的连接的拥塞情况。更糟糕的是，如果没有与本文档中讨论的机制类似的机制，混合器（它知道网络上的拥塞情况）
all connections it manages) has no standardized means to inform media senders to slow down, short of forging its own receiver reports (which is undesirable). In principle, a mixer confronted with such a situation is obliged to thin or transcode streams intended for connections that detected congestion.
它管理的所有连接）都没有标准化的方法来通知媒体发送者放慢速度，除非伪造自己的接收者报告（这是不可取的）。原则上，遇到这种情况的混频器必须对用于检测到拥塞的连接的流进行精简或转码。
In practice, unfortunately, media-aware streaming thinning is a very difficult and cumbersome operation and adds undesirable delay. If media-unaware, it leads very quickly to unacceptable reproduced media quality. Hence, a means to slow down senders even in the absence of congestion on their connections to the mixer is desirable.
不幸的是，在实践中，媒体感知流细化是一个非常困难和繁琐的操作，并增加了不希望的延迟。如果媒体不知道，很快就会导致无法接受的复制媒体质量。因此，即使发送器与混频器的连接没有拥塞，也需要一种降低发送器速度的方法。
To allow the mixer to throttle traffic on the individual links, without performing transcoding, there is a need for a mechanism that enables the mixer to ask a participant's media encoders to limit the media stream bit rate they are currently generating. TMMBR provides the required mechanism. When the mixer detects congestion between itself and a given participant, it executes the following procedure:
为了允许混频器在不执行转码的情况下限制各个链路上的流量，需要一种机制，使得混频器能够请求参与者的媒体编码器限制他们当前生成的媒体流比特率。TMMBR提供了所需的机制。当混音器检测到自身和给定参与者之间的拥塞时，它将执行以下过程：
1. It starts thinning the media traffic to the congested participant to the supported bit rate.
1. 它开始将拥挤参与者的媒体流量稀释到支持的比特率。
2. It uses TMMBR to request the media sender(s) to reduce the total media bit rate sent by them to the mixer, to a value that is in compliance with congestion control principles for the slowest link. Slow refers here to the available bandwidth / bit rate / capacity and packet rate after congestion control.
2. 它使用TMMBR请求媒体发送器将其发送到混音器的总媒体比特率降低到符合最慢链路拥塞控制原则的值。这里的Slow是指拥塞控制后的可用带宽/比特率/容量和分组速率。
3. As soon as the bit rate has been reduced by the sending part, the mixer stops stream thinning implicitly, because there is no need for it once the stream is in compliance with congestion control.
3. 一旦发送部分降低了比特率，混频器就隐式地停止流细化，因为一旦流符合拥塞控制，就不需要流细化。
This use of stream thinning as an immediate reaction tool followed up by a quick control mechanism appears to be a reasonable compromise between media quality and the need to combat congestion.
将流细化作为一种即时反应工具，然后采用一种快速控制机制，这似乎是媒体质量和应对拥塞需求之间的合理折衷。
3.5.4.4. Use of TMMBR in Point-to-Multipoint Using Multicast or Translators
3.5.4.4. 使用多播或转换器在点对多点中使用TMMBR
In these topologies, corresponding to Topo-Multicast or Topo-Translator, RTCP RRs are transmitted globally. This allows all participants to detect transmission problems such as congestion, on a medium timescale. As all media senders are aware of the congestion situation of all media receivers, the rationale for the use of TMMBR in the previous section does not apply. However, even in this case the congestion control response can be improved when the unicast
在这些拓扑中，对应于拓扑多播或拓扑转换器，RTCP RRs是全局传输的。这允许所有参与者在中等时间尺度上检测传输问题，如拥塞。由于所有媒体发送者都知道所有媒体接收器的拥塞情况，因此前一节中使用TMMBR的基本原理不适用。然而，即使在这种情况下，当单播
links are using congestion controlled transport protocols (such as TCP or DCCP). A peer may also report local limitations to the media sender.
链路使用拥塞控制传输协议（如TCP或DCCP）。对等方也可以向媒体发送方报告本地限制。
In use case 7, it is possible to use TMMBR to improve the performance when the known upper limit of the bit rate changes. In this use case, the signaling protocol has established an upper limit for the session and total media bit rates. However, at the time of transport link bit rate reduction, a receiver can avoid serious congestion by sending a TMMBR to the sending side. Thus, TMMBR is useful for putting restrictions on the application and thus placing the congestion control mechanism in the right ballpark. However, TMMBR is usually unable to provide the continuously quick feedback loop required for real congestion control. Nor do its semantics match those of congestion control given its different purpose. For these reasons, TMMBR SHALL NOT be used as a substitute for congestion control.
在用例7中，当已知的比特率上限改变时，可以使用TMMBR来提高性能。在这个用例中，信令协议已经为会话和总媒体比特率建立了上限。然而，在传输链路比特率降低时，接收机可以通过向发送侧发送TMMBR来避免严重的拥塞。因此，TMMBR有助于对应用程序施加限制，从而使拥塞控制机制处于正确的位置。然而，TMMBR通常无法提供实际拥塞控制所需的连续快速反馈回路。考虑到拥塞控制的不同目的，它的语义也不匹配。由于这些原因，TMMBR不得用作拥塞控制的替代品。
The reaction of a media sender to the reception of a TMMBR message is not immediately identifiable through inspection of the media stream. Therefore, a more explicit mechanism is needed to avoid unnecessary re-sending of TMMBR messages. Using a statistically based retransmission scheme would only provide statistical guarantees of the request being received. It would also not avoid the retransmission of already received messages. In addition, it would not allow for easy suppression of other participants' requests. For these reasons, a mechanism based on explicit notification is used.
通过检查媒体流，无法立即识别媒体发送者对接收TMMBR消息的反应。因此，需要更明确的机制来避免不必要的TMMBR消息重新发送。使用基于统计的重传方案只能提供接收请求的统计保证。它也无法避免已接收消息的重新传输。此外，它不允许轻易压制其他参与者的请求。出于这些原因，使用了基于显式通知的机制。
Upon the reception of a TMMBR, a media sender sends a TMMBN containing the current bounding set, and indicating which session participants own that limit. In multicast scenarios, that allows all other participants to suppress any request they may have, if their limitations are less strict than the current ones (i.e., define lines lying outside the feasible region as defined in section 2.2). Keeping and notifying only the bounding set of tuples allows for small message sizes and media sender states. A media sender only keeps state for the SSRCs of the current owners of the bounding set of tuples; all other requests and their sources are not saved. Once the bounding set has been established, new TMMBR messages should be generated only by owners of the bounding tuples and by other entities that determine (by applying the algorithm of section 3.5.4.2 or its equivalent) that their limitations should now be part of the bounding set.
在接收到TMMBR后，媒体发送方发送包含当前边界集的TMMBN，并指示哪些会话参与者拥有该限制。在多播场景中，允许所有其他参与者抑制他们可能有的任何请求，如果他们的限制没有当前限制严格（即，定义位于第2.2节中定义的可行区域之外的行）。仅保留和通知元组的边界集允许较小的消息大小和媒体发送者状态。媒体发送方仅保留当前元组边界集所有者的SSRC的状态；不会保存所有其他请求及其源。一旦建立了边界集，新的TMMBR消息应仅由边界元组的所有者和其他实体生成（通过应用第3.5.4.2节或其等效算法）确定其限制现在应成为边界集的一部分。
This memo specifies six new feedback messages. The Full Intra Request (FIR), Temporal-Spatial Trade-off Request (TSTR), Temporal-Spatial Trade-off Notification (TSTN), and Video Back Channel Message (VBCM) are "Payload Specific Feedback Messages" as defined in section 6.3 of AVPF [RFC4585]. The Temporary Maximum Media Stream Bit Rate Request (TMMBR) and Temporary Maximum Media Stream Bit Rate Notification (TMMBN) are "Transport Layer Feedback Messages" as defined in section 6.2 of AVPF.
此备忘录指定了六条新的反馈消息。完整的帧内请求（FIR）、时空权衡请求（TSTR）、时空权衡通知（TSTN）和视频反向通道消息（VBCM）是AVPF[RFC4585]第6.3节中定义的“有效负载特定反馈消息”。临时最大媒体流比特率请求（TMMBR）和临时最大媒体流比特率通知（TMMBN）是AVPF第6.2节中定义的“传输层反馈消息”。
The new feedback messages are defined in the following subsections, following a similar structure to that in sections 6.2 and 6.3 of the AVPF specification [RFC4585].
新的反馈信息在以下小节中定义，其结构与AVPF规范[RFC4585]第6.2节和第6.3节中的结构类似。
RTCP was originally introduced as a channel to convey presence, reception quality statistics and hints on the desired media coding. A limited set of media control mechanisms was introduced in early RTP payload formats for video formats, for example, in RFC 2032 [RFC2032] (which was obsoleted by RFC 4587 [RFC4587]). However, this specification, for the first time, suggests a two-way handshake for some of its messages. There is danger that this introduction could be misunderstood as a precedent for the use of RTCP as an RTP session control protocol. To prevent such a misunderstanding, this subsection attempts to clarify the scope of the extensions specified in this memo, and it strongly suggests that future extensions follow the rationale spelled out here, or compellingly explain why they divert from the rationale.
RTCP最初是作为一种信道引入的，用于传输状态、接收质量统计信息和所需媒体编码提示。早期RTP有效负载格式中引入了一组有限的媒体控制机制，用于视频格式，例如RFC 2032[RFC2032]（已被RFC 4587[RFC4587]淘汰）。然而，该规范首次建议对某些消息进行双向握手。这一介绍有可能被误解为将RTCP用作RTP会话控制协议的先例。为避免此类误解，本小节试图澄清本备忘录中规定的延期范围，并强烈建议未来的延期遵循此处所述的理由，或强制解释其偏离理由的原因。
In this memo, and in AVPF [RFC4585], only such messages have been included as:
在本备忘录和AVPF[RFC4585]中，仅包含以下信息：
a) have comparatively strict real-time constraints, which prevent the use of mechanisms such as a SIP re-invite in most application scenarios (the real-time constraints are explained separately for each message where necessary);
a) 具有相对严格的实时约束，这会阻止在大多数应用场景中使用SIP重新邀请等机制（必要时会针对每条消息单独解释实时约束）；
b) are multicast-safe in that the reaction to potentially contradicting feedback messages is specified, as necessary for each message; and
b) 多播是安全的，因为根据每个消息的需要，指定了对可能相互矛盾的反馈消息的反应；和
c) are directly related to activities of a certain media codec, class of media codecs (e.g., video codecs), or a given RTP packet stream.
c) 与特定媒体编解码器、媒体编解码器类别（例如，视频编解码器）或给定RTP数据包流的活动直接相关。
In this memo, a two-way handshake is introduced only for messages for which:
在本备忘录中，双向握手仅适用于以下信息：
a) a notification or acknowledgement is required due to their nature. An analysis to determine whether this requirement exists has been performed separately for each message.
a) 由于其性质，需要通知或确认。已对每条消息分别进行分析，以确定该需求是否存在。
b) the notification or acknowledgement cannot be easily derived from the media bit stream.
b) 通知或确认不能轻易地从媒体比特流中导出。
All messages in AVPF [RFC4585] and in this memo present their contents in a simple, fixed binary format. This accommodates media receivers that have not implemented higher control protocol functionalities (SDP, XML parsers, and such) in their media path.
AVPF[RFC4585]和本备忘录中的所有消息均以简单、固定的二进制格式显示其内容。这适用于在其媒体路径中未实现更高控制协议功能（SDP、XML解析器等）的媒体接收器。
Messages that do not conform to the design principles just described are not an appropriate use of RTCP or of the Codec Control Framework defined in this document.
不符合上述设计原则的消息不适用于RTCP或本文档中定义的编解码器控制框架。
As specified in section 6.1 of RFC 4585 [RFC4585], transport layer feedback messages are identified by the RTCP packet type value RTPFB (205).
如RFC 4585[RFC4585]第6.1节所述，传输层反馈消息由RTCP数据包类型值RTPFB（205）标识。
In AVPF, one message of this category had been defined. This memo specifies two more such messages. They are identified by means of the feedback message type (FMT) parameter as follows:
在AVPF中，定义了一条此类信息。此备忘录指定了另外两条此类消息。它们通过反馈消息类型（FMT）参数识别，如下所示：
Assigned in AVPF [RFC4585]:
在AVPF[RFC4585]中分配：
1: Generic NACK 31: reserved for future expansion of the identifier number space
1：通用NACK 31：保留用于标识符编号空间的未来扩展
Assigned in this memo:
在本备忘录中分配：
2: reserved (see note below) 3: Temporary Maximum Media Stream Bit Rate Request (TMMBR) 4: Temporary Maximum Media Stream Bit Rate Notification (TMMBN)
2：保留（参见下面的注释）3：临时最大媒体流比特率请求（TMMBR）4：临时最大媒体流比特率通知（TMMBN）
Note: early versions of AVPF [RFC4585] reserved FMT=2 for a code point that has later been removed. It has been pointed out that there may be implementations in the field using this value in accordance with the expired document. As there is sufficient numbering space available, we mark FMT=2 as reserved so to avoid possible interoperability problems with any such early implementations.
注：AVPF[RFC4585]的早期版本为后来删除的代码点保留FMT=2。已经指出，根据过期的文档，现场可能会有使用此值的实现。由于有足够的可用编号空间，我们将FMT=2标记为保留，以避免任何此类早期实现可能出现的互操作性问题。
Available for assignment:
可供分配：
0: unassigned 5-30: unassigned
0:未分配5-30:未分配
The following subsection defines the formats of the Feedback Control Information (FCI) entries for the TMMBR and TMMBN messages, respectively, and specifies the associated behaviour at the media sender and receiver.
以下小节分别定义了TMMBR和TMMBN消息的反馈控制信息（FCI）条目的格式，并指定了媒体发送方和接收方的相关行为。
The Temporary Maximum Media Stream Bit Rate Request is identified by RTCP packet type value PT=RTPFB and FMT=3.
临时最大媒体流比特率请求由RTCP数据包类型值PT=RTPFB和FMT=3标识。
The FCI field of a Temporary Maximum Media Stream Bit Rate Request (TMMBR) message SHALL contain one or more FCI entries.
临时最大媒体流比特率请求（TMMBR）消息的FCI字段应包含一个或多个FCI条目。
The Feedback Control Information (FCI) consists of one or more TMMBR FCI entries with the following syntax:
反馈控制信息（FCI）由一个或多个TMMBR 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Syntax of an FCI Entry in the TMMBR Message
图2-TMMBR消息中FCI条目的语法
SSRC (32 bits): The SSRC value of the media sender that is requested to obey the new maximum bit rate.
SSRC（32位）：被请求遵守新的最大比特率的媒体发送器的SSRC值。
MxTBR Exp (6 bits): The exponential scaling of the mantissa for the maximum total media bit rate value. The value is an unsigned integer [0..63].
MxTBR Exp（6位）：最大媒体总比特率值尾数的指数缩放。该值是一个无符号整数[0..63]。
MxTBR Mantissa (17 bits): The mantissa of the maximum total media bit rate value as an unsigned integer.
MxTBR尾数（17位）：作为无符号整数的最大媒体总比特率值的尾数。
Measured Overhead (9 bits): The measured average packet overhead value in bytes. The measurement SHALL be done according to the description in section 4.2.1.2. The value is an unsigned integer [0..511].
测量的开销（9位）：以字节为单位的测量的平均数据包开销值。应根据第4.2.1.2节中的说明进行测量。该值是一个无符号整数[0..511]。
The maximum total media bit rate (MxTBR) value in bits per second is calculated from the MxTBR exponent (exp) and mantissa in the following way:
最大总媒体比特率（MxTBR）值（以比特/秒为单位）通过MxTBR指数（exp）和尾数按以下方式计算：
MxTBR = mantissa * 2^exp
MxTBR = mantissa * 2^exp
This allows for 17 bits of resolution in the range 0 to 131072*2^63 (approximately 1.2*10^24).
这允许在0到131072*2^63（约1.2*10^24）范围内实现17位分辨率。
The length of the TMMBR feedback message SHALL be set to 2+2*N where N is the number of TMMBR FCI entries.
TMMBR反馈信息的长度应设置为2+2*N，其中N是TMMBR FCI条目的数量。
Behaviour at the Media Receiver (Sender of the TMMBR)
媒体接收器（TMMBR的发送器）的行为
TMMBR is used to indicate a transport-related limitation at the reporting entity acting as a media receiver. TMMBR has the form of a tuple containing two components. The first value is the highest bit rate per sender of a media stream, available at a receiver-chosen protocol layer, which the receiver currently supports in this RTP session. The second value is the measured header overhead in bytes as defined in section 2.2 and measured at the chosen protocol layer in the packets received for the stream. The measurement of the overhead is a running average that is updated for each packet received for this particular media source (SSRC), using the following formula:
TMMBR用于指示作为媒体接收器的报告实体的传输相关限制。TMMBR的形式是包含两个组件的元组。第一个值是媒体流的每个发送方的最高比特率，在接收方选择的协议层可用，接收方当前在此RTP会话中支持该协议层。第二个值是第2.2节中定义的、在为流接收的数据包中所选协议层测量的以字节为单位的测量头开销。开销的测量是一个运行平均值，使用以下公式为该特定媒体源（SSRC）接收的每个数据包更新该平均值：
avg_OH (new) = 15/16*avg_OH (old) + 1/16*pckt_OH,
平均值OH（新）=15/16*平均值OH（旧）+1/16*pckt_OH，
where avg_OH is the running (exponentially smoothed) average and pckt_OH is the overhead observed in the latest packet.
其中avg_OH是运行（指数平滑）平均值，pckt_OH是在最新数据包中观察到的开销。
If a maximum bit rate has been negotiated through signaling, the maximum total media bit rate that the receiver reports in a TMMBR message MUST NOT exceed the negotiated value converted to a common basis (i.e., with overheads adjusted to bring it to the same reference protocol layer).
如果已通过信令协商最大比特率，则接收机在TMMBR消息中报告的最大媒体总比特率不得超过转换为公共基础的协商值（即，调整开销以使其达到相同的参考协议层）。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to 0. Within a particular TMMBR FCI entry, the "SSRC of media source" in the FCI field denotes the media sender that the tuple applies to. This is useful in the multicast or translator topologies where the reporting entity may address all of the media senders in a single TMMBR message using multiple FCI entries.
在反馈消息的公共分组报头（如[RFC4585]第6.1节所定义）中，“分组发送方的SSRC”字段表示请求的来源，“媒体源的SSRC”未使用，应设置为0。在特定TMMBR FCI条目中，FCI字段中的“媒体源的SSRC”表示元组应用于的媒体发送方。这在多播或转换器拓扑中非常有用，其中报告实体可以使用多个FCI条目在单个TMMBR消息中寻址所有媒体发送者。
The media receiver SHALL save the contents of the latest TMMBN message received from each media sender.
媒体接收方应保存从每个媒体发送方收到的最新TMMBN消息的内容。
The media receiver MAY send a TMMBR FCI entry to a particular media sender under the following circumstances:
在以下情况下，媒体接收器可向特定媒体发送者发送TMMBR FCI条目：
o before any TMMBN message has been received from that media sender;
o 在从该媒体发送方收到任何TMMBN消息之前；
o when the media receiver has been identified as the source of a bounding tuple within the latest TMMBN message received from that media sender, and the value of the maximum total media bit rate or the overhead relating to that media sender has changed;
o 当媒体接收器被识别为从该媒体发送者接收的最新TMMBN消息内的边界元组的源，并且与该媒体发送者相关的最大总媒体比特率或开销的值已经改变时；
o when the media receiver has not been identified as the source of a bounding tuple within the latest TMMBN message received from that media sender, and, after the media receiver applies the incremental algorithm from section 3.5.4.2 or a stricter equivalent, the media receiver's tuple relating to that media sender is determined to belong to the bounding set.
o 当媒体接收器未被识别为从该媒体发送方接收的最新TMMBN消息中的边界元组的源，并且在媒体接收器应用第3.5.4.2节中的增量算法或更严格的等效算法后，与该媒体发送方相关的媒体接收方元组被确定为属于该边界集。
A TMMBR FCI entry MAY be repeated in subsequent TMMBR messages if no Temporary Maximum Media Stream Bit Rate Notification (TMMBN) FCI has been received from the media sender at the time of transmission of the next RTCP packet. The bit rate value of a TMMBR FCI entry MAY be changed from one TMMBR message to the next. The overhead measurement SHALL be updated to the current value of avg_OH each time the entry is sent.
如果在传输下一个RTCP数据包时没有从媒体发送方接收到临时最大媒体流比特率通知（TMMBN）FCI，则TMMBR FCI条目可在后续TMMBR消息中重复。TMMBR FCI条目的比特率值可以从一条TMMBR消息更改为下一条。每次发送条目时，应将开销测量值更新为avg_OH的当前值。
If the value set by a TMMBR message is expected to be permanent, the TMMBR setting party SHOULD renegotiate the session parameters to reflect that using session setup signaling, e.g., a SIP re-invite.
如果TMMBR消息设置的值预期为永久值，则TMMBR设置方应使用会话设置信令（例如SIP重新邀请）重新协商会话参数，以反映会话参数。
Behaviour at the Media Sender (Receiver of the TMMBR)
媒体发送方（TMMBR的接收方）的行为
When it receives a TMMBR message containing an FCI entry relating to it, the media sender SHALL use an initial or incremental algorithm as applicable to determine the bounding set of tuples based on the new information. The algorithm used SHALL be at least as strict as the corresponding algorithm defined in section 3.5.4.2. The media sender MAY accumulate TMMBRs over a small interval (relative to the RTCP sending interval) before making this calculation.
当收到包含与其相关的FCI条目的TMMBR消息时，媒体发送方应使用初始或增量算法（如适用）根据新信息确定元组的边界集。使用的算法应至少与第3.5.4.2节中定义的相应算法一样严格。在进行此计算之前，媒体发送器可能会在一个小的间隔（相对于RTCP发送间隔）内累积TMMBR。
Once it has determined the bounding set of tuples, the media sender MAY use any combination of packet rate and net media bit rate within the feasible region that these tuples describe to produce a lower
一旦确定了元组的边界集，媒体发送器就可以在这些元组描述的可行区域内使用分组速率和净媒体比特率的任意组合来产生较低的比特率
total media stream bit rate, as it may need to address a congestion situation or other limiting factors. See section 5 (congestion control) for more discussion.
总媒体流比特率，因为它可能需要解决拥塞情况或其他限制因素。更多讨论请参见第5节（拥塞控制）。
If the media sender concludes that it can increase the maximum total media bit rate value, it SHALL wait before actually doing so, for a period long enough to allow a media receiver to respond to the TMMBN if it determines that its tuple belongs in the bounding set. This delay period is estimated by the formula:
如果媒体发送方认为其可以增加最大总媒体比特率值，则其应在实际这样做之前等待足够长的时间，以允许媒体接收器在其确定其元组属于边界集中时响应TMMBN。该延迟期通过以下公式估算：
2 * RTT + T_Dither_Max,
2*RTT+T_抖动最大值，
where RTT is the longest round trip time known to the media sender and T_Dither_Max is defined in section 3.4 of [RFC4585]. Even in point-to-point sessions, a media sender MUST obey the aforementioned rule, as it is not guaranteed that a participant is able to determine correctly whether all the sources are co-located in a single node, and are coordinated.
其中RTT是媒体发送方已知的最长往返时间，T_抖动_Max在[RFC4585]的第3.4节中定义。即使在点对点会话中，媒体发送者也必须遵守上述规则，因为不能保证参与者能够正确地确定所有源是否位于同一个节点中，并且是否协调。
A TMMBN message SHALL be sent by the media sender at the earliest possible point in time, in response to any TMMBR messages received since the last sending of TMMBN. The TMMBN message indicates the calculated set of bounding tuples and the owners of those tuples at the time of the transmission of the message.
媒体发送方应在尽可能早的时间点发送TMMBN消息，以响应自上次发送TMMBN以来收到的任何TMMBR消息。TMMBN消息指示在传输消息时计算出的一组边界元组和这些元组的所有者。
An SSRC may time out according to the default rules for RTP session participants, i.e., the media sender has not received any RTP or RTCP packets from the owner for the last five regular reporting intervals. An SSRC may also explicitly leave the session, with the participant indicating this through the transmission of an RTCP BYE packet or using an external signaling channel. If the media sender determines that the owner of a tuple in the bounding set has left the session, the media sender SHALL transmit a new TMMBN containing the previously determined set of bounding tuples but with the tuple belonging to the departed owner removed.
SSRC可能根据RTP会话参与者的默认规则超时，即，媒体发送方在过去五个定期报告间隔内未收到来自所有者的任何RTP或RTCP数据包。SSRC也可以明确地离开会话，参与者通过传输RTCP BYE分组或使用外部信令信道来指示这一点。如果媒体发送方确定边界集中元组的所有者已离开会话，则媒体发送方应发送一个新的TMMBN，该TMMBN包含先前确定的边界元组集，但属于已离开所有者的元组已被删除。
A media sender MAY proactively initiate the equivalent to a TMMBR message to itself, when it is aware that its transmission path is more restrictive than the current limitations. As a result, a TMMBN indicating the media source itself as the owner of a tuple is being sent, thereby avoiding unnecessary TMMBR messages from other participants. However, like any other participant, when the media sender becomes aware of changed limitations, it is required to change the tuple, and to send a corresponding TMMBN.
当媒体发送方意识到其传输路径比当前限制更严格时，可以主动向其自身发起相当于TMMBR消息的消息。因此，将发送指示媒体源本身为元组所有者的TMMBN，从而避免来自其他参与者的不必要TMMBR消息。然而，与任何其他参与者一样，当媒体发送者意识到更改的限制时，需要更改元组，并发送相应的TMMBN。
Discussion
讨论
Due to the unreliable nature of transport of TMMBR and TMMBN, the above rules may lead to the sending of TMMBR messages that appear to disobey those rules. Furthermore, in multicast scenarios it can happen that more than one "non-owning" session participant may determine, rightly or wrongly, that its tuple belongs in the bounding set. This is not critical for a number of reasons:
由于TMMBR和TMMBN传输的不可靠性，上述规则可能会导致发送看起来不符合这些规则的TMMBR消息。此外，在多播场景中，多个“非拥有”会话参与者可能会正确或错误地确定其元组属于边界集。这并不重要，原因有很多：
a) If a TMMBR message is lost in transmission, either the media sender sends a new TMMBN message in response to some other media receiver or it does not send a new TMMBN message at all. In the first case, the media receiver applies the incremental algorithm and, if it determines that its tuple should be part of the bounding set, sends out another TMMBR. In the second case, it repeats the sending of a TMMBR unconditionally. Either way, the media sender eventually gets the information it needs.
a) 如果TMMBR消息在传输过程中丢失，则媒体发送方发送新的TMMBN消息以响应其他媒体接收器，或者根本不发送新的TMMBN消息。在第一种情况下，媒体接收器应用增量算法，如果它确定其元组应该是边界集的一部分，则发送另一个TMMBR。在第二种情况下，它无条件地重复发送TMMBR。无论哪种方式，媒体发送者最终都会获得所需的信息。
b) Similarly, if a TMMBN message gets lost, the media receiver that has sent the corresponding TMMBR does not receive the notification and is expected to re-send the request and trigger the transmission of another TMMBN.
b) 类似地，如果TMMBN消息丢失，则已发送相应TMMBR的媒体接收器不会收到通知，并且预期将重新发送请求并触发另一个TMMBN的传输。
c) If multiple competing TMMBR messages are sent by different session participants, then the algorithm can be applied taking all of these messages into account, and the resulting TMMBN provides the participants with an updated view of how their tuples compare with the bounded set.
c) 如果多个相互竞争的TMMBR消息由不同的会话参与者发送，则可以应用该算法，同时考虑所有这些消息，并且生成的TMMBN为参与者提供了一个更新的视图，说明他们的元组与有界集的比较情况。
d) If more than one session participant happens to send TMMBR messages at the same time and with the same tuple component values, it does not matter which of those tuples is taken into the bounding set. The losing session participant will determine, after applying the algorithm, that its tuple does not enter the bounding set, and will therefore stop sending its TMMBR.
d) 如果多个会话参与者碰巧同时发送具有相同元组组件值的TMMBR消息，则将这些元组中的哪一个放入边界集中并不重要。失败的会话参与者将在应用算法后确定其元组未进入边界集，因此将停止发送其TMMBR。
It is important to consider the security risks involved with faked TMMBRs. See the security considerations in section 6.
考虑伪造的TMBRs涉及的安全风险是很重要的。参见第6节中的安全注意事项。
As indicated already, the feedback messages may be used in both multicast and unicast sessions in any of the specified topologies. However, for sessions with a large number of participants, using the lowest common denominator, as required by this mechanism, may not be the most suitable course of action. Large sessions may need to consider other ways to adapt the bit rate to participants' capabilities, such as partitioning the session into different quality tiers or using some other method of achieving bit rate scalability.
如已经指出的，反馈消息可以在任何指定拓扑中的多播和单播会话中使用。然而，对于参与者众多的会议，按照这一机制的要求，使用最低公分母可能不是最合适的行动方针。大型会话可能需要考虑其他方式来将比特率适配到参与者的能力，例如将会话划分成不同的质量等级或使用其他实现比特率可伸缩性的方法。
The first transmission of the TMMBR message MAY use early or immediate feedback in cases when timeliness is desirable. Any repetition of a request message SHOULD use regular RTCP mode for its transmission timing.
在需要及时性的情况下，TMMBR消息的第一次传输可以使用早期或即时反馈。请求消息的任何重复都应使用常规RTCP模式进行传输定时。
Media translators and mixers will need to receive and respond to TMMBR messages as they are part of the chain that provides a certain media stream to the receiver. The mixer or translator may act locally on the TMMBR and thus generate a TMMBN to indicate that it has done so. Alternatively, in the case of a media translator it can forward the request, or in the case of a mixer generate one of its own and pass it forward. In the latter case, the mixer will need to send a TMMBN back to the original requestor to indicate that it is handling the request.
媒体翻译器和混音器需要接收和响应TMMBR消息，因为它们是向接收器提供特定媒体流的链的一部分。混频器或转换器可在TMMBR上本地操作，从而生成TMMBN以指示其已这样做。或者，在媒体转换器的情况下，它可以转发请求，或者在混合器的情况下，生成自己的请求并将其转发。在后一种情况下，混频器将需要将TMMBN发送回原始请求者，以指示它正在处理请求。
The Temporary Maximum Media Stream Bit Rate Notification is identified by RTCP packet type value PT=RTPFB and FMT=4.
临时最大媒体流比特率通知由RTCP数据包类型值PT=RTPFB和FMT=4标识。
The FCI field of the TMMBN feedback message may contain zero, one, or more TMMBN FCI entries.
TMMBN反馈消息的FCI字段可能包含零个、一个或多个TMMBN FCI条目。
The Feedback Control Information (FCI) consists of zero, one, or more TMMBN FCI entries with the following syntax:
反馈控制信息（FCI）由零个、一个或多个TMMBN 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Syntax of an FCI Entry in the TMMBN Message
图3-TMMBN消息中FCI条目的语法
SSRC (32 bits): The SSRC value of the "owner" of this tuple.
SSRC（32位）：此元组的“所有者”的SSRC值。
MxTBR Exp (6 bits): The exponential scaling of the mantissa for the maximum total media bit rate value. The value is an unsigned integer [0..63].
MxTBR Exp（6位）：最大媒体总比特率值尾数的指数缩放。该值是一个无符号整数[0..63]。
MxTBR Mantissa (17 bits): The mantissa of the maximum total media bit rate value as an unsigned integer.
MxTBR尾数（17位）：作为无符号整数的最大媒体总比特率值的尾数。
Measured Overhead (9 bits): The measured average packet overhead value in bytes represented as an unsigned integer [0..511].
测量开销（9位）：以字节为单位的测量平均数据包开销值，表示为无符号整数[0..511]。
Thus, the FCI within the TMMBN message contains entries indicating the bounding tuples. For each tuple, the entry gives the owner by the SSRC, followed by the applicable maximum total media bit rate and overhead value.
因此，TMMBN消息中的FCI包含指示边界元组的条目。对于每个元组，条目由SSRC提供所有者，后跟适用的最大媒体总比特率和开销值。
The length of the TMMBN message SHALL be set to 2+2*N where N is the number of TMMBN FCI entries.
TMMBN消息的长度应设置为2+2*N，其中N是TMMBN FCI条目的数量。
This feedback message is used to notify the senders of any TMMBR message that one or more TMMBR messages have been received or that an owner has left the session. It indicates to all participants the current set of bounding tuples and the "owners" of those tuples.
此反馈消息用于通知任何TMMBR消息的发送者已收到一条或多条TMMBR消息或所有者已离开会话。它向所有参与者指示当前的一组边界元组以及这些元组的“所有者”。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the notification. The "SSRC of media source" is not used and SHALL be set to 0.
在反馈消息的公共数据包报头内（如[RFC4585]第6.1节所定义），“数据包发送方的SSRC”字段表示通知的来源。未使用“媒体源SSRC”，应设置为0。
A TMMBN message SHALL be scheduled for transmission after the reception of a TMMBR message with an FCI entry identifying this media sender. Only a single TMMBN SHALL be sent, even if more than one TMMBR message is received between the scheduling of the transmission and the actual transmission of the TMMBN message. The TMMBN message indicates the bounding tuples and their owners at the time of transmitting the message. The bounding tuples included SHALL be the set arrived at through application of the applicable algorithm of section 3.5.4.2 or an equivalent, applied to the previous bounding set, if any, and tuples received in TMMBR messages since the last TMMBN was transmitted.
TMMBN消息应在接收到TMMBR消息后安排传输，该消息带有识别该媒体发送者的FCI条目。即使在传输调度和TMMBN消息实际传输之间接收到多个TMMBR消息，也只能发送一个TMMBN。TMMBN消息表示传输消息时的边界元组及其所有者。包括的边界元组应是通过应用第3.5.4.2节的适用算法或适用于前一个边界集（如有）的等效算法得到的集合，以及自上次TMMBN传输以来TMMBR消息中接收的元组。
The reception of a TMMBR message SHALL still result in the transmission of a TMMBN message even if, after application of the algorithm, the newly reported TMMBR tuple is not accepted into the bounding set. In such a case, the bounding tuples and their owners are not changed, unless the TMMBR was from an owner of a tuple within the previously calculated bounding set. This procedure allows session participants that did not see the last TMMBN message to get a correct view of this media sender's state.
即使在应用算法后，新报告的TMMBR元组未被接受到边界集中，TMMBR消息的接收仍应导致TMMBN消息的传输。在这种情况下，边界元组及其所有者不会更改，除非TMMBR来自先前计算的边界集中元组的所有者。此过程允许未看到最后一条TMMBN消息的会话参与者正确查看此媒体发件人的状态。
As indicated in section 4.2.1.2, when a media sender determines that an "owner" of a bounding tuple has left the session, then that tuple is removed from the bounding set, and the media sender SHALL send a TMMBN message indicating the remaining bounding tuples. If there are no remaining bounding tuples, a TMMBN without any FCI SHALL be sent to indicate this. Without a remaining bounding tuple, the maximum media bit rate and maximum packet rate negotiated in session signaling, if any, apply.
如第4.2.1.2节所述，当媒体发送方确定边界元组的“所有者”已离开会话时，该元组将从边界集中移除，媒体发送方应发送一条TMMBN消息，指示剩余的边界元组。如果没有剩余的边界元组，则应发送不带任何FCI的TMMBN以表明这一点。如果没有剩余的边界元组，则应用会话信令中协商的最大媒体比特率和最大分组率（如果有）。
Note: if any media receivers remain in the session, this last will be a temporary situation. The empty TMMBN will cause every remaining media receiver to determine that its limitation belongs in the bounding set and send a TMMBR in consequence.
注意：如果任何媒体接收器仍在会话中，最后一个将是临时情况。空的TMMBN将使每个剩余的媒体接收器确定其限制属于边界集，并因此发送TMMBR。
In unicast scenarios (i.e., where a single sender talks to a single receiver), the aforementioned algorithm to determine ownership degenerates to the media receiver becoming the "owner" of the one bounding tuple as soon as the media receiver has issued the first TMMBR message.
在单播场景中（即，单个发送方与单个接收方对话），上述确定所有权的算法退化为媒体接收方在媒体接收方发出第一条TMMBR消息后立即成为一个边界元组的“所有者”。
The TMMBN acknowledgement SHOULD be sent as soon as allowed by the applied timing rules for the session. Immediate or early feedback mode SHOULD be used for these messages.
TMMBN确认应在应用的会话定时规则允许的情况下尽快发送。这些信息应使用即时或早期反馈模式。
As discussed in section 4.2.1.4, mixers or translators may need to issue TMMBN messages as responses to TMMBR messages for SSRCs handled by them.
如第4.2.1.4节所述，混音器或翻译器可能需要发出TMMBN消息，作为对其处理的SSRC的TMMBR消息的响应。
As specified by section 6.1 of RFC 4585 [RFC4585], Payload-Specific FB messages are identified by the RTCP packet type value PSFB (206).
按照RFC 4585[RFC4585]第6.1节的规定，特定于有效负载的FB消息由RTCP数据包类型值PSFB（206）标识。
AVPF [RFC4585] defines three payload-specific feedback messages and one application layer feedback message. This memo specifies four additional payload-specific feedback messages. All are identified by means of the FMT parameter as follows:
AVPF[RFC4585]定义了三条特定于有效负载的反馈消息和一条应用层反馈消息。此备忘录指定了四条额外的特定于有效负载的反馈消息。通过以下FMT参数识别所有组件：
Assigned in [RFC4585]:
在[RFC4585]中分配：
1: Picture Loss Indication (PLI) 2: Slice Lost Indication (SLI) 3: Reference Picture Selection Indication (RPSI) 15: Application layer FB message 31: reserved for future expansion of the number space
1：图片丢失指示（PLI）2：片丢失指示（SLI）3：参考图片选择指示（RPSI）15：应用层FB消息31：保留用于将来扩展数字空间
Assigned in this memo:
在本备忘录中分配：
4: Full Intra Request (FIR) Command 5: Temporal-Spatial Trade-off Request (TSTR) 6: Temporal-Spatial Trade-off Notification (TSTN) 7: Video Back Channel Message (VBCM)
4：完整帧内请求（FIR）命令5：时空权衡请求（TSTR）6：时空权衡通知（TSTN）7：视频反向通道消息（VBCM）
Unassigned:
未分配：
0: unassigned 8-14: unassigned 16-30: unassigned
0:未分配8-14:未分配16-30:未分配
The following subsections define the new FCI formats for the payload-specific feedback messages.
以下小节定义了有效负载特定反馈消息的新FCI格式。
The FIR message is identified by RTCP packet type value PT=PSFB and FMT=4.
FIR消息由RTCP数据包类型值PT=PSFB和FMT=4标识。
The FCI field MUST contain one or more FIR entries. Each entry applies to a different media sender, identified by its SSRC.
FCI字段必须包含一个或多个FIR条目。每个条目适用于不同的媒体发送者，由其SSRC标识。
The Feedback Control Information (FCI) for the Full Intra Request consists of one or more FCI entries, the content of which is depicted in Figure 4. The length of the FIR feedback message MUST be set to 2+2*N, where N is the number of FCI entries.
完整帧内请求的反馈控制信息（FCI）由一个或多个FCI条目组成，其内容如图4所示。FIR反馈消息的长度必须设置为2+2*N，其中N是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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - Syntax of an FCI Entry in the FIR Message
图4-FIR消息中FCI条目的语法
SSRC (32 bits): The SSRC value of the media sender that is requested to send a decoder refresh point.
SSRC（32位）：被请求发送解码器刷新点的媒体发送器的SSRC值。
Seq nr. (8 bits): Command sequence number. The sequence number space is unique for each pairing of the SSRC of command source and the SSRC of the command target. The sequence number SHALL be increased by 1 modulo 256 for each new command. A repetition SHALL NOT increase the sequence number. The initial value is arbitrary.
序号（8位）：命令序列号。对于命令源的SSRC和命令目标的SSRC的每个配对，序列号空间是唯一的。对于每个新命令，序列号应增加1模256。重复不得增加序列号。初始值是任意的。
Reserved (24 bits): All bits SHALL be set to 0 by the sender and SHALL be ignored on reception.
保留（24位）：发送方应将所有位设置为0，并在接收时忽略。
The semantics of this feedback message is independent of the RTP payload type.
此反馈消息的语义与RTP有效负载类型无关。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of the media senders to which the FIR command applies are in the corresponding FCI entries. A FIR message MAY contain requests to multiple media senders, using one FCI entry per target media sender.
在反馈消息的公共分组报头（如[RFC4585]第6.1节所定义）中，“分组发送方的SSRC”字段表示请求的来源，“媒体源的SSRC”未使用，应设置为0。FIR命令适用的媒体发送器的SSRC位于相应的FCI条目中。FIR消息可能包含对多个媒体发送者的请求，每个目标媒体发送者使用一个FCI条目。
Upon reception of FIR, the encoder MUST send a decoder refresh point (see section 2.2) as soon as possible.
收到FIR后，编码器必须尽快发送解码器刷新点（见第2.2节）。
The sender MUST consider congestion control as outlined in section 5, which MAY restrict its ability to send a decoder refresh point quickly.
发送者必须考虑如第5节所述的拥塞控制，这可能限制其快速发送解码器刷新点的能力。
FIR SHALL NOT be sent as a reaction to picture losses -- it is RECOMMENDED to use PLI [RFC4585] instead. FIR SHOULD be used only in situations where not sending a decoder refresh point would render the video unusable for the users.
FIR不应作为图像丢失的反应发送——建议改用PLI[RFC4585]。FIR应仅在不发送解码器刷新点会导致用户无法使用视频的情况下使用。
A typical example where sending FIR is appropriate is when, in a multipoint conference, a new user joins the session and no regular decoder refresh point interval is established. Another example would be a video switching MCU that changes streams. Here, normally, the MCU issues a FIR to the new sender so to force it to emit a decoder refresh point. The decoder refresh point normally includes a Freeze Picture Release (defined outside this specification), which re-starts the rendering process of the receivers. Both techniques mentioned are commonly used in MCU-based multipoint conferences.
发送FIR合适的典型示例是，在多点会议中，新用户加入会话，并且没有建立规则的解码器刷新点间隔。另一个例子是改变流的视频交换MCU。在这里，通常情况下，MCU向新发送方发出FIR，以迫使其发出解码器刷新点。解码器刷新点通常包括一个冻结图片释放（定义在本规范之外），它重新启动接收器的渲染过程。上述两种技术通常用于基于MCU的多点会议。
Other RTP payload specifications such as RFC 2032 [RFC2032] already define a feedback mechanism 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 of receiving and reacting to the feedback scheme defined in the respective RTP payload format, if this is required by that payload format.
其他RTP有效负载规范（如RFC 2032[RFC2032]）已经为某些编解码器定义了反馈机制。支持这两种方案的应用程序在发送反馈时必须使用本规范中定义的反馈机制。出于向后兼容性的原因，如果有效载荷格式需要，这样的应用程序还应该能够接收在各自的RTP有效载荷格式中定义的反馈方案并对其作出反应。
The timing follows the rules outlined in section 3 of [RFC4585]. FIR commands MAY be used with early or immediate feedback. The FIR feedback message MAY be repeated. If using immediate feedback mode, the repetition SHOULD wait at least one RTT before being sent. In early or regular RTCP mode, the repetition is sent in the next regular RTCP packet.
计时遵循[RFC4585]第3节中概述的规则。FIR命令可用于早期或即时反馈。FIR反馈消息可以重复。如果使用即时反馈模式，在发送之前，重复应至少等待一次RTT。在早期或常规RTCP模式下，重复在下一个常规RTCP数据包中发送。
A media translator or a mixer performing media encoding of the content for which the session participant has issued a FIR is responsible for acting upon it. A mixer acting upon a FIR SHOULD NOT forward the message unaltered; instead, it SHOULD issue a FIR itself.
对会话参与者已发出FIR的内容执行媒体编码的媒体翻译器或混音器负责对其进行操作。作用于FIR的混频器不应原封不动地转发消息；相反，它应该自己发布FIR。
Currently, video appears to be the only useful application for FIR, as it appears to be the only RTP payload widely deployed that relies heavily on media prediction across RTP packet boundaries. However, use of FIR could also reasonably be envisioned for other media types that share essential properties with compressed video, namely, cross-frame prediction (whatever a frame may be for that media type). One possible example may be the dynamic updates of MPEG-4 scene descriptions. It is suggested that payload formats for such media types refer to FIR and other message types defined in this specification and in AVPF [RFC4585], instead of creating similar mechanisms in the payload specifications. The payload specifications may have to explain how the payload-specific terminologies map to the video-centric terminology used herein.
目前，视频似乎是FIR唯一有用的应用，因为它似乎是唯一广泛部署的RTP有效负载，严重依赖跨RTP数据包边界的媒体预测。然而，FIR的使用也可以合理地设想用于与压缩视频共享基本属性的其他媒体类型，即跨帧预测（无论该媒体类型的帧是什么）。一个可能的例子是MPEG-4场景描述的动态更新。建议此类媒体类型的有效负载格式参考本规范和AVPF[RFC4585]中定义的FIR和其他消息类型，而不是在有效负载规范中创建类似机制。有效载荷规范可能必须解释有效载荷特定术语如何映射到本文使用的以视频为中心的术语。
In conjunction with video codecs, FIR messages typically trigger the sending of full intra or IDR pictures. Both are several times larger than 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 significant multiple 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
与视频编解码器结合使用时，FIR消息通常会触发发送完整的帧内或IDR图片。这两张照片都比预测的（inter）照片大好几倍。它们的大小与生成它们的时间无关。在大多数环境中，尤其是在使用带宽有限的链路时，帧内图片的使用意味着允许的延迟是典型帧持续时间的显著倍数。例如：如果发送帧速率为10 fps，并且帧内图片假定为图像的10倍大
inter picture, then a full second of latency has to be accepted. In such an environment, there is no need for a particularly short delay in sending the FIR message. Hence, waiting for the next possible time slot allowed by RTCP timing rules as per [RFC4585] should not have an overly negative impact on the system performance.
在图片之间，则必须接受整整一秒的延迟。在这样的环境中，发送FIR消息时不需要特别短的延迟。因此，根据[RFC4585]等待RTCP定时规则允许的下一个可能的时隙不应对系统性能产生过度负面影响。
Mandating a maximum delay for completing the sending of a decoder refresh point would be desirable from an application viewpoint, but is problematic from a congestion control point of view. "As soon as possible" as mentioned above appears to be a reasonable compromise.
从应用程序的角度来看，为完成解码器刷新点的发送指定最大延迟是可取的，但从拥塞控制的角度来看是有问题的。上述“尽快”似乎是一种合理的妥协。
In environments where the sender has no control over the codec (e.g., when streaming pre-recorded and pre-coded content), the reaction to this command cannot be specified. One suitable reaction of a sender would be to skip forward in the video bit stream to the next decoder refresh point. In other scenarios, it may be preferable not to react to the command at all, e.g., when streaming to a large multicast group. Other reactions may also be possible. When deciding on a strategy, a sender could take into account factors such as the size of the receiving group, the "importance" of the sender of the FIR message (however "importance" may be defined in this specific application), the frequency of decoder refresh points in the content, and so on. However, a session that predominantly handles pre-coded content is not expected to use FIR at all.
在发送方无法控制编解码器的环境中（例如，流式传输预录制和预编码的内容时），无法指定对此命令的反应。发送方的一个适当反应是在视频比特流中向前跳到下一个解码器刷新点。在其他场景中，例如，当流传输到大型多播组时，可能最好根本不对命令作出反应。其他反应也可能发生。在决定策略时，发送者可以考虑诸如接收组的大小、FIR消息的发送者的“重要性”（然而在该特定应用中可以定义“重要性”）、内容中解码器刷新点的频率等因素。但是，主要处理预编码内容的会话根本不需要使用FIR。
The relationship between the Picture Loss Indication and FIR is as follows. As discussed in section 6.3.1 of AVPF [RFC4585], a Picture Loss Indication informs the decoder about the loss of a picture and hence the likelihood of misalignment of the reference pictures between the encoder and decoder. Such a scenario is normally related to losses in an ongoing connection. In point-to-point scenarios, and without the presence of advanced error resilience tools, one possible option for an encoder consists in sending a decoder refresh point. However, there are other options. One example is that the media sender ignores the PLI, because the embedded stream redundancy is likely to clean up the reproduced picture within a reasonable amount of time. The FIR, in contrast, leaves a (real-time) encoder no choice but to send a decoder refresh point. It does not allow the encoder to take into account any considerations such as the ones mentioned above.
图像丢失指示和FIR之间的关系如下所示。如AVPF[RFC4585]第6.3.1节所述，图片丢失指示通知解码器图片丢失，从而告知编码器和解码器之间参考图片未对准的可能性。这种情况通常与正在进行的连接中的损失有关。在点对点场景中，如果没有高级错误恢复工具，编码器的一个可能选项是发送解码器刷新点。但是，还有其他选择。一个例子是，媒体发送器忽略PLI，因为嵌入的流冗余可能在合理的时间量内清除再现的图片。相反，FIR使（实时）编码器别无选择，只能发送解码器刷新点。它不允许编码器考虑上述任何考虑因素。
The TSTR feedback message is identified by RTCP packet type value PT=PSFB and FMT=5.
TSTR反馈信息由RTCP数据包类型值PT=PSFB和FMT=5标识。
The FCI field MUST contain one or more TSTR FCI entries.
FCI字段必须包含一个或多个TSTR FCI条目。
The content of the FCI entry for the Temporal-Spatial Trade-off Request is depicted in Figure 5. The length of the feedback message MUST be set to 2+2*N, where N is the number of FCI entries included.
时空权衡请求的FCI条目的内容如图5所示。反馈信息的长度必须设置为2+2*N，其中N是包含的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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - Syntax of an FCI Entry in the TSTR Message
图5-TSTR消息中FCI条目的语法
SSRC (32 bits): The SSRC of the media sender that is requested to apply the trade-off value given in Index.
SSRC（32位）：被请求应用索引中给出的折衷值的媒体发送器的SSRC。
Seq nr. (8 bits): Request sequence number. The sequence number space is unique for pairing of the SSRC of request source and the SSRC of the request target. The sequence number SHALL be increased by 1 modulo 256 for each new command. A repetition SHALL NOT increase the sequence number. The initial value is arbitrary.
序号（8位）：请求序列号。序列号空间对于请求源的SSRC和请求目标的SSRC的配对是唯一的。对于每个新命令，序列号应增加1模256。重复不得增加序列号。初始值是任意的。
Reserved (19 bits): All bits SHALL be set to 0 by the sender and SHALL be ignored on reception.
保留（19位）：发送方应将所有位设置为0，并在接收时忽略。
Index (5 bits): An integer value between 0 and 31 that indicates the relative trade-off that is requested. An index value of 0 indicates the highest possible spatial quality, while 31 indicates the highest possible temporal resolution.
索引（5位）：介于0和31之间的整数值，表示请求的相对权衡。索引值0表示可能的最高空间质量，而31表示可能的最高时间分辨率。
A decoder can suggest a temporal-spatial trade-off level by sending a TSTR message to an encoder. If the encoder is capable of adjusting its temporal-spatial trade-off, it SHOULD take into account the received TSTR message for future coding of pictures. A value of 0 suggests a high spatial quality and a value of 31 suggests a high frame rate. The progression of values from 0 to 31 indicates monotonically a desire for higher frame rate. The index values do not correspond to precise values of spatial quality or frame rate.
解码器可以通过向编码器发送TSTR消息来建议时空权衡水平。如果编码器能够调整其时空平衡，则应考虑接收到的TSTR消息，以便将来对图片进行编码。值0表示空间质量高，值31表示帧速率高。值从0到31的级数单调地表示对更高帧速率的渴望。索引值与空间质量或帧速率的精确值不对应。
The reaction to the reception of more than one TSTR message by a media sender from different media receivers is left open to the implementation. The selected trade-off SHALL be communicated to the media receivers by means of the TSTN message.
对于媒体发送者从不同媒体接收器接收到多个TSTR消息的反应，由实现人员决定。所选权衡应通过TSTN消息传达给媒体接收者。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of the media senders to which the TSTR applies are in the corresponding FCI entries.
在反馈消息的公共分组报头（如[RFC4585]第6.1节所定义）中，“分组发送方的SSRC”字段表示请求的来源，“媒体源的SSRC”未使用，应设置为0。TSTR适用的媒体发送方的SSRC位于相应的FCI条目中。
A TSTR message MAY contain requests to multiple media senders, using one FCI entry per target media sender.
TSTR消息可能包含对多个媒体发送者的请求，每个目标媒体发送者使用一个FCI条目。
The timing follows the rules outlined in section 3 of [RFC4585]. This request message is not time critical and SHOULD be sent using regular RTCP timing. Only if it is known that the user interface requires quick feedback, the message MAY be sent with early or immediate feedback timing.
计时遵循[RFC4585]第3节中概述的规则。此请求消息不受时间限制，应使用常规RTCP定时发送。只有当知道用户界面需要快速反馈时，才可以提前或立即发送反馈定时消息。
A mixer or media translator that encodes content sent to the session participant issuing the TSTR SHALL consider the request to determine if it can fulfill it by changing its own encoding parameters. A media translator unable to fulfill the request MAY forward the request unaltered towards the media sender. A mixer encoding for multiple session participants will need to consider the joint needs of these participants before generating a TSTR on its own behalf towards the media sender. See also the discussion in section 3.5.2.
将发送给TSTR的会话参与者发送的内容编码的混合器或媒体翻译器应考虑通过改变其自身编码参数来确定它是否能够满足它的请求。无法完成请求的媒体翻译人员可以将请求原封不动地转发给媒体发送者。对于多个会话参与者的混频器编码将需要考虑这些参与者的联合需求，然后在其自身代表向媒体发送器生成TSTR之前。另见第3.5.2节中的讨论。
The term "spatial quality" does not necessarily refer to the resolution as measured by the number of pixels the reconstructed video is using. In fact, in most scenarios the video resolution stays constant during the lifetime of a session. However, all video compression standards have means to adjust the spatial quality at a given resolution, often influenced by the Quantizer Parameter or QP. A numerically low QP results in a good reconstructed picture quality, whereas a numerically high QP yields a coarse picture. The typical reaction of an encoder to this request is to change its rate control parameters to use a lower frame rate and a numerically lower (on average) QP, or vice versa. The precise mapping of Index value to
术语“空间质量”不一定指由重建视频使用的像素数测量的分辨率。事实上，在大多数情况下，视频分辨率在会话生命周期内保持不变。然而，所有视频压缩标准都有在给定分辨率下调整空间质量的方法，通常受到量化器参数或QP的影响。数值较低的QP会产生良好的重建图像质量，而数值较高的QP会产生粗略的图像。编码器对此请求的典型反应是更改其速率控制参数以使用较低的帧速率和数字上较低的（平均）QP，反之亦然。索引值到目标函数的精确映射
frame rate and QP is intentionally left open here, as it depends on factors such as the compression standard employed, spatial resolution, content, bit rate, and so on.
这里有意将帧速率和QP留空，因为它取决于所采用的压缩标准、空间分辨率、内容、比特率等因素。
The TSTN message is identified by RTCP packet type value PT=PSFB and FMT=6.
TSTN消息由RTCP数据包类型值PT=PSFB和FMT=6标识。
The FCI field SHALL contain one or more TSTN FCI entries.
FCI字段应包含一个或多个TSTN FCI条目。
The content of an FCI entry for the Temporal-Spatial Trade-off Notification is depicted in Figure 6. The length of the TSTN message MUST be set to 2+2*N, where N is the number of FCI entries.
时空权衡通知的FCI条目的内容如图6所示。TSTN消息的长度必须设置为2+2*N，其中N是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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 - Syntax of the TSTN
图6-TSTN的语法
SSRC (32 bits): The SSRC of the source of the TSTR that resulted in this Notification.
SSRC（32位）：导致此通知的TSTR源的SSRC。
Seq nr. (8 bits): The sequence number value from the TSTR that is being acknowledged.
序列号（8位）：正在确认的TSTR序列号值。
Reserved (19 bits): All bits SHALL be set to 0 by the sender and SHALL be ignored on reception.
保留（19位）：发送方应将所有位设置为0，并在接收时忽略。
Index (5 bits): The trade-off value the media sender is using henceforth.
索引（5位）：媒体发送方今后使用的折衷值。
Informative note: The returned trade-off value (Index) may differ from the requested one, for example, in cases where a media encoder cannot tune its trade-off, or when pre-recorded content is used.
资料性说明：返回的折衷值（索引）可能与请求的值不同，例如，在媒体编码器无法调整其折衷值的情况下，或者在使用预录制内容的情况下。
This feedback message is used to acknowledge the reception of a TSTR. For each TSTR received targeted at the session participant, a TSTN FCI entry SHALL be sent in a TSTN feedback message. A single TSTN message MAY acknowledge multiple requests using multiple FCI entries. The index value included SHALL be the same in all FCI entries of the TSTN message. Including a FCI for each requestor allows each requesting entity to determine that the media sender received the request. The Notification SHALL also be sent in response to TSTR repetitions received. If the request receiver has received TSTR with several different sequence numbers from a single requestor, it SHALL only respond to the request with the highest (modulo 256) sequence number. Note that the highest sequence number may be a smaller integer value due to the wrapping of the field. Appendix A.1 of [RFC3550] has an algorithm for keeping track of the highest received sequence number for RTP packets; it could be adapted for this usage.
此反馈信息用于确认接收到TSTR。对于针对会话参与者收到的每个TSTR，应在TSTN反馈消息中发送TSTN FCI条目。单个TSTN消息可以使用多个FCI条目确认多个请求。TSTN报文的所有FCI条目中包含的索引值应相同。包括每个请求者的FCI允许每个请求实体确定媒体发送者接收到请求。还应发送通知以响应收到的TSTR重复。如果请求接收方从单个请求方接收到具有多个不同序列号的TSTR，则其应仅响应具有最高（模256）序列号的请求。请注意，由于字段的包装，最高序列号可能是较小的整数值。[RFC3550]的附录A.1有一个算法，用于跟踪RTP数据包的最高接收序列号；它可以适应这种用途。
The TSTN SHALL include the Temporal-Spatial Trade-off index that will be used as a result of the request. This is not necessarily the same index as requested, as the media sender may need to aggregate requests from several requesting session participants. It may also have some other policies or rules that limit the selection.
TSTN应包括将作为请求结果使用的时空权衡指数。这不一定与请求的索引相同，因为媒体发送者可能需要聚合来自多个请求会话参与者的请求。它还可能有一些限制选择的其他策略或规则。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the Notification, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of the requesting entities to which the Notification applies are in the corresponding FCI entries.
在反馈消息的公共数据包头（如[RFC4585]第6.1节所定义）中，“数据包发送方的SSRC”字段表示通知的来源，“媒体源的SSRC”未使用，应设置为0。通知适用的请求实体的SSRC位于相应的FCI条目中。
The timing follows the rules outlined in section 3 of [RFC4585]. This acknowledgement message is not extremely time critical and SHOULD be sent using regular RTCP timing.
计时遵循[RFC4585]第3节中概述的规则。此确认消息对时间不是非常关键，应使用常规RTCP定时发送。
A mixer or translator that acts upon a TSTR SHALL also send the corresponding TSTN. In cases where it needs to forward a TSTR itself, the notification message MAY need to be delayed until the TSTR has been responded to.
作用于TSTR的混合器或转换器也应发送相应的TSTN。如果需要转发TSTR本身，则可能需要延迟通知消息，直到TSTR得到响应。
None.
没有一个
The VBCM is identified by RTCP packet type value PT=PSFB and FMT=7.
VBCM由RTCP数据包类型值PT=PSFB和FMT=7标识。
The FCI field MUST contain one or more VBCM FCI entries.
FCI字段必须包含一个或多个VBCM FCI条目。
The syntax of an FCI entry within the VBCM indication is depicted in Figure 7.
VBCM指示中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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. |0| Payload Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VBCM Octet String.... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. |0| Payload Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VBCM Octet String.... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 - Syntax of an FCI Entry in the VBCM
图7-VBCM中FCI条目的语法
SSRC (32 bits): The SSRC value of the media sender that is requested to instruct its encoder to react to the VBCM.
SSRC（32位）：被请求指示其编码器对VBCM作出反应的媒体发送器的SSRC值。
Seq nr. (8 bits): Command sequence number. The sequence number space is unique for pairing of the SSRC of the command source and the SSRC of the command target. The sequence number SHALL be increased by 1 modulo 256 for each new command. A repetition SHALL NOT increase the sequence number. The initial value is arbitrary.
序号（8位）：命令序列号。序列号空间对于命令源的SSRC和命令目标的SSRC配对是唯一的。对于每个新命令，序列号应增加1模256。重复不得增加序列号。初始值是任意的。
0: Must be set to 0 by the sender and should not be acted upon by the message receiver.
0:必须由发件人设置为0，并且不应由邮件收件人执行操作。
Payload Type (7 bits): The RTP payload type for which the VBCM bit stream must be interpreted.
有效负载类型（7位）：必须为其解释VBCM位流的RTP有效负载类型。
Length (16 bits): The length of the VBCM octet string in octets exclusive of any padding octets.
长度（16位）：VBCM八位字节字符串的长度，以八位字节为单位，不包括任何填充八位字节。
VBCM Octet String (variable length): This is the octet string generated by the decoder carrying a specific feedback sub-message.
VBCM八位字节字符串（可变长度）：这是由携带特定反馈子消息的解码器生成的八位字节字符串。
Padding (variable length): Bits set to 0 to make up a 32-bit boundary.
填充（可变长度）：设置为0的位组成32位边界。
The "payload" of the VBCM indication carries different types of codec-specific, feedback information. The type of feedback information can be classified as a 'status report' (such as an indication that a bit stream was received without errors, or that a partial or complete picture or block was lost) or 'update requests' (such as complete refresh of the bit stream).
VBCM指示的“有效载荷”携带不同类型的编解码器特定反馈信息。反馈信息的类型可分为“状态报告”（如接收到的比特流没有错误，或部分或完整图片或块丢失的指示）或“更新请求”（如比特流的完全刷新）。
Note: There are possible overlaps between the VBCM sub-messages and CCM/AVPF feedback messages, such as FIR. Please see section 3.5.3 for further discussion.
注意：VBCM子消息和CCM/AVPF反馈消息（如FIR）之间可能存在重叠。请参阅第3.5.3节以了解进一步的讨论。
The different types of feedback sub-messages carried in the VBCM are indicated by the "payloadType" as defined in [H.271]. These sub-message types are reproduced below for convenience. "payloadType", in ITU-T Rec. H.271 terminology, refers to the sub-type of the H.271 message and should not be confused with an RTP payload type.
VBCM中携带的不同类型的反馈子消息由[H.271]中定义的“payloadType”表示。为了方便起见，下面复制了这些子消息类型。在ITU-T Rec.H.271术语中，“payloadType”指的是H.271报文的子类型，不应与RTP有效负载类型混淆。
Payload Message Content
Type
---------------------------------------------------------------------
0 One or more pictures without detected bit stream error
mismatch
1 One or more pictures that are entirely or partially lost
2 A set of blocks of one picture that is entirely or partially
lost
3 CRC for one parameter set
4 CRC for all parameter sets of a certain type
5 A "reset" request indicating that the sender should completely
refresh the video bit stream as if no prior bit stream data
had been received
> 5 Reserved for future use by ITU-T
Payload Message Content
Type
---------------------------------------------------------------------
0 One or more pictures without detected bit stream error
mismatch
1 One or more pictures that are entirely or partially lost
2 A set of blocks of one picture that is entirely or partially
lost
3 CRC for one parameter set
4 CRC for all parameter sets of a certain type
5 A "reset" request indicating that the sender should completely
refresh the video bit stream as if no prior bit stream data
had been received
> 5 Reserved for future use by ITU-T
Table 2: H.271 message types ("payloadTypes")
表2:H.271消息类型（“payloadTypes”）
The bit string or the "payload" of a VBCM is of variable length and is self-contained and coded in a variable-length, binary format. The media sender necessarily has to be able to parse this optimized binary format to make use of VBCMs.
VBCM的位字符串或“有效载荷”具有可变长度，并且是自包含的，并以可变长度的二进制格式进行编码。媒体发送方必须能够解析这种优化的二进制格式，才能使用VBCMs。
Each of the different types of sub-messages (indicated by payloadType) may have different semantics depending on the codec used.
每个不同类型的子消息（由payloadType指示）可能具有不同的语义，具体取决于所使用的编解码器。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source"
在反馈消息的公共数据包报头中（如[RFC4585]第6.1节所定义），“数据包发送方的SSRC”字段表示请求的来源，“媒体源的SSRC”
is not used and SHALL be set to 0. The SSRCs of the media senders to which the VBCM applies are in the corresponding FCI entries. The sender of the VBCM MAY send H.271 messages to multiple media senders and MAY send more than one H.271 message to the same media sender within the same VBCM.
未使用，应设置为0。VBCM适用的媒体发送器的SSRC位于相应的FCI条目中。VBCM的发送方可以向多个媒体发送方发送H.271消息，也可以向同一VBCM内的同一媒体发送方发送多个H.271消息。
The timing follows the rules outlined in section 3 of [RFC4585]. The different sub-message types may have different properties in regards to the timing of messages that should be used. If several different types are included in the same feedback packet, then the requirements for the sub-message type with the most stringent requirements should be followed.
计时遵循[RFC4585]第3节中概述的规则。关于应该使用的消息的定时，不同的子消息类型可能具有不同的属性。如果同一反馈数据包中包含多个不同类型，则应遵循要求最严格的子消息类型的要求。
The handling of a VBCM in a mixer or translator is sub-message type dependent.
混音器或转换器中VBCM的处理取决于子消息类型。
Please see section 3.5.3 for a discussion of the usage of H.271 messages and messages defined in AVPF [RFC4585] and this memo with similar functionality.
有关H.271消息的使用以及AVPF[RFC4585]和本备忘录中定义的具有类似功能的消息的讨论，请参见第3.5.3节。
Note: There has been some discussion whether the RTP payload type field in this message is needed. It will be needed if there is potentially more than one VBCM-capable RTP payload type in the same session, and the semantics of a given VBCM changes between payload types. For example, the picture identification mechanism in messages of H.271 type 0 is fundamentally different between H.263 and H.264 (although both use the same syntax). Therefore, the payload field is justified here. There was a further comment that for TSTR and FIR such a need does not exist, because the semantics of TSTR and FIR are either loosely enough defined, or generic enough, to apply to all video payloads currently in existence/envisioned.
注意：对于是否需要此消息中的RTP有效负载类型字段，已经进行了一些讨论。如果在同一会话中可能有多个支持VBCM的RTP有效负载类型，并且给定VBCM的语义在有效负载类型之间发生变化，则需要使用它。例如，H.271类型0的消息中的图片识别机制在H.263和H.264之间有根本的不同（尽管两者使用相同的语法）。因此，有效载荷字段在这里是合理的。有人进一步评论说，对于TSTR和FIR，不存在这种需求，因为TSTR和FIR的语义定义不够松散，或不够通用，适用于当前存在/设想的所有视频有效载荷。
The correct application of the AVPF [RFC4585] timing rules prevents the network from being flooded by feedback messages. Hence, assuming a correct implementation and configuration, the RTCP channel cannot break its bit rate commitment and introduce congestion.
AVPF[RFC4585]定时规则的正确应用可防止网络被反馈消息淹没。因此，假设实现和配置正确，RTCP信道无法打破其比特率承诺并引入拥塞。
The reception of some of the feedback messages modifies the behaviour of the media senders or, more specifically, the media encoders.
一些反馈消息的接收修改了媒体发送者或更具体地说，媒体编码器的行为。
Thus, modified behaviour MUST respect the bandwidth limits that the application of congestion control provides. For example, when a media sender is reacting to a FIR, the unusually high number of packets that form the decoder refresh point have to be paced in compliance with the congestion control algorithm, even if the user experience suffers from a slowly transmitted decoder refresh point.
因此，修改后的行为必须遵守拥塞控制应用程序提供的带宽限制。例如，当媒体发送方对FIR作出反应时，形成解码器刷新点的异常多的分组必须按照拥塞控制算法进行调整，即使用户体验受到缓慢传输的解码器刷新点的影响。
A change of the Temporary Maximum Media Stream Bit Rate value can only mitigate congestion, but not cause congestion as long as congestion control is also employed. An increase of the value by a request REQUIRES the media sender to use congestion control when increasing its transmission rate to that value. A reduction of the value results in a reduced transmission bit rate, thus reducing the risk for congestion.
改变临时最大媒体流比特率值只能缓解拥塞，但只要采用拥塞控制，就不会引起拥塞。请求增加该值要求媒体发送方在将其传输速率增加到该值时使用拥塞控制。该值的减少导致传输比特率降低，从而降低拥塞风险。
The defined messages have certain properties that have security implications. These must be addressed and taken into account by users of this protocol.
定义的消息具有某些具有安全含义的属性。本协议的用户必须解决并考虑这些问题。
The defined setup signaling mechanism is sensitive to modification attacks that can result in session creation with sub-optimal configuration, and, in the worst case, session rejection. To prevent this type of attack, authentication and integrity protection of the setup signaling is required.
定义的设置信令机制对修改攻击非常敏感，修改攻击可能导致会话创建和次优配置，在最坏的情况下，会话拒绝。为了防止此类攻击，需要设置信令的身份验证和完整性保护。
Spoofed or maliciously created feedback messages of the type defined in this specification can have the following implications:
本规范中定义类型的伪造或恶意创建的反馈消息可能具有以下含义：
a. severely reduced media bit rate due to false TMMBR messages that sets the maximum to a very low value;
a. 由于错误的TMMBR消息将最大值设置为非常低的值，严重降低了媒体比特率；
b. assignment of the ownership of a bounding tuple to the wrong participant within a TMMBN message, potentially causing unnecessary oscillation in the bounding set as the mistakenly identified owner reports a change in its tuple and the true owner possibly holds back on changes until a correct TMMBN message reaches the participants;
b. 将边界元组的所有权分配给TMMBN消息中的错误参与者，可能导致边界集中不必要的振荡，因为错误识别的所有者报告其元组中的更改，而真正的所有者可能会保留更改，直到正确的TMMBN消息到达参与者为止；
c. sending TSTRs that result in a video quality different from the user's desire, rendering the session less useful;
c. 发送导致不同于用户期望的视频质量的tstr，使得会话不那么有用；
d. sending multiple FIR commands to reduce the frame rate, and make the video jerky, due to the frequent usage of decoder refresh points.
d. 由于频繁使用解码器刷新点，发送多个FIR命令以降低帧速率，并使视频抖动。
To prevent these attacks, there is a need to apply authentication and integrity protection of the feedback messages. This can be accomplished against threats external to the current RTP session using the RTP profile that combines Secure RTP [SRTP] and AVPF into SAVPF [SAVPF]. In the mixer cases, separate security contexts and filtering can be applied between the mixer and the participants, thus protecting other users on the mixer from a misbehaving participant.
为了防止这些攻击，需要对反馈消息应用身份验证和完整性保护。使用将安全RTP[SRTP]和AVPF组合到SAVPF[SAVPF]中的RTP配置文件，可以针对当前RTP会话外部的威胁实现这一点。在混音器的情况下，可以在混音器和参与者之间应用单独的安全上下文和过滤，从而保护混音器上的其他用户不受行为不端的参与者的影响。
Section 4 of [RFC4585] defines a new SDP [RFC4566] attribute, rtcp-fb, that may be used to negotiate the capability to handle specific AVPF commands and indications, such as Reference Picture Selection, Picture Loss Indication, etc. The ABNF for rtcp-fb is described in section 4.2 of [RFC4585]. In this section, we extend the rtcp-fb attribute to include the commands and indications that are described for codec control in the present document. We also discuss the Offer/Answer implications for the codec control commands and indications.
[RFC4585]第4节定义了一个新的SDP[RFC4566]属性rtcp fb，该属性可用于协商处理特定AVPF命令和指示的能力，如参考图片选择、图片丢失指示等。rtcp fb的ABNF在[RFC4585]第4.2节中描述。在本节中，我们扩展了rtcp fb属性，以包括本文档中描述的用于编解码器控制的命令和指示。我们还讨论了编解码器控制命令和指示的提供/应答含义。
As described in AVPF [RFC4585], the rtcp-fb attribute indicates the capability of using RTCP feedback. AVPF specifies that the rtcp-fb attribute must only be used as a media level attribute and must not be provided at session level. All the rules described in [RFC4585] for rtcp-fb attribute relating to payload type and to multiple rtcp-fb attributes in a session description also apply to the new feedback messages defined in this memo.
如AVPF[RFC4585]所述，rtcp fb属性表示使用rtcp反馈的能力。AVPF指定rtcp fb属性只能用作媒体级属性，不能在会话级提供。[RFC4585]中描述的与有效负载类型和会话描述中多个rtcp fb属性相关的rtcp fb属性的所有规则也适用于本备忘录中定义的新反馈消息。
The ABNF [RFC4234] for rtcp-fb as defined in [RFC4585] is
[RFC4585]中定义的rtcp fb的ABNF[RFC4234]为
"a=rtcp-fb: " rtcp-fb-pt SP rtcp-fb-val CRLF
“a=rtcp fb:“rtcp fb pt SP rtcp fb val CRLF
where rtcp-fb-pt is the payload type and rtcp-fb-val defines the type of the feedback message such as ack, nack, trr-int, and rtcp-fb-id. For example, to indicate the support of feedback of Picture Loss Indication, the sender declares the following in SDP
其中，rtcp fb pt是有效负载类型，rtcp fb val定义反馈消息的类型，如ack、nack、trr int和rtcp-fb-id。例如，为了表示支持图片丢失指示的反馈，发送方在SDP中声明以下内容
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 nack pli
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 nack pli
In this document, we define a new feedback value "ccm", which indicates the support of codec control using RTCP feedback messages. The "ccm" feedback value SHOULD be used with parameters that indicate the specific codec control commands supported. In this document, we define four such parameters, namely:
在本文中，我们定义了一个新的反馈值“ccm”，它表示使用RTCP反馈消息支持编解码器控制。“ccm”反馈值应与指示支持的特定编解码器控制命令的参数一起使用。在本文件中，我们定义了四个此类参数，即：
o "fir" indicates support of the Full Intra Request (FIR).
o "tmmbr" indicates support of the Temporary Maximum Media Stream
Bit Rate Request/Notification (TMMBR/TMMBN). It has an
optional sub-parameter to indicate the session maximum packet
rate (measured in packets per second) to be used. If not
included, this defaults to infinity.
o "tstr" indicates support of the Temporal-Spatial Trade-off
Request/Notification (TSTR/TSTN).
o "vbcm" indicates support of H.271 Video Back Channel Messages
(VBCMs). It has zero or more subparameters identifying the
supported H.271 "payloadType" values.
o "fir" indicates support of the Full Intra Request (FIR).
o "tmmbr" indicates support of the Temporary Maximum Media Stream
Bit Rate Request/Notification (TMMBR/TMMBN). It has an
optional sub-parameter to indicate the session maximum packet
rate (measured in packets per second) to be used. If not
included, this defaults to infinity.
o "tstr" indicates support of the Temporal-Spatial Trade-off
Request/Notification (TSTR/TSTN).
o "vbcm" indicates support of H.271 Video Back Channel Messages
(VBCMs). It has zero or more subparameters identifying the
supported H.271 "payloadType" values.
In the ABNF for rtcp-fb-val defined in [RFC4585], there is a placeholder called rtcp-fb-id to define new feedback types. "ccm" is defined as a new feedback type in this document, and the ABNF for the parameters for ccm is defined here (please refer to section 4.2 of [RFC4585] for complete ABNF syntax).
在[RFC4585]中定义的rtcp fb val的ABNF中，有一个名为rtcp fb id的占位符，用于定义新的反馈类型。“ccm”在本文件中定义为一种新的反馈类型，此处定义了ccm参数的ABNF（有关完整的ABNF语法，请参阅[RFC4585]第4.2节）。
rtcp-fb-val =/ "ccm" rtcp-fb-ccm-param
rtcp fb val=/“ccm”rtcp fb ccm参数
rtcp-fb-ccm-param = SP "fir" ; Full Intra Request
/ SP "tmmbr" [SP "smaxpr=" MaxPacketRateValue]
; Temporary max media bit rate
/ SP "tstr" ; Temporal-Spatial Trade-Off
/ SP "vbcm" *(SP subMessageType) ; H.271 VBCMs
/ SP token [SP byte-string]
; for future commands/indications
subMessageType = 1*8DIGIT
byte-string = <as defined in section 4.2 of [RFC4585] >
MaxPacketRateValue = 1*15DIGIT
rtcp-fb-ccm-param = SP "fir" ; Full Intra Request
/ SP "tmmbr" [SP "smaxpr=" MaxPacketRateValue]
; Temporary max media bit rate
/ SP "tstr" ; Temporal-Spatial Trade-Off
/ SP "vbcm" *(SP subMessageType) ; H.271 VBCMs
/ SP token [SP byte-string]
; for future commands/indications
subMessageType = 1*8DIGIT
byte-string = <as defined in section 4.2 of [RFC4585] >
MaxPacketRateValue = 1*15DIGIT
The Offer/Answer [RFC3264] implications for codec control protocol feedback messages are similar to those described in [RFC4585]. The offerer MAY indicate the capability to support selected codec commands and indications. The answerer MUST remove all CCM parameters corresponding to the CCMs that it does not wish to support in this particular media session (for example, because it does not implement the message in question, or because its application logic suggests that support of the message adds no value). The answerer MUST NOT add new ccm parameters in addition to what has been offered.
编解码器控制协议反馈消息的提供/应答[RFC3264]含义与[RFC4585]中描述的类似。报价人可指示支持所选编解码器命令和指示的能力。应答者必须删除与此特定媒体会话中不希望支持的CCM相对应的所有CCM参数（例如，因为应答者没有实现有问题的消息，或者因为其应用逻辑表明支持消息不会增加任何价值）。除已提供的参数外，应答者不得添加新的ccm参数。
The answer is binding for the media session and both offerer and answerer MUST NOT use any feedback messages other than what both sides have explicitly indicated as being supported. In other words, only the joint subset of CCM parameters from the offer and answer may be used.
答案对媒体会议具有约束力，除双方明确表示支持的信息外，报价人和应答人不得使用任何反馈信息。换句话说，只能使用来自要约和应答的CCM参数的联合子集。
Note that including a CCM parameter in an offer or answer indicates that the party (offerer or answerer) is at least capable of receiving the corresponding CCM(s) and act upon them. In cases when the reception of a negotiated CCM mandates the party to respond with another CCM, it must also have that capability. Although it is not mandated to initiate CCMs of any negotiated type, it is generally expected that a party will initiate CCMs when appropriate.
请注意，在报价或应答中包含CCM参数表示该方（报价人或应答人）至少能够接收相应的CCM并对其采取行动。在接收协商的CCM要求该方使用另一个CCM进行响应的情况下，该方还必须具备该能力。尽管没有强制要求启动任何协商类型的CCM，但通常预期一方将在适当时启动CCM。
The session maximum packet rate parameter part of the TMMBR indication is declarative, and the highest value from offer and answer SHALL be used. If the session maximum packet rate parameter is not present in an offer, it SHALL NOT be included by the answerer.
TMMBR指示的会话最大数据包速率参数部分是声明性的，应使用要约和应答中的最高值。如果会话最大分组速率参数不存在于报价中，则应答者不得将其包括在内。
Example 1: The following SDP describes a point-to-point video call with H.263, with the originator of the call declaring its capability to support the FIR and TSTR/TSTN codec control messages. The SDP is carried in a high-level signaling protocol like SIP.
示例1：以下SDP描述了使用H.263的点对点视频呼叫，呼叫发起人声明其支持FIR和TSTR/TSTN编解码器控制消息的能力。SDP以类似SIP的高级信令协议进行传输。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Point-to-Point call
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Point-to-Point call
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
In the above example, when the sender receives a TSTR message from the remote party it is capable of adjusting the trade-off as indicated in the RTCP TSTN feedback message.
在上述示例中，当发送方收到来自远程方的TSTR消息时，它能够按照RTCP TSTN反馈消息中的指示调整权衡。
Example 2: The following SDP describes a SIP end point joining a video mixer that is hosting a multiparty video conferencing session. The participant supports only the FIR (Full Intra Request) codec control command and it declares it in its session description.
示例2：下面的SDP描述了加入承载多方视频会议会话的视频混合器的SIP端点。参与者仅支持FIR（完整内部请求）编解码器控制命令，并在其会话描述中声明该命令。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multiparty Video Call
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm fir
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multiparty Video Call
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm fir
When the video MCU decides to route the video of this participant, it sends an RTCP FIR feedback message. Upon receiving this feedback message, the end point is required to generate a full intra request.
当视频MCU决定路由该参与者的视频时，它发送RTCP FIR反馈消息。收到此反馈消息后，端点需要生成完整的内部请求。
Example 3: The following example describes the Offer/Answer implications for the codec control messages. The offerer wishes to support "tstr", "fir" and "tmmbr". The offered SDP is
示例3：以下示例描述编解码器控制消息的提供/应答含义。报价人希望支持“tstr”、“fir”和“tmmbr”。提供的SDP是
-------------> Offer
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Offer/Answer
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
a=rtcp-fb:* ccm tmmbr smaxpr=120
-------------> Offer
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Offer/Answer
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
a=rtcp-fb:* ccm tmmbr smaxpr=120
The answerer wishes to support only the FIR and TSTR/TSTN messages and the answerer SDP is
应答者希望仅支持FIR和TSTR/TSTN消息，应答者SDP为
<---------------- Answer
<---------------- Answer
v=0
o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
s=Offer/Answer
c=IN IP4 192.0.2.37
m=audio 47190 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 53273 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
v=0
o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
s=Offer/Answer
c=IN IP4 192.0.2.37
m=audio 47190 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 53273 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
Example 4: The following example describes the Offer/Answer implications for H.271 Video Back Channel Messages (VBCMs). The offerer wishes to support VBCM and the sub-messages of payloadType 1 (one or more pictures that are entirely or partially lost) and 2 (a set of blocks of one picture that are entirely or partially lost).
示例4：以下示例描述了H.271视频反向通道消息（VBCMs）的提供/应答含义。报价人希望支持VBCM和payloadType 1（完全或部分丢失的一张或多张图片）和2（完全或部分丢失的一张图片的一组块）的子消息。
-------------> Offer
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Offer/Answer
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm vbcm 1 2
-------------> Offer
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Offer/Answer
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm vbcm 1 2
The answerer only wishes to support sub-messages of type 1 only
回答者只希望支持类型1的子消息
<---------------- Answer
<---------------- Answer
v=0
o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
s=Offer/Answer
c=IN IP4 192.0.2.37
m=audio 47190 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 53273 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm vbcm 1
v=0
o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
s=Offer/Answer
c=IN IP4 192.0.2.37
m=audio 47190 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 53273 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm vbcm 1
So, in the above example, only VBCM indications comprised of "payloadType" 1 will be supported.
因此，在上述示例中，仅支持由“payloadType”1组成的VBCM指示。
The new value "ccm" has been registered with IANA in the "rtcp-fb"
Attribute Values registry located at the time of publication at:
http://www.iana.org/assignments/sdp-parameters
The new value "ccm" has been registered with IANA in the "rtcp-fb"
Attribute Values registry located at the time of publication at:
http://www.iana.org/assignments/sdp-parameters
Value name: ccm Long Name: Codec Control Commands and Indications Reference: RFC 5104
值名称：ccm长名称：编解码器控制命令和指示参考：RFC 5104
A new registry "Codec Control Messages" has been created to hold
"ccm" parameters located at time of publication at:
http://www.iana.org/assignments/sdp-parameters
A new registry "Codec Control Messages" has been created to hold
"ccm" parameters located at time of publication at:
http://www.iana.org/assignments/sdp-parameters
New registration in this registry follows the "Specification required" policy as defined by [RFC2434]. In addition, they are required to indicate any additional RTCP feedback types, such as "nack" and "ack".
此注册表中的新注册遵循[RFC2434]定义的“所需规范”策略。此外，还需要指示任何其他RTCP反馈类型，如“nack”和“ack”。
The initial content of the registry is the following values:
注册表的初始内容为以下值：
Value name: fir Long name: Full Intra Request Command Usable with: ccm Reference: RFC 5104
值名称：fir长名称：完整的请求内命令可用于：ccm参考：RFC 5104
Value name: tmmbr Long name: Temporary Maximum Media Stream Bit Rate Usable with: ccm Reference: RFC 5104
值名称：tmmbr Long name:临时最大媒体流比特率可用于：ccm Reference:RFC 5104
Value name: tstr Long name: Temporal Spatial Trade Off Usable with: ccm Reference: RFC 5104
值名称：tstr Long name:可与ccm一起使用的时空权衡参考：RFC 5104
Value name: vbcm Long name: H.271 video back channel messages Usable with: ccm Reference: RFC 5104
值名称：vbcm长名称：H.271视频反向通道消息可用于：ccm参考：RFC 5104
The following values have been registered as FMT values in the "FMT
Values for RTPFB Payload Types" registry located at the time of
publication at: http://www.iana.org/assignments/rtp-parameters
The following values have been registered as FMT values in the "FMT
Values for RTPFB Payload Types" registry located at the time of
publication at: http://www.iana.org/assignments/rtp-parameters
RTPFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- ---------
Reserved 2 [RFC5104]
TMMBR Temporary Maximum Media Stream Bit 3 [RFC5104]
Rate Request
TMMBN Temporary Maximum Media Stream Bit 4 [RFC5104]
Rate Notification
RTPFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- ---------
Reserved 2 [RFC5104]
TMMBR Temporary Maximum Media Stream Bit 3 [RFC5104]
Rate Request
TMMBN Temporary Maximum Media Stream Bit 4 [RFC5104]
Rate Notification
The following values have been registered as FMT values in the "FMT
Values for PSFB Payload Types" registry located at the time of
publication at: http://www.iana.org/assignments/rtp-parameters
The following values have been registered as FMT values in the "FMT
Values for PSFB Payload Types" registry located at the time of
publication at: http://www.iana.org/assignments/rtp-parameters
PSFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- ---------
FIR Full Intra Request Command 4 [RFC5104]
TSTR Temporal-Spatial Trade-off Request 5 [RFC5104]
TSTN Temporal-Spatial Trade-off Notification 6 [RFC5104]
VBCM Video Back Channel Message 7 [RFC5104]
PSFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- ---------
FIR Full Intra Request Command 4 [RFC5104]
TSTR Temporal-Spatial Trade-off Request 5 [RFC5104]
TSTN Temporal-Spatial Trade-off Notification 6 [RFC5104]
VBCM Video Back Channel Message 7 [RFC5104]
Tom Taylor has made a very significant contribution to this specification, for which the authors are very grateful, by helping rewrite the specification. Especially the parts regarding the algorithm for determining bounding sets for TMMBR have benefited.
Tom Taylor通过帮助重写规范，对本规范做出了非常重要的贡献，对此作者非常感谢。特别是关于确定TMMBR边界集的算法的部分受益匪浅。
The authors would like to thank Andrea Basso, Orit Levin, and Nermeen Ismail for their work on the requirement and discussion document [Basso].
作者要感谢Andrea Basso、Orit Levin和Nermeen Ismail为需求和讨论文件[Basso]所做的工作。
Versions of this memo were reviewed and extensively commented on by Roni Even, Colin Perkins, Randell Jesup, Keith Lantz, Harikishan Desineni, Guido Franceschini, and others. The authors appreciate these reviews.
Roni Even、Colin Perkins、Randell Jesup、Keith Lantz、Harikishan Desneni、Guido Franceschini和其他人对本备忘录的版本进行了审查和广泛评论。作者对这些评论表示赞赏。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-Time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[Basso] Basso, A., Levin, O., and N. Ismail, "Requirements for transport of video control commands", Work in Progress, October 2004.
[Basso]Basso，A.，Levin，O.，和N.Ismail，“视频控制命令传输要求”，正在进行的工作，2004年10月。
[AVC] Joint Video Team of ITU-T and ISO/IEC JTC 1, Draft ITU-T Recommendation and Final Draft International Standard of Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC 14496-10 AVC), Joint Video Team (JVT) of ISO/IEC MPEG and ITU-T VCEG, JVT-G050, March 2003.
[AVC]ITU-T和ISO/IEC JTC 1联合视频团队，ITU-T建议草案和联合视频规范国际标准最终草案（ITU-T Rec.H.264 | ISO/IEC 14496-10 AVC），ISO/IEC MPEG和ITU-T VCEG联合视频团队（JVT），JVT-G050，2003年3月。
[H245] ITU-T Rec. H.245, "Control protocol for multimedia communication", May 2006.
[H245]ITU-T Rec.H.245，“多媒体通信控制协议”，2006年5月。
[NEWPRED] S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient Video Coding by Dynamic Replacing of Reference Pictures", in Proc. Globcom'96, vol. 3, pp. 1503 - 1508, 1996.
[NEWPRED]S.Fukunaga，T.Nakai和H.Inoue，“通过动态替换参考图片进行抗错误视频编码”，在Proc。《全球通讯》1996年第3卷，第1503-15081996页。
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[SRTP]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC2032] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 Video Streams", RFC 2032, October 1996.
[RFC2032]Turletti，T.和C.Huitema，“H.261视频流的RTP有效载荷格式”，RFC 2032，1996年10月。
[SAVPF] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", Work in Progress, November 2007.
[SAVPF]Ott，J.和E.Carrara，“基于RTCP的反馈的扩展安全RTP配置文件（RTP/SAVPF）”，正在进行的工作，2007年11月。
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC3525]Groves，C.，Pantaleo，M.，Anderson，T.，和T.Taylor，“网关控制协议版本1”，RFC 35252003年6月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
[H.271] ITU-T Rec. H.271, "Video Back Channel Messages", June 2006.
[H.271]ITU-T Rec.H.271，“视频反向通道信息”，2006年6月。
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.
[RFC3890]Westerlund，M.“会话描述协议（SDP）的传输无关带宽修改器”，RFC 38902004年9月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[RFC2198]Perkins，C.，Kouvelas，I.，Hodson，O.，Hardman，V.，Handley，M.，Bolot，J.，Vega Garcia，A.，和S.Fosse Parisis，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", RFC 4587, August 2006.
[RFC4587]偶数，R.，“H.261视频流的RTP有效负载格式”，RFC4587，2006年8月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117]Westerlund，M.和S.Wenger，“RTP拓扑”，RFC 51172008年1月。
[XML-MC] Levin, O., Even, R., and P. Hagendorf, "XML Schema for Media Control", Work in Progress, November 2007.
[XML-MC]Levin，O.，Even，R.，和P.Hagendorf，“用于媒体控制的XML模式”，正在进行的工作，2007年11月。
Authors' Addresses
作者地址
Stephan Wenger Nokia Corporation 975, Page Mill Road, Palo Alto,CA 94304 USA
美国加利福尼亚州帕洛阿尔托佩奇米尔路975号诺基亚公司，邮编94304
Phone: +1-650-862-7368
EMail: stewe@stewe.org
Phone: +1-650-862-7368
EMail: stewe@stewe.org
Umesh Chandra Nokia Research Center 975, Page Mill Road, Palo Alto,CA 94304 USA
美国加利福尼亚州帕洛阿尔托佩奇米尔路975号梅什钱德拉诺基亚研究中心，邮编94304
Phone: +1-650-796-7502
Email: Umesh.1.Chandra@nokia.com
Phone: +1-650-796-7502
Email: Umesh.1.Chandra@nokia.com
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80瑞典斯德哥尔摩
Phone: +46 8 7190000
EMail: magnus.westerlund@ericsson.com
Phone: +46 8 7190000
EMail: magnus.westerlund@ericsson.com
Bo Burman Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN
博伯曼爱立信研究公司爱立信AB SE-16480瑞典斯德哥尔摩
Phone: +46 8 7190000
EMail: bo.burman@ericsson.com
Phone: +46 8 7190000
EMail: bo.burman@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.