Phone API Gateway под нагрузкой: как не положить SIP, RTP и интеграции

Phone API Gateway под нагрузкой: как не положить SIP, RTP и интеграции

Шлюз должен быть не “сервером с Asterisk”, а слоем маршрутизации между внешними API и телеком-ядром. Его задача: принять запрос, проверить авторизацию, выбрать маршрут, отдать вызов в SBC/softswitch и пережить отказ любого узла без потери сессии.

Базовая схема: API Gateway без stateful-сессий, отдельный control-plane и media-plane, балансировка по L4/L7, а состояние вызова — в Redis или БД с TTL. SIP-трафик лучше уводить через Kamailio/OpenSIPS, RTP — напрямую между SBC и конечными узлами, иначе получите лишний jitter и рост задержки.

На практике ломается не SIP, а обвязка:
• нет idempotency-key — повторный POST создает дубль вызова;
• нет circuit breaker — таймауты интеграции валят весь пул;
• нет очереди на provisioning — burst запросов забивает backend;
• нет sticky-маршрутизации по Call-ID — теряются транзакции при failover.
Разбираем дамп трафика в Wireshark, и вот что мы там видим: INVITE ушел, 200 OK вернулся, а ACK потерялся на промежуточном NAT из-за неверного contact/record-route.

Отказоустойчивость — это не кластер ради кластера. Нужны health-check на SIP OPTIONS, active-active узлы, быстрый перевод маршрута, отдельный мониторинг ASR/ACD/answer-seizure latency и журналирование всех решений маршрутизатора. Оптимизируем обработку RTP-трафика и минимизируем джиттер в сети.

Если шлюз не умеет переживать повтор запроса, обрыв backend и смену маршрута без повторного набора номера — это не gateway, а точка отказа.