<b>Отказоустойчивый Phone API Gateway: схема, которая переживает пики и падение узлов</b>

<b>Отказоустойчивый Phone API Gateway: схема, которая переживает пики и падение узлов</b>

Phone API Gateway нельзя строить как один «толстый» сервер. Входной слой должен принимать SIP/WebRTC, нормализовать сигналы и раздавать вызовы по нескольким медиасерверам. Перед ним — балансировщик с health-check по SIP OPTIONS и отдельным контролем RTP, иначе живой SIP-порт еще не значит живой шлюз.

Дальше работают два независимых контура:
— сигнализация: Kamailio/OpenSIPS, stateless, с гео- и весовой маршрутизацией;
— медиа: Asterisk/FreeSWITCH, stateful, с pinned calls и выключенным лишним hairpin.
Важно держать SIP и RTP в разных плоскостях: signaling может пережить рестарт, а медиа-сессия — нет, поэтому нужна sticky-политика на время звонка и предсказуемый failover на уровне нового INVITE.

Отказоустойчивость ломается не на «железе», а на состояниях: NAT bindings, транки, регистрация, очереди, DTMF, запись. Храните критичные состояния вне узла — Redis, SQL, shared DB, но без попытки тащить в кластер RTP-стрим как «общий ресурс». Для медиа используйте горячий резерв, а не актив-актив на одном и том же вызове.

Разбираем дамп трафика в Wireshark, и вот что мы там видим: при деградации шлюза SIP 200 OK еще может проходить, но RTP уже сыпется из-за потери маршрута или исчерпания портов. Поэтому мониторинг должен смотреть не только на процесс, но и на качество медиа: MOS, jitter, packet loss, ASR/ACD, количество незавершенных диалогов.

Проектируйте шлюз как набор независимых отказов, а не как один «кластер». Тогда при падении узла вы теряете не платформу, а только текущие сессии, и это уже управляемый риск.