Как ужать голосовой трафик без потери качества и не убить SIP-ядро
При проектировании голосовой сети сначала фиксируют не «какой кодек красивее», а где платится полоса: SIP-сигнализация, RTP-поток, транскодирование на SBC или медиасервере. Если звонок идет G.711 end-to-end, считайте не только payload, но и накладные расходы IP/UDP/RTP, VLAN и L2. В реальной сети именно это съедает магистраль и ломает емкость.
Базовое правило: кодек выбирают по профилю канала. Для LAN и коротких транков часто оставляют G.711, чтобы не тратить CPU на транскодирование. Для WAN и удаленных площадок лучше смотреть в сторону узкополосных кодеков с фиксированным битрейтом. Главное — не смешивать «экономию полосы» с «экономией ресурсов»: один лишний transcoding-hop может стоить дороже, чем сэкономленные килобиты.
Контрольные точки:
— на SBC и Asterisk/FreeSWITCH отключайте лишние codec-matching и запрещайте нежелательные альтернативы;
— следите, чтобы приоритет кодека в SDP совпадал на обоих концах;
— для RTP включайте packetization interval без фанатизма: меньше ptime — больше пакетов и overhead;
— закладывайте запас на джиттер-буфер, echo cancellation и burst loss, иначе экономия полосы превращается в деградацию MOS.
Отдельно проверяйте MTU, QoS и очереди на WAN: голосу вредят не только потери, но и микрозадержки. Разбираем дамп трафика в Wireshark, и вот что мы там видим: лишние фрагментации, перекос DSCP, retransmit на соседнем трафике. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.
Практика простая: сначала считайте емкость канала с учетом overhead, потом режьте кодеки и только после этого меняйте маршрутизацию.
Работа с API телефонии
@phone_api_gateway_arb
Как ужать голосовой трафик без потери качества и не убить SIP-ядро
Этот пост опубликован в Telegram-канале Работа с API телефонии. Подписаться можно по ссылке: @phone_api_gateway_arb.