【RFC5104 带有反馈的RTP视听配置文件中的编解码器控制消息（AVPF）】（翻译）
作者：互联网
原文 rfc5104 (ietf.org) Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) 带有反馈的 RTP 视听配置文件中的编解码器控制消息 (AVPF)
概述
本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）
本文档指定了对带有反馈的视听配置文件 (AVPF) 中定义的消息的一些扩展。它们主要用于使用集中式多点功能的对话多媒体场景。但是，有些也可用于较小的多播环境和点对点呼叫。
讨论的扩展是与 ITU-T Rec. 相关的消息。 H.271 视频反向通道、完整帧内请求、临时最大媒体流比特率和时空权衡。
目录
1. 简介
2. 定义
2.1.词汇表
2.2.术语
2.3.拓扑
3. 动机
3.1.用例
3.2.使用媒体路径
3.3.使用 AVPF
3.3.1.可靠性
3.4.组播
3.5.反馈信息
3.5.1.完整的内部请求命令
3.5.1.1.可靠性
3.5.2.时空权衡请求和通知
3.5.2.1.点对点
3.5.2.2.使用多播或转换器的点对多点
3.5.2.3.使用 RTP 混合器的点对多点
3.5.2.4.可靠性
3.5.3. H.271 视频反向通道消息
3.5.3.1.可靠性
3.5.4.临时最大媒体流比特率请求和通知
3.5.4.1.使用 TMMBR 的媒体接收器的行为
3.5.4.2.建立电流限制的算法
3.5.4.3.在基于混合器的多点操作中使用 TMMBR
3.5.4.4.在使用多播或转换器的点对多点中使用 TMMBR
3.5.4.5. TMMBR 在点对点操作中的使用
3.5.4.6.可靠性
4. RTCP 接收器报告扩展
4.1.扩展机制的设计原则
4.2.传输层反馈消息
4.2.1.临时最大媒体流比特率
请求 (TMMBR)
4.2.1.1.消息格式
4.2.1.2.语义
4.2.1.3.计时规则
4.2.1.4.在转换器和混音器中处理
4.2.2.临时最大媒体流比特率通知 (TMMBN)
4.2.2.1.消息格式
4.2.2.2.语义
4.2.2.3.计时规则
4.2.2.4.在转换器和混音器中处理
4.3.特定于负载的反馈消息
4.3.1.完整的内部请求 (FIR)
4.3.1.1.消息格式
4.3.1.2.语义
4.3.1.3.计时规则
4.3.1.4.在转换器和混音器中处理FIR消息
4.3.1.5.评论
4.3.2.时空权衡请求 (TSTR)
4.3.2.1.消息格式
4.3.2.2.语义
4.3.2.3.计时规则
4.3.2.4.在转换器和混音器中处理消息
4.3.2.5.评论
4.3.3.时空权衡通知 (TSTN)
4.3.3.1.消息格式
4.3.3.2.语义
4.3.3.3.计时规则
4.3.3.4.在转换器和混音器中处理 TSTN
4.3.3.5.评论
4.3.4. H.271 视频反向通道消息 (VBCM)
4.3.4.1.消息格式
4.3.4.2.语义
4.3.4.3.计时规则
4.3.4.4.在混合器或转换器中处理消息
4.3.4.5.评论
5. 拥塞控制
6. 安全考虑
7. SDP 定义
7.1. rtcp-fb 属性的扩展
7.2. Offer-Answer 提供-应答
7.3.案例
8. IANA 考虑
9. 贡献者（略）
10. 致谢（略)
11. 参考文献 (略）
11.1.规范参考（略）
11.2.参考资料（略）
1. 简介
在开发带有反馈的视听配置文件 (AVPF)[RFC4585] 时，主要重点在于有效支持点对点和小型多点场景，而无需集中多点控制。然而，在实践中，许多小型多点会议使用称为多点控制单元 (MCU) 的设备进行操作。会话视频会议行业的长期经验表明，需要一些额外的反馈消息，以有效地支持集中式多点会议。一些消息的应用超出了集中式多点的范围，这在消息的描述中有所声明。对于打算携带 ITU-T Rec. 的消息尤其如此。 H.271 [H.271] 用于视频反向信道消息的比特串。
在实时传输协议 (RTP) [RFC3550] 术语中，MCU 包括混合器和转换器。大多数 MCU 还包括信令支持。在本文的发展过程中，人们注意到社区中与混音器、转换器和 MCU 等术语的使用相关的相当混乱。针对这些问题，已经确定了许多与行业实际相关的拓扑结构，但在 [RFC3550] 中没有提供足够详细的记录。这些拓扑记录在 [RFC5117] 中，理解本文需要事先或并行研究 [RFC5117]。
此处定义的一些消息仅用于转发，因为它们不需要向消息发送者明确通知它们已被接收和/或声明消息接收者的操作。其他消息需要响应，从而形成一种双向通信模型，人们可以将其视为对控制目的有用。但是，本文的目的不是将 RTP 控制协议 (RTCP) 开放为通用控制协议。所有提到的消息都有相对严格的实时限制，因为它们的价值随着延迟的增加而减少。这使得使用更传统的控制协议方法，例如会话发起协议 (SIP) [RFC3261]，在用于相同目的时是不可取的。
这就是为什么推荐使用此解决方案而不是“媒体控制的 XML 模式”[XML-MC] 的原因，后者使用 SIP 信息来传输具有与本文中定义的语义相似的语义的 XML 消息。
此外，所有消息都是一种非常简单的格式，可以由 RTP/RTCP 发送方/接收方轻松处理。最后，也是最重要的是，所有消息仅与它们关联的 RTP 流相关，与通信系统的任何其他属性无关。特别是，它们都与会话所经过的访问链路的属性无关。
2. 定义
2.1.词汇表
AIMD - 加法增加乘法减少
AVPF - 基于 RTCP 反馈的扩展 RTP 配置文件
FCI - 反馈控制信息 [RFC4585]
FEC - 前向纠错
FIR - 完整的内部请求
MCU - 多点控制单元
MPEG - 运动图像专家组
PLI - 图像丢失指示
PR - 数据包速率
QP - 量化器参数
RTT——往返时间
SSRC - 同步源
TMMBN - 临时最大媒体流比特率通知
TMMBR - 临时最大媒体流比特率请求
TSTN - 时空权衡通知
TSTR - 时空权衡请求
VBCM - 视频反向通道消息
2.2.术语
消息：本规范定义的 RTCP 反馈消息 [RFC4585]，属于以下类型之一：
请求：请求确认的消息
命令：强制接收者采取行动的消息
指示（声明）：报告情况的消息
通知：提供事件已发生通知的消息。通知通常是响应请求而生成的。
请注意，除“通知”外，该术语与 ITU-T Rec. H.245 [H245]对准。
解码器刷新点：
一个位串，打包在一个或多个 RTP 数据包中，将解码器完全重置为已知状态。
例如，“硬”解码器刷新点的示例是 H.261、H.263、MPEG-1、MPEG-2 和 MPEG-4 第 2 部分中的帧内图片，以及 H.264 中的瞬时解码器刷新 (IDR) 图片。也可以使用“渐进”解码器刷新点；参见案例 [AVC]。虽然“硬”和“渐进”解码器刷新点在本规范的范围内都是可接受的，但在大多数情况下，用户体验将受益于使用“硬”解码器刷新点。
解码器刷新点还包含在带内传送的图片层（或等效的，取决于视频压缩标准）之上的所有头部信息。例如，在 H.264 中，解码器刷新点包含参数集网络适配层 (NAL) 单元，这些单元生成解码后续切片/数据分区 NAL 单元所需的参数集（并且不会在带外传送）。
解码：重构媒体流的操作。
渲染：向用户呈现（部分）重建的媒体流的操作。
流细化：
从媒体流中删除一些数据包的操作。优选地，流细化是媒体感知的，这意味着按照与再现质量的相关性增加的顺序移除媒体分组。然而，即使采用媒体感知流细化，大多数媒体流在细化程度增加时也会迅速降低质量。媒体不感知流细化会导致更严重的质量下降。与转码相反，流细化通常被视为计算上的轻量级操作。
媒体：
经常使用（有时与比特率、流、发送方等术语结合使用）来标识转发 RTP 数据包流（携带编解码器数据）的内容，编解码器控制消息适用于该内容。
媒体流：
标有单个同步源 (SSRC) 的 RTP 数据包流携带媒体（在某些情况下还可以修复信息，例如重传或前向纠错 (FEC) 信息）。
总媒体比特率：
媒体流中每秒传输的总比特数，在观察者选择的协议层测量，并在合理的时间尺度上取平均值，其长度取决于应用程序。通常，媒体发送方和媒体接收方将观察到同一流的不同总媒体比特率，首先是因为他们可能选择了不同的参考协议层，其次是因为沿传输路径的每个数据包开销的变化。比特率平均的目标是能够忽略由调度或链路层分组化效应引入的非常短的时间尺度（例如，低于 100 毫秒）的任何突发性。
最大总媒体比特率：
特定接收器处的给定媒体流及其所选协议层的总媒体比特率上限。请注意，无法在接收到的媒体流上测量此值。相反，它需要通过其他方式来计算或确定，例如服务质量 (QoS) 协商或本地资源限制。另请注意，该值是平均值（在对应用程序合理的时间尺度上），并且它可能与媒体流中的数据包看到的瞬时比特率不同。
高架：
将带有媒体数据的数据包从发送方传送到接收方，从应用层向下到预定义的协议级别（例如，向下到并包括 IP 标头）所需的所有协议标头信息。开销可以包括例如 IP、UDP 和 RTP 报头、任何第 2 层报头、任何贡献源 (CSRC)、RTP 填充和 RTP 报头扩展。开销不包括任何 RTP 负载头和负载本身。
净媒体比特率：
媒体流承载的比特率，扣除开销。也就是说，每秒比特数由编码媒体、任何适用的有效载荷标头以及放置在 RTP 数据包中的任何直接关联的元有效载荷信息计算。后者的典型例子是使用 RFC 2198 [RFC2198] 提供的冗余数据。请注意，与总媒体比特率不同，净媒体比特率在媒体发送方和媒体接收方将具有相同的值，除非发生了任何媒体混合或转换。
对于给定的观察者，媒体流的总媒体比特率等于净媒体比特率和上面定义的每个数据包开销的总和乘以数据包速率。
可行区域：
分组速率和净媒体比特率的所有组合的集合，这些组合不超过给定媒体发送方收到的临时最大媒体流比特率请求 (TMMBR) 消息施加的最大媒体比特率限制。当接收到新的 TMMBR 消息时，可行区域将发生变化。
边界集：
从给定媒体发送方接收的所有元组中选择的 TMMBR 元组集，定义了该媒体发送方的可行区域。媒体发送器使用诸如第 3.5.4.2 节中的算法来确定或迭代近似当前边界集，并在临时最大媒体流比特率通知 (TMMBN) 消息中将设置返回给媒体接收器。
2.3.拓扑
请参考 [RFC5117] 进行深入讨论。本备忘录中提到的拓扑结构标记如下（与[RFC5117]一致）：
拓扑点对点 . . . .点对点通信
拓扑多播 . . . . . .组播通信
拓扑转换器 . . . . . .基于翻译
拓扑混合器 . . . . . . . .基于混合器
拓扑-RTP-开关-MCU . . . . RTP流切换MCU
拓扑-RTCP-终止-MCU...混合器但终止 RTCP
3. 动机
本节讨论不同视频和媒体控制消息的动机和用途。视频控制消息已经讨论了很长时间，并起草了一份需求文档[Basso]。该文件已过期；但是，我们引用其中的相关部分来提供动机和要求。
3.1.用例
建议的反馈消息有多种可能的用途。让我们先看看 Basso 等的用例。 一些用例已经过重新制定并添加了评论。
1. RTP 视频混合器将多个编码视频源组合成单个编码视频流。每次添加视频源时，RTP混合器都需要向视频源请求解码器刷新点，以便在新视频源的数据所占据的混合画面的空间区域上启动未损坏的预测链。
2. RTP 视频混合器接收来自会议参与者的多个编码 RTP 视频流，并动态选择其中一个流包含在其输出 RTP 流中。在比特流发生变化时（通过语音激活或用户界面等方式确定），混合器向远程源请求解码器刷新点，以避免将不相关的内容用作图像间预测的参考数据。
请求解码器刷新点后，视频混合器停止传递当前 RTP 流并监视来自新源的 RTP 流，直到它检测到属于解码器刷新点的数据。那时，RTP 混合器开始将新选择的流转发到接收器。
3. 应用程序需要向远程编码器发出信号，表明时间和空间分辨率之间的所需权衡已经改变。例如，一个用户可能更喜欢较高的帧速率和较低的空间质量，而另一位用户可能更喜欢相反的情况。
这种选择也高度依赖于内容。许多当前的视频会议系统在用户界面中提供了一种进行这种选择的机制，通常采用滑块的形式。该机制有助于点对点、集中式多点和非集中式多点使用。
4. Basso 文档的用例 4 仅适用于 AVPF [RFC4585] 中定义的图像丢失指示 (PLI)，此处不再复制。
5. Basso 文档的用例 5 涉及一种称为“冻结图片请求”的机制。通过不可靠的前向 RTCP 通道发送冻结图片请求已被识别为有问题。因此，本备忘录中未包含冻结图片请求，此处不再复制用例讨论。
6. 视频混合器动态地选择接收到的视频流之一发送给参与者，并尝试向所有参与者提供可能的最高比特率，同时最小化流传输速率。实现这一点的一种方法是使用每个端点接受的最大比特率与端点建立会话，并由混合器使用的呼叫准入方法接受。通过减少最大媒体的命令
流比特率低于会话建立期间协商的比特率，混合器可以将端点发送的最大比特率降低到所有接受比特率中的最低值。
当最低接受比特率因端点加入和离开或由于网络拥塞而发生变化时，混合器可以调整端点可以发送其流的限制以匹配新值。然后混合器请求一个新的最大比特率，该比特率等于或小于在会话建立时为特定媒体流协商的最大比特率，并且远程端点可以用它可以支持的实际比特率进行响应。
Basso 等人绘制的图片涵盖了我们预见的大多数应用。但是，我们想用两个额外的用例来扩展列表：
7. 当前部署的拥塞控制算法（AIMD 和 TCP 友好速率控制 (TFRC) [RFC3448]）探测额外的可用容量，只要有东西要发送。对于使用数据包丢失作为拥塞指示的拥塞控制算法，由于数据包丢失和延迟增加，这种探测通常会导致媒体质量降低（通常达到失真大到足以使媒体无法使用的程度）。
在许多部署场景中，尤其是蜂窝部署场景中，瓶颈链路通常是最后一跳链路。该蜂窝链路通常还具有某种类型的 QoS 协商，使蜂窝设备能够了解最后一跳上可用的最大比特率。在大多数（如果不是全部）情况下，该链路后面的媒体接收器至少可以计算其当前接收的每个媒体流可用的比特率的上限。这是如何完成的是一个实现细节，这里不讨论。
向传输方指示各种媒体流的最大可用比特率可以有益于防止该方探测超过已知硬限制的该流的带宽。对于蜂窝或其他移动设备，每个流的已知可用比特率（从链路比特率推导出）可能会快速变化，原因是切换到另一种传输技术、拥塞导致的 QoS 重新协商等。
为了使服务中断最小化，快速收敛是必要的，因此媒体路径信令是可取的。
8. 使用参考图片选择 (RPS) 作为容错工具于 1997 年作为 NEWPRED [NEWPRED] 引入，现在已广泛部署。当使用 RPS 时，简单地说，接收方可以向发送方发送反馈消息，指示应该用于未来预测的参考图片。 （[NEWPRED] 也提到了其他形式的反馈。）AVPF 包含一种用于传达此类消息的机制，但没有指定消息应符合哪种编解码器以及根据哪种语法。最近，ITU-T 最终确定了 Rec. H.271，其中（在其他消息类型中）还包括反馈消息。预计此反馈信息将很快得到广泛支持。因此，根据 H.271 传送反馈消息的机制似乎是可取的。
3.2.使用媒体路径
我们为编解码器控制消息使用媒体路径有两个原因。
首先，采用 MCU 的系统通常将控制和媒体处理部分分开。由于这些消息旨在或由媒体部分而不是 MCU 的信令部分生成，因此将它们放在媒体路径上可以避免跨接口传输以及信令和处理之间不必要的控制流量。如果 MCU 被物理分解，媒体路径的使用避免了对媒体控制协议扩展的需要（例如，在媒体网关控制（MEGACO）[RFC3525]中）。
其次，信令路径通常包含多个信令实体，例如 SIP 代理和应用服务器。
由于多种原因，避免通过信令实体避免了延迟。代理的延迟要求不如媒体处理那么严格，并且由于其复杂和更通用的特性，可能会导致显着的处理延迟。信令实体的拓扑位置通常也不是针对最小延迟进行优化，而是针对其他架构目标进行优化。因此，在地理和延迟意义上，信令路径可以明显更长。
3.3.使用 AVPF
AVPF 反馈消息框架 [RFC4585] 提供了适当的框架来实现新消息。 AVPF 实施控制反馈消息时间的规则，以避免通过 RTCP 流量造成网络泛洪造成拥塞。我们通过引用 AVPF 来重用这些规则。
AVPF 的信令设置允许在 RTP 会话的基础上配置或协商每种单独的功能类型。
3.3.1.可靠性
RTCP 消息的使用意味着每个消息传输都是不可靠的，除非低层传输提供可靠性。本规范中提出的不同消息在可靠性方面有不同的要求。但是，在所有情况下，都指定了对（偶尔）反馈消息丢失的反应。
3.4.组播
编解码器控制消息可能与多播一起使用。 [RFC3550]和[RFC4585]中规定的RTCP定时规则确保消息不会导致RTCP连接过载。使用多播可能会导致接收到语义不一致的消息。对不一致的反应取决于消息类型，并针对每种消息类型分别进行讨论。
3.5.反馈信息
本节描述了不同反馈消息的语义以及它们如何应用于不同的用例。
3.5.1.完整的内部请求命令
指定媒体发送方接收到完整帧内请求 (FIR) 命令时，要求媒体发送方尽早发送解码器刷新点（参见第 2.2 节）。这种机会的评估包括当前的编码器编码策略和当前可用的网络资源。
FIR也称为“瞬时解码器刷新请求”、“快速视频更新请求”或“视频快速更新请求”。
使用解码器刷新点意味着避免使用在该点之前发送的任何图片作为流中发送的任何后续图片的编码过程的参考。对于非视频的预测媒体类型，模拟适用。例如，如果在 MPEG-4 系统中使用场景更新，则解码器刷新点由场景的完整表示组成，而不是相对于先前更新进行增量编码。
解码器刷新点，尤其是帧内或 IDR 图片，通常比预测图片大几倍。因此，在可用比特率较小的情况下，解码器刷新点的使用意味着明显长于典型图片持续时间的延迟。
可以在多播中使用；但是，建议对命令进行聚合。在发送解码器刷新点后密切接收请求的接收器——在已知最长往返时间 (RTT) 的 2 倍内，加上任何 AVPF 引起的 RTCP 数据包发送延迟——应等待第二个请求消息，以确保媒体先前交付的解码器刷新点尚未为接收器提供服务。指定延迟的原因是为了避免发送不必要的解码器刷新点。一个会话参与者可能已经发送了自己的请求，而另一个参与者的请求正在发送给他们。抑制那些可能在不了解其他请求的情况下发送的请求可以避免此问题。
明确禁止使用 FIR 命令从错误中恢复，而应使用 AVPF [RFC4585] 中定义的 PLI 消息。 PLI 消息报告丢失的图片，并且正是为此目的而将其包含在 AVPF 中。
完整的内部请求适用于用例 1 和 2。
3.5.1.1.可靠性
FIR 消息导致传送解码器刷新点，除非消息丢失。解码器刷新点很容易从比特流中识别出来。
因此，不需要协议级别的通知，简单的命令重复机制就足以保证所需的可靠性级别。然而，重复的潜在用途确实需要一种机制来防止接收者响应已经接收和响应的消息。
为了确保最佳可能的可靠性，FIR 的发送者可能会重复 FIR，直到接收到所需的内容。重复间隔由适用于会话的 RTCP 计时规则确定。在接收到完整的解码器刷新点或检测到尝试发送解码器刷新点（由于数据包丢失而损坏）时，必须停止 FIR 的重复。
如果需要另一个 FIR，则必须增加请求序列号。一个 FIR 发送方在会话中的每个媒体发送方任何时候都不得有超过一个未完成的 FIR（不同的请求序列号）。
FIR 的接收器（即媒体发送器）以互补方式运行以确保传送解码器刷新点。如果它在发送一个解码器刷新点后收到超过 2*RTT 的 FIR 重复，它应该发送一个新的解码器刷新点。两个往返时间允许解码器刷新点返回到请求者以及FIR 的重复结束到达并被媒体发送者检测到的时间。
从媒体接收器接收 FIR 的 RTP 混合器或 RTP 切换 MCU 负责确保将解码器刷新点传送到请求接收器。混频器/MCU 可能需要生成 FIR 命令。从可靠性的角度来看，两个分支（FIR 请求端点到混频器/MCU，混频器/MCU 到解码器刷新点生成端点）彼此独立处理。
3.5.2.时空权衡请求和通知
时空权衡请求 (TSTR) 指示视频编码器更改其时空分辨率之间的权衡。从 0 到 31 的索引值单调地表示需要更高的帧速率。也就是说，请求索引为 0 的请求者更喜欢高质量并愿意接受低帧率，而请求索引为 31 的请求者希望获得高帧率，这可能以低空间质量为代价。
通常，编码器反应时间可能比典型的画面持续时间长得多。有关示例，请参见用例 3。编码器决定请求是否以及在多大程度上导致权衡的改变。它返回一个时间-空间权衡通知 (TSTN) 消息以指示它将在以后使用的权衡。
引入 TSTR 和 TSTN 主要是因为人们认为控制协议机制（例如 SIP 重新邀请）太重且太慢，无法提供合理的用户体验。例如，考虑远程用户使用滑块选择时间/空间权衡的用户界面。合理的用户体验需要对任何滑块移动的即时反馈。
SIP re-INVITE [RFC3261] 至少需要多两次往返（与 TSTR/TSTN 机制相比），并且可能涉及代理和其他复杂机制。即使在设计良好的系统中，最终选择新的权衡也可能需要一秒钟左右的时间。
此外，RTCP 的使用非常有效地解决了多播用例。
在多点场景中使用 TSTR 和 TSTN 是一个重要的主题，可以通过许多特定于实现的方式来实现。
问题源于这样一个事实，即 TSTR 通常会不同步地到达，并且可能会为相同的流和/或端点编码器请求不同的权衡值。本备忘录没有指定翻译者、混合者或端点对 TSTR 中传达的建议权衡的接收的反应。我们只要求 TSTR 消息的接收者通过发送 TSTN 来回复它，携带由其自己的标准选择的新权衡（可能基于也可能不基于 TSTR 传达的权衡）。换句话说，在 TSTR 中发送的权衡是一个非约束性的建议，仅此而已。
根据 [RFC5117] 中描述的拓扑结构，需要区分三种 TSTR/TSTN 场景。以下小节描述了这些场景。
3.5.2.1.点对点
在这种最简单的情况下（拓扑点对点），媒体发送器通常根据 TSTR 中的请求值调整其时间/空间权衡，这取决于其自身的能力。 TSTN 消息传送回新的权衡值（例如，如果发送方无法调整其权衡，则该权衡值可能与旧值相同）。
3.5.2.2.使用多播或转换器的点对多点
RTCP 多播与根据 Topo-Multicast 的媒体多播一起使用，或根据 Topo-Translator 遵循 RFC 3550 的转换器模型。在这些情况下，可能会收到来自不同接收方的未同步 TSTR 消息，可能需要进行不同的权衡（因为用户偏好不同）。本备忘录未指定媒体发送方如何调整其权衡。可能的策略包括选择收到的所有权衡请求的平均值或中位数，优先考虑某些参与者，或继续使用先前选择的权衡（例如，当发送方无法调整时）。同样，所有 TSTR 消息都需要由 TSTN 确认，并且传回的值必须反映做出的决定。
3.5.2.3.使用 RTP 混合器的点对多点
在这种情况下（拓扑混合器），RTP 混合器接收所有 TSTR 消息，并有机会根据自己的标准对它们采取行动。在大多数情况下，混合器应该对来自不同参与者的潜在冲突 TSTR 消息形成“共识”，并向媒体发送者发起自己的 TSTR 消息。与之前的场景一样，形成这种“共识”的策略取决于实现，例如，可以包括平均参与者的请求值、优先考虑某些参与者或使用会话默认值。
即使混合器或翻译器执行转码，也很难以所请求的权衡交付媒体，除非混合器或翻译器接收的内容已经接近该权衡。因此，如果混音器改变了它的权衡，它需要通过创建自己的 TSTR 来请求媒体发送者使用新值。在对使用的权衡做出决定后，它会将该值包含在对下游请求者的确认中。只有在原始源具有更高质量（和比特率）的情况下，单独转码才有可能导致所请求的权衡。
3.5.2.4.可靠性
规定了请求和接收确认机制。时间-空间权衡通知 (TSTN) 消息通知请求者它的请求已被接收，以及此后使用什么权衡。至少出于以下原因，需要这种确认机制：
o 不能直接从媒体比特流中识别权衡的变化。
o 根据媒体发送者的限制，在不知道选择的权衡值的情况下无法实施用户反馈。
o 可以避免重复发送请求无法实现的权衡的消息。
3.5.3. H.271 视频反向通道消息
ITU-T 建议书H.271 定义了语法、语义和建议的编码器对视频反向通道消息的反应。本备忘录中定义的结构用于将此类消息从媒体接收方透明地传送到媒体发送方。在本备忘录中，我们避免深入讨论 H.271 中的可用代码点，而是参考规范文本 [H.271]。
但是，我们注意到一些 H.271 消息与 AVPF 和本备忘录的本地消息具有相似性。此外，我们注意到一些 H.271 消息已知在多播环境中需要谨慎——或者在多播或多点场景中显然不可用。表 1 简要概述了 H.271 中当前定义的消息、它们大致对应的 AVPF 或编解码器控制消息 (CCM)（本备忘录中指定的后者），以及我们目前对其多播安全性的了解。
注意：H.271 消息类型 0 不是严格等同于 AVPF 的参考图片选择指示 (RPSI)；它是解码器处已知正确参考图片的指示。它不命令编码器使用定义的参考图片（预想在 RPSI 中携带的控制信息的形式）。然而，人们相信并打算将 H.271 消息类型 0 用于与 AVPF 的 RPSI 相同的目的——尽管其他使用形式也是可能的。
为了响应 H.271 消息的不透明性，尤其是在多播安全方面，当实现希望使用 H.271 视频反向信道消息时，必须遵循以下指南：
1. 使用 H.271 反馈消息的实现必须遵守拥塞控制原则，如第 5 节所述。
2. 实现应该使用[RFC4585]和本备忘录中定义的IETF-native消息，而不是[H.271]中定义的类似消息。我们目前对类似消息的理解记录在上面的表 1 中。偏离上述 SHOULD 语句的一个很好的理由是，如果清楚地理解，对于给定的应用程序和视频压缩标准，上述“相似性”并未给出，与表中的内容相反。
3. 据观察，目前存在的一些 H.271 代码点不是多播安全的。因此，明智的做法是不要在多播环境中使用 H.271 反馈消息类型。只有当后面提到的所有问题都被实现者完全理解并被所有端点正确考虑时，才可以使用它。在所有其他情况下，H.271 消息类型绝不能与多播结合使用。
4. 已经观察到，即使在集中式多点环境中，理论上混合器应该能够解决如下所述的问题，但这种混合器和协作端点的实现是一项非常困难和乏味的任务。因此，H.271 消息不得用于集中式多点场景，除非实现者完全理解下面提到的所有问题，并且混合器和端点都正确考虑了这些问题。
在多点环境中考虑使用 H.271 时要考虑的问题：
1. 不同接收器上的不同状态。在许多环境中，无法保证所有媒体接收器的解码器状态在任何给定时间点都相同。这种可能的状态未对准的最明显原因是仅在到许多媒体接收器之一的路径上发生的丢失。但是，还有其他不那么明显的原因，例如最近加入多点会议（通过加入多播组或通过额外的混合器输出）。不同的状态可能导致媒体接收器发出潜在矛盾的 H.271 消息（或一个媒体接收器发出的 H.271 消息，当媒体发送器观察到时，对其他媒体接收器没有帮助）。媒体发件人对这些相互矛盾的消息的天真反应可能会导致不可预测和令人讨厌的结果。
2. 在媒体发送器中组合来自不同媒体接收器的消息是一项非常重要的任务。作为原因，我们注意到这些消息可能相互矛盾，并且它们的传输不可靠（很可能还有其他原因）。在许多 H.271 消息（即类型 0、2、3 和 4）的情况下，用于组合的算法必须了解网络/协议环境（即，关于拥塞）和所采用的媒体编解码器，因为给定类型的 H.271 消息对于不同的媒体编解码器可以具有不同的语义。
3. 请求的抑制可能需要超出 AVPF 中描述的基本机制（这些机制完全由协议级别的时序和传输考虑驱动）。例如，基于从媒体流接收的信息，接收器通常需要避免（或延迟）生成请求。例如，当 Intra/IDR 图片的传输正在进行时，接收器发出 FIR 是没有意义的。
4. 当在较大的多播组中使用非多播安全消息（例如，H.271 类型 0 接收图片/切片的肯定 ACK）时，媒体接收器可能会被迫延迟甚至省略发送这些消息。对于媒体发送者来说，这看起来像是数据没有被正确接收（尽管它被正确接收），并且一个天真的实现的媒体发送者对这些不应该出现的问题做出了反应。
3.5.3.1.可靠性
H.271 视频反向信道消息不需要可靠传输，消息接收的确认可以从前向视频比特流中导出。因此，没有指定特定的接收确认。
关于重发规则，3.5.1.1 节适用。
3.5.4.临时最大媒体流比特率请求和通知
接收器、翻译器或混合器使用临时最大媒体流比特率请求（TMMBR，“木材”）来请求发送者将媒体流的最大比特率（参见第 2.2 节）限制为或低于提供的值.临时最大媒体流比特率通知 (TMMBN) 包含媒体发送方对其已接收的 TMMBR 定义限制的最大限制子集的当前视图，以帮助参与者抑制不会进一步限制媒体发送方的 TMMBR。 TMMBR/TMMBN 消息的主要用途是在具有 MCU 或混合器（用例 6）的场景中，对应于拓扑转换器或拓扑混合器，但也适用于拓扑点对点。
媒体流上的每个临时限制都表示为一个元组。元组的第一个组成部分是媒体接收器当前准备接受该媒体流的最大总媒体比特率（如第 2.2 节中所定义）。第二个组成部分是媒体接收器在其选择的参考协议层为该媒体流观察到的每个数据包的开销。
如第 2.2 节所述，由于使用不同的参考协议，TMMBR 的发送方（即媒体接收方）观察到的开销可能与 TMMBR 接收方（即媒体发送方）观察到的开销不同另一端的层或由于影响每个数据包开销量的转换器或混合器的干预。例如，在 IPv4 和 IPv6 之间转换的两者之间的网关会影响每个数据包的开销 20 字节。其他改变开销的机制包括隧道。 [RFC3890] 中也讨论了不同开销的问题。正如将在使用 TMMBR 的算法的描述中看到的那样，发送端和接收端之间感知开销的差异不存在困难，因为计算是根据在发送端和接收端具有相同值的变量进行的-- 例如，数据包速率和净媒体速率。
报告最大总媒体比特率和每个数据包的开销允许不同的接收器为不同的协议层提供比特率和开销值，例如，在 IP 层、在隧道协议的外部或在链路层。对等点报告的协议级别取决于对等点的集成级别，因为它需要能够从该协议级别提取信息。例如，一个不知道它正在运行的 IP 版本的应用程序无法有意义地确定 IP 报头的开销，因此不希望在开销或最大总媒体比特率计算中包含 IP 开销。
预计大多数对等体至少能够报告 IP 层的值。在某些实现中，还包括与链路层有关的信息可能是有利的，这又允许更精确的开销计算和连接资源的更好优化。
临时最大媒体流比特率消息是可应用于任何 RTP 数据包流的通用消息。这将它们与本规范中定义的其他编解码器控制消息分开，后者仅适用于特定的媒体类型或有效载荷格式。 TMMBR 功能适用于传输，以及传输对媒体编码的要求。
下面的推理假设参与者已经使用信令协议协商了会话最大比特率。该值可以是全局的，例如，在点对点、多播或转换器的情况下。它也可以在参与者和对等方或混合器之间是本地的。在任一情况下，信令中协商的比特率是参与者保证能够处理（解包和解码）的比特率。实际上，参与者的连通性也会影响协商值——协商一个网络接口不支持的总媒体比特率没有多大意义。
为会话或发送方协商最大数据包速率也是有益的。 RFC 3890 提供了可用于此目的的 SDP [RFC4566] 属性；但是，该属性在使用 offer/answer [RFC3264] 建立的 RTP 会话中不可用。因此，本备忘录规定了一个可选的最大数据包速率信令参数。
已经建立的最大总媒体比特率可以在任何时候改变，受控制反馈消息发送的定时规则的约束。该限制可以更改为介于零和会话最大值之间的任何值，如会话建立信令期间协商的那样。然而，即使发送方收到了允许增加比特率的 TMMBR 消息，所有的增加也必须由拥塞控制机制控制。 TMMBR 仅表示已知限制，通常在本地环境中，并不提供有关完整路径的任何保证。此外，TMMBR 建立的比特率限制的任何增加都将仅在发送 TMMBN 消息后的一定延迟后执行，该消息通知世界有关限制的增加。延迟被指定为媒体发送方已知的最长 RTT 的至少两倍，加上媒体发送方根据 AVPF 计时规则计算的为该会话发送另一个 TMMBR 消息所需的等待时间。引入此延迟是为了允许其他会话参与者知道他们的比特率限制要求，该要求可能较低。
如果 TMMBR 指示的新值可能对会话的剩余部分有效，则 TMMBR 发送方应使用会话信令协议执行会话上限的重新协商。
3.5.4.1.使用 TMMBR 的媒体接收器的行为
本节是对第 4.2 节中更准确描述的行为的非正式描述。
媒体发送方开始会话时，会话受限于会话信令中协商的最大媒体比特率和最大数据包速率（如果有）。
请注意，此值可能会针对另一协议层进行协商，而不是参与者在其 TMMBR 消息中使用的协议层。每个媒体接收器选择一个参考协议层，在该参考层形成对它正在观察的开销的估计（如果还没有看到数据包，则估计它），并确定它可以接受的最大总媒体比特率，考虑到它自身的限制以及它可能意识到的任何传输路径限制。如果当前限制比会话信令中商定的限制更多，媒体接收器使用 TMMBR 消息向媒体发送器报告其对这两个数量的初始估计。通过在同一 TMMBR 消息中包含多个媒体发送者的元组的可能性，减少了整体消息流量。
媒体发送方应用 3.5.4.2 节中指定的算法来选择它接收到的哪些元组最受限制（即，2.2 节中定义的边界集）。它修改其操作以保持在可行区域内（如第 2.2 节中所定义），并向媒体接收器发送一个 TMMBN，指示所选的边界集。该通知还表明谁对边界集中的元组负责，即限制的“所有者”。在边界集中不拥有元组的会话参与者称为“非所有者”。
如果媒体接收者不拥有 TMMBN 报告的边界集中的元组之一，则它应用与媒体发送者相同的算法来确定其当前估计的（最大总媒体比特率、开销）元组是否会进入边界集如果媒体发件人知道。如果是，它会发出 TMMBR 向发送者报告元组值。否则，它暂时不采取任何行动。
周期性地，它的估计元组值可能会改变，或者它可能会收到一个新的 TMMBN。如果是，它会重新应用算法来决定是否需要发布 TMMBR。
或者，如果媒体接收器拥有报告的边界集中的元组之一，则在其对自己的元组值的估计发生变化之前，它不会采取任何行动。此时，它会向媒体发送方发送 TMMBR 以报告更改的值。
媒体接收器可以在一个 TMMBN 消息和下一个之间的边界元组的所有者和非所有者之间改变状态。因此，它必须检查每个 TMMBN 的内容以确定其后续操作。
实现可以使用他们选择的其他算法，只要由 TMMBR 和 TMMBN 消息交换产生的比特率限制至少与使用 TMMBR 和 TMMBN 消息产生的比特率限制一样严格（至少在比特率维度上一样低）上述算法。
显然，在点对点的情况下，当只有一个媒体接收器时，这个接收器一旦接收到第一个 TMMBN 以响应其自己的 TMMBR 就成为“所有者”，并在会话的其余部分保持“所有者”。因此，当知道总是只有一个媒体接收器时，就不需要上述算法。
知道他们是会话中唯一的媒体接收器可以随时发送比特率限制高于和低于先前通知限制的 TMMBR 消息（受 AVPF [RFC4585] RTCP RR 发送定时规则的约束）。然而，会话参与者可能难以确定它是否是会话中的唯一接收者。因此，任何 TMMBR 的实现都需要包含下一节中描述的算法或更严格的等效算法。
3.5.4.2.建立电流限制的算法
本节介绍用于计算会话限制的示例算法。可以采用其他算法，只要计算结果至少与通过该算法获得的结果一样具有限制性。
首先，重要的是要考虑使用元组来限制媒体发送者的行为的含义。比特率和开销值导致计算媒体流比特率的二维解空间。幸运的是，这两个变量是相互关联的。具体来说，RTP 有效载荷可用的比特率等于 TMMBR 报告的比特率减去使用的数据包速率，再乘以 TMMBR 报告的转换为比特的开销。因此，当需要考虑不同的比特率/开销组合时，数据包速率决定了正确的限制。这也许最好用一个例子来解释：
对于给定的数据包速率 (PR)，RTP 中媒体有效载荷可用的比特率将是：
对于 PR = 20，这些计算将产生 Max_net media_BR_A = 28600 bps 和 Max_net media_BR_B = 30400 bps，这表明接收器 A 是此数据包速率的限制之一。 然而，在某个 PR 有一个切换点，在该点接收器 B 成为限制接收器。 可以通过设置 Max_media_BR_A 等于 Max_media_BR_B 并打破 PR 来识别切换点：
对于上面的数字，它产生 31.25 作为两个限制之间的转换点。也就是说，对于低于每秒 31.25 的数据包速率，接收器 A 是限制接收器，而对于更高的数据包速率，接收器 B 更具限制性。将要控制媒体编码及其分组化的实现必须考虑这种行为的含义。如上所述，多个 TMMBR 限制可以应用于净媒体比特率和数据包速率之间的权衡。适用的限制取决于所考虑的数据包速率。
这也对 TMMBR 机制需要如何工作有影响。
首先，存在多个 TMMBR 元组对媒体发送方提供限制的可能性。其次，任何会话参与者（媒体发送方和接收方）都需要能够确定给定的元组是否会成为对媒体发送方的限制，或者已经给定的限制集是否比给定的值更严格。如果无法做出此决定，则 TMMBR 的抑制将不起作用。
该算法的基本思想如下。每个 TMMBR 元组可以看作是一条直线的方程（参见方程 (1) 和 (2)），其中数据包速率位于 X 轴，净比特率位于 Y 轴。对应于完整 TMMBR 元组集的线集的下包络连同 X 和 Y 轴，定义了一个多边形。位于该多边形内的点是满足所有 TMMBR 约束的数据包速率和比特率的组合。该区域内的最高可行包速率是边界多边形与 X 轴相交的速率或由信令提供的会话最大包速率（SMAXPR，以每秒包数为单位）中的最小值，如果有的话。典型地，媒体发送者更愿意以比该理论最大值更低的速率操作，以便增加实际媒体内容到达接收器的速率。该算法的目的是区分构成边界集的 TMMBR 元组，从而划定可行区域，以便媒体发送方可以在该区域内选择其首选操作点
下面的图 1 显示了由 TMMBR 元组 A 和 B 形成的边界多边形。第三个元组 C 位于边界多边形之外，因此与确定媒体速率和数据包速率之间的可行权衡无关。标记为 ss..s 的线代表限制
由会话建立期间通过信令获得的会话最大数据包速率 (SMAXPR) 施加的数据包速率。在图 1 中，由元组 B 确定的限制恰好比 SMAXPR 更具限制性。
情况很容易反过来，这意味着边界多边形在右侧由表示 SMAXPR 约束的垂直线终止。
请注意，随着数据包速率增加的方向移动，构成边界多边形的线的斜率越来越负。 另请注意，稍作重新排列后，等式 (1) 和 (2) 具有规范形式：
其中 m 是斜率，其值等于元组开销的负值（以比特为单位），b 是 y 截距，其值等于元组最大总媒体比特率。
这些观察得出的结论是，在处理 TMMBR 元组以选择初始边界集时，应该按照开销增加的顺序对元组进行排序和处理。一旦将特定元组添加到边界集中，就可以消除所有尚未选择且开销较低的元组，因为边界多边形的下一条边必须比边界多边形的下边更陡峭（即，相应的 TMMBR 必须具有更高的开销）最新添加的元组。
图 1 中的 cc..c 线说明了另一个原理。这条线与线 aa..a 平行，但具有更高的 Y 轴截距。也就是说，对应的 TMMBR 元组包含更高的最大总媒体比特率值。由于线 cc..c 在边界多边形之外，它说明了以下结论：如果两个 TMMBR 元组具有相同的开销值，则最大总媒体比特率值较高的那个不能成为边界集的一部分，可以放在一边。
两个进一步的观察完成了算法。显然，从左边开始，边界多边形的连续角（即，连续对边之间的交点）处于连续更高的分组速率。另一方面，再次从左侧移动，构成边界集的每条连续线以较低的数据包速率穿过 X 轴。
现在可以指定完整的算法。该算法使用两个 TMMBR 元组列表，候选列表 X 和选定列表 Y，它们都按增加的开销值排序。当 X 的所有成员都被丢弃或移除进行处理时，算法终止。在算法完成之前，所选列表 Y 的成员资格是试用的。所选列表的每个成员都与一个交集值相关联，该值是对应于该 TMMBR 元组的线与对应于所选列表中前一个 TMMBR 元组的线相交的数据包速率。所选列表的每个成员还与最大数据包速率值相关联，该值是会话最大数据包速率 SMAXPR（如果有）和对应于该元组的线穿过 X 轴的数据包速率中的较小者。
当算法终止时，所选列表等于第 2.2 节中定义的边界集。
初始算法
当媒体发送方接收到一个或多个 TMMBR 并且在第一次确定边界集之前，它会使用该算法。
1. 按开销增加的顺序对 TMMBR 元组进行排序。这是初始候选列表 X。
2.当候选列表中的多个元组具有相同的开销值时，丢弃除最大总媒体比特率值最低的那个之外的所有元组。
3.从候选列表中选择并移除具有最低最大总媒体比特率值的TMMBR元组。如果具有该值的元组不止一个，则选择开销值最高的元组。这是所选列表 Y 的第一个成员。将其交集值设置为零。计算其最大包速率为SMAXPR（如果可用）的最小值和从以下公式获得的值，即对应线与X轴交叉的包速率。
4. 从候选列表中丢弃开销值低于所选元组的所有元组。
5. 从候选列表中移除第一个剩余的元组进行处理。称其为当前候选人。
6.使用等式(3)计算当前候选者生成的行与所选列表Y中的最后一个元组生成的行的交点处的分组速率PR。
7、如果计算出的值PR等于或小于为所选列表的最后一个元组存储的交集值，则丢弃所选列表的最后一个元组并返回步骤6（保留相同的当前候选）。
请注意，步骤 3 中所选列表 Y 的初始成员的选择保证了所选列表永远不会被此过程清空，这意味着该算法必须最终（如果不是立即）落入第 8 步。
8.（当计算出当前候选的PR值大于当前选择列表Y的最后一个成员的交集值时，到达此步骤。）如果计算出的当前候选的PR值小于最大包速率与所选列表中的最后一个元组关联，将当前候选元组添加到所选列表的末尾。将 PR 存储为其交集值。将其最大数据包速率计算为 SMAXPR（如果可用）和使用等式 (4) 计算的最大数据包速率中的较小者。
9. 如果候选列表中仍有任何元组，请返回步骤 5。
增量算法
先前的算法涵盖了初始情况，其中先前未创建选定列表。它也仅适用于媒体发件人。当先前创建的选定列表在媒体发送方或媒体接收方可用时，可以考虑另外两种情况：
o 当当前不在所选列表中的 TMMBR 元组是添加的候选时；
o 当前在选定列表中的 TMMBR 元组中的值发生变化时。
在媒体接收器处，这些情况分别对应于 TMMBN 报告的边界集中元组的非所有者和所有者的情况。
在任一情况下，更新选定列表以考虑新的/更改的元组的过程可以使用上述基本算法，修改为初始候选集仅由现有的选定列表和新的或更改的元组组成。通过利用以下观察结果，一些进一步的优化是可能的（除了从减少的候选集开始）。
第一个观察结果是，如果新的/更改的候选者成为新选择列表的一部分，结果可能是导致从列表中删除零个或多个其他元组。但是，如果删除了多个其他元组，则删除的元组将是连续的。这可以通过可视化一条新线来从几何上确认，该线从先前存在的边界中切断了一系列线段
多边形。截断的段一个接一个地连接，几何等价于按开销值排序的列表中的连续元组。除了任一方向的删除集之外，先前选择的列表中的所有元组都将位于更新的元组中。第二个观察结果是，撇开新的候选者不谈，在更新的选定列表中剩余的元组的顺序没有改变，因为它们的开销值没有改变。
这两个观察的结果是，一旦确定了新候选者的位置和删除的元组集（如果有的话）的范围，剩余的元组可以直接从候选者列表复制到选择的列表中，保留他们的顺序。该结论提出以下改进算法：
o 运行基本算法的步骤 1-4。
o 如果新候选人在第 2 步和第 4 步中幸存下来并成为所选列表的第一个新成员，则对后续候选人运行步骤 5-9，直到将另一个候选人添加到所选列表中。然后将所有剩余的候选者移动到选定的列表中，保留它们的顺序。
o 如果新候选者在第 2 步和第 4 步中幸存下来并且没有成为所选列表的新的第一个成员，则首先将候选列表中开销值低于新候选者的所有元组移动到所选列表中，保留它们命令。对新候选者运行步骤 5-9，修改后必须即时计算所选列表中元组的交集值和最大数据包速率，因为它们之前没有存储。继续处理直到后续元组被添加到所选列表中，然后将所有剩余的候选者移动到所选列表中，保持它们的顺序。
请注意，新的候选项可以添加到选定的列表中，但在处理下一个元组时会再次删除。可以很容易地看出，在这种情况下，新候选者不会替换所选列表中任何较早的元组。 ASCII 艺术的局限性使其难以在图中显示。如果图 1 中的线 cc..c 具有更陡峭的斜率（元组 C 具有更高的开销值），但仍然与线 aa..a 相交，超出了线 aa..a 与线 bb..b 相交的位置，那么它就是一个示例。
刚刚描述的算法是近似的，因为它没有考虑所选列表之外的元组。要了解这些元组如何变得相关，请考虑图 1，并假设元组 A 中的最大总媒体比特率增加到线 aa..a 移到线 cc..c 之外的点。元组 A 将保留在媒体发送者计算的边界集中。然而，一旦它发出新的 TMMBN，媒体接收器 C 将应用该算法并发现它的元组 C 现在应该进入边界集。它将向媒体发送方发出 TMMBR，媒体发送方将重复计算并得出适当的结论。
第 4.2 节的规则要求媒体发送方在媒体接收方有机会响应 TMMBN 之前不要提高其发送速率。在刚刚给出的示例中，此延迟确保元组 A 的松弛实际上不会导致尝试以超过 C 处容量的速率发送媒体。
3.5.4.3.在基于混合器的多点操作中使用 TMMBR
假设一个基于混合器的小型多方会议正在进行，如 [RFC5117] 的 Topo-Mixer 中所述。所有参与者都协商了此会话可以使用的公共最大比特率。会议在参与者和混音器之间的多个单播路径上运行。这些路径中每条路径上的拥塞情况都可以由相关参与者和混频器监控，例如利用 RTCP 接收器报告 (RR) 或传输协议，例如数据报拥塞控制协议 (DCCP) [RFC4340]。然而，任何给定的参与者都不知道与其他参与者的连接的拥塞情况。
更糟糕的是，如果没有与本文档中讨论的机制类似的机制，混频器（知道其管理的所有连接上的拥塞情况）没有标准化的方法来通知媒体发送者放慢速度，除了伪造自己的接收者报告（这是不可取的）。原则上，遇到这种情况的混频器必须对用于检测到拥塞的连接的流进行精简或转码。
在实践中，不幸的是，媒体感知流细化是一项非常困难和繁琐的操作，并且会增加不受欢迎的延迟。如果媒体不知道，它会很快导致无法接受的再现媒体质量。因此，即使在发送者到混频器的连接上没有拥塞的情况下，也需要一种减慢发送者速度的方法。
为了允许混合器在不执行转码的情况下限制各个链路上的流量，需要一种机制，使混合器能够要求参与者的媒体编码器限制他们当前生成的媒体流比特率。 TMMBR 提供了所需的机制。当混频器检测到自己和给定参与者之间的拥塞时，它会执行以下过程：
1. 它开始将流向拥塞参与者的媒体流量减少到支持的比特率。
2. 它使用 TMMBR 请求媒体发送方将他们发送给混频器的总媒体比特率降低到符合最慢链路拥塞控制原则的值。慢在这里指的是拥塞控制后可用的带宽/比特率/容量和包速率。
3. 一旦发送部分降低了比特率，混合器就隐式地停止流稀疏，因为一旦流符合拥塞控制就不需要它了。
使用流细化作为一种即时反应工具，然后是快速控制机制，这似乎是媒体质量和对抗拥塞的需要之间的合理折衷。
3.5.4.4.在使用多播或转换器的点对多点中使用 TMMBR
在这些拓扑中，对应于 Topo-Multicast 或 Topo-Translator，RTCP RR 是全局传输的。这允许所有参与者在中等时间尺度上检测传输问题，例如拥塞。由于所有媒体发送者都知道所有媒体接收的拥塞情况。
3.5.4.5. TMMBR 在点对点操作中的使用
在用例 7 中，当已知的比特率上限发生变化时，可以使用 TMMBR 来提高性能。在此用例中，信令协议为会话和总媒体比特率建立了上限。但是，在传输链路比特率降低的时候，接收端可以通过向发送端发送一个TMMBR来避免严重的拥塞。因此，TMMBR 可用于对应用程序施加限制，从而将拥塞控制机制置于正确的范围内。然而，TMMBR 通常无法提供真正拥塞控制所需的连续快速反馈回路。鉴于其不同的目的，它的语义也不匹配拥塞控制的语义。由于这些原因，TMMBR 不应用作拥塞控制的替代品。
3.5.4.6.可靠性
媒体发送方对 TMMBR 消息接收的反应不能通过媒体流的检查立即识别。
因此，需要更明确的机制来避免不必要的 TMMBR 消息重发。使用基于统计的重传方案只会为接收到的请求提供统计保证。它也不会避免已接收消息的重传。此外，它不允许轻易抑制其他参与者的请求。由于这些原因，使用了基于显式通知的机制。
在接收到 TMMBR 后，媒体发送方发送一个包含当前边界集的 TMMBN，并指示哪些会话参与者拥有该限制。在多播场景中，这允许所有其他参与者抑制他们可能有的任何请求，如果他们的限制没有当前的限制那么严格（即定义位于第 2.2 节中定义的可行区域之外的行）。仅保留和通知元组的边界集允许较小的消息大小和媒体发送者状态。媒体发送者只为边界组元组的当前所有者的 SSRC 保持状态；不会保存所有其他请求及其来源。一旦建立了边界集，新的 TMMBR 消息应该只由边界元组的所有者和其他实体生成（通过应用第 3.5.4.2 节或其等效的算法）他们的限制现在应该是边界集。
4. RTCP 接收器报告扩展
本备忘录指定了六个新的反馈消息。完整帧内请求 (FIR)、时空权衡请求 (TSTR)、时空权衡通知 (TSTN) 和视频反向信道消息 (VBCM) 是第 6.3 节中定义的“有效负载特定反馈消息” AVPF [RFC4585]。临时最大媒体流比特率请求 (TMMBR) 和临时最大媒体流比特率通知 (TMMBN) 是 AVPF 第 6.2 节中定义的“传输层反馈消息”。
新的反馈消息在以下小节中定义，其结构与 AVPF 规范 [RFC4585] 的 6.2 和 6.3 节中的结构相似。
4.1.扩展机制的设计原则
RTCP 最初被引入作为传达存在、接收质量统计和所需媒体编码提示的通道。在视频格式的早期 RTP 负载格式中引入了一组有限的媒体控制机制，例如，在 RFC 2032 [RFC2032]（已被 RFC 4587 [RFC4587] 废弃）。但是，该规范首次建议对其某些消息进行双向握手。存在这种引入可能被误解为使用 RTCP 作为 RTP 会话控制协议的先例的危险。为了防止这种误解，本小节试图澄清本备忘录中指定的扩展的范围，并强烈建议未来的扩展遵循此处阐明的基本原理，或令人信服地解释为什么它们偏离基本原理。
在本备忘录和 AVPF [RFC4585] 中，仅包含以下消息：
a) 具有比较严格的实时性约束，在大多数应用场景中阻止使用SIP重新邀请等机制（实时性约束在必要时针对每个消息单独说明）；
b) 是多播安全的，因为根据每个消息的需要，指定了对潜在矛盾反馈消息的反应；和
c) 与特定媒体编解码器、媒体编解码器类别（例如视频编解码器）或给定 RTP 数据包流的活动直接相关。
在本备忘录中，仅针对以下消息引入了双向握手：
a) 由于其性质，需要通知或确认。已针对每条消息单独执行了确定是否存在此要求的分析。
b) 通知或确认不能轻易地从媒体比特流中导出。
AVPF [RFC4585] 和本备忘录中的所有消息都以简单、固定的二进制格式呈现其内容。这适用于尚未在其媒体路径中实现更高控制协议功能（SDP、XML 解析器等）的媒体接收器。
不符合刚刚描述的设计原则的消息不适合使用 RTCP 或本文档中定义的编解码器控制框架。
4.2.传输层反馈消息
如 RFC 4585 [RFC4585] 的第 6.1 节所述，传输层反馈消息由 RTCP 数据包类型值 RTPFB(205) 标识。
在 AVPF 中，定义了一个此类消息。这份备忘录指定了另外两条这样的消息。它们通过反馈消息类型 (FMT) 参数进行标识，如下所示：
在 AVPF [RFC4585] 中分配：
1：通用NACK
31：为以后扩展标识符号空间保留
在本备忘录中分配：
2：保留（见下面的注释）
3：临时最大媒体流比特率请求（TMMBR）
4：临时最大媒体流比特率通知（TMMBN）
注意：AVPF [RFC4585] 的早期版本为后来被删除的代码点保留了 FMT=2。已经指出，在该领域中可能存在根据过期文档使用该值的实现。由于有足够的编号空间可用，我们将 FMT=2 标记为保留，以避免任何此类早期实现可能出现互操作性问题。
可分配：
0：未分配
5-30：未分配
以下小节分别定义了 TMMBR 和 TMMBN 消息的反馈控制信息 (FCI) 条目的格式，并指定了媒体发送方和接收方的相关行为。
4.2.1.临时最大媒体流比特率请求 (TMMBR)
临时最大媒体流比特率请求由 RTCP 数据包类型值 PT=RTPFB 和 FMT=3 标识。
临时最大媒体流比特率请求（TMMBR）消息的 FCI 字段应包含一个或多个 FCI 条目。
4.2.1.1.消息格式
反馈控制信息 (FCI) 由一个或多个 TMMBR FCI 条目组成，语法如下：
SSRC（32 位）：被请求遵守新的最大比特率的媒体发送方的 SSRC 值。
MxTBR Exp（6 位）：最大总媒体比特率值的尾数指数缩放。 该值是一个无符号整数 [0..63]。
MxTBR 尾数（17 位）：作为无符号整数的最大总媒体比特率值的尾数。
测量的开销（9 位）：测量的平均数据包开销值（以字节为单位）。 测量应根据第 4.2.1.2 节中的描述进行。 该值是一个无符号整数 [0..511]。
以每秒比特数为单位的最大总媒体比特率 (MxTBR) 值按以下方式从 MxTBR 指数 (exp) 和尾数计算得出：
这允许在 0 到 131072*2^63（大约 1.2*10^24）范围内的 17 位分辨率。
TMMBR 反馈消息的长度应设置为 2+2*N，其中 N 是 TMMBR FCI 条目的数量。
4.2.1.2. 语义
媒体接收器（TMMBR 的发送器）的行为。
TMMBR 用于指示作为媒体接收器的报告实体的传输相关限制。 TMMBR 具有包含两个组件的元组形式。 第一个值是媒体流的每个发送方的最高比特率，在接收方选择的协议层可用，接收方当前在此 RTP 会话中支持该协议层。 第二个值是在 2.2 节中定义的以字节为单位的测量报头开销，并在为流接收的数据包中在所选协议层测量。 开销的测量是一个运行平均值，该平均值针对此特定媒体源 (SSRC) 接收到的每个数据包进行更新，使用以下公式：
其中 avg_OH 是运行（指数平滑）平均值，而 pckt_OH 是在最新数据包中观察到的开销。
如果通过信令协商了最大比特率，则接收方在 TMMBR 消息中报告的最大总媒体比特率不得超过转换为公共基础的协商值（即，调整开销以使其具有相同的参考协议层）。
在反馈消息的公共包头（如[RFC4585]的第6.1节中定义）中，“包发送者的SSRC”字段指示请求的来源，“媒体源的SSRC”不使用，应设置到 0。在特定的 TMMBR FCI 条目中，FCI 字段中的“媒体源的 SSRC”表示该元组适用的媒体发送者。这在多播或转换器拓扑中很有用，其中报告实体可以使用多个 FCI 条目在单个 TMMBR 消息中寻址所有媒体发送器。
媒体接收方应保存从每个媒体发送方收到的最新 TMMBN 消息的内容。
在以下情况下，媒体接收者可以向特定媒体发送者发送 TMMBR FCI 条目：
o 在从该媒体发送方收到任何 TMMBN 消息之前；
o 当媒体接收器已被识别为从该媒体发送器接收的最新 TMMBN 消息中的边界元组的源时，并且最大总媒体比特率的值或与该媒体发送器相关的开销发生了变化；
o 当媒体接收器未被识别为从该媒体发送器接收的最新 TMMBN 消息中的边界元组的源时，并且在媒体接收器应用第 3.5.4.2 节或更严格的等效项中的增量算法后，媒体接收器的与该媒体发送者相关的元组被确定为属于边界集。
如果在传输下一个 RTCP 数据包时没有从媒体发送方接收到临时最大媒体流比特率通知 (TMMBN) FCI，则 TMMBR FCI 条目可以在后续 TMMBR 消息中重复。 TMMBR FCI 条目的比特率值可以从一个 TMMBR 消息更改为下一个。每次发送条目时，开销测量应更新为 avg_OH 的当前值。
如果预期 TMMBR 消息设置的值是永久的，则 TMMBR 设置方应该重新协商会话参数以反映使用会话建立信令的参数，例如 SIP 重新邀请。
媒体发送方（TMMBR 接收方）的行为
当它接收到包含与其相关的 FCI 条目的 TMMBR 消息时，媒体发送方应根据新信息使用初始或增量算法来确定元组的边界集。所使用的算法应至少与第 3.5.4.2 节中定义的相应算法一样严格。在进行这个计算之前，媒体发送者可以在一个小的时间间隔内（相对于 RTCP 发送时间间隔）累积 TMMBR。
一旦确定了元组的边界集，媒体发送方可以在这些元组描述的可行区域内使用数据包速率和净媒体比特率的任意组合来产生较低的总媒体流比特率，因为它可能需要解决一个拥堵情况或其他限制因素。有关更多讨论，请参阅第 5 节（拥塞控制）。
如果媒体发送方断定它可以增加最大总媒体比特率值，则它应在实际这样做之前等待足够长的时间，以允许媒体接收方在确定其元组属于边界时响应 TMMBN放。该延迟时间由以下公式估算：
其中 RTT 是媒体发送方已知的最长往返时间，T_Dither_Max 在 [RFC4585] 的第 3.4 节中定义。即使在点对点会话中，媒体发送方也必须遵守上述规则，因为不能保证参与者能够正确确定所有源是否共同位于单个节点中并进行协调。
TMMBN 消息应由媒体发送方在尽可能早的时间点发送，以响应自上次发送 TMMBN 以来收到的任何 TMMBR 消息。 TMMBN 消息指示在消息传输时计算出的一组边界元组和这些元组的所有者。
SSRC 可能会根据 RTP 会话参与者的默认规则超时，即媒体发送方在最近五个定期报告间隔内没有收到来自所有者的任何 RTP 或 RTCP 数据包。
SSRC 也可以明确地离开会话，参与者通过传输 RTCP BYE 数据包或使用外部信令信道来指示这一点。如果媒体发送方确定边界集中元组的所有者已离开会话，则媒体发送方应发送包含先前确定的边界元组集的新 TMMBN，但删除属于已离开所有者的元组。
当一个媒体发送者意识到它的传输路径比当前限制更严格时，它可以主动向自己发起 TMMBR 消息的等效消息。结果，正在发送指示媒体源本身为元组所有者的 TMMBN，从而避免来自其他参与者的不必要的 TMMBR 消息。但是，与任何其他参与者一样，当媒体发送方意识到更改的限制时，需要更改元组，并发送相应的 TMMBN。
讨论
由于 TMMBR 和 TMMBN 传输的不可靠特性，上述规则可能导致发送看似违反这些规则的 TMMBR 消息。此外，在多播场景中，可能发生多个“非拥有”会话参与者可能正确或错误地确定其元组属于边界集的情况。出于多种原因，这并不重要：
a) 如果 TMMBR 消息在传输中丢失，则媒体发送方发送新的 TMMBN 消息以响应其他媒体接收方，或者根本不发送新的 TMMBN 消息。在第一种情况下，媒体接收器应用增量算法，如果它确定它的元组应该是边界集的一部分，则发送另一个 TMMBR。在第二种情况下，它无条件地重复发送 TMMBR。无论哪种方式，媒体发送方最终都会获得所需的信息。
b) 类似地，如果一个 TMMBN 消息丢失，已经发送相应 TMMBR 的媒体接收器不会收到通知，并期望重新发送请求并触发另一个 TMMBN 的传输。
c) 如果多个相互竞争的 TMMBR 消息由不同的会话参与者发送，则可以应用该算法，将所有这些消息都考虑在内，并且由此产生的 TMMBN 为参与者提供他们的元组如何与有界集进行比较的更新视图。
d) 如果多个会话参与者碰巧同时发送具有相同元组组件值的 TMMBR 消息，那么将这些元组中的哪一个纳入边界集并不重要。失败的会话参与者将在应用该算法后确定其元组未进入边界集，因此将停止发送其 TMMBR。
考虑伪造 TMMBR 所涉及的安全风险很重要。参见第 6 节中的安全考虑。正如已经指出的，反馈消息可以在任何指定拓扑中的多播和单播会话中使用。
但是，对于具有大量参与者的会话，按照此机制的要求使用最小公分母可能不是最合适的操作过程。大型会话可能需要考虑其他方式来调整比特率以适应参与者的能力，例如将会话划分为不同的质量等级或使用其他一些实现比特率可扩展性的方法。
4.2.1.3.计时规则
在需要及时性的情况下，TMMBR 消息的第一次传输可以使用早期或立即反馈。请求消息的任何重复应该使用常规 RTCP 模式作为其传输时间。
4.2.1.4.在转换器和混音器中处理
媒体翻译器和混合器需要接收和响应 TMMBR 消息，因为它们是向接收器提供特定媒体流的链的一部分。混频器或翻译器可以本地作用于 TMMBR 并因此生成 TMMBN 以指示它已经这样做了。或者，在媒体翻译器的情况下，它可以转发请求，或者在混合器的情况下生成自己的请求并将其转发。在后一种情况下，混合器需要将 TMMBN 发送回原始请求者以指示它正在处理请求。
4.2.2.临时最大媒体流比特率通知 (TMMBN)
临时最大媒体流比特率通知由 RTCP 数据包类型值 PT=RTPFB 和 FMT=4 标识。
TMMBN 反馈消息的 FCI 字段可以包含零个、一个或多个 TMMBN FCI 条目。
4.2.2.1.消息格式
反馈控制信息 (FCI) 由零个、一个或多个 TMMBN FCI 条目组成，语法如下：
SSRC（32 位）：该元组的“所有者”的 SSRC 值。
MxTBR Exp（6 位）：最大总媒体比特率值的尾数指数缩放。该值是一个无符号整数 [0..63]。
MxTBR 尾数（17 位）：作为无符号整数的最大总媒体比特率值的尾数。
测量的开销（9 位）：测量的平均数据包开销值，以字节表示，表示为无符号整数 [0..511]。
因此，TMMBN 消息中的 FCI 包含指示边界元组的条目。对于每个元组，该条目由 SSRC 提供所有者，然后是适用的最大总媒体比特率和开销值。
TMMBN 消息的长度应设置为 2+2*N，其中 N 是 TMMBN FCI 条目的数量。
4.2.2.2.语义
此反馈消息用于通知任何 TMMBR 消息的发送者已收到一个或多个 TMMBR 消息或所有者已离开会话。它向所有参与者指示当前的一组边界元组和这些元组的“所有者”。
在反馈消息的公共包头中（如 [RFC4585] 的第 6.1 节所定义），“包发送方的 SSRC”字段指示通知的来源。不使用“媒体源的 SSRC”，应设置为 0。
TMMBN 消息应在接收到带有标识该媒体发送者的 FCI 条目的 TMMBR 消息后安排传输。即使在传输调度和 TMMBN 消息的实际传输之间接收到多个 TMMBR 消息，也应仅发送单个 TMMBN。 TMMBN 消息在传输消息时指示边界元组及其所有者。包含的边界元组应是通过应用第 3.5.4.2 节的适用算法或等效算法得出的集合，应用于先前的边界集合（如果有），以及自上次 TMMBN 传输以来在 TMMBR 消息中接收的元组。
即使在应用该算法之后，新报告的 TMMBR 元组没有被接受到边界集中，TMMBR 消息的接收仍会导致 TMMBN 消息的传输。在这种情况下，边界元组及其所有者不会更改，除非 TMMBR 来自先前计算的边界集中元组的所有者。此过程允许未看到最后 TMMBN 消息的会话参与者正确查看此媒体发送者的状态。
如第 4.2.1.2 节所述，当媒体发送方确定边界元组的“所有者”已离开会话时，则将该元组从边界集中删除，并且媒体发送方应发送 TMMBN 消息指示剩余边界元组。如果没有剩余的边界元组，则应发送不带任何 FCI 的 TMMBN 来指示这一点。如果没有剩余的边界元组，则会话信令中协商的最大媒体比特率和最大数据包速率（如果有）适用。
注意：如果有任何媒体接收器保留在会话中，这将是暂时的情况。空的 TMMBN 将导致每个剩余的媒体接收器确定其限制属于边界集中并因此发送 TMMBR。
在单播场景中（即，单个发送方与单个接收方通话），一旦媒体接收方发出第一个 TMMBR 消息，上述确定所有权的算法就退化为媒体接收方成为一个边界元组的“所有者” 。
4.2.2.3.计时规则
TMMBN 确认应该在会话应用的定时规则允许的情况下尽快发送。立即或早期反馈模式应该用于这些消息。
4.2.2.4.由转换器和混音器处理
如第 4.2.1.4 节所述，混合器或转换器可能需要发布 TMMBN 消息作为对由他们处理的 SSRC 的 TMMBR 消息的响应。
4.3.特定于负载的反馈消息
正如 RFC 4585 [RFC4585] 的第 6.1 节所指定的，Payload-Specific FB 消息由 RTCP 数据包类型值 PSFB (206) 标识。
AVPF [RFC4585] 定义了三个特定负载的反馈消息和一个应用层反馈消息。该备忘录指定了四个额外的特定于有效载荷的反馈消息。所有这些都通过 FMT 参数进行识别，如下所示：
在 [RFC4585] 中分配：
1：图像丢失指示（PLI）
2：切片丢失指示（SLI）
3：参考图片选择指示（RPSI）
15：应用层FB消息
31：预留给以后扩号空间
在本文中分配：
4：完整的帧内请求 (FIR) 命令
5：时空权衡请求（TSTR）
6：时空权衡通知（TSTN）
7：视频反向通道消息（VBCM）
未分配：
0：未分配
8-14：未分配
16-30：未分配
以下小节为特定于有效载荷的反馈消息定义了新的 FCI 格式。
4.3.1.完整的内部请求 (FIR)
FIR 消息由 RTCP 数据包类型值 PT=PSFB 和 FMT=4 标识。
FCI 字段必须包含一个或多个 FIR 条目。每个条目适用于不同的媒体发送者，由其 SSRC 标识。
4.3.1.1.消息格式
完整帧内请求的反馈控制信息 (FCI) 由一个或多个 FCI 条目组成，其内容如图 4 所示。 FIR 反馈消息的长度必须设置为 2+2*N，其中 N 是FCI 条目的数量。
SSRC（32 位）：媒体发送方的 SSRC 值
请求发送解码器刷新点。
序列号（8 位）：命令序列号。序列号空间对于命令源的 SSRC 和命令目标的 SSRC 的每个配对都是唯一的。对于每个新命令，序列号应增加 1 模 256。重复不应增加序列号。初始值是任意的。
保留（24 位）：发送方应将所有位设置为 0，接收时应忽略。
该反馈消息的语义与 RTP 负载类型无关。
4.3.1.2.语义
在反馈消息的公共包头内（如[RFC4585]第6.1节定义），“包发送者的SSRC”字段指示请求的来源，“媒体源的SSRC”不使用，应设置到0。FIR命令应用的媒体发送方的SSRC在相应的FCI表项中。
FIR 消息可以包含对多个媒体发送者的请求，每个目标媒体发送者使用一个 FCI 条目。
收到 FIR 后，编码器必须尽快发送解码器刷新点（参见第 2.2 节）。
发送方必须考虑第 5 节中概述的拥塞控制，这可能会限制其快速发送解码器刷新点的能力。
FIR 不应作为对图片丢失的反应发送——建议使用 PLI [RFC4585] 代替。 FIR 应该只在不发送解码器刷新点会使用户无法使用视频的情况下使用。
适合发送 FIR 的典型示例是，在多点会议中，当新用户加入会话且未建立常规解码器刷新点间隔时。另一个例子是改变流的视频切换 MCU。在这里，通常情况下，MCU 会向新发送方发出 FIR，以强制其发出解码器刷新点。解码器刷新点通常包括冻结图片发布（在本规范之外定义），它重新启动接收器的渲染过程。提到的两种技术通常用于基于 MCU 的多点会议。
其他 RTP 负载规范，例如 RFC 2032 [RFC2032] 已经为某些编解码器定义了反馈机制。支持这两种方案的应用程序在发送反馈时必须使用本规范中定义的反馈机制。出于向后兼容的原因，这样的应用程序也应该能够接收并响应在相应 RTP 有效载荷格式中定义的反馈方案，如果该有效载荷格式需要的话。
4.3.1.3.计时规则
时间遵循 [RFC4585] 第 3 节中概述的规则。 FIR 命令可以与早期或立即反馈一起使用。 FIR 反馈消息可以重复。如果使用立即反馈模式，重复应该在发送前至少等待一个 RTT。在早期或常规 RTCP 模式下，重复在下一个常规 RTCP 数据包中发送。
4.3.1.4.在混频器和转换器中处理 FIR 消息
对会话参与者已为其发出 FIR 的内容执行媒体编码的媒体翻译器或混合器负责对其进行操作。对 FIR 起作用的混合器不应原封不动地转发消息；相反，它应该自己发出 FIR。
4.3.1.5.评论
目前，视频似乎是 FIR 唯一有用的应用程序，因为它似乎是唯一广泛部署的严重依赖跨 RTP 数据包边界的媒体预测的 RTP 有效载荷。然而，对于与压缩视频共享基本属性的其他媒体类型，也可以合理地设想使用 FIR，即跨帧预测（无论该媒体类型的帧可能是什么）。一个可能的例子可能是 MPEG-4 场景描述的动态更新。建议此类媒体类型的有效载荷格式参考本规范和 AVPF [RFC4585] 中定义的 FIR 和其他消息类型，而不是在有效载荷规范中创建类似的机制。有效载荷规范可能必须解释有效载荷特定术语如何映射到此处使用的以视频为中心的术语。
结合视频编解码器，FIR 消息通常会触发发送完整的内部或 IDR 图片。两者都比预测的（间）图片大几倍。它们的大小与它们生成的时间无关。在大多数环境中，尤其是在使用带宽受限的链路时，使用帧内图片意味着允许的延迟是典型帧持续时间的显着倍数。一个例子：如果发送帧率为 10fps，假设帧内图片是帧间图片的 10 倍，则必须接受一整秒的延迟。在这样的环境中，发送 FIR 消息不需要特别短的延迟。
因此，根据 [RFC4585] 等待 RTCP 定时规则允许的下一个可能的时隙不应对系统性能产生过度的负面影响。
从应用程序的角度来看，强制要求完成发送解码器刷新点的最大延迟是可取的，但从拥塞控制的角度来看是有问题的。上面提到的“尽快”似乎是一个合理的妥协。
在发送方无法控制编解码器的环境中（例如，流式传输预录制和预编码的内容时），无法指定对此命令的反应。发送方的一种合适反应是在视频比特流中向前跳到下一个解码器刷新点。在其他情况下，最好不要对命令做出任何反应，例如，当流式传输到大型多播组时。其他反应也是可能的。在决定策略时，发送方可以考虑以下因素：接收组的大小、FIR 消息发送方的“重要性”（但在此特定应用程序中可以定义“重要性”）、内容中的解码器刷新点，等等。然而，主要处理预编码内容的会话根本不会使用 FIR。
Picture Loss Indication 和 FIR 之间的关系如下。如 AVPF [RFC4585] 的第 6.3.1 节所述，图像丢失指示通知解码器有关图像丢失以及编码器和解码器之间参考图像未对齐的可能性。这种情况通常与正在进行的连接中的丢失有关。在点对点场景中，并且没有高级错误恢复工具，编码器的一种可能选择是发送解码器刷新点。
但是，还有其他选择。一个例子是媒体发送者忽略 PLI，因为嵌入的流冗余很可能会在合理的时间内清理再现的图片。相比之下，FIR 使（实时）编码器别无选择，只能发送解码器刷新点。它不允许编码器考虑任何考虑因素，例如上述考虑因素。
4.3.2.时空权衡请求 (TSTR)
TSTR 反馈消息由 RTCP 数据包类型值 PT=PSFB 和 FMT=5 标识。
FCI 字段必须包含一个或多个 TSTR FCI 条目。
4.3.2.1.消息格式
时间-空间权衡请求的 FCI 条目的内容如图 5 所示。反馈消息的长度必须设置为 2+2*N，其中 N 是包含的 FCI 条目的数量。
SSRC（32 位）：被请求应用索引中给出的权衡值的媒体发送者的 SSRC。
序列号（8 位）：请求序列号。序列号空间对于请求源的 SSRC 和请求目标的 SSRC 的配对是唯一的。对于每个新命令，序列号应增加 1 模 256。重复不应增加序列号。初始值是任意的。
保留（19 位）：发送方应将所有位设置为 0，接收时应忽略。
索引（5 位）：一个介于 0 和 31 之间的整数值，表示所请求的相对权衡。索引值为 0 表示可能的最高空间质量，而 31 表示可能的最高时间分辨率。
4.3.2.2.语义
解码器可以通过向编码器发送 TSTR 消息来建议时空权衡级别。如果编码器能够调整它的时间-空间权衡，它应该考虑接收到的 TSTR 消息，以便将来对图片进行编码。 0 值表示高空间质量，31 值表示高帧速率。值从 0 到 31 的进展单调地表明需要更高的帧速率。索引值不对应于空间质量或帧速率的精确值。
对来自不同媒体接收者的媒体发送者接收到多个 TSTR 消息的反应对实现开放。选择的权衡应通过 TSTN 消息传达给媒体接收器。
在反馈消息的公共包头（如[RFC4585]的第6.1节中定义）中，“包发送者的SSRC”字段指示请求的来源，“媒体源的SSRC”不使用，应设置到 0。TSTR 适用的媒体发送方的 SSRC 在相应的 FCI 条目中。
TSTR 消息可以包含对多个媒体发送者的请求，每个目标媒体发送者使用一个 FCI 条目。
4.3.2.3.计时规则
时间遵循 [RFC4585] 第 3 节中概述的规则。这个请求消息不是时间关键的，应该使用常规的 RTCP 定时发送。仅当知道用户界面需要快速反馈时，消息才可以提前或立即反馈时间发送。
4.3.2.4.在混合器和转换器中处理消息
对发送给发出 TSTR 的会话参与者的内容进行编码的混合器或媒体转换器应考虑该请求，以确定它是否可以通过更改自己的编码参数来满足它。无法满足请求的媒体翻译器可以将请求原封不动地转发给媒体发送者。用于多个会话参与者的混合器编码将需要考虑这些参与者的共同需求，然后才能代表自己向媒体发送者生成 TSTR。另见第 3.5.2 节中的讨论。
4.3.2.5.评论
术语“空间质量”不一定是指由重建视频使用的像素数衡量的分辨率。事实上，在大多数情况下，视频分辨率在会话的生命周期内保持不变。然而，所有视频压缩标准都有在给定分辨率下调整空间质量的方法，通常受量化参数或 QP 的影响。
数值低的 QP 导致良好的重建图像质量，而数值高的 QP 会产生粗糙的图像。编码器对此请求的典型反应是更改其速率控制参数以使用较低的帧速率和数值较低（平均）的 QP，反之亦然。索引值到帧速率和 QP 的精确映射在这里是有意保留的，因为它取决于所采用的压缩标准、空间分辨率、内容、比特率等因素。
4.3.3.时空权衡通知 (TSTN)
TSTN 消息由 RTCP 数据包类型值 PT=PSFB 和 FMT=6 标识。
FCI 字段应包含一个或多个 TSTN FCI 条目。
4.3.3.1.消息格式
时间-空间权衡通知的 FCI 条目的内容如图 6 所示。TSTN 消息的长度必须设置为 2+2*N，其中 N 是 FCI 条目的数量。
SSRC（32 位）：导致此通知的 TSTR 源的 SSRC。
序列号（8 位）：来自正在确认的 TSTR 的序列号值。
保留（19 位）：发送方应将所有位设置为 0，接收时应忽略。
索引（5 位）：媒体发送方此后使用的权衡值。
信息说明：返回的权衡值 (Index) 可能与请求的值不同，例如，在媒体编码器无法调整其权衡的情况下，或使用预先录制的内容时。
4.3.3.2.语义
该反馈消息用于确认 TSTR 的接收。对于针对会话参与者接收的每个 TSTR，应在 TSTN 反馈消息中发送 TSTN FCI 条目。单个 TSTN 消息可以使用多个 FCI 条目确认多个请求。
包含的索引值在 TSTN 消息的所有 FCI 条目中应相同。为每个请求者包括一个 FCI 允许每个请求实体确定媒体发送者收到了请求。通知也应发送以响应收到的 TSTR 重复。如果请求接收者从一个请求者那里收到了几个不同序列号的 TSTR，它应该只响应具有最高（模 256）序列号的请求。请注意，由于字段的包装，最高序列号可能是较小的整数值。 [RFC3550] 的附录 A.1 有一个算法，用于跟踪 RTP 数据包的最高接收序列号；它可以适用于这种用途。
TSTN 应包括将作为请求结果使用的时空权衡指数。这不一定与请求的索引相同，因为媒体发送者可能需要聚合来自多个请求会话参与者的请求。它也可能有其他一些限制选择的政策或规则。
在反馈消息的公共包头内（如[RFC4585]第6.1节定义），“包发送者的SSRC”字段指示通知的来源，不使用“媒体源的SSRC”，应设置到 0。通知适用的请求实体的 SSRC 在相应的 FCI 条目中。
4.3.3.3.计时规则
计时遵循 [RFC4585] 第 3 节中概述的规则 该确认消息对时间要求不高，应该使用常规 RTCP 计时发送。
4.3.3.4.在混合器和转换器中处理 TSTN
作用于 TSTR 的混合器或翻译器也应发送相应的 TSTN。在需要转发 TSTR 本身的情况下，通知消息可能需要延迟，直到 TSTR 得到响应。
4.3.3.5.评论
空
4.3.4. H.271 视频反向通道消息 (VBCM)
VBCM 由 RTCP 数据包类型值 PT=PSFB 和 FMT=7 标识。
FCI 字段必须包含一个或多个 VBCM FCI 条目。
4.3.4.1.消息格式
VBCM 指示中 FCI 条目的语法如图 7 所示。
SSRC（32 位）：被请求指示其编码器对 VBCM 作出反应的媒体发送方的 SSRC 值。
序列号（8 位）：命令序列号。序列号空间对于命令源的 SSRC 和命令目标的 SSRC 的配对是唯一的。对于每个新命令，序列号应增加 1 模 256。重复不应增加序列号。初始值是任意的。
0：必须由发送方设置为 0，并且不应由消息接收方执行。
负载类型（7 位）：必须为其解释 VBCM 位流的 RTP 负载类型。
长度（16 位）：VBCM 八位字节串的长度，以八位字节为单位，不包括任何填充八位字节。
VBCM Octet String（可变长度）：这是解码器生成的带有特定反馈子消息的八位字节串。
填充（可变长度）：位设置为 0 以构成 32 位边界。
4.3.4.2.语义
VBCM 指示的“有效载荷”携带不同类型的特定于编解码器的反馈信息。反馈信息的类型可以归类为“状态报告”（例如指示接收到的比特流没有错误，或者部分或完整图片或块丢失）或“更新请求”（例如完全刷新位流）。
注意：VBCM 子消息和 CCM/AVPF 反馈消息（例如 FIR）之间可能存在重叠。进一步讨论请参见第 3.5.3 节。
VBCM 中携带的不同类型的反馈子消息由[H.271]中定义的“payloadType”指示。为方便起见，下面复制了这些子消息类型。 “payloadType”，在 ITU-T Rec. H.271 术语是指 H.271 消息的子类型，不应与 RTP 有效载荷类型混淆。
有效载荷消息内容
类型
-------------------------------------------------- -------------------
0 一张或多张没有检测到比特流错误的图片
错配
1 一张或多张完全或部分丢失的图片
2 完全或部分丢失的一组图片块
3 一个参数集的 CRC
4 某种类型的所有参数集的CRC
5 一个“重置”请求，指示发送方应该完全刷新视频比特流，就好像没有接收到先前的比特流数据一样
> 5 保留供 ITU-T 将来使用
表 2：H.271 消息类型（“payloadTypes”）
VBCM 的位串或“有效载荷”是可变长度的，是独立的，并以可变长度的二进制格式编码。媒体发送者必须能够解析这种优化的二进制格式才能使用 VBCM。
每种不同类型的子消息（由
payloadType) 可能具有不同的语义，具体取决于所使用的编解码器。
在反馈消息的公共包头（如[RFC4585]的第6.1节中定义）中，“包发送者的SSRC”字段指示请求的来源，“媒体源的SSRC”不使用，应设置为0。VBCM应用的媒体发送方的SSRC在对应的FCI表项中。 VBCM 的发送方可以向多个媒体发送方发送 H.271 消息，也可以向同一个 VBCM 内的同一个媒体发送方发送多个 H.271 消息。
4.3.4.3.计时规则
时间遵循 [RFC4585] 第 3 节中概述的规则。不同的子消息类型在应该使用的消息的定时方面可能具有不同的属性。如果在同一个反馈包中包含几种不同的类型，则应遵循对要求最严格的子消息类型的要求。
4.3.4.4.在混合器或转换器中处理消息
在混合器或转换器中对 VBCM 的处理取决于子消息类型。
4.3.4.5.评论
有关 H.271 消息和 AVPF [RFC4585] 中定义的消息的使用的讨论，请参阅第 3.5.3 节，以及具有类似功能的本备忘录。
注：是否需要此消息中的 RTP 负载类型字段，已经有一些讨论。如果在同一个会话中可能有多个支持 VBCM 的 RTP 有效载荷类型，并且给定 VBCM 的语义在有效载荷类型之间发生变化，则需要它。例如，H.271 类型 0 消息中的图片识别机制在 H.263 和 H.264 之间有着根本的不同（尽管两者使用相同的语法）。因此，这里的有效载荷字段是合理的。有进一步评论认为，对于 TSTR 和 FIR 而言，这种需求不存在，因为 TSTR 和 FIR 的语义定义不够松散，或者足够通用，以适用于当前存在/设想的所有视频有效载荷。
5. 拥塞控制
AVPF [RFC4585] 计时规则的正确应用可防止网络被反馈消息淹没。因此，假设正确的实现和配置，RTCP 信道不会破坏其比特率承诺并引入拥塞。
一些反馈消息的接收修改了媒体发送者的行为，或者更具体地说，媒体编码器的行为。
因此，修改后的行为必须遵守拥塞控制应用提供的带宽限制。例如，当媒体发送方对 FIR 做出反应时，形成解码器刷新点的异常大量数据包必须按照拥塞控制算法进行调整，即使用户体验受到缓慢传输的解码器刷新点的影响.
临时最大媒体流比特率值的改变只能缓解拥塞，只要还采用拥塞控制，就不会导致拥塞。通过请求增加该值要求媒体发送方在将其传输速率增加到该值时使用拥塞控制。该值的减小会导致传输比特率降低，从而降低拥塞的风险。
6. 安全考虑
定义的消息具有某些具有安全含义的属性。本协议的用户必须解决和考虑这些问题。
定义的建立信令机制对修改攻击很敏感，这可能导致会话创建与次优配置，在最坏的情况下，会话拒绝。为了防止这种类型的攻击，需要对设置信令进行身份验证和完整性保护。
本规范中定义的类型的欺骗或恶意创建的反馈消息可能具有以下含义：
一种。由于错误的 TMMBR 消息将最大值设置为非常低的值，媒体比特率严重降低；
湾在 TMMBN 消息中将边界元组的所有权分配给错误的参与者，可能会导致边界集中不必要的振荡，因为错误识别的所有者报告了其元组的更改，而真正的所有者可能会阻止更改，直到正确的 TMMBN 消息到达参与者；
C。发送导致视频质量与用户期望不同的 TSTR，使会话变得不那么有用；
d.由于解码器刷新点的频繁使用，发送多个 FIR 命令以降低帧速率，并使视频抖动。
为了防止这些攻击，需要对反馈消息应用认证和完整性保护。这可以使用将安全 RTP [SRTP] 和 AVPF 组合到 SAVPF [SAVPF] 中的 RTP 配置文件针对当前 RTP 会话外部的威胁来实现。在混音器的情况下，可以在混音器和参与者之间应用单独的安全上下文和过滤，从而保护混音器上的其他用户免受行为不端的参与者的影响。
7. SDP 定义
[RFC4585] 的第 4 节定义了一个新的 SDP [RFC4566] 属性 rtcp-fb，可用于协商处理特定 AVPF 命令和指示的能力，例如参考图片选择、图片丢失指示等。 ABNF 用于rtcp-fb 在 [RFC4585] 的第 4.2 节中描述。在本节中，我们扩展了 rtcp-fb 属性以包括在本文档中为编解码器控制描述的命令和指示。我们还讨论了对编解码器控制命令和指示的 Offer/Answer 含义。
7.1. rtcp-fb 属性的扩展
如 AVPF [RFC4585] 中所述，rtcp-fb 属性表示使用 RTCP 反馈的能力。 AVPF 指定 rtcp-fb 属性只能用作媒体级别属性，不得在会话级别提供。 [RFC4585]中描述的与有效载荷类型和会话描述中的多个rtcp-fb属性相关的rtcp-fb属性的所有规则也适用于本备忘录中定义的新反馈消息。
[RFC4585] 中定义的 rtcp-fb 的 ABNF [RFC4234] 是
"a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF
其中 rtcp-fb-pt 是有效载荷类型，rtcp-fb-val 定义了反馈消息的类型，例如 ack、nack、trr-int 和 rtcp-fb-id。
例如表示支持Picture Loss Indication的反馈，发送方在SDP中声明如下
在本文档中，我们定义了一个新的反馈值“ccm”，表示支持使用 RTCP 反馈消息进行编解码控制。
“ccm”反馈值应该与指示支持的特定编解码器控制命令的参数一起使用。在本文档中，我们定义了四个这样的参数，即：
o “fir”表示支持完整的内部请求 (FIR)。
o “tmmbr”表示支持临时最大媒体流比特率请求/通知（TMMBR/TMMBN）。它有一个可选的子参数来指示要使用的会话最大数据包速率（以每秒数据包为单位）。如果不包括，则默认为无穷大。
o “tstr”表示支持时间-空间权衡请求/通知（TSTR/TSTN）。
o “vbcm”表示支持 H.271 视频反向通道消息 (VBCM)。它有零个或多个子参数来标识支持的 H.271“payloadType”值。
在 [RFC4585] 中定义的 rtcp-fb-val 的 ABNF 中，有一个
称为 rtcp-fb-id 的占位符用于定义新的反馈类型。 “ccm”在本文档中被定义为一种新的反馈类型，这里定义了ccm参数的ABNF（完整的ABNF语法请参考[RFC4585]的4.2节）。
7.2.提供-答复
Offer/Answer [RFC3264] 对编解码器控制协议反馈消息的影响类似于 [RFC4585] 中描述的那些。提供者可以指示支持所选编解码器命令和指示的能力。应答者必须删除与其不希望在该特定媒体会话中支持的 CCM 对应的所有 CCM 参数（例如，因为它没有实现所讨论的消息，或者因为它的应用程序逻辑表明该消息的支持添加了不价值）。除了已提供的参数外，应答者不得添加新的 ccm 参数。
答案对媒体会话具有约束力，并且提供方和应答方都不得使用任何反馈消息，除非双方明确表示支持。换句话说，只能使用来自提议和回答的 CCM 参数的联合子集。
请注意，在报价或答复中包含 CCM 参数表明该方（报价方或应答方）至少能够接收相应的 CCM 并对其采取行动。如果协商的 CCM 的接收要求一方用另一个 CCM 做出响应，则它也必须具有该能力。尽管没有强制要求发起任何协商类型的 CCM，但通常期望一方在适当的时候发起 CCM。
TMMBR 指示的会话最大数据包速率参数部分是声明性的，应使用提供和应答中的最高值。如果会话最大数据包速率参数不存在于报价中，则应答者不应包含该参数。
7.3.案例
示例 1：以下 SDP 描述了使用 H.263 的点对点视频呼叫，呼叫发起方声明其支持 FIR 和 TSTR/TSTN 编解码器控制消息的能力。 SDP 承载在类似于 SIP 的高级信令协议中。
在上面的示例中，当发送方从远程方接收到 TSTR 消息时，它能够调整权衡，如 RTCP TSTN 反馈消息中所示。
示例 2：以下 SDP 描述了加入托管多方视频会议会话的视频混合器的 SIP 端点。 参与者仅支持 FIR（完整内部请求）编解码器控制命令，并在其会话描述中声明。
当视频 MCU 决定路由该参与者的视频时，它会发送 RTCP FIR 反馈消息。 收到此反馈消息后，端点需要生成完整的内部请求。
示例 3：以下示例描述了对编解码器控制消息的提供/应答含义。 提议者希望支持“tstr”、“fir”和“tmmbr”。 提供的 SDP 是
应答者希望仅支持 FIR 和 TSTR/TSTN 消息，应答者 SDP 是
示例 4：以下示例描述了 H.271 视频反向通道消息 (VBCM) 的提供/应答含义。 提供者希望支持VBCM和payloadType 1（一个或多个完全或部分丢失的图片）和2（一个图片的一组完全或部分丢失的块）的子消息。
应答者只希望支持类型 1 的子消息
8. IANA 考虑
新值“ccm”已在 IANA 发布时在“rtcp-fb”属性值注册表中注册，网址为：http://www.iana.org/assignments/sdp-parameters
值名称：ccm
长名称：编解码器控制命令和指示
参考：RFC 5104
已创建一个新的注册表“编解码器控制消息”以保存发布时位于以下位置的“ccm”参数：http://www.iana.org/assignments/sdp-parameters
此注册表中的新注册遵循 [RFC2434] 定义的“规范要求”策略。 此外，它们需要指示任何额外的 RTCP 反馈类型，例如“nack”和“ack”。
（略）
标签：配置文件,媒体,编解码器,比特率,AVPF,发送,消息,元组,TMMBR 来源： https://blog.csdn.net/PiPiQ_Blog/article/details/118060891