3. 降低 RTP 同步延迟

本节定义了三个向后兼容的 RTP 扩展, 用于降低可能出现的同步延迟 (synchronisation delay): 面向 SSM 发送方的缩短初始 RTCP 间隔, 快速重新同步请求消息, 以及能够在带内传送同步元数据 (synchronisation metadata) 的 RTP 头部扩展.

3.1. 面向 SSM 发送方的缩短初始 RTCP 间隔

在初始同步延迟很重要的 SSM 会话中, RTP 发送方可以将发送初始复合 RTCP 数据包之前的延迟设置为零, 并在加入 SSM 会话后立即发送其第一个 RTCP 数据包. 这完全是发送方本地的改变, 可以实现为一个可配置选项. 在 SSM 会话中发送单播 RTCP 反馈的 RTP 接收方禁止以零初始延迟发送 RTCP 数据包; [RFC5760] 中定义的定时规则对接收方保持不变.

3.2. 快速重新同步请求

RTP/AVPF 传输层反馈消息的一般格式如 Figure 4 所示, 详情见 [RFC4585].

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|   FMT   | PT=RTPFB=205  |          length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  SSRC of packet sender                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  SSRC of media source                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :            Feedback Control Information (FCI)                 :
     :                                                               :

            Figure 4: RTP/AVPF Transport Layer Feedback Message

这里定义了一种新的反馈消息类型 RTCP-SR-REQ, 其 FMT = 5. 反馈消息中的 Feedback Control Information (FCI) 部分必须为空. 数据包发送方的 SSRC 表示无法同步媒体流的成员, 媒体源的 SSRC 表示该成员无法同步的媒体发送方. length 必须等于 2.

如果正在使用 RTP/AVPF 配置文件 [RFC4585], 接收方可以发送此反馈消息, 表明它无法同步某些媒体流, 并希望媒体源尽快发送 RTCP SR 数据包 (受 RTCP 早期反馈定时规则约束). 收到这种指示时, 理解 RTCP-SR-REQ 数据包的媒体源应当在遵守 RTCP 早期反馈规则的同时, 尽快生成 RTCP SR 数据包. 如果此前已经协商使用非复合 RTCP [RFC5506], 反馈请求和 RTCP SR 响应都可以作为非复合 RTCP 数据包发送. 如果还没有收到 RTCP SR 数据包, RTCP-SR-REQ 数据包可以在每个 RTCP 报告间隔中重复发送一次. 如果媒体源按常规调度发送同步元数据, 预计已足以让接收方在合理时间范围内同步媒体流, 则媒体源可以忽略 RTCP-SR-REQ 数据包.

使用带单播反馈的 SSM 会话时, 反馈目标和媒体源可能并不位于同一处. 在这种情况下, 如果反馈目标收到 RTCP-SR-REQ 反馈消息, 则应将该请求转发给媒体源. 本文不定义用于转发此类请求的机制.

如果反馈目标提供网络管理接口, 记录哪些接收方发送 RTCP-SR-REQ 反馈数据包以及哪些接收方未发送, 可能会很有用, 因为未发送者会经历更慢的流同步.

3.3. 同步元数据的带内传送

[RFC5285] 中定义的 RTP 头部扩展机制可以进行适配, 以在 RTP 数据包中携带可选的 NTP 格式时间戳 (NTP-format timestamp). 如果包含这样的时间戳, 它必须对应于数据包头部中 RTP 时间戳所表示的同一时间瞬间, 并且必须派生自用于生成 RTCP SR 数据包中 NTP 格式时间戳的同一时钟. 只要接收方知道 SSRC 到 CNAME 的映射, 无论该映射来自此前收到的 RTCP CNAME 数据包, 还是来自带外信令 (out-of-band signalling) [RFC5576], 接收方就可以将所提供的信息作为同步算法的输入, 其方式与该流又收到一个额外 RTCP SR 数据包时完全相同.

此头部扩展定义了两个变体. 第一个变体使用 [RFC5905] 中定义的 64-bit NTP 格式时间戳扩展 RTP 头部. 第二个变体携带 NTP 格式时间戳中 Seconds 的低 24-bit 部分, 以及 NTP 格式时间戳中 Fraction 的 32-bit. 这两个变体的格式如 Figure 5 和 Figure 6 所示.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|1|  CC   |M|     PT      |       sequence number         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
     |                           timestamp                           |T
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
     |           synchronisation source (SSRC) identifier            |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |       0xBE    |    0xDE       |           length=3            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
     |  ID-A | L=7   |   NTP timestamp format - Seconds (bit 0-23)   |x
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
     |NTP Sec.(24-31)|   NTP timestamp format - Fraction (bit 0-23)  |n
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |NTP Frc.(24-31)|    0 (pad)    |    0 (pad)    |    0 (pad)    |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |                         payload data                          |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 5: Variant A/64-Bit NTP RTP Header Extension

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P|1|  CC   |M|     PT      |       sequence number         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
     |                           timestamp                           |T
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
     |           synchronisation source (SSRC) identifier            |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |       0xBE    |    0xDE       |           length=2            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
     |  ID-B | L=6   |  NTP timestamp format - Seconds (bit 8-31)    |x
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
     |           NTP timestamp format - Fraction (bit 0-31)          |n
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |                         payload data                          |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 6: Variant B/56-Bit NTP RTP Header Extension

发送方可以在其选择的任何 RTP 数据包中包含 NTP 格式时间戳, 但在对通过多个 RTP 流传输的分层编解码器执行基于时间戳的解码顺序恢复时, 推荐包含该时间戳, 详见 Section 4.1. 此头部扩展还应当在对应于视频随机接入点 (video random access point) 的 RTP 数据包以及相关音频数据包中发送, 以便在多媒体会话中的后加入者场景以及视频切换场景中实现快速同步.

注意: 如果使用 RTP 头部压缩, 包含 RTP 头部扩展会降低其效率. 此外, 不理解这些头部扩展的中间盒 (middlebox) 可能会移除它们, 或者可能不会按照本文更新其内容.

在所有情况下, 无论是否包含带内 NTP 格式时间戳, 都必须发送常规 RTCP SR 数据包, 以便为按照 [RFC3550] 同步 RTP 流的接收方提供向后兼容性, 并在面对可能剥离 RTP 头部扩展的中间盒 (RTP 转换器) 时提供稳健性. 如果使用 Variant B/56-bit NTP RTP 头部扩展, 则必须使用 RTCP 发送方报告来推导 NTP 格式时间戳 Seconds 的高 8-bit.

使用 SDP 时, 必须按照 [RFC5285] 的规定指示上文定义的 RTP 头部扩展的使用. 因此, 必须使用以下 URI:

• 在 SDP 中用于以信令表示使用 Variant A/64-bit NTP RTP 头部扩展的 URI 是 "urn:ietf:params:rtp-hdrext:ntp-64".

• 在 SDP 中用于以信令表示使用 Variant B/56-bit NTP RTP 头部扩展的 URI 是 "urn:ietf:params:rtp-hdrext:ntp-56".

使用这些 RTP 头部扩展可以显著改善 IPTV 频道切换以及某些交互式视频会议场景中的用户体验. 试图监测用户体验的网络管理工具可以记录哪些会话以信令表示并使用了这些扩展.