Кратко

  • RFC 3555 связал имена форматов RTP с реестром медиатипов и задал явное преобразование в SDP; его преемники разделили процедуру и конкретные записи, сохранив основную схему.
  • Запись IANA подтверждает состояние каталога и нормативную ссылку, но не наличие кодека, согласованность параметров, соответствие пакетов или результат декодирования.

В замороженном XML реестра IANA рядом с audio/L16, audio/PCMA и audio/PCMU стоит ссылка на RFC 4856. Это не ошибка и не исчезновение истории. В 2007 году RFC 4855 и RFC 4856 совместно объявили RFC 3555 устаревшим: первый сохранил и обновил процедуру регистрации, второй вынес конкретные регистрации профиля RTP.

RFC 4856 отдельно отметил, что перенос записей не внёс в них технических изменений. Значит, административная точка ссылки сменилась, а формат не был автоматически переписан. Такое различие позволяет поддерживать каталог, общую процедуру и спецификации нагрузок в разных циклах.

Как одна строка превращалась в несколько свидетельств

RFC 3555 показывал выражение audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15. В SDP оно не сохранялось единым фрагментом.

audio становилось типом среды в строке m=. L16, частота часов RTP и два канала составляли a=rtpmap:97 L16/48000/2. Параметр emphasis переходил в a=fmtp:97. Рекомендованная длительность пакета становилась самостоятельным a=ptime:5.

Каждая часть отвечала на свой вопрос. Тип описывал класс среды. rtpmap давал локальному номеру нагрузки имя, часы и параметры кодирования. fmtp переносил значения, смысл которых должен знать инструмент формата. ptime выражал рекомендацию по длительности, но не телеметрию фактических пакетов.

Номер 97 не был всемирным кодом L16. В другой сессии он мог означать другой формат, а L16 мог получить другой номер. Архив RTP без соответствующего SDP теряет связь, необходимую для толкования динамического номера. Но архив SDP без пакетов тоже не доказывает исполнение заявленного договора.

Реестр не мог дописать формат

Особенно важен запрет RFC 3555 на расширение набора форматных параметров одной лишь регистрацией медиаподтипа. Допустимые параметры определял RFC формата нагрузки. Регистрация могла объяснить, как перенести их в fmtp, но для новой семантики требовалось изменить саму спецификацию нагрузки.

Иначе административная запись получила бы власть менять байты на линии. Частный ключ способен работать между двумя согласованными реализациями, но не становится от этого общим стандартом. SDP может передать непрозрачное значение, не понимая его; принимающая программа может его отвергнуть или истолковать иначе.

Нечувствительность к регистру символов тоже была ограниченной. Имена кодировок и имена параметров сравнивались без учёта регистра, поскольку профиль RTP и медиатипы традиционно оформляли их по-разному. Это не означало, что все значения параметров можно самовольно переводить в нижний регистр.

Что именно продолжает жить

Замороженная копия IANA обновлена 6 октября 2026 года. В ней 165 аудиозаписей и 97 видеозаписей; двадцать прямо ссылаются на RFC 4856. Эти числа относятся к каталогу на указанную дату. Они не измеряют распространённость кодеков и не описывают ни одного звонка, устройства или потока.

Нынешняя спецификация SDP, RFC 8866, продолжает различать rtpmap и fmtp. Первая связь объясняет номер, имя, часы и параметры кодирования; второе поле передаёт форматные параметры инструменту, который их реализует. Успешный разбор SDP поэтому остаётся лишь промежуточным доказательством.

Полная цепочка длиннее: строка медиатипа принята; подтип зарегистрирован для нужного транспорта; параметры попали в верные поля; динамический номер связан с точной комбинацией; оба конца поддерживают формат; пакеты соответствуют описанию; декодер выдаёт пригодный результат. Ни один ранний шаг не гарантирует поздний.

Историческое значение RFC 3555 состоит в отказе от магии общего имени. Имя можно было перенести, потому что стандарт показал маршрут каждого параметра и оставил исполнение там, где оно действительно происходит — в работающем коде.

Источники