Кратко

  • 24-битное поле Ident в RFC 5215 связывает данные Vorbis с нужной Configuration. Полученный индекс показывает выбор отправителя, но не доказывает, что получатель собрал, проверил и установил соответствующие codebooks.
  • При смене Ident клиент без правильной Configuration не должен декодировать связанные сырые данные. Поэтому непрерывный ряд RTP-пакетов и полная тишина могут быть одновременно корректными результатами.

Сбой, которого не было на графике потерь

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

Но в той же точке изменился Ident. Новое значение ссылалось на другую Configuration, переданную несколькими фрагментами. Один из них не дошёл. Поток данных продолжался, а математическая модель, необходимая для его прочтения, так и не стала частью состояния декодера.

RFC 5215 запрещает подменять это состояние догадкой. Если клиент видит новый Ident и не располагает правильной Configuration, он не должен декодировать относящиеся к ней данные, пока не получит конфигурацию. Тишина была не отсутствием пакетов, а корректной реакцией на отсутствие основания для интерпретации.

Указатель длиной 24 бита не является объектом

У Vorbis нет единой статически заданной вероятностной модели. Параметры энтропийного декодирования, векторного квантования и модели Huffman входят в отдельный блок конкретного потока. Декодеру также нужны сведения о каналах и другие характеристики.

Заголовки Identification и Setup должны быть доступны до интерпретации аудиокадров. Заголовок Comment входит в структуру Vorbis, но не нужен для декодирования последовательности и в упакованной форме может быть фиктивным. Человекочитаемые метаданные оказываются менее важными для исполнения, чем почти невидимый набор правил.

Ident экономит повторение: пакет несёт короткий индекс, а не всю Configuration. Это позволяет менять codebooks по ходу сеанса и работать с цепочками потоков. Однако индекс лишь объявляет зависимость. Он не подтверждает получение каждого фрагмента, успешный разбор или то, что локальная таблица связывает Ident с теми же байтами.

Панель, объединяющая payload type, частоту, число каналов, Ident и долю полученных пакетов в один зелёный статус, смешивает описание с исполнением. Ни одно из этих полей само по себе не является инвентаризацией состояния декодера.

SDP задаёт входные данные, но не удостоверяет установку

В rtpmap описание сеанса может сообщить vorbis, тактовую частоту и число каналов. RFC 5215 предлагает считать эти значения подсказками: точные сведения приносит Configuration. Обязательный параметр configuration размещается в fmtp, а для нецепочечного потока рекомендуется передать Packed Configuration в исходном SDP.

Настройки способны меняться внутри сеанса. Новые codebooks доставляются в RTP, с новым описанием сеанса либо по внешнему адресу. Поддержка доставки внутри полосы обязательна, внешнего пути — желательна. RTP-метка времени Configuration указывает первый пакет данных, к которому она относится.

Это граница применимости, а не квитанция получателя. Отправитель может доказать корректное объявление новой конфигурации, но не её своевременную установку на каждом клиенте.

Один редкий объект определяет судьбу тысяч пакетов

Configuration бывает значительно крупнее обычного аудиопакета, поэтому она фрагментируется и периодически повторяется. Потеря сырого пакета обычно отнимает участок сигнала. Потеря фрагмента Configuration может сделать недекодируемым весь последующий поток с данным Ident.

Метрика по количеству пакетов переворачивает приоритеты. Тысячи успешно доставленных малых объектов статистически скрывают единственный пропуск. Но именно редкий объект даёт смысл всем остальным. Транспортная доступность близка к ста процентам, полезная — к нулю.

Клиент может запросить Configuration снова, взять её из внешнего источника, дождаться повтора или буферизовать данные. Он также может сбросить или завершить сеанс. Позднее восстановление спасёт запись, но не обязательно прямой эфир. Сброс вернёт звук, но способен уничтожить причинное состояние.

Квитанция на право декодировать

Надёжная запись связывает поколение offer/answer, SSRC и payload type с точным хешем Packed Configuration. В ней Ident сопоставляется с хешами Identification и Setup и с первой применимой RTP-меткой времени.

Далее фиксируется путь доставки, полнота фрагментов, результат разбора и время установки на клиенте. Нужна фактическая таблица Ident→хеш, а не только заявление сервера. Пока настройки не было, следует отмечать буферизованные и отброшенные пакеты, попытки повторной передачи и внешней загрузки. Первый декодированный кадр, переданные на воспроизведение семплы и наблюдаемый выход завершают цепочку.

Эта «квитанция на право декодировать» — редакционный вывод BTW, а не дополнительное требование RFC 5215. Она удерживает каждое свидетельство в своих границах. RTP говорит о транспорте, SDP — о согласовании, Ident — о выборе, установленное состояние — о способности интерпретировать, а выход — о выполненной услуге.

Принцип работающего кода у Heng Lu даёт точный критерий: видимое объявление приобретает действие только в компоненте, который его потребляет. Повторение Ident в каждом пакете не создаёт отсутствующие codebooks. Ссылка не вправе представлять объект, которого нет.

Поэтому зрелый отчёт не прячет вывод: сеть доставила все пакеты, но звук не был доставлен, поскольку условие их понимания не дошло до декодера вовремя.

Источники

  1. RFC 5215
  2. IETF Datatracker — RFC 5215
  3. Сведения о RFC 5215
  4. История RFC 5215
  5. RFC 3550 — RTP
  6. RFC 4566 — SDP
  7. RFC 3264 — Offer/Answer
  8. RFC 4588 — повторная передача RTP
  9. RFC 3611 — RTCP XR
  10. RFC 3533 — инкапсуляция Ogg
  11. RFC 4648 — Base-кодирование
  12. RFC 3986 — URI
  13. RFC 3551 — профиль RTP
  14. RFC 1191 — Path MTU
  15. RFC 1981 — IPv6 Path MTU
  16. Спецификация Vorbis I
  17. RFC 8088 — ограничители RTP
  18. RFC 8866 — SDP
  19. Heng Lu — приоритет работающего кода