Кратко

  • RFC 3952 не передавала число кадров iLBC: получатель делил длину RTP-нагрузки на 38 или 50 октетов в зависимости от режима, согласованного через SDP.
  • Errata, поданная в 2026 году и пока имеющая статус Reported, предлагает исправить 32/50 на 38/50; совпавшая длина не заменяет доказательство переговоров, защиты, декодирования и воспроизведения.

Счётчик исчез, состояние осталось

Двадцатимиллисекундный кадр занимал 38 октетов, тридцатимиллисекундный — 50. RFC 3952 разрешала поместить несколько кадров подряд и не добавляла отдельное число. Зная режим, получатель восстанавливал границы делением.

Поэтому 76 октетов означали два кадра при mode 20, а 100 — два при mode 30. Пакет сообщал делимое; сигнализация сообщала делитель. Архив мог сохранить каждый байт RTP и всё же потерять правило, которым пользовался узел.

Стандарт запрещал делить один кадр между пакетами и смешивать два режима внутри пакета. Число агрегированных кадров не должно было выводить пакет за MTU. Малое число сокращало задержку и увеличивало долю заголовков; большое экономило накладные расходы, но усиливало последствия одной потери.

Режим был общим решением сторон

В SDP формат обозначался iLBC/8000, а a=fmtp переносил mode. При отсутствии параметра действовал mode 30. В двустороннем сеансе обе стороны обязаны были применять один итог.

Предложение выражало предпочтение, ответ мог назвать другое значение. Общим становился режим с меньшей полосой. 50 октетов раз в 30 мс дают меньшую скорость полезной нагрузки, чем 38 раз в 20 мс, поэтому оба примера разногласия в RFC завершаются mode 30.

RFC 2327 задавала SDP, RFC 3264 — модель offer/answer, а RFC 3550 — последовательность и время RTP. Эти записи не были взаимозаменяемы: принятый SDP не доказывал соблюдение каждым пакетом, а корректная последовательность не объявляла размер iLBC-кадра.

Ошибка возникла в самой формуле

Разделы 2 и 3.1 RFC 3952 указывают 38 октетов для 20 мс. Это согласуется с описанием кодека в RFC 3951. Но раздел 3.2, объясняя деление, печатает 32/50.

На странице errata запись 8866 от 3 апреля 2026 года предлагает 38/50. Её статус — Reported, не Verified. Внутренняя согласованность сильно поддерживает 38, но состояние редакционного процесса следует называть точно.

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

Нулевой остаток был началом проверки

При mode 20 длина 114 даёт три кадра без остатка. Это свидетельство совместимости длины. Оно не подтверждает допустимость кодовых слов, личность отправителя, SRTP, решение jitter buffer, декодирование или звук на выходе.

RFC 3711 определяет SRTP отдельно. Аутентифицированная нагрузка может быть непригодной при устаревшем режиме; делимая открытая нагрузка никого не аутентифицирует. Остаток указывает на рассинхронизацию режима, неверный payload type, повреждение или неполный захват, но не выбирает причину.

Карточка RFC Editor датирует экспериментальный документ декабрём 2004 года. Его урок не требует всегда передавать счётчик. Он требует видеть, куда переехало состояние после оптимизации. Если внешний контракт не хранится, компактность формата превращается в нехватку доказательств.

Источники