ARI или почему ami — зло

Этим докладом мы начинаем цикл выступлений о технологиях управления Asterisk, которые часто называют «злом», — AMI, AGI и ARI.

Основная цель — не противопоставить их друг другу, а разобраться, для каких задач каждая технология действительно подходит, и почему появление ARI (Asterisk REST Interface) стало логичным этапом развития Asterisk.

Исторический контекст: как Asterisk управлялся раньше

Когда Asterisk появился в 1999 году, никакого API в современном понимании не существовало. Управление осуществлялось исключительно через CLI.
Позже появился AMI (Asterisk Manager Interface) — telnet-интерфейс, который позволил управлять:

• каналами (channels);
• событиями вызовов;
• базовым call control.

AMI даёт широкие возможности, но при высокой нагрузке требует парсинга большого количества событий, что усложняет разработку и масштабирование.

AGI: гибкость ценой блокировок

Следующим шагом развития стал AGI — Asterisk Gateway Interface. Он позволил передавать управление dialplan во внешний скрипт и выносить бизнес-логику за пределы Asterisk, используя любой удобный язык программирования.

Однако у AGI есть принципиальное ограничение: это синхронный интерфейс. Пока AGI-скрипт выполняется, dialplan фактически блокируется. В простых сценариях это не вызывает проблем, но при усложнении логики — необходимости отслеживать DTMF, реагировать на состояние канала или обрабатывать несколько событий параллельно — такие блокировки начинают мешать.

В результате во многих проектах AGI приходилось дополнять AMI, чтобы компенсировать эти ограничения. Это увеличивало сложность архитектуры и делало решения менее устойчивыми при высокой нагрузке.

Появление ARI и его архитектура

Начиная с Asterisk 13, был представлен ARI — Asterisk REST Interface. Это полноценный REST-интерфейс, состоящий из трёх ключевых частей:

1. REST API — управление ресурсами Asterisk (channels, bridges, endpoints и др.).
2. WebSocket — асинхронные события в формате JSON.
3. Stasis Application — приложение, которому передаётся управление вызовом.

Ключевая особенность ARI — работа через Stasis.
Когда вызов попадает в Stasis, Asterisk больше не управляет им автоматически — вся логика переходит во внешнее приложение.

Важно понимать:

• Stasis-приложение не завершается само;
• события остаются активными, пока приложение их явно не обработает;
• ответственность за жизненный цикл вызова полностью лежит на разработчике.

Философия ARI: не управление, а создание приложений

ARI часто воспринимают как замену AMI или AGI, но это неверный подход. ARI — не просто ещё один интерфейс управления Asterisk, а инструмент для создания собственных коммуникационных приложений.

Если в AGI можно передать вызов стандартному voicemail, то в ARI необходимо реализовать собственный voicemail-сценарий. ARI не предназначен для управления примитивами Asterisk «из коробки», он даёт возможность построить свою логику обработки вызовов поверх существующего ядра.

При этом каждая технология остаётся на своём месте: AMI подходит для управления и мониторинга, AGI — для логики внутри dialplan, а ARI — для асинхронных сценариев и внешних сервисов.

Практические кейсы, где ARI выигрывает

External Media и TTS / STT

Одно из самых сильных нововведений — External Media (Asterisk 16+).
ARI позволяет отправлять RTP-поток во внешнее приложение и получать его обратно.

Это критично для:

• синтеза речи (TTS);
• распознавания речи (STT);
• интеграции с Google Speech, Yandex Speech и другими сервисами.

В отличие от AMI и AGI:

• медиапоток не нужно «костылить» через файловые дескрипторы;
• логика обработки полностью контролируется приложением.

External Media и TTS / STT

ARI удобно использовать для:

• мониторинга состояния каналов и endpoints;
• сбора RTP-статистики по Call-ID;
• интеграции с Zabbix, Prometheus и другими системами.

Простой HTTP-запрос с curl часто заменяет сложный парсинг AMI-событий.

Управляемые обзвоны
Вместо call-файлов и слепых запусков:

• ARI позволяет точно знать статус каждого вызова;
• контролировать соединение каналов;
• управлять логикой обзвона в реальном времени.