1

在处理 RTP 标头扩展的RFC 8285中，1 字节标头扩展的结构如下所示（第 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 和长度组成。为两字节报头扩展定义了类似的结构。

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

4

1 回答 1

1

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

于 2020-01-08T15:13:01.853 回答