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, 或使用混合器 (Topo-Mixer), 或某些形式的视频切换 MCU (Topo-Video-switch-MCU) 的组, 会将 RTCP 数据包分发给组内所有成员, 因此在初始同步延迟方面与 ASM 组以相同方式扩展.
Session| Number of receivers:
Bandwidth| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 10.94 10.94 10.94 10.94
16 kbps| 2.50 2.50 2.73 3.42 5.47 5.47 5.47 5.47
32 kbps| 2.50 2.50 2.50 2.50 2.73 2.73 2.73 2.73
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 2: Average Initial Synchronisation Delay in Seconds
for an RTP Session with 2 Senders
Session| Number of receivers:
Bandwidth| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 13.67 54.69 54.69 54.69
16 kbps| 2.50 2.50 2.73 3.42 6.84 27.34 27.34 27.34
32 kbps| 2.50 2.50 2.50 2.50 3.42 13.67 13.67 13.67
64 kbps| 2.50 2.50 2.50 2.50 2.50 6.84 6.84 6.84
128 kbps| 1.41 1.41 1.41 1.41 1.41 3.42 3.42 3.42
256 kbps| 0.70 0.70 0.70 0.70 0.70 1.71 1.71 1.71
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.85 0.85 0.85
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.43 0.43 0.43
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.21 0.21 0.21
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.11 0.11 0.11
Figure 3: Average Initial Synchronisation Delay in Seconds
for an RTP Session with 10 Senders
2.1.4. 讨论 (Discussion)
对于单播会话, 只要初始 RTCP 数据包没有丢失, 现有基于 RTCP SR 的机制就允许立即同步.
对于 SSM 会话, 初始同步延迟足以支持唇音同步, 但对某些分层编解码器而言可能高于期望. 不为组播组发送即时 RTCP 数据包的理由, 是为了避免大量成员同时加入组时产生请求内爆, 即 "flash crowd". 对 SSM 发送方来说, 这不是问题, 因为最多只能有一个发送方, 因此应允许 SSM 发送方在加入会话时发送即时 RTCP SR. 当前单播会话也允许这样做, 且同样不存在内爆问题. 使用单播反馈的 SSM 接收方则不允许发送即时 RTCP. 对于 ASM 会话, 响应内爆是一个顾虑, 因此不建议修改 RTCP 定时规则.
在所有情况下, 初始 RTCP SR 数据包都有可能丢失. 发生这种情况时, 接收方在报告间隔过去并发送下一个 RTCP SR 数据包之前, 将无法同步媒体. 这是不理想的. 第 3.2 节定义了一种新的 RTP/AVPF 传输层反馈消息, 用于请求生成 RTCP SR, 从而在数据包丢失时实现快速重新同步.
2.2. 晚加入者的同步 (Synchronisation for Late Joiners)
对于晚加入者而言, RTP 会话之间的同步可能比会话开始时已存在的参与者更慢. 原因有三点:
-
许多允许快速发送 RTCP SR 数据包的优化只适用于会话开始阶段. 这意味着新参与者可能必须在每个会话中等待一个完整的 RTCP 报告间隔, 才能收到同步媒体流所需的数据. 根据配置的会话带宽和参与者数量, 这可能需要数秒.
-
额外的同步延迟来自 RTCP 定时规则本身. 数据包平均每个报告间隔生成一次, 但为了避免报告同步, 确切发送时间会随机化 +/- 50%. 这对于避免组播会话中的网络拥塞很重要, 但也意味着不同 RTP 会话的 RTCP 发送方报告定时并不同步. 因此, 接收方必须估计 NTP 格式时钟上的偏斜, 以便跨会话对齐 RTP 时间戳. 这种估计是 RTP 同步实现的必要组成部分, 在获得足够报告后可以达到很高精度. 然而, 收集足够的 RTCP SR 数据来执行这种估计, 可能需要接收多个 RTCP 报告, 从而进一步增加同步延迟.
-
许多媒体编解码器具有周期性访问点的概念, 因而新加入的接收方通常必须等到收到与访问点对应的数据包后, 才能开始解码媒体流. 这些访问点的发送频率可能低于 RTCP SR 数据包, 因此可能成为晚加入者开始同步媒体播放的限制因素. 在某些场景中, 可使用面向基于单播的组播 RTP 会话快速获取的 RTP 扩展 [AVT-ACQUISITION-RTP], 来缩短接收访问点所需时间.
这些延迟很可能影响调入一个正在进行的组播 RTP 会话, 或影响视频切换 MCU.