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

Phone API Gateway — это не «один сервер с Asterisk», а слой маршрутизации между приложением, SIP/SBC и медиасетью. Базовая схема: App → API Gateway → SIP Proxy/SBC → B2BUA/PBX → Trunks. На границе обязателен отдельный контур для сигнализации и RTP, иначе NAT, фрагментация и перегрузка медиапути быстро превращаются в потерю вызовов.

Критичные элементы архитектуры:
— stateless API-сервис с быстрым failover через LB;
— SIP proxy в актив-актив, без хранения сессий в памяти одного узла;
— B2BUA/PBX в кластере, но с явным контролем sticky-routing;
— отдельный media-relay, если нужен SRTP, transcoding или обход NAT.

Для отказоустойчивости не смешивайте роли. API-слой принимает запросы, валидирует, кладёт задачу в очередь и лишь потом инициирует SIP-сценарий. Если downstream не отвечает, должен сработать retry с идемпотентным ключом, а не повторный звонок «вслепую». Иначе получите дубли вызовов и гонки в CDR.

Отдельно проверьте таймауты: DNS, TCP connect, SIP provisional, 200 OK, RTP timeout. Неверная связка таймаутов даёт ложные failover-срабатывания и лавину re-INVITE/BYE. Разбираем дамп трафика в Wireshark, и вот что мы там видим: чаще всего шлюз жив, но балансировщик уже отрезал долгую установку сессии.

Практика простая: режьте состояние на минимум, держите health-check на уровне SIP OPTIONS и контролируйте RTP отдельно от сигнализации. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.