RTPengine без схемы: как не утонуть в медиатрафике при росте нагрузки

RTPengine без схемы: как не утонуть в медиатрафике при росте нагрузки

Если SIP-сигнализацию еще можно балансировать L7, то RTP требует отдельной логики: медиапуть должен быть предсказуемым, а не “как получится” через NAT, разные подсети и асимметричный маршрут. Разбираем дамп трафика в Wireshark, и вот что мы там видим: звонок есть, а аудио идет в обход или режется фаерволом.

Базовый паттерн такой: SIP-узлы принимают сигнализацию, а RTPengine становится B2BUA для медиа и закрепляет RTP-сессию за конкретным медиа-сервером. Это дает контроль над адресацией, NAT traversal, transcoding и anchoring потока. Для горизонтального роста важно не смешивать control-plane и media-plane: Asterisk/FreeSWITCH не должны тащить весь RTP, если их роль — только сигнализация, IVR или логика маршрутизации.

Критичные точки отказа: • нет sticky-логики на уровне SIP-dialog, и re-INVITE уходит на другой узел; • RTPengine не знает о медиасессии после failover; • health-check проверяет только SIP-порт, но не реальную передачу RTP; • не учтены symmetric RTP и conntrack на firewall. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Практически это решается пулом RTPengine за балансировщиком, где вызов фиксируется по Call-ID, From-tag и SDP-параметрам. Балансировщик не должен “раскидывать пакеты”, он должен обеспечивать детерминированный выбор узла и быстрый вывод из пула при деградации медиа. Оптимизируем обработку RTP-трафика и минимизируем джиттер в сети.

Если RTPengine стоит отдельно от SBC, сначала проектируйте не количество серверов, а жизненный цикл сессии: создание, re-INVITE, teardown, failover. Только после этого масштабирование становится линейным, а не аварийным.