【RFC5104 带有反馈的RTP视听配置文件中的编解码器控制消息（AVPF）】（翻译）

最新推荐文章于 2024-02-27 19:59:22 发布

羊羊洒洒_Blog

最新推荐文章于 2024-02-27 19:59:22 发布

阅读量1.4k

点赞数

文章标签： rfc rtp

本文链接：https://blog.csdn.net/PiPiQ_Blog/article/details/118060891

版权

原文 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 代理和应用服务器。
由于多种原因，避免通过信令实体避免了延迟。代理的延迟要求不如媒体处理那么严格，并且由于其复杂和更通用的特性，可能会导致显着的处理延迟。信令实体的拓扑位置通常也不是针对最小延迟进行优化，而是针对其他架构目标进行优化。因此，在地理和延迟意义上，信令路径可以明显更长。