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

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

Phone API Gateway не должен быть «толстым» медиа-сервисом. Его роль — быстро принять HTTP/Webhook/API-запрос, проверить политику, выбрать маршрут и отдать вызов в SIP-контур. Медиа и сигнализацию лучше разделять: API-слой без RTP, SIP-прокси отдельно, media relay отдельно. Так проще масштабировать и изолировать отказ.

Базовая схема: LB/Ingress → stateless API gateway → очередь/контур маршрутизации → Kamailio/registrar → Asterisk/FreeSWITCH → RTP relay. На уровне шлюза держим только идентификацию, авторизацию, rate limit, идемпотентность и запись в журнал событий. Все, что связано с диалогом SIP, должно переживать рестарты без потери состояния.

Критичные правила:
• не хранить состояние вызова в памяти одного инстанса;
• делать health-check не только по TCP, но и по зависимостям: Redis, БД, SIP edge;
• ограничивать burst по tenant, а не глобально;
• выносить retry в асинхронный контур, чтобы не дублировать INVITE.

Разбираем дамп трафика в Wireshark, и вот что мы там видим... при перегрузе чаще всего ломается не RTP, а логика маршрутизации: таймауты API, повторная отправка webhook, гонка за один и тот же call-id. Лечится корреляционным ID, дедупликацией событий и жестким разделением control plane / media plane. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Практика простая: делайте gateway stateless, SIP-контур кластерным, RTP — максимально коротким по пути. Тогда падение одного узла не превращается в каскадный обвал звонков.