Кратко

  • RFC 3119 предписывал имя mp3 для SDP, хотя зарегистрированный подтип и соседний пример rtpmap содержали mpa-robust; RFC 5219 привёл имя кодирования к единому виду.
  • Преемник сохранил конструкцию RTP-полезной нагрузки на основе ADU и назвал правки псевдокода небольшими, ненормативными уточнениями. В истории стандартов нет подтверждения, что работающая реализация использовала противоречивое имя или что из-за него сорвался сеанс.

Два имени в одном разделе

Это расхождение легко не заметить. Опубликованный в 2001 году RFC 3119 регистрирует mpa-robust как тип медиаданных для своего формата MP3 поверх RTP. Однако в разделе об использовании SDP он требует имя кодирования mp3. Сразу следом пример назначает динамический тип полезной нагрузки 121 и указывает a=rtpmap:121 mpa-robust/90000.

Эти строки описывают один формат на разных уровнях. RTP переносит номера типов полезной нагрузки; для динамического номера атрибут SDP rtpmap сообщает другой стороне, какому кодированию и тактовой частоте он соответствует. Это сопоставление определяет RFC 4566. Поэтому RFC 3119 предлагал два несовместимых имени для описания сеанса, хотя зарегистрированный подтип и пример сопоставления совпадали.

Речь не только об опечатке. Сам по себе динамический номер не раскрывает содержимое пакетов. Обеим сторонам нужно общее сопоставление между номером в RTP-пакете и форматом, ожидаемым получателем. Конструкция полезной нагрузки может быть внутренне согласованной, даже если переговорный уровень, который её описывает, содержит противоречие. Документы подтверждают дефект спецификации, но не показывают поведение реального оборудования.

Зачем понадобился другой формат RTP

Исходная конструкция учитывала конкретное свойство MP3 Layer III. Кадр может ссылаться назад на закодированные данные из предыдущих кадров и потому не всегда является самостоятельной единицей декодирования. RFC 3119 объяснял, что выравнивание RTP-пакетов по границам кадров при потере пакета способно сделать бесполезными данные и в других, успешно доставленных кадрах.

Альтернатива перестраивала поток в единицы прикладных данных (ADU). Перед каждой ADU помещался дескриптор с её размером и признаком продолжения из другого пакета. Отправитель мог также перемежать ADU, распределяя последовательные единицы по непоследовательным пакетам. Это было не простым добавлением избыточности: границы пакетов переносились относительно единиц, которые обрабатывает декодер, при сохранении закодированных данных.

Опубликованный в феврале 2008 года RFC 5219 сохранил этот базовый подход. Во введении снова изложены обратная ссылка, ADU, дескрипторы и необязательное перемежение. В аннотации сказано, что документ заменяет RFC 3119, исправляя типографские ошибки в разделе SDP и приложениях с псевдокодом. Приложение C уточняет: основное изменение — имя кодирования SDP; в приложениях A и B внесены небольшие исправления и уточнения ненормативного псевдокода.

Исправление сформулировано прямо. RFC 5219 требует имя mpa-robust в соответствии с зарегистрированным подтипом; его пример по-прежнему сопоставляет динамический тип 121 с mpa-robust/90000. Проверенная редактором RFC запись об ошибке 3119 также фиксирует исходное расхождение и несколько правок примеров: backpointer — это значение, а не размер; вместо curADU должна использоваться переменная prevADU; два предела массива в B.2 меняются с 32 на 256. Так уточняется письменная инструкция, но это не доказывает, что полезная нагрузка в работающих сетях изменилась в 2008 году.

Номер RFC — не отчёт об аварии

RFC 5219 показывает, что стандарты исправляются на нескольких уровнях. Имя SDP относится к нормативным правилам описания сеанса: редакция уточняет, как участникам называть кодирование. Правки приложений касаются псевдокода, который сам RFC 5219 обозначает как ненормативный. Ни один из этих фактов сам по себе не измеряет масштаб эксплуатационной проблемы.

В документах нет обзора реализаций, захвата пакетов, записи о сорванном соединении, примечаний к выпуску поставщика или сравнительного теста до и после. Они не утверждают, что какое-либо устройство действительно объявляло mp3, что другая сторона отвергала его или что исправленное написание повысило совместимость в измеренных развёртываниях. Подтверждённая редактором запись об ошибке доказывает дефект текста, но не частоту его воспроизведения программами.

Именно эту историческую границу нужно сохранять. RFC 5219 заменил предшественника, потому что инструкцию для описания сеанса следовало исправить, а часть рекомендаций по реализации — уточнить. Модель полезной нагрузки с ADU осталась прежней. Стандарты фиксируют, что исправили авторы; для вывода о влиянии на реальные системы нужны отдельные свидетельства из реализаций и сеансов.

Источники

  1. https://www.rfc-editor.org/rfc/rfc3119.html
  2. https://www.rfc-editor.org/info/rfc3119/
  3. https://www.rfc-editor.org/rfc/rfc5219.html
  4. https://www.rfc-editor.org/info/rfc5219/
  5. https://datatracker.ietf.org/doc/rfc5219/
  6. https://www.rfc-editor.org/errata/eid331
  7. https://www.rfc-editor.org/rfc/rfc4566.html
  8. https://www.rfc-editor.org/rfc/rfc2250.html
  9. https://www.rfc-editor.org/rfc/rfc3550.html
  10. https://www.rfc-editor.org/rfc/rfc3551.html
  11. https://www.rfc-editor.org/rfc/rfc2736.html