Asterisk + Tinkoff VoiceKit или почему мы отказались от uniMRCP

Голосовые роботы давно перестали быть экспериментом и всё чаще используются в промышленных сценариях: уведомлениях, опросах, напоминаниях и первичном взаимодействии с клиентами. Особенно это актуально для компаний, где телефонный канал — один из ключевых способов коммуникации.

При этом классические инструменты Asterisk не всегда подходят для построения «человекообразных» сценариев: с перебиванием, фоновым распознаванием речи и сложной логикой диалога. Ниже рассматривается практический путь к созданию таких роботов — от первых MVP до собственной неблокирующей архитектуры и open-source-модулей.

Зачем вообще нужны голосовые роботы

В массовых сценариях значительная часть звонков укладывается в простые и короткие диалоги. В реальных кейсах до 80–85% разговоров длятся меньше минуты и подчиняются предсказуемому сценарию. Это делает их хорошими кандидатами для автоматизации.

Попытки выполнять такие задачи силами операторов быстро упираются в низкую эффективность. Например, обзвоны с напоминанием о платеже дают минимальную конверсию, при этом требуют значительных ресурсов. Это и стало отправной точкой для перехода к роботам.

Первый подход и ограничения UnimRCP

Начальный MVP был построен на базе UnimRCP с интеграцией распознавания и синтеза речи. Такой вариант позволяет быстро запустить прототип, но довольно рано проявляет архитектурные ограничения.

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

Даже наличие гибридных приложений вроде Synth & Recog не решает проблему масштабируемости: при усложнении сценариев архитектура перестаёт быть расширяемой.

Первый подход и ограничения UnimRCP

AGI и FastAGI выглядят более гибкими, так как позволяют выносить логику за пределы Asterisk. Однако на практике они создают другие сложности.

Вся бизнес-логика оказывается жёстко привязана к конкретному языку и реализации, а каждый вызов сопровождается запуском отдельного процесса. Кроме того, Asterisk в такой схеме фактически превращается в прокси, а управление звонком размазывается между AGI-кодом и AMI-клиентом.

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

Переход к неблокирующей модели и gRPC

Вместо этого был выбран путь разработки собственных модулей с неблокирующей логикой, аналогичной работе с асинхронными сокетами. Ключевая идея — вынести распознавание и синтез в фоновые потоки, а в dialplan оставить только управление событиями.

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

Так появилась связка модулей AST VoiceKit, включающая фоновое распознавание, управление воспроизведением и синтезом речи, а также механизм ожидания и обработки событий.

Управление событиями и построение сценариев

Ключевым элементом архитектуры стало управление событиями в dialplan. Для этого используется отдельный модуль ожидания событий с тайм-аутом, который позволяет строить циклы обработки без блокировки канала.

Событиями могут быть:

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

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

Такой подход позволяет реализовывать гибридные сценарии: сочетать предзаписанные фразы и синтез речи, накладывать несколько аудиослоёв, корректно перебивать пользователя и управлять диалогом в реальном времени.