В течение последних лет был реализован проект по разработке коробочной версии облачной АТС с мультитенантностью, возможностью брендирования, модулем планирования звонков, функцией автодозвона с синтезом голоса, расширенной системой отчетности и интеграцией с CRM.
Изначально в качестве основной платформы использовался Asterisk, однако в процессе развития системы возникла необходимость перехода на FreeSWITCH. Причиной стала потребность в соответствующем уровне отказоустойчивости, определённом в тендерных требованиях, во многом связанных с нормативами Минцифры.
Основные требования
Ключевым требованием была именно отказоустойчивость звонков. В отличие от Asterisk, где для восстановления звонка применяются внешние решения (например, Kamailio с восстановлением INVITE), FreeSWITCH изначально предоставляет встроенные механизмы восстановления состояния вызова.
Важным ограничением архитектуры являлось отсутствие предопределённого линейного сценария обработки звонка. Каждый шаг диалплана мог иметь различные ветвления — например, при отсутствии ответа выполнялся повторный дозвон, а при ответе — перенаправление в опрос. Таким образом, система должна была поддерживать динамические сценарии и нелинейную логику обработки.
SBC и интеграция
SBC (Session Border Controller) был реализован для разграничения внутренней инфраструктуры и внешних провайдеров, с вынесением всех транков на SBC (как с регистрацией, так и без неё).
На уровне SBC выполняется преобразование протоколов, адаптация звонков под конкретного оператора, а также передача служебных параметров (лимиты звонков, уникальные идентификаторы, Call-ID для CRM) внутрь системы. Для прокидывания этих данных используется заголовок user-to-user, что позволяет передавать их между нодами без дополнительных запросов.
Архитектура взаимодействия компонентов
База данных:
PostgreSQL используется как основное хранилище.
Кэш:
Tarantool — для ускорения выборок и снижения нагрузки на PostgreSQL.
Сигнальные данные:
Передаются через SIP-заголовки.
Событийная шина:
RabbitMQ для внутренних событий, HTTP-запросы — для интеграции с внешними CRM.
Kamailio:
Контроль лимитов, идентификация транков, обработка регистраций, публикация событий в Redis.
Логика диалплана
Реализация основана на mod_xml_curl. Диалпланы проектируются как один extension с условием и набором действий, завершающихся transfer на следующий шаг.
Каждый шаг генерирует собственный CDR, а также участвует в общем CDR всего звонка. Состояние звонка хранится в канальных переменных FreeSWITCH, которые могут занимать значительный объём и сохраняются вместе с состоянием вызова. Это позволяет при сбое FreeSWITCH восстановить текущий шаг из базы данных и продолжить сценарий.
Для управления событиями используются переменные:
execute_on_transfer
execute_on_originate
execute_on_pre_originate
execute_on_bridge
execute_on_pre_bridge
execute_on_ring
api_hangup_hook
Для сложных случаев возможна подписка на события через ESL.
Работа с IVR
Для обработки DTMF не используется встроенный IVR FreeSWITCH. Вместо этого применяется play_and_get_digits с анализом нажатых кнопок, после чего сценарий возвращается за новым диалпланом. Такой подход позволяет прерывать исполнение шага и менять логику в реальном времени.
Производительность
Запросы к HTTP-серверу, генерирующему диалплан, выполняются за ≤50 мс, что не влияет на реакцию пользователя. Сервера генерации диалпланов являются stateless и могут масштабироваться горизонтально.
Пример работы с заголовками
Kamailio хранит в хэш-таблицах JSON с параметрами транка (обрезка/добавление цифр в номер, кастомные SIP-заголовки и т.д.). При необходимости эти данные можно привязать не только к транкам, но и к конкретным звонкам.
Проблемы и ограничения
mod_callcenter
используется как демонстрация принципов работы очередей, но имеет серьёзные ограничения (один сервер, опрос БД каждые 100 мс, невозможность корректной работы в распределённой среде без доработки).
В некоторых сценариях потребуется доработка логики перевода звонков с сохранением сквозной аналитики в CDR.
Заключение
На данный момент реализовано около 90% функционала, который ранее был на Asterisk, без потери возможностей для пользователей:
Сохранены все отчёты и пользовательские интерфейсы.
Обеспечена отказоустойчивость на уровне FreeSWITCH.
Kamailio отвечает за контроль лимитов и распределение нагрузки.
Архитектура поддерживает масштабируемость и работу с динамическими сценариями.
Я -
Виталий Шелест
, менеджер компании Voxlink. Хотите уточнить детали или готовы оставить заявку? Укажите номер телефона, я перезвоню в течение 3-х секунд.
Заказать звонок
@ 2011-2025 ООО "Вокс Линк" Установка и настройка Asterisk. IP-телефония для офиса и Call-центры., ИНН: 7715856113, ОГРН: 1117746186084. Все права защищены.
Информация на сайте не является публичной офертой.
