Вопрос о структуре заголовков расширения RTP, как объяснено в RFC 8285.

В RFC 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, который объясняется в RFC. Затем идут биты «длина = 3», за которыми следуют фактические расширения. Каждое расширение состоит из идентификатора, за которым следует длина. Аналогичная структура определена для двухбайтовых расширений заголовка.

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


webrtc rtp rtcp
person asinix    schedule 08.01.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

person Philipp Hancke    schedule 08.01.2020