Как не задушить SIP-голос: кодеки, полоса и запас на RTP-поток
При проектировании голосовой сети смотрят не только на битрейт кодека, но и на накладные расходы SIP/RTP, заголовки IP/UDP, интерливинг пакетов и поведение NAT. Если считать только G.711 или G.729, реальная нагрузка на канал почти всегда окажется выше расчётной.
Базовое правило: кодек выбирают от сети, а не от вкуса. Для WAN и транзитных участков чаще фиксируют один-двa кодека в приоритете, чтобы избежать лишних трансляций. Каждая transcoding-операция съедает CPU и добавляет задержку, поэтому лучше строить маршрут так, чтобы Asterisk, FreeSWITCH или SBC пропускали RTP без перекодирования.
Для оценки ёмкости используйте не «битрейт на вызов», а полный профиль: RTP payload + headers + пакетизация + запас на джиттер. На практике полезно закладывать резерв 20–30% на burst-трафик, повторные SIP-INVITE, фрагментацию и параллельные служебные потоки. Если в сети есть QoS, голос должен идти в отдельном классе с приоритетом очереди и ограничением policing на остальных классах.
Разбираем дамп трафика в Wireshark, и вот что мы там видим: loss, jitter и reordering часто появляются не из-за кодека, а из-за перегруженного uplink, асимметричной маршрутизации или неправильного MTU. Проверяйте DSCP-маркировку, RTP pinhole на firewall и отсутствие NAT hairpin для внутренних вызовов.
Оптимизируем RTP-трафик и минимизируем джиттер в сети: уберите лишний transcoding, зафиксируйте набор кодеков, посчитайте реальную полосу с заголовками и держите запас. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.
Работа с API телефонии
@phone_api_gateway_arb
Как не задушить SIP-голос: кодеки, полоса и запас на RTP-поток
Этот пост опубликован в Telegram-канале Работа с API телефонии. Подписаться можно по ссылке: @phone_api_gateway_arb.