RTPengine как точка масштабирования: где заканчивается SIP и начинается медиа

RTPengine как точка масштабирования: где заканчивается SIP и начинается медиа

Когда SIP-сигналинг уже уехал в кластер, а RTP всё ещё проходит через один узел, бутылочное горлышко обычно сидит не в CPS, а в media-plane. RTPengine решает это не «магией балансировки», а строгой привязкой медиа-сессии к конкретному экземпляру, где важны NAT, симметричный RTP, conntrack и контроль таймеров.

Базовая схема выглядит так: Kamailio или другой SIP-proxy принимает INVITE, выбирает RTPengine по hash от Call-ID/From/To, и переписывает SDP так, чтобы оба конца видели адрес медиа-сервера, а не друг друга. Если нужна отказоустойчивость, используйте несколько RTPengine-нод и детерминированный алгоритм выбора; при падении узла новая сессия уйдёт на живой экземпляр, а активная — не должна зависеть от одного firewall state.

Критичные правила эксплуатации:
— не смешивайте управление сигналингом и медиа на одном сервере без жёсткого лимита CPU;
— держите отдельные pools под WebRTC и обычный SIP;
— фиксируйте допустимые кодеки на границе, иначе transcoding съест весь запас;
— следите за MTU, jitter buffer и RTP timeout, иначе «плавающие» обрывы будут выглядеть как проблемы оператора.

Разбираем дамп трафика в Wireshark, и вот что мы там видим: если RTP идёт в обход media-server, значит SDP не был переписан; если пакеты есть, а аудио нет — смотрите NAT hairpin, asymmetric routing и firewall pinholes. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Практика простая: балансируйте не RTP-пакеты, а медиа-сессии, и считайте RTPengine частью stateful-архитектуры, а не обычным L4-узлом.