Как мы строили Programmable Voice сервис на Asterisk

Построение голосовых сервисов на базе Asterisk в облачной среде требует не только понимания телефонии, но и продуманной архитектуры взаимодействия с внешними API, масштабирования и отказоустойчивости. Далее рассматривается практический опыт построения Voice-платформы с использованием Asterisk, ARI и собственного прокси-слоя, а также проблемы, с которыми пришлось столкнуться в реальной эксплуатации.

Платформа MessageBird и Voice API

MessageBird относится к классу CPaaS-платформ — коммуникаций как сервиса. Платформа объединяет множество каналов взаимодействия: голосовую связь, SMS, мессенджеры, email, API для чатов и полноценные колл-центры. Решение используется крупными компаниями и рассчитано на работу с большими объёмами трафика.

В контексте голосовых сервисов ключевым элементом является Voice API — программный интерфейс для управления звонками. Он позволяет строить сценарии входящих и исходящих вызовов, работать с SIP-транкингом и, при необходимости, использовать графический интерфейс вместо прямого обращения к API. Вся логика сценариев абстрагирована от конкретной реализации Asterisk.

Архитектура Call Flow и работа с Asterisk

В основе голосовой логики лежит Call Flow — сценарий обработки звонка, который описывает последовательность шагов: приветствие, IVR, ввод DTMF, соединение абонентов и завершение вызова. С точки зрения Asterisk взаимодействие предельно упрощено и строится через ARI.

Используется минимальный dialplan:

• вход в Stasis,
• завершение вызова (Hangup).

Вся остальная логика вынесена во внешний сервис и управляется через события ARI. Такой подход позволяет гибко управлять звонками, не усложняя конфигурацию Asterisk и не перегружая dialplan бизнес-логикой.

Управление звонками через ARI

ARI используется как основной механизм управления состоянием звонка. Каждый шаг сценария — это реакция на событие, пришедшее от Asterisk. Например, при воспроизведении приветствия заранее сгенерированный аудиофайл передаётся в Asterisk, после чего начинается ожидание пользовательского ввода.

Типовой сценарий выглядит следующим образом:

• воспроизведение приветствия;
• ожидание DTMF;
• обработка выбора пользователя;
• создание Bridge и соединение абонентов;
• завершение звонка при разрыве канала.

Ключевая сложность заключается в большом количестве событий ARI и их неоднозначной интерпретации. В частности, обработка ChannelHangupRequest и ChannelDestroyed приводила к попыткам завершить один и тот же звонок дважды, что вызывало состояния гонки и некорректную работу логики.

Масштабирование и отказоустойчивость

Для решения задач масштабирования платформа была перенесена в Kubernetes. Это позволило избавиться от проблем горизонтального масштабирования, но не решило вопрос отказоустойчивости полностью. Asterisk взаимодействует с Voice API через WebSocket, и при обновлении сервисов часть активных соединений терялась.

Для решения этой проблемы был реализован ARI-прокси, который взял на себя:

• приём событий от Asterisk;
• постановку событий в очередь;
• повторную отправку при сбоях;
• изоляцию Voice API от нестабильных соединений.

Дополнительные сложности возникли из-за особенностей балансировки нагрузки и долгоживущих соединений. Переход на HTTP/1 решил часть проблем, но привёл к росту потребления файловых дескрипторов на Asterisk-серверах при высокой нагрузке.

Контроль состояния каналов и биллинг

Отдельной критической задачей стал контроль завершения звонков, так как биллинг полностью завязан на события ChannelDestroyed. Потеря этого события приводила к «вечным» звонкам и некорректным списаниям, особенно опасным для предоплаченных клиентов.

Для решения была реализована система Channel Watcher:

• при создании канала он добавляется в очередь наблюдения;
• каждые 10 секунд выполняется запрос ChannelInfo в Asterisk;
• при ошибке канал принудительно завершается на стороне API.

Этот механизм позволил компенсировать потерю событий, но полностью проблему не устранил. Нарушение порядка событий, особенно при быстром вводе DTMF и одновременных обновлениях системы, остаётся архитектурным ограничением текущего решения.