Отказоустойчивый Phone API Gateway: как не уронить SIP при пиковых нагрузках

Отказоустойчивый Phone API Gateway: как не уронить SIP при пиковых нагрузках

Phone API Gateway — это не один сервер, а контур: SIP edge, медиапрокси, балансировщик и слой маршрутизации. Если смешать signaling и RTP на одной точке, вы получите SPOF, проблемы с NAT и деградацию под нагрузкой. Разделяйте плоскости: SIP-алгоритмы отдельно, медиа отдельно, хранение состояния — в реплицируемом backend.

Базовая схема выглядит так: внешний LB принимает TLS/SIP, дальше трафик уходит на Kamailio/OpenSIPS как stateless edge, а медиа выводится через RTPengine/медиашлюз. Для сценариев с B2BUA и записью звонков Asterisk/FreeSWITCH лучше держать за отдельным маршрутом, чтобы не тащить тяжелую логику в критический путь. Разбираем дамп трафика в Wireshark, и вот что мы там видим: retransmit INVITE часто связан не с SIP-сервером, а с асимметричным маршрутом или неверным advertised address.

Критичные правила:
• health-check должен проверять не только TCP-порт, но и SIP OPTIONS с контрольным ответом;
• sticky session нужна только там, где реально есть диалоговое состояние;
• failover должен учитывать timer-ы SIP, иначе получите каскадные повторные вызовы;
• лимиты на CPS, concurrent dialogs и RTP ports ставьте до ввода в прод, а не после инцидента.

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