Прыжок сквозь время или как обновить Asterisk 11 до 18

Введение

     В данном докладе описан опыт обновления Asterisk с 11-й версии до 18-й. Рассматриваются причины, повлиявшие на необходимость обновления, возникавшие сложности и способы их решения, а также конечные результаты проделанной работы.

Предыстория и причины обновления

     Изначально в инфраструктуре использовался кластер Asterisk 11 и многочисленные скрипты на Perl. Казалось бы, такого сочетания более чем достаточно, однако объём этих скриптов был велик, и они активно взаимодействовали с Asterisk по AMI и через FastAGI. Длительное время подобная конфигурация работала стабильно, однако с выходом новых версий, в которых были устранены недостатки предыдущих релизов и добавлен актуальный функционал, сформировались конкретные цели для обновления.

Основными целями стали:

1. Переход на актуальную версию из пакетов – чтобы упростить будущие апгрейды и воспользоваться новыми возможностями Asterisk.
2. Оптимизация инфраструктуры – потребность в ней выявилась в процессе обновления.
3. Внедрение ARI – для использования современных методов разработки и более удобного взаимодействия с системой.
4. Интеграция платформы автоматизации контакт-центра – обеспечивающая более гибкую и интеллектуальную обработку входящих вызовов.

Процесс обновления и автоматизация

     В имеющемся кластере три сервера работают в продакшене и один – в резерве, при этом балансировка трафика идёт через Kamailio. Чтобы ускорить и упростить процесс обновления, применён Ansible. Роль Ansible, созданная после рефакторинга проекта и удаления неиспользуемых компонентов, за 20 минут разворачивает на серверах Asterisk требуемой версии, производит настройку iptables, SystemD, обновляет ПО и выполняет прочие необходимые задачи.

Основные проблемы и их решения

• Неподдерживаемая библиотека для AMI (Perl).Использовавшаяся библиотека (выпущенная в 2011 году) перестала корректно работать, начиная с Asterisk 13, из-за изменений в формате выдаваемых сообщений. Рассматривались несколько вариантов решения: создание локального API на Python или переписывание скриптов под ARI. Однако удалось найти готовое исправление на GitHub (решение Евгения Горькова), позволившее адаптировать эту библиотеку к Asterisk 16, а впоследствии успешно протестировать и на 18-й версии. 
• Изменения в AMI-событиях. В новых релизах Asterisk некоторые события были переименованы и содержали расширенный набор данных. Например, раньше при соединении каналов генерировался ивент Bridge один раз за звонок, а в версии 18 его заменили на BridgeEnter, причём событие вызывается для каждого канала отдельно. Для корректной работы пришлось переписать соответствующие Perl-скрипты и учесть все изменения в поведении.
• Нюансы приложения Queue в диалплане. Предположительно в Asterisk 11 существовала ошибка, на которую опиралась логика отслеживания переводов вызовов из одной очереди в другую. В 18-й версии баг исправили, и привычный «маркер» исчез. Для решения этого задействовано приложение UserEvent, позволяющее создавать собственное AMI-событие с любым набором параметров (например, операторы источника и приёмника перевода). Скрипты, работающие по AMI, теперь получают нужный сигнал именно через UserEvent.

Оптимизация инфраструктуры

     В процессе обновления стало ясно, что необходимо более надёжное решение, чем прямое обращение скриптов к AMI: при высокой нагрузке или сетевых сбоях соединения могли разрываться, что приводило к дублированию вызовов и ошибкам в статистике. Для повышения отказоустойчивости события AMI начали складываться в Redis, а дальнейшая обработка ведётся уже скриптами, которые берут данные из Redis в формате JSON. Если одно соединение прерывается, нагрузка перенаправляется на резервный сервер.

     Также объединили два разных скрипта (для статистики и для бизнес-логики звонков), которые вели обработку одних и тех же событий, чтобы упростить поддержку. Дополнительно настроили фильтрацию в manager.conf, исключив из потока ненужные события (например, NewExten или Varset со значениями, не влияющими на бизнес-логику). Это значительно снизило объём трафика и нагрузку на систему.

Внедрение ARI

• Работа с внешними API
  Раньше для запросов к внешним сервисам использовалось приложение Curl в диалплане, причём ответ парсился там же. Теперь применяется приложение на Go вместе с библиотекой ari-proxy: одна строчка в диалплане передаёт вызов в Stasis-приложение, которое само обращается к API, парсит ответ и возвращает в Asterisk уже готовый результат.
• Снятие метрик по каналам
  ARI упрощает доступ к метрикам каналов (например, джиттер), что помогает оперативно реагировать на проблемы со звуком.
• Постепенный отказ от AMI
  Благодаря ARI создаётся REST-интерфейс, позволяющий упростить разработку и поддержку. Переписка всего функционала требует времени, поэтому переход идёт постепенно: новые компоненты сразу реализуются на ARI, а старые модули переезжают по мере необходимости.

Интеграция платформы контакт-центра

     Одним из приоритетных направлений стало внедрение интеллектуальной платформы автоматизации контакт-центра. Прежний IVR состоял из заранее записанных модулей и умел лишь распознавать ответы «да» или «нет», что выглядело слишком шаблонно. В новой платформе задействуются гибкие сценарии, собственные базы данных, а также обученный голосовой ассистент, способный поддерживать диалог в более «живой» форме.
Первоначально рассматривалось использование app_audiosocket (доступного с 18-й версии), чтобы передавать поток данных в сторону бота по TCP. Однако при межсерверном соединении возникали нестабильности, из-за которых Asterisk преждевременно «завершал» вызов при потере пакетов. Поэтому применён более надёжный подход через Dial: бот обрабатывает разговор, после чего возвращает информацию о необходимости перевода вызова на оператора.

Итоги и ключевые выводы

1. Актуальная версия Asterisk и автоматизированное развёртывание
   Создана роль Ansible, способная быстро настраивать серверы, устанавливать нужные пакеты и конфигурации. Это упрощает последующие обновления и обеспечивает единообразие окружения.
2. Отказоустойчивость и удобство обработки
   Реализована схема с промежуточным хранением событий в Redis и внедрён UserEvent для отслеживания специфических сценариев, например, переводов звонков.
3. Частичное внедрение ARI
   ARI даёт более современный подход к разработке, упрощает интеграции с внешними сервисами и снимает дополнительные метрики каналов.
4. Интеграция с платформой автоматизации контакт-центра
   Несмотря на начальную идею использовать app_audiosocket, решение оказалось нестабильным при межсерверном соединении. Поэтому связь с ботом организована через Dial, что позволило полноценно ввести интеллектуального голосового ассистента в рабочий процесс.

Рекомендации при переходе на Asterisk 18

• Проверять совместимость используемых библиотек и скриптов с новым форматом AMI-сообщений.
• Предусмотреть механизмы фильтрации и отказоустойчивости при высоких нагрузках (обрывы соединений, дубли вызовов).
• Учитывать возможную нестабильность app_audiosocket при работе между разными серверами.
• Планировать постепенный перевод функционала на ARI, поскольку полный отказ от AMI может требовать значительной переработки кода.

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