Asterisk в крупной компании

В компании TransTech Service несколько лет идёт поэтапный переход от традиционной АТС Coral к IP-телефонии. Инфраструктура распределена между десятью городами и объединена в три региональные зоны — Казань, Набережные Челны и Уфа. Такой масштаб потребовал гибкой архитектуры, устойчивой маршрутизации вызовов и возможности постепенно внедрять новые технологии без резкого отказа от существующих решений.

Исходная архитектура и используемый стек

Во всех городах используются локальные и узловые АТС Coral, обслуживающие абонентов на конкретных площадках. Узловые станции отвечают за маршрутизацию вызовов между площадками внутри города и между регионами.

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

• CentOS как базовая ОС на всех серверах
• Asterisk версий 13–16 в роли IP-АТС
• MySQL и Redis для хранения и обработки данных
• VoIP Monitor для анализа качества связи
• Dialplan: постепенный переход с IAX/IEL на Lua
• ELK-стек для централизованного сбора логов
• Физические серверы с E1-картами для стыков с операторами и Coral
• В отдельных сценариях — SIP-шлюзы Grandstream

Во всех городах архитектура выстроена по одному принципу, что упрощает масштабирование и сопровождение.

Маршрутизация вызовов и роль Asterisk

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

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

Со временем стало очевидно, что функциональности Coral не хватает — прежде всего в части интеграций, логирования и гибкости сценариев обработки вызовов. Это стало отправной точкой для дальнейшего развития IP-телефонии.

Отказ от DECT и внедрение FMC/FMTN

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

В качестве альтернативы было выбрано решение FMC/FMTN:

• FMTN от Beeline
• FMC от МегаФона

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

Преимущества подхода:

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

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

Внешняя база данных и логика обработки вызовов

Ключевым элементом архитектуры стала внешняя база данных MySQL. В ней хранится:

• тип конечного устройства абонента (IP, FMC, FMTN)
• параметры маршрутизации
• чёрные списки
• служебные данные для провижининга

Именно на основе этих данных принимается решение, по какому каналу должен быть отправлен вызов. Это позволяет избежать ситуаций, когда звонок уходит в неправильный транк или «упирается» в недоступную АТС.

Часть логики обработки вызовов хранится локально на серверах Asterisk. Например:

• интеграция с 1С для сервисных подразделений
• обработка звонков клиентов с активными заказами
• механизм ringback: клиент автоматически соединяется с последним сотрудником, с которым общался ранее

Последний сценарий оказался особенно важен, так как все исходящие вызовы выполняются через единый номер автосекретаря, и клиент не видит прямой номер сотрудника.

P-телефоны, отказоустойчивость и провижининг

Перед массовым внедрением IP-телефонии были протестированы разные модели телефонов: Cisco, Grandstream, Yealink. Под нагрузкой контакт-центра наиболее нестабильными оказались Grandstream — наблюдались зависания и обрывы вызовов. В итоге в эксплуатации остались Cisco и Yealink.

Для отказоустойчивости была внедрена схема с Kamailio, который балансирует нагрузку между двумя PBX-нодами. При отказе одной из них вторая продолжает обслуживать вызовы.

Для управления конечными устройствами используется сервер автопровижининга. Сейчас в IP-сегменте около 500 телефонов, в перспективе — более 2000. Ручная настройка в таком масштабе неприемлема.

Процесс подключения нового абонента занимает около пяти минут:

• данные добавляются во внешнюю БД
• конфигурации автоматически формируются и доставляются на телефон
• SIP-учётки синхронизируются с серверами

Мониторинг всей системы осуществляется через Zabbix, который уже используется для контроля остальных сервисов компании.