ARI + Python для обработки звонков: как не превратить Asterisk в монолит

ARI + Python для обработки звонков: как не превратить Asterisk в монолит

Если логика звонка уходит в Python, Asterisk должен остаться медиасервером и SIP-ядром, а не «всем сразу». Через ARI управляйте только тем, что действительно требует прикладной логики: ответ, постановка в bridge, transfer, запись, play/stop, DTMF-сценарии. RTP, транки, NAT, таймауты и failover должны жить в самой телефонии, а не в коде приложения.

Базовый паттерн простой: ARI-приложение подписывается на StasisStart, получает call_id, строит состояние вызова и хранит его отдельно от потока событий. Не держите логику в одном long-poll цикле без контроля reconnect: при обрыве websocket нужен idempotent recovery по channel.id и bridge.id. Для Python используйте явную модель состояний, а не набор if-else на события.

Из типовых ошибок:
• смешивать SIP-логику и бизнес-правила в одном обработчике;
• создавать bridge до полной готовности канала;
• игнорировать race condition между Hangup и ChannelDestroyed;
• не ограничивать таймауты на внешние API и БД.

Для продакшена сразу закладывайте: очередь событий, retry с backoff, дедупликацию команд, structured logging с correlation_id и отдельный watchdog на reconnect к ARI. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Если приложение падает, звонок не должен зависеть от одного процесса Python.

Правильная схема такая: Asterisk принимает и маршрутизирует вызов, ARI-приложение оркестрирует сценарий, а все тяжёлые интеграции выносятся во внешние сервисы. Разбираем дамп трафика в Wireshark, и вот что мы там видим: стабильность начинается там, где у каждого слоя есть своя зона ответственности.