Как мы с Asterisk на FreeSWITCH переезжали

В течение последних лет был реализован проект по разработке коробочной версии облачной АТС с мультитенантностью, возможностью брендирования, модулем планирования звонков, функцией автодозвона с синтезом голоса, расширенной системой отчетности и интеграцией с 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.