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

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

Когда SIP-сигнализация уже живёт отдельно от медиа, узкое место почти всегда сидит в RTP: NAT, симметрия потоков, DSCP, переполненные очереди и hairpin через ядро. Решение — вынести media relay в отдельный слой и не пускать RTP через B2BUA, если он не должен транскодировать или записывать разговор.

Типовая схема: SBC/Kamailio держит сигнализацию, RTPengine принимает offer/answer, переписывает SDP, закрепляет media endpoint и гонит пакеты по shortest path. Для горизонтального масштаба важны не «мощные сервера», а предсказуемая привязка сессии: одинаковая логика выбора узла, стабильный hashing по Call-ID или 5-tuple, отсутствие случайного флапа между инстансами.

Практика настройки:
— держите RTPengine ближе к краю сети, а не за несколькими L3-hop;
— разделяйте control-plane и data-plane: SIP может идти через один кластер, RTP — через другой;
— используйте health-check не только на TCP-порт, но и на реальную обработку SDP/RTP;
— не смешивайте транскодирование и pure relay в одном пуле без профилей нагрузки;
— следите за симметрией NAT: если наружу уходит один адрес, то и обратный поток должен возвращаться туда же.

Разбираем дамп трафика в Wireshark, и вот что мы там видим: если RTPengine выбран правильно, потери проявляются как локальный джиттер, а не как каскадный обрыв сессии. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Правильный балансировщик для RTP — тот, который не ломает медиасессию при отказе соседнего узла.