Восстановление разговоров
Исходная задача
Обслуживание каждого вызова протекает через несколько микросервисов. Микросервисы, обслуживающие медиатрафик и SIP-сигнализацию, резервируются масштабируются в режиме active-active. Каждый разговор (соединение) связан с конкретными экземплярами медиашлюзов, и с конкретными экземплярами сервисов обслуживания SIP-сигнализации.
Если в системе несколько серверов, то каждый из типов микросервисов представлен несколькими экземплярами. Таким образом при потере какого-либо сервера или ноды/микросервиса новые вызовы устанавливаются с привязкой к другим серверам и активным экземплярам микросервисов.
Решается задача сохранения текущих разговоров при потере различных экземпляров микросервисов обслуживания медиатрафика и SIP-сигнализации.
В обычных условиях поведение системы следующее:
-
При потере микросервисов, резервирующихся в режиме active-passive, их задачи принимают на себя второстепенные экземпляры. Например mgc, mdc, store, callstore, broker, mware, wssubscr и др.
-
При потере медиашлюзов, в том числе при их перезагрузке, медиа-контекст вызова теряется. Однако, если остается в работе SIP-сервер юзер-агента - владельца медиаконтекста - то на основе информации о потере медиашлюза он инициирует создание нового контекста на одном из доступных медиашлюзов и осуществляет подмену медиасессий обоим плечам диалога. При этом:
-
сценарий IVR восстанавливает медиа-контекст с начала текущего компонента, то есть фоновые воспроизведения теряются;
-
некоторые провайдеры/устройства не поддерживают подмену сессий, в частности RTP-портов, что влечет невозможность восстановить полноценный обмен трафиком.
-
-
При потере какого-либо из сервисов SIP-сигнализации, обслуживающих конкретный разговор между абонентами, дальнейшее обслуживание сигнализации становится невозможным. При этом:
-
если медиа-шлюз остался активным и доступным, то медиа-контекст продолжает обслуживать медиа-трафик. Таким образом абоненты могут довести разговор до точки;
-
удержание, перевод, подключение прослушки и суфлера прерывают разговор.
-
Основная проблема состоит в том, что при обслуживании абонента в IVR-сценарии или нахождения его в очереди ожидания, потеря сервера сигнализации фатальна для разговора.
Таким образом задача состоит в том, чтобы при потере микросервисов сигнализации, восстановить разговор и некоторую актуальную точку в контексте обслуживания.
На односерверной системе потеря микросервисов связана либо с ручными операциями, либо с нехваткой ОЗУ на сервере, либо с критическими ошибками в коде микросервиса - всё маловероятно. А при условии, что система развернута на нескольких серверах, потеря микросервисов может быть связана с потерей отдельных серверов или связи с ними.
Принцип работы
Система сохраняет информацию об узлах, участвующих в обслуживании SIP-сигнализации каждого разговора. Этот контекст сохраняется в распределенном хранилище под обслуживанием микросервиса callstore, резервирующегося в режиме active-passive. Система мониторит доступность всех узлов.
При обнаружении потери узлов вычисляется зацепление среди диалогов. Для каждого из зацепленных диалогов формируется задание на восстановление. В зависимости от конфигурации зацепления (какие узлы в каких плечах потеряны) производится выбор алгоритма восстановления.
В любом случае формируется новый диалог, а конечные юзер-агенты вызываются путем подмены (INVITE+Replaces). Предварительно система ожидает появления всех узлов, нужных регистраций, состояний и коннектов.
Контекст восстанавливаемого вызова в коллцентре сохраняется за счет назначения новому вызову того же сеанса.
IVR сценарии являются юзерагентами, поэтому при их утрате сценарии запускаются либо с начала, либо с последней сохраненной точки/контекста.
Настройка
Настройке с необходимостью предшествует проект конфигурации:
-
Дублирование и размещение сиповых микросервисов системы по серверам.
-
Настройка Virtual Ip или иного способа резервирования подключений внутренних абонентов (альтернативные outbound proxy).
-
Резервирование подключений к провайдерам именно путем переноса ответственности на другой экземпляр esg. Вариант резервирования путем альтернативной маршрутизации на другую учетную запись не обеспечивает возможности дальнейшего восстановления разговора.
После проведения предварительной подготовки система должна обеспечивать возможность подключения и работы всех абонентов во всех возможных вариантах недоступности части серверов, которые попадабют в рассмотрение исходя из модели угроз. Такая настройка обеспечивает готовность системы продолжать обслуживание новых вызовов после обнаружения изменений в составе серверов и микросервисов и подстройки конфигурации под новое состояние.
Теперь можно переходить к настройке сервиса восстановления.
-
Обязательно. В конфигурации включить опцию в разделе 'roles..callstore.sip_restore_enabled' для всех экземпляров микросервиса callstore.
-
Рекомендательно. Организовать маршрутизацию в очереди коллцентра через обособленные номера фичакодов вместо размещения компонента глубоко во вложенном сценарии относительно начального вызова.
-
Рекомендательно. В сценариях IVR расставить точки сохранения контекста.
-
Рекомендательно. Создать по нескольку экземпляров каждого из сиповых микросервисов и распределить их по разным серверам.
-
Настройка для восстановления внешнего плеча. Для каждого из провайдеров определить режим восстановления, внести в настройки учетной записи провайдера (opts.sip_restore_mode). Если аплинк поддерживает Replaces (RFC-3891), то следует установить в opts.sip_restore_mode режим 'replaces'. В иных случаях принять решение о том, стоит создавать новый вызов или отказаться от восстановления.
-
Настройка для восстановления внутреннего плеча. Если резервирование подключений настроено не через Virtual Ip, а через альтернативные outbound proxy или DNS-имя с несколькими IP-адресами, то включить в конфигурационных параметрах экземпляров sg 'roles..sg.reregister'.
Лог журнал этого сервиса находится в активной ноде callstore (/callstore/erl_*.log). Процесс восстановления разговоров сопровождается интенсивным трафиком, который на общих основаниях размещается в лог-журналах /sip/trn_*.log сиповых микросервисов.