ARI + Python: как не сломать обработку звонков при первом кастомном приложении

ARI даёт прямой контроль над вызовом, но вместе с ним — ответственность за state machine. Если приложение не держит входящий канал, не обрабатывает hangup и не восстанавливает подписки на события, вы получите зависшие каналы, утечки ресурсов и «тихие» отказы в маршрутизации.

Базовый паттерн такой: Asterisk отвечает за SIP/RTP и создает события, Python-сервис через WebSocket читает ARI, а бизнес-логика живет отдельно от dialplan. В dialplan оставляйте только вход в приложение: answer, set переменных, bridge в ARI-оркестратор. Вся логика перевода, IVR, запись, очереди и таймауты — в коде.

Критичные правила реализации:
— идентифицируйте вызов по linkedid и храните состояние вне памяти процесса;
— обрабатывайте StasisStart, ChannelDestroyed, Hangup и ошибки WebSocket;
— делайте идемпотентные обработчики: повторное событие не должно ломать сценарий;
— не держите блокирующий код внутри event loop, выносите HTTP/DB/RTP-операции в отдельные воркеры.

Для Python обычно хватает aiohttp или websockets, плюс отдельный слой для очередей и ретраев. Если нужен bridge, создавайте его явно и контролируйте участников через ARI, а не через «магические» экстеншены. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Разбираем дамп трафика в Wireshark, и вот что мы там видим: стабильный ARI-проект — это не «скрипт на коленке», а сервис с явными состояниями, таймаутами и журналированием каждого transition.