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

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

Phone API Gateway нельзя строить как один «умный» сервер с логикой, SIP-терминацией и медиа. Правильная схема — разнести control plane и media plane: входящие SIP/HTTP идут на edge, а RTP либо проксируется через отдельный media relay, либо закрепляется за выделенными медианодами. Иначе NAT, фрагментация маршрутов и stateful-сессии быстро превращают отказ одного узла в массовый обрыв вызовов.

Базовый контур обычно такой: DNS SRV/Anycast на входе, несколько stateless-edge нод, за ними кластер маршрутизации, отдельно — B2BUA/softswitch и пул RTP-relay. Между слоями нужен health-check не только по TCP-порту, но и по реальному сценарию: INVITE → 200 OK → ACK → RTP. Если узел отвечает на ping, но не собирает медиасессию, это уже деградация, а не «живой сервис».

Критичные правила:
— Не хранить диалоговое состояние только в памяти одного процесса.
— Не держать sticky-session без резервного маршрута.
— Не смешивать SIP-сигнализацию и тяжелую запись/транскодирование на одном CPU-контуре.
— Закладывать быстрый failover на уровне SBC или Kamailio, а не в приложении.

Разбираем дамп трафика в Wireshark, и вот что мы там видим: при перегрузе первым ломается не SIP, а RTP-джиттер и очереди на медиасегменте. Поэтому лимиты по CPS, очереди на транзите и отдельные quotas на транскодирование должны быть частью архитектуры, а не «потом докрутим». Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.