Как не сломать обработку звонков в Asterisk ARI, когда пишете логику на Python

Как не сломать обработку звонков в Asterisk ARI, когда пишете логику на Python

ARI — это не «ещё один REST API», а событийная шина управления звонком. Типовая ошибка: пытаться держать всю бизнес-логику в одном Python-процессе без очереди, таймаутов и восстановления состояния. В результате любой сетевой сбой между приложением и Asterisk превращает диалог в непредсказуемое поведение.

Разбираем рабочий каркас:
• Stasis-вход только для маршрутизации, а не для тяжёлой логики
• События ARI складывать в очередь, обработку отделять от приёма
• Состояние звонка хранить вне процесса: Redis, PostgreSQL, in-memory cache с реконструкцией
• Все действия над каналом делать идемпотентными: answer, bridge, play, hangup должны безопасно повторяться

Разбираем дамп трафика в Wireshark, и вот что мы там видим... ARI-приложение должно переживать дубли событий, рестарты и reorder. Если вы реагируете на ChannelCreated как на единственный источник истины, то при реконнекте получите двойной bridge, потерянный hangup или вечный «зависший» канал. Нормальный паттерн — state machine по uniqueid/channel id и явные переходы состояний.

Для Python-пакета держите отдельный слой: transport, event dispatcher, call state, action executor. Асинхронный клиент полезен, но не спасает без backpressure: ограничивайте число одновременных операций, логируйте correlation id и не блокируйте обработчик событий синхронным I/O. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Если нужен предсказуемый call-flow, проектируйте ARI-приложение как распределённую систему: с очередями, таймаутами, реконнектом и журналом состояний. Тогда Python остаётся оркестратором, а не точкой отказа.