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

ARI нужен там, где dialplan уже не тянет сложную логику: IVR с состояниями, маршрутизация по БД, callback, bridge-оркестрация, запись и контроль медиа. Но ошибка многих проектов одна: управление call flow пишут как синхронный скрипт, а событийную модель Asterisk игнорируют.

Правильный каркас такой:
• ARI-сервис держит только оркестрацию вызова, без бизнес-логики в теле хендлера.
• Состояние звонка хранится вне процесса: Redis, PostgreSQL или хотя бы in-memory cache с TTL.
• Каждый event обрабатывается идемпотентно: StasisStart, ChannelDestroyed, BridgeDestroyed, ChannelStateChange.

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

Еще один критичный момент — ошибка “два источника истины”. Если dialplan уже перевел канал в Stasis, дальнейший контроль маршрута должен быть только в ARI. Иначе получите гонки: один поток кладет канал в bridge, второй делает hangup, третий пытается сыграть prompt. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Держите логику звонка событийной, состояние — внешним, а обработчики — идемпотентными. Тогда кастомное приложение на Asterisk ARI и Python переживет нагрузку, рестарты и неожиданные сценарии без хаоса в call flow.