Вопрос о структуре заголовков расширений RTP, как объяснено в RF C 8285 - PullRequest
1 голос
/ 08 января 2020

В RF C 8285 , который касается расширений заголовка RTP, структура для расширения заголовка в 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                                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Я понимаю OxBEDE, который объясняется в RF C. Затем идут биты «length = 3», за которыми следуют фактические расширения. Каждое расширение состоит из идентификатора и длины. Аналогичная структура определена для двухбайтовых расширений заголовка.

В обоих типах заголовков я не понимаю раздел битов "length = 3". Это просто заполнение используется для 32-битной границы? Если да, то какой цели это служит? Легкость в разборе? Почему бы не запустить элементы расширения сразу после xBEDE. Конечно, было бы экономно. Может быть, я что-то упускаю, если c.

1 Ответ

1 голос
/ 08 января 2020

Это, вероятно, восходит к RF C 3550 . Такое явное указание поля длины позволяет клиентам, которые не понимают расширения, легче их пропускать. Также обратите внимание, что до тех пор, пока он не будет расширен RF C 5285 (обновлен 8285), может быть только одно расширение, так что вы видите взлом обратной совместимости.

...