【问题标题】:Question on the structure of RTP Extension headers as explaind in RFC 8285RFC 8285 中解释的有关 RTP 扩展标头结构的问题
【发布时间】:2020-04-26 03:40:31
【问题描述】:

在处理RTP Header Extensions的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 之后立即启动扩展元素。当然会节省空间。 可能是我缺少一些基本的东西。

【问题讨论】:

    标签: webrtc rtp rtcp


    【解决方案1】:

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2023-01-21
      • 2013-08-08
      • 1970-01-01
      • 2013-07-05
      • 1970-01-01
      • 2011-03-10
      • 1970-01-01
      相关资源
      最近更新 更多