RTPengine не “ускоряет” звонки, а снимает с ядра медиапуть и NAT-боль

RTPengine не “ускоряет” звонки, а снимает с ядра медиапуть и NAT-боль

Когда SIP-сигналинг живёт отдельно от RTP, масштабирование строится вокруг медиа-узла: Asterisk/FreeSWITCH держат логику вызова, а RTPengine принимает, проксирует и при необходимости транскодирует поток. Это снимает с SBC и приложений прямую работу с внешними адресами, asymmetrical RTP и hairpin NAT.

Ключевые правила:
• держите RTPengine ближе к пограничным сегментам сети, чтобы сократить RTT и джиттер;
• разделяйте signalling и media plane по разным интерфейсам и таблицам маршрутизации;
• не смешивайте транскодирование и простую проксификацию на одном “тяжёлом” контуре без расчёта CPU и pps;
• для отказоустойчивости используйте несколько RTPengine за балансировщиком, но маршрутизацию RTP увязывайте с тем, где хранится состояние диалога.

Балансировщик для RTP — это не L4 для HTTP. Здесь важны sticky-правила, одинаковые ACL, синхронная конфигурация и предсказуемый возврат пакетов. Если один узел получил offer, а ответ ушёл на другой, получите односторонний звук, резаный аудиоканал или silent call. Разбираем дамп трафика в Wireshark, и вот что мы там видим: SIP-сессия установлена, а RTP идёт в чёрную дыру из-за неверного media-handover.

На практике схема выглядит так: SIP-сервер принимает INVITE, через control-канал отдаёт SDP в RTPengine, тот переписывает адреса и пины, затем медиапоток идёт через выбранный узел. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Если нужен рост без сюрпризов, проектируйте RTP как отдельный слой, а не как побочный эффект SIP-стека.