1. 简介 (Introduction)

使用 RTP (实时传输协议, Real-time Transport Protocol) 的实时媒体流在一定程度上能够抵御丢包. RTP [1] 提供了在接收端恢复发送端处的排序与时间信息以正确再现媒体流所需的全部机制. RTP 还提供来自所有接收端的关于总体接收质量的连续反馈, 从而使发送端在中等时间尺度 (数秒到数分钟量级) 上能够根据观测到的网络服务质量 (QoS, quality of service) 调整其编码方案与传输行为. 然而, 除少数与载荷相关的机制 [6] 外, RTP 并未规定可让发送端立即修复媒体流的及时反馈机制: 例如通过重传, 追溯式前向纠错 (FEC, Forward Error Correction) 控制, 或某些视频编解码的媒体专用机制 (如参考图像选择).

当前可与 RTP 配合用于提高抗错能力的机制包括音频冗余编码 [13], 视频冗余编码 [14], RTP 层 FEC [11], 以及关于更稳健的媒体流传输的一般性考虑 [12]. 这些机制可以主动应用 (从而增加给定媒体流的带宽). 或者, 在规模足够小且往返时间 (RTT, round-trip time) 足够小的组中, 发送端可以按需执行修复, 使用上述机制和/或与媒体编码相关的方法. 注意, "小规模的组" 与 "足够小的 RTT" 都高度依赖于具体应用.

本文档在 [1] 和 [2] 的基础上规定了一种用于具有最小控制的音视频会议的经修改的 RTP 概要, 通过两项修改/补充实现: 第一, 为实现及时反馈, 引入 Early RTCP 消息的概念以及允许在小规模多播组中低延迟反馈 (并在大规模组中防止反馈内爆) 的算法, 并对点到点场景给予特别关注. 第二, 规定少量通用反馈消息以及用于在 RTCP 载荷中传输的编解码与应用专用反馈信息的格式.