Freeswitch HA, sofia recovery, как не терять вызовы

Мастер-класс посвящён проблеме нулевой толерантности к потере вызовов в системах VoIP-телефонии, а также инструментам и архитектурным подходам, позволяющим минимизировать прерывания соединений при проведении плановых и аварийных работ.

Ключевые технологии и решения: FreeSWITCH, OpenSIPS, Kamailio, RTP Engine, кластерные файловые системы, базы данных (PostgreSQL, SQLite), механизмы Keepalive и High Availability Cluster.

Постановка задачи

В крупных телеком-и контактных центрах часто предъявляется требование к нулевой толерантности потери вызовов. Это означает, что даже в случае технического обслуживания или аварии система не должна допускать прерывания соединений. Потеря звонка = потеря клиента, снижение лояльности и упущенная прибыль.

Задача инженера — обеспечить архитектуру, способную выдерживать такие требования, при этом сохраняя баланс между затратами и сложностью эксплуатации.

Ограничения классической схемы High Availability Cluster FreeSWITCH

Документация FreeSWITCH описывает базовую модель Active/Standby, при которой:

• Активная нода обрабатывает вызовы;
• Резервная находится в холодном или горячем резерве;
• При отказе активной ноды виртуальный IP переезжает на Standby, и запускается процесс восстановления вызовов.

Недостатки:

1. Пассивный сервер простаивает и не обрабатывает трафик.
2. Риск рассинхронизации конфигураций между нодами.
3. Ограничения по типу транспорта — схема надёжно работает только с UDP.
4. Отсутствие горизонтального масштабирования (на каждую активную ноду требуется выделенная резервная).
5. Потенциально низкая эффективность использования ресурсов.

Альтернативный подход: ферма FreeSWITCH

Для устранения недостатков предлагается архитектура фермы серверов FreeSWITCH с балансировкой и проксированием через OpenSIPS/Kamailio.

Основные принципы:

• Горизонтальное масштабирование — несколько активных нод одновременно обрабатывают вызовы.
• Единый кластер баз данных для механизма Recovery.
• Кластерная файловая система (NFS, Ceph и т.д.) для синхронизации конфигураций.
• Автоматизация релизов через CI/CD для поддержания консистентности конфигураций.
• Вынесение бизнес-логики за пределы FreeSWITCH — упрощение нод до транспортного уровня.
• Использование RTP Engine для проксирования медиапотока.

Механизм Recovery в FreeSWITCH

Recovery позволяет восстанавливать активные вызовы при отказе ноды.

Принцип работы:

• Включается опция track_calls в профиле.
• Указывается подключение к БД для хранения состояния вызовов.
• В таблицу recovery пишутся данные о сессиях: UUID, параметры каналов, IP-адреса, порты.
• При активации Recovery создаются каналы с восстановлением медиасессий.

Особенности:

• Работает только с отвеченными вызовами.
• При использовании TCP/TLS механизм не применим.
• Возможны нюансы при восстановлении IVR-сценариев, таймеров и проигрываемых файлов.

Расширенное применение Recovery

Помимо классического failover, механизм можно использовать для:

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

Методика:

1. В таблице recovery изменяются switchname и IP-адрес на адрес целевой ноды.
2. На целевой ноде выполняется команда sofia recover.
3. Вызовы продолжаются без разрыва медиасессии.

Практические рекомендации

• Для автоматизации переключений использовать Keepalive-скрипты или event-триггеры FreeSWITCH.
• Следить за размером и структурой полей в таблице recovery (особенно для переменных с длинной историей, например transfer_history).
• Для SQLite возможна синхронизация файлов БД через SSH или перенос данных вручную.
• Обеспечивать резервирование всех ключевых ролей (proxy, registrar, media-proxy, FS-ноды).