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

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

Phone API Gateway нельзя строить как один SIP-прокси перед Asterisk. Это точка входа, где сходятся SIP, RTP, WebRTC и внешние API, поэтому архитектура должна переживать отказ узла без потери маршрутизации и сессий.

Базовый паттерн: несколько stateless-gateway узлов за L4/L7 балансировщиком, а состояние вызова выносится в внешнее хранилище или в кластерный контроллер. SIP-сигнализация должна уметь идти по любой ноде, а RTP — либо пиноваться на media relay, либо фиксироваться через session affinity. Иначе при перекидывании диалога получите рассыпание SDP и повторный INVITE по кривому пути.

Критично разделить контуры:
— сигнализация отдельно от медиа;
— авторизация и rate limit отдельно от маршрутизации;
— транзит на PSTN отдельно от внутренних диалпланов;
— health-check не только по TCP, но и по SIP OPTIONS с проверкой ответов 200/403.

Разбираем дамп трафика в Wireshark, и вот что мы там видим: при деградации шлюза чаще ломается не RTP, а контрольная плоскость. Если upstream отвечает, но не может создать транзакцию в БД или Redis, вызов висит в полудобитом состоянии. Лечится это таймаутами на каждый hop, idempotent-логикой на уровне API и быстрым failover на резервный маршрут. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Практика простая: строим gateway как распределенный state machine с журналированием событий, отдельным media plane и жестким лимитом на очереди. Тогда при падении одного узла вызов либо корректно дожимается на соседнем, либо завершается предсказуемым кодом, без залипания трубки и фантомных сессий.