Отказоустойчивый Phone API Gateway: схема, которая не падает под нагрузкой
Шлюз для телефонии — это не «один сервер с SIP-аккаунтами», а слой маршрутизации между API, SIP, RTP и внешними транками. Если он один, то любой сбой бьёт сразу по входящим, исходящим и callback-сценариям. Базовый паттерн: stateless edge, отдельный media-plane, а состояние вызова — во внешнем хранилище или в B2BUA-кластере.
Критичные узлы:
— балансировка по SIP/RTP отдельно, без попытки «склеить» всё в одном LB;
— health-check не только по TCP-порту, но и по SIP OPTIONS, регистрации и пробному INVITE;
— симметричный NAT, корректный rport/received, явный advertise/public IP;
— контроль лимитов: CPS, число диалогов, таймауты на 100rel, re-INVITE, BYE.
Разбираем дамп трафика в Wireshark, и вот что мы там видим: большинство аварий начинается не с падения процесса, а с асимметрии маршрута, потери RTP после failover или «залипших» диалогов в таблице транзакций. Поэтому state sync должен покрывать только то, что реально нужно для перевода вызова, а не весь SIP-трафик целиком. Иначе получите кластер, который синхронизируется медленно и деградирует под нагрузкой.
Практический каркас: два edge-узла, любойcast/ECMP или L4-L7 балансировщик, отдельные медианоды, централизованный сигналинг-бэкенд, понятная стратегия draining при выводе узла. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.
Если шлюз проектируется как набор независимых плоскостей, он переживает отказ одного узла без потери сессий и без ручного вмешательства.
Работа с API телефонии
@phone_api_gateway_arb
Отказоустойчивый Phone API Gateway: схема, которая не падает под нагрузкой
Этот пост опубликован в Telegram-канале Работа с API телефонии. Подписаться можно по ссылке: @phone_api_gateway_arb.