RTPengine спасает SIP-кластер, но только если медиа вынесено из маршрутизации

RTPengine спасает SIP-кластер, но только если медиа вынесено из маршрутизации

Если SIP-сигналинг уже живёт за балансировщиком, а RTP всё ещё идёт «напрямую», узкое место обычно не в CPS, а в media-plane. Правильная схема простая: B2BUA/прокси обрабатывает INVITE, а RTPengine подменяет SDP и держит медиа-потоки на себе. Тогда Kamailio остаётся быстрым контроллером вызова, а медиа не ломает latency и не упирается в conntrack.

Ключевые правила размещения:
— RTPengine ставят ближе к SIP-edge, а не в глубину DC
— балансируют не RTP-пакеты, а сессии через несколько медиа-нод
— hashing по Call-ID и branch обязателен, иначе re-INVITE уйдёт на другой узел
— sticky-сессия нужна не только для звонка, но и для SRTP keying, DTMF relay, hold/resume

Типовая ошибка — пытаться балансировать UDP-поток L4-сплитом без контроля состояния. RTP сессия живёт дольше, чем один SIP-диалог, и при failover без синхронизации таблиц вызовов получите one-way audio, «тишину» после перевода и разъезд SSRC. Нормальный паттерн: единый контроллер маршрутизации, несколько RTPengine, health-check по control socket и аварийный вывод узла из пула без разрыва активных call legs.

Для отказоустойчивости держите две зоны медиа, разные подсети для RTP и management, и жёстко ограничивайте advertised address, иначе NAT начнёт маппить не туда. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Если медиа не отделено от сигналинга, масштабирование заканчивается раньше, чем заканчивается CPU. Оптимизируем обработку RTP-трафика и минимизируем джиттер в сети.