Кратко

  • RFC 5577 заменил прежнюю спецификацию RTP payload, добавив поддержку аудио 14 кГц из приложения C рекомендации G.722.1, тактовую частоту 32 кГц и режим 48 кбит/с.
  • Жёсткого разрыва с прежним профилем он не требовал: для совместимости RFC рекомендовал и дальше предлагать вариант 16 кГц, а каждую планируемую комбинацию тактовой частоты и битрейта предписывал объявлять через SDP.

Замена спецификации не устраняет терминалы, знающие прежнюю

Опубликованный в июле 2009 года RFC 5577 начинался отметкой «Obsoletes: 3047». Её легко прочесть как мгновенное переключение: одна спецификация вышла, другая вступила в силу. Но раздел о совместимости описывал более осторожный переход. RFC 3047 задавал для G.722.1 тактовую частоту дискретизации 16 кГц. Новая редакция добавила поддержку сверхширокополосного аудио из приложения C пересмотренной рекомендации ITU-T: полоса аудио расширилась до 14 кГц, появилась конфигурация с частотой 32 кГц и битрейтом 48 кбит/с.

Эти числа относятся к разным параметрам. 14 кГц — полоса закодированного аудио; 16 или 32 кГц — тактовая частота дискретизации, используемая временными метками RTP; 24, 32 или 48 кбит/с — скорость кодека. RFC 5577 не свёл их к одной настройке «качества». Используемую комбинацию описывает сигнализация сеанса.

В битовом потоке кодека не было внутриполосного уведомления о смене битрейта. Поэтому RFC 5577 потребовал отдельную сигнализацию и закрепил постоянный битрейт за каждым значением RTP payload type. Приложение могло менять профиль между пакетами, но только присваивая разные значения payload type. В SDP атрибут a=rtpmap задаёт кодирование и тактовую частоту, а a=fmtp — битрейт. Вместе они описывают конфигурацию, которую предлагают принимающей стороне.

В модели Offer/Answer это объявление становилось обязательным условием работы. RFC 5577 требовал перечислять в offer каждую конфигурацию, которую отправитель намеревался использовать. Затем он прямо указывал на разрыв совместимости: RFC 3047 поддерживал только частоту 16 кГц, поэтому для взаимодействия со старыми терминалами следовало также предложить payload type с частотой 16 кГц. В примере профили 16 кГц/24 кбит/с и 32 кГц/48 кбит/с назначены разным типам payload.

Это не означает, что любой старый терминал мог успешно согласовать параметры или что новая конфигурация автоматически переключалась на старую. Offer перечисляет допустимые варианты, но не доказывает ответ другой стороны или то, что звук дошёл до слушателя. Принимающий терминал должен выбрать поддерживаемый профиль, а дальнейший сеанс — передавать согласованную конфигурацию. RFC 5577 сохранил путь, но не зафиксировал, кто им воспользовался.

Структура пакета сохранила ещё одну границу. Длительность кадра осталась равной 20 миллисекундам. При стандартных битрейтах один кадр занимал 60, 80 или 120 октетов. В пакет можно было объединить последовательные кадры с одинаковыми битрейтом и тактовой частотой; делить кадр между пакетами запрещалось. Число кадров не передавалось отдельным полем: получатель вычислял его по общей длине payload и ожидаемому числу октетов на кадр. Для телефонии, чувствительной к задержке, RFC советовал меньше кадров на пакет; потоковое воспроизведение и обмен сообщениями могли терпеть больше. Универсальное значение задержки он не устанавливал.

Как документ о миграции, RFC 5577 рассказывает не о том, как «новый кодек вытеснил старый», а о сохранении явного выбора. Строка “Obsoletes” заменила нормативный текст. Предложение профиля 16 кГц оставило прежнюю границу совместимости доступной. Ни одно из этих утверждений не показывает, сколько терминалов реализовали тот или иной профиль.

Источники