【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 混合器开始将新选择的流转发到接收