Кратко

  • В публикации LACNIC от 26 августа 2026 года César Díaz объясняет переход телефонии на IP и прямо указывает, что к звуку добавляются заголовки и управляющие данные. Нового правила расчёта ёмкости он не объявляет.
  • Для непрерывной одноканальной речи в одном направлении при интервале 20 ms поток G.729 на 8 kbit/s составляет 24 kbit/s с базовыми IPv4/UDP/RTP-заголовками и 32 kbit/s с IPv6.
  • Более длинные пакеты позволяют реже передавать заголовки, но требуют дольше накапливать звук и увеличивают длительность фрагмента, потерянного вместе с пакетом.

Экономия, у которой есть часы

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

Такой вопрос естественно продолжает статью LACNIC о преобразовании телефонных вызовов. В тексте от 26 августа César Díaz сопоставляет G.711 на 64 кбит/с с более экономными способами кодирования. Он отдельно отмечает заголовки IP и управляющий трафик. Следовательно, речь не о разоблачении неверной цифры, а о практическом значении уже сделанной оговорки.

Для начала рассмотрим фиксированную конфигурацию. RFC 3551 описывает кадр G.729 длиной 10 байт, соответствующий 10 миллисекундам речи. По умолчанию два кадра объединяются в пакет на 20 миллисекунд. При непрерывном звуке это 20 байт полезной нагрузки и 50 пакетов в секунду.

К ним добавляются 12 байт основного заголовка RTP, восемь байт UDP и минимум 20 байт IPv4. Полный IP-пакет занимает 60 байт. Умножение 60 × 50 × 8 даёт 24 кбит/с, хотя аудиоданные по-прежнему занимают только 8 кбит/с.

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

Что именно сравнивается

В таблице предполагаются непрерывная одноканальная речь в одном направлении, интервал 20 ms и несжатые базовые заголовки без опций и расширений. Основной заголовок IPv6 занимает 40 байт вместо минимальных 20 у IPv4.

Кодек Только звук Пакетов в секунду Полные пакеты IPv4 Полные пакеты IPv6
G.711 64 kbit/s 50 80 kbit/s 88 kbit/s
G.729 8 kbit/s 50 24 kbit/s 32 kbit/s

Объём закодированного звука уменьшился в восемь раз. Для полных пакетов IPv4 отношение составляет 80 к 24, приблизительно 3,33 к одному. Частота отправки не изменилась. Поэтому сокращение числа байтов само по себе не доказывает такое же уменьшение работы, которую оборудование выполняет для каждого пакета.

Разница между двумя IP-колонками тоже имеет узкий смысл: дополнительные 20 байт, передаваемые 50 раз в секунду, добавляют 8 кбит/с. Это не сравнение полной стоимости IPv4 и IPv6 и не основание отказываться от внедрения IPv6.

За пределами модели остаются сигнализация, RTCP, дополнительные средства защиты, туннели, кадры канального уровня, избыточность и запас пропускной способности. Подавление тишины изменит характер трафика. В разговоре два направления, а здесь подсчитано одно. Нельзя превращать эти величины в универсальную полосу для целого звонка.

Два счётчика также могут расходиться без ошибки: приложение считает полезный звук, а сетевой счётчик — полный IP-пакет. Сначала надо установить границу измерения, а уже затем искать неисправность.

Меньше заголовков — больше ожидания

Теперь изменим только интервал. В модели G.729 с теми же заголовками IPv4 пакеты на 10 ms требуют 40 kbit/s, на 20 ms — 24, на 40 ms — 16. Во всех трёх случаях кодек остаётся на 8 kbit/s. Снижается частота передачи фиксированной части пакета.

Цена появляется во времени. Для более длинного пакета нужно накопить больше речи, а его потеря затронет более длинный участок разговора. RFC 3551 прямо связывает увеличение интервала с меньшими накладными расходами, но большей задержкой и более заметным воздействием потерь. Минимальное число в колонке трафика не выбирает подходящую настройку.

Сам RTP не гарантирует своевременную доставку. Номера последовательности и временные метки полезны получателю, однако не подтверждают качество разговорного сервиса. Его надо проверять на предполагаемом пути и в условиях приложения.

LACNIC объясняет, почему общая IP-инфраструктура и эффективное кодирование дают преимущества. Для закупки ёмкости этого объяснения недостаточно без сохранения условий расчёта. Иначе корректный битрейт незаметно становится обещанием, которого ни кодек, ни автор статьи не давали.