跳到主要内容

1. 介绍 (Introduction)

使用 RTP 传送多媒体内容时, 通常需要同步播放一个演示中的音频和视频组成部分. 这种同步通过 RTP 控制协议 (RTP Control Protocol, RTCP) 发送方报告 (sender report, SR) 数据包 [RFC3550] 中包含的信息来完成. 这些报告会周期性发送, 并且只有在每个 RTP 流都收到足够的 RTCP SR 数据包后, 接收方才能建立每个 RTP 流所用媒体时钟与用于同步的公共 NTP 格式参考时钟之间的映射, 从而同步多媒体会话的各个组成部分.

近期有人提出, 这种同步延迟会对某些应用造成问题, 例如使用分层视频编码或多描述视频编码的应用. 本备忘录回顾 RTP 同步的工作方式, 并说明可以预期的同步延迟. 本文提出三种与基本 RTP 同步机制向后兼容的扩展:

  • 放宽特定源组播 (source-specific multicast, SSM) 发送方的 RTCP 传输定时规则, 以降低大型 SSM 组的初始同步延迟. 参见第 3.1 节.

  • 定义一项针对基于 RTCP 反馈的扩展 RTP 配置文件 (RTP/AVPF) [RFC4585] 的增强, 允许接收方请求额外的 RTCP SR 数据包, 从而提供同步 RTP 流所需的元数据. 当加入具有较长 RTCP 报告间隔的会话, 出现数据包丢失, 或使用视频切换 MCU 时, 这可以降低同步延迟. 参见第 3.2 节.

  • 定义两个 RTP 头部扩展, 用于随 RTP 数据包带内传送同步元数据. 这些扩展提供与 RTP 数据包对齐的同步元数据, 因而无需在同步前估计各流之间的时钟偏斜. 它们还可以减少在同步各流之前必须接收 RTCP SR 数据包的需求, 但并不会消除对 RTCP 的需求. 参见第 3.3 节.

这些扩展的直接用例是在加入分层视频会话时降低同步带来的延迟, 例如处于非交织基于时间戳 (Non-Interleaved Timestamp-based, NI-T) 模式 [AVT-RTP-SVC] 的 H.264/SVC (Scalable Video Coding) 会话. 不过, 这些扩展并不局限于分层编码, 在任何同步延迟成为问题的环境中都可以使用.

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 和 "OPTIONAL" 应按 RFC 2119 [RFC2119] 中的说明解释.

2. RTP 流的同步 (Synchronisation of RTP Flows)

接收方根据发送方生成的 RTCP SR 数据包中包含的信息同步 RTP 流, 具体而言是 NTP 格式时间戳和 RTP 时间戳. 同步要求在要同步的一组流中, 生成 NTP 格式时间戳时 MUST 使用公共参考时钟. 也就是说, 同步多个 RTP 流时, 每个流的 RTP 时间戳来自各自独立且与媒体相关的时钟, 但所有要同步的流在 RTCP SR 数据包中的 NTP 格式时间戳 MUST 从同一个时钟采样. 为实现更快且更准确的同步, 还 RECOMMENDED 发送方和接收方在可能时使用具有共同属性, 特别是共同时间基的同步公共 NTP 格式参考时钟. 需要承认的是, 当 RTP 用于受控环境之外时, 这通常无法做到. 该公共参考时钟及其属性如何被信令传递和分发不在本备忘录范围内.

对于多媒体会话, 每种媒体类型, 例如音频或视频, 都在单独的 RTP 会话中发送. 接收方通过发送方生成的 RTCP 源描述 (Source Description, SDES) 数据包中包含的规范端点标识符 (canonical end-point identifier, CNAME) 项, 或通过带外信令 [RFC5576], 将需要同步的 RTP 流关联起来. 对于分层媒体, 不同层可以在不同 RTP 会话中发送, 也可以在单个 RTP 会话中使用不同的同步源 (synchronisation source, SSRC) 值发送. 在这两种情况下, CNAME 都用于标识需要同步的流. 因此, 为确保同步, RTP 发送方 MUST 按 RFC 3550 [RFC3550] 第 6 节发送周期性的复合 RTCP 数据包.

这些周期性复合 RTCP 数据包的定时取决于每个 RTP 会话中的成员数量, 其中正在发送数据的成员比例, 会话带宽, 配置的 RTCP 带宽比例, 以及会话是组播还是单播. 详情见 RFC 3550 第 6.2 节. 概括而言, RTCP 控制流量会分配到会话带宽的一小部分, 通常为 5%. 在这部分中, 四分之一分配给活动 RTP 发送方, 接收方使用剩余四分之三. 这些比例可以通过会话描述协议 (Session Description Protocol, SDP) [RFC3556] 配置. RTP 会话的每个成员会根据这些比例, 会话是组播还是单播, 已观察到的成员数量, 以及自己是否正在主动发送数据, 推导出 RTCP 报告间隔. 随后, 它平均每个报告间隔发送一次复合 RTCP 数据包. 实际的数据包发送时间会在报告间隔的 [0.5 ... 1.5] 倍范围内随机化, 以避免报告同步.

RECOMMENDED 最小报告间隔为 5 秒, 但发送初始报告前的延迟 "MAY be set to half the minimum interval to allow quicker notification that the new participant is present" [RFC3550]. 此外, 对于单播会话, "the delay before sending the initial compound RTCP packet MAY be zero" [RFC3550]. 另外, 对于单播会话以及组播会话中的活动发送方, 固定最小报告间隔 MAY 缩放为 "360 divided by the session bandwidth in kilobits/second. This minimum is smaller than 5 seconds for bandwidths greater than 72 kb/s" [RFC3550].

2.1. 初始同步延迟 (Initial Synchronisation Delay)​

一个多媒体会话由一组共同参与者之间并发的 RTP 会话组成, 每种媒体类型使用一个 RTP 会话. 例如, 一个视频会议作为多媒体会话, 可能包含一个音频 RTP 会话和一个视频 RTP 会话. 为了让接收方同步多媒体会话的各个组成部分, 每个发送方 MUST 向该多媒体会话中的每个 RTP 会话发送一个复合 RTCP 数据包, 其中包含 RTCP SR 数据包以及带有 CNAME 项的 RTCP SDES 数据包. 在所有组成 RTP 会话上收到这类 RTCP 数据包之前, 接收方无法跨整个多媒体会话同步播放. 如果没有数据包丢失, 则预期初始同步延迟等于在 RTCP 报告间隔最长的 RTP 会话中收到第一个 RTCP 数据包的平均耗时. 该值会随单播和组播 RTP 会话而不同.

分层会话的初始同步延迟与多媒体会话类似. 在收到会话中每一层的 RTCP SR 和 CNAME 信息之前, 各层无法同步.

2.1.1. 单播会话 (Unicast Sessions)​

对于单播多媒体会话或分层会话, 发送方 SHOULD 在加入多媒体会话中的每个 RTP 会话时立即发送一个初始复合 RTCP 数据包, 其中包含 RTCP SR 数据包以及带有 CNAME 项的 RTCP SDES 数据包. 当用于 NAT 穿越的任何带内信令, 例如 [RFC5245], 和/或安全密钥协商, 例如 [RFC5764] 和 [ZRTP], 已经结束且媒体路径打开后, 即认为各个 RTP 会话已经加入. 这意味着初始 RTCP 数据包会与第一个数据包并行发送, 遵循 RFC 3550 中 "the delay before sending the initial compound RTCP packet MAY be zero" 的指导. 在没有任何数据包丢失的情况下, 各流可以立即同步.

预期在发送第一个 RTCP 数据包之前, NAT 针孔, 防火墙通孔, 服务质量以及媒体安全密钥都已作为信令的一部分完成协商, 无论信令是带内还是带外. 这应能确保任何中间盒已经准备好接收流量, 并降低初始 RTCP 数据包丢失的可能性.

2.1.2. 特定源组播 (SSM) 会话 (Source-Specific Multicast Sessions)​

对于组播会话, 发送初始 RTCP 数据包前的延迟以及由此产生的同步延迟, 会随会话带宽和会话成员数量而变化. 对于组播多媒体会话或分层会话, 平均同步延迟取决于最慢的组成 RTP 会话. 假设所有 RTP 会话具有相同成员数量, 这通常是带宽最低的会话.

向组播组发送时, 如果同步延迟可能成为问题, 应使用 360 秒除以会话带宽, 单位为千比特每秒, 得到的缩短版最小 RTCP 报告间隔 [RFC3550]. 另外, 按通常做法, 第一个 RTCP 数据包的报告间隔减半. 根据会话带宽和成员数量, 这会得到图 1 所示的平均同步延迟.

        Session| Number of receivers:
      Bandwidth|  2     3     4     5     10   100   1000  10000
             --+------------------------------------------------
         8 kbps| 2.73  4.10  5.47  5.47  5.47  5.47  5.47  5.47
        16 kbps| 2.50  2.50  2.73  2.73  2.73  2.73  2.73  2.73
        32 kbps| 2.50  2.50  2.50  2.50  2.50  2.50  2.50  2.50
        64 kbps| 2.50  2.50  2.50  2.50  2.50  2.50  2.50  2.50
       128 kbps| 1.41  1.41  1.41  1.41  1.41  1.41  1.41  1.41
       256 kbps| 0.70  0.70  0.70  0.70  0.70  0.70  0.70  0.70
       512 kbps| 0.35  0.35  0.35  0.35  0.35  0.35  0.35  0.35
         1 Mbps| 0.18  0.18  0.18  0.18  0.18  0.18  0.18  0.18
         2 Mbps| 0.09  0.09  0.09  0.09  0.09  0.09  0.09  0.09
         4 Mbps| 0.04  0.04  0.04  0.04  0.04  0.04  0.04  0.04

        Figure 1: Average Initial Synchronisation Delay in Seconds
                     for an RTP Session with 1 Sender

这些数值假定使用一个只有单个活动发送方的特定源组播信道, 并假定平均 RTCP 数据包大小为 70 个八位字节. 这些间隔足以在不过度延迟的情况下实现唇音同步, 但对于同步分层视频流的各部分而言, 可能仍会被认为延迟过高.

RTCP 间隔按通常方式随机化, 因此最小同步延迟为这些间隔的一半, 最大延迟为这些间隔的 1.5 倍. 还应注意, 这些 RTCP 间隔是在假定完全知道会话成员数量的情况下计算的.

2.1.3. 任意源组播 (ASM) 会话 (Any-Source Multicast Sessions)​

对于 ASM 会话, 成员中发送方所占比例非常重要, 并会导致平均 RTCP 报告间隔出现更大变化. 图 2 和图 3 展示了这一点. 它们使用与图 1 所述 SSM 会话相同的会话带宽和接收方数量, 但分别针对具有 2 个和 10 个发送方的会话给出 RTCP 报告间隔. 可以看到, 初始同步延迟会随发送方数量扩展. 这样做是为了确保所有组成员产生的 RTCP 总流量不会无界增长. 该延迟可能明显大于特定源组播组中的延迟. 尽管如此, 在典型中小规模组视频会议场景中, 初始同步时间对于唇音同步仍然可以接受.

注意, 使用带中央 RTP 转换器的多单播实现的多发送方组, 即 [RFC5117] 术语中的 Topo-Translator, 其同步性能与 ASM 组 (Topo-ASM) 类似, 因为该转换器实际上形成了一个 ASM 组.

(图 2 和图 3 在此片段中省略, 但会在后续章节中讨论, 如适用).

最后于 更新