<b>Как ужать голосовой трафик без потери качества и не убить RTP-поток</b>

<b>Как ужать голосовой трафик без потери качества и не убить RTP-поток</b>

Для телефонии важны не только выбранный кодек, но и накладные расходы: SIP-заголовки, RTP/UDP/IP, VLAN, а иногда ещё SRTP. Если на линии G.711 проходит 80 кбит/с на канал, это не значит, что столько же надо считать в QoS-плане: реальная полоса зависит от packetization time, заголовков и количества вызовов.

Главное правило: кодек выбирают не по “качеству на слух”, а по профилю сети.
• G.711 — минимальная задержка, но высокая нагрузка на канал.
• G.729/Opus/AMR дают экономию полосы, но требуют CPU на транскодирование и аккуратной настройки jitter buffer.
• Если обе стороны поддерживают один и тот же кодек, запрещайте лишний transcoding в SBC или Asterisk: каждый переход кодека добавляет задержку и риск артефактов.

Оптимизация начинается с трёх параметров: ptime, размер RTP-пакета и маршрутизация медиа. Увеличение ptime снижает частоту пакетов и нагрузку на сеть, но повышает latency и потери при обрывах. Для WAN и перегруженных каналов полезно считать не только Mbps, но и packets per second: именно pps часто упирается в NAT, firewall и softswitch.

Разбираем дамп трафика в Wireshark, и вот что мы там видим: если джиттер растёт, а RTCP reports показывают burst loss, проблема может быть не в кодеке, а в очередях, микробёрстах и неправильном QoS. Голосовой трафик надо маркировать DSCP, изолировать в отдельный класс и не смешивать с bulk TCP.

Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Сначала режем транскодирование, затем считаем pps и задержку, и только после этого выбираем кодек под реальную сеть.