关于 RFC 8285 中解释的 RTP 扩展 headers 结构的问题

Question

在处理 RTP Header 扩展的 RFC 8285 中，1 字节 header 扩展的结构如下所示（第 4.2 节）：

  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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       0xBE    |    0xDE       |           length=3            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  ID   | L=0   |     data      |  ID   |  L=1  |   data...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ...data   |    0 (pad)    |    0 (pad)    |  ID   | L=3   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          data                                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

我了解 RFC 中解释的 OxBEDE。然后是“length=3”位，其后是实际的扩展名。每个扩展都由 ID 和长度组成。为 two-byte header 扩展定义了类似的结构。

在这两种类型的 header 中，我不理解“length=3”位部分。它只是用于 32 位边界的填充吗？如果是这样，这样做的目的是什么？易于解析？为什么不在 xBEDE 之后立即启动扩展元素。当然会 space 高效。可能是我遗漏了一些基本的东西。

Answer 1

这可能可以追溯到 RFC 3550。像这样明确指定长度字段允许不理解扩展的客户端更容易地跳过它们。另请注意，在 RFC 5285（由 8285 更新）扩展之前，只能有一个扩展，因此您看到的是向后兼容性 hack。

关于 RFC 8285 中解释的 RTP 扩展 headers 结构的问题

Question on the structure of RTP Extension headers as explaind in RFC 8285

webrtc

rtp

rtcp