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

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

ARI нужен там, где dialplan уже тесен: IVR, очереди, перевод на внешние сервисы, запись, логика по состоянию вызова. Ключевой принцип — не делать Python «мозгом всего»; Asterisk остается точкой медиапути, а приложение через ARI управляет событиями и состояниями вызовов.

Базовая архитектура проста: ARI-сервис получает StasisStart, подписывается на channel events, создает bridge и решает, кого куда подключать. В Python держите отдельный event loop, таймауты на HTTP/WebSocket и явную модель состояний: incoming, playing, collecting_digits, bridged, hangup. Без этого появляются гонки, дублирование ответов и зависшие каналы.

Типовые ошибки:
• ответ на канал после hangup — ловите 404 и идем дальше;
• блокирующий код в обработчике событий — вы теряете очередь событий;
• отсутствие idempotency — повторный event создает второй bridge или второй playback;
• игнорирование таймаутов и retry — приложение «замирает» при сетевом сбое.

Для продакшена нужны: отдельный сервис под ARI, логирование с call_id/channel_id, health-check, ограничение параллелизма и аккуратная работа с playback/recording. Разбираем дамп трафика в Wireshark, и вот что мы там видим: чаще ломается не SIP, а именно логика приложения, когда оно не успевает синхронизировать состояние вызова с событиями Asterisk.

Если строите кастомную обработку звонков, проектируйте не «скрипт», а state machine с явными переходами, иначе масштабирование закончится на первом всплеске входящих.