Как сжать голосовой трафик без потери качества и не убить SIP-сеть
Для голоса узкое место почти всегда не RTP как таковой, а комбинация кодека, ptime, NAT и лишней трансформации медиа. Если между абонентами возможен прямой поток без transcoding — это лучший путь: каждый лишний пересчет аудио съедает CPU, добавляет задержку и повышает риск артефактов.
Базовая схема оптимизации выглядит так:
— G.711 оставляют для локальных сегментов и точек, где важна минимальная задержка.
— Opus или G.729 используют на WAN/мобильных каналах, где дороже полоса, чем CPU.
— Исключают transcoding в ядре, а на SBC или B2BUA жестко фиксируют приоритет кодеков.
— Укорачивают ptime до разумного значения: меньше пакет — выше накладные расходы, больше пакет — выше задержка и потери при джиттере.
По сети смотрим не только на Mbps, но и на PPS: для голоса критичны число пакетов, очереди на интерфейсах, MTU, QoS и корректная маркировка DSCP. Разбираем дамп трафика в Wireshark, и вот что мы там видим: RTP идет ровно до момента, когда очередь на аплинке забивается фоновым трафиком, после чего появляются jitter, packet loss и «металлический» голос. Здесь помогает не магия, а приоритизация голосового VLAN, ограничение burst-трафика и контроль буферблоута. 📡
Если у вас несколько площадок, задавайте профиль кодеков по направлению: внутри офиса один набор, через VPN другой, на внешних транках третий. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Нельзя допускать, чтобы один неудачный preferred codec ломал переговоры на всей цепочке.
Оптимизируем обработку RTP-трафика и минимизируем джиттер в сети. Начинайте не с «какой кодек лучше», а с профиля нагрузки: сколько одновременных вызовов, какие каналы, где будет transcoding и кто реально держит очереди на линии.
Работа с API телефонии
@phone_api_gateway_arb
Как сжать голосовой трафик без потери качества и не убить SIP-сеть
Этот пост опубликован в Telegram-канале Работа с API телефонии. Подписаться можно по ссылке: @phone_api_gateway_arb.