Олег Агапов

Управляющий партнер

Для обеспечения бесперебойной работы необходимо реализовать механизмы сохранения разговоров при недоступности серверов и/или их перезапуске, т. е. обеспечивать отказоустойчивость системы. В данной статье рассмотрены кейсы, которые помогают решить проблему сохранения разговоров при недоступности и перезапуске сервисов на омниканальной коммуникационной Платформе Эра.

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

Аварийное сохранение разговоров

Часть кейсов (аварийное сохранение разговоров) были доступны с первых дней существования платформы и входят сегодня в версию «Бизнес», другая же часть — полноценное восстановление разговоров, включая голосовые меню и очереди ожидания, стала возможной в декабре прошлого года и входит в версию «Корпорация».

Итак, представим разговор двух абонентов, подключенных по протоколу SIP к платформе Эра. В качестве оконечных устройств могут использоваться IP-телефоны, классические softphone и webphone, подключенные по технологии WebRTC и WebSocket.

Сначала рассмотрим аварийное сохранение разговоров. Наиболее близкая по смыслу аналогия из мира автомобилей — это использование докатки при проколе колеса. Ехать вроде бы можно, но не очень далеко и не очень быстро. В нашем случае это означает, что при потере сервера не все сохраненные разговоры получится перевести и поставить на удержание. Появляется риск потери звонков в IVR и в очередях. Кроме этого, сохранить все разговоры при потере второго сервера невозможно, поэтому для реализации этой схемы потребуется как минимум четыре сервера.

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

Фасадом на данной схеме выступает роль SipGate, размещенная на первом сервере; на втором — back-to-back-useragent, который занимается маршрутизацией; на третьем — медиашлюз, позволяющий обмениваться голосом; на четвертом — контроллер, связывающий b2b и медиашлюз. Телефонные аппараты взаимодействуют по сети с первым сервером по протоколу SIP и третьим по протоколу RTP.

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

Первый кейс - недоступность SipGate

Несмотря на то, что b2b остался на втором сервере, фактически мы полностью потеряли сигнализацию. Абоненты могут продолжать разговор благодаря живому медиашлюзу, однако поставить звонок на удержание или выполнить перевод не получится, так как sip-пакеты принять уже некому.

Второй кейс - недоступность back-to-back

С точки зрения продолжения разговора, эта ситуация хуже, чем недоступность SipGate, так как именно b2b хранит оперативную информацию о звонках и исполняет машины состояний диалога. Последствия аналогичны первому кейсу: разговор продолжается, абоненты друг друга слышат, но каких-либо дальнейших действий с разговором провести уже не получится.

Третий кейс - недоступность media gate (медиа-шлюза)

Данная ситуация не столь критична, потому что при обнаружении недоступности медиа-шлюза, media gate controller подключает к работе резервный медиа-шлюз. Примерно в течение 100 миллисекунд b2b инициирует отправку сипгейтом реинвайтов на оба телефона с новой информацией в sdp. Это приводит к переключению rtp-трафика на четвертый сервер. В этом случае негативных последствий и ограничений для абонентов не возникает.

Четвертый кейс - недоступность media gate controller (медиагейт-контроллера)

Без какого-либо взаимодействия с телефонными аппаратами выполняется его переезд на третий сервер, в результате чего разговор продолжается без потерь.

Можно сказать, что при четырехсерверной конфигурации недоступность одного любого сервера позволяет нам продолжить разговор во всех случаях, и производить дальнейшие манипуляции с ним (переводы и удержания) в двух случаях из четырех, то есть с вероятностью 50%. Отметим, что все новые звонки при этом во всех кейсах обрабатываются в штатном режиме без какого-либо вмешательства администраторов.

Подходы SIP re-INVITE, INVITE re-PLAY

Рассмотрим подходы, которые появились недавно в версии «Корпорация», позволяющие обеспечить полноценное сохранение разговоров, то есть без потери функциональности. Для решения этих задач мы применяем подходы SIP re-INVITE, INVITE re-PLAY (инвайты с реплейсом), и, в некоторых случаях, используем виртуальные IP-адреса.

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

Если же меняется media gate (а это обычно не рестарт, а переезд на соседнюю ноду), то пропадание голоса вряд ли превысит 100 мсек, то есть для наших абонентов эти процессы остаются практически незаметными.

Вернемся к четырехсерверной конфигурации. Напоминаем, что потерю сигнализации (b2b и sip gate) мы зафиксировали, как наиболее неприятные кейсы.

Для полноценного сохранения разговора мы переключаем обслуживание сигнализации на другой сервер. На устройства со второго сипгейта отправляются инвайты с реплейсом, и после их обработки разговор продолжается с полным сохранением функциональности. Отметим, что для внутренних абонентов похожих результатов мы могли бы добиться применением виртуального IP-адреса, однако же для сохранения IVR и диалогов с провайдерами это бы не подошло — в этих случаях мы также применяем инвайты с реплейсами.

Рассмотрим двухсерверную конфигурацию. Роли полностью дублируют друг друга, однако система стремится для каждого разговора сохранить отделение медиа от сигнализации. В нашем примере первый сервер обслуживает сигнализацию, второй — медиа.

При недоступности первого сервера, сигнализация переносится на второй (аналогично предыдущему кейсу — инвайтами с реплейсами). Разговор продолжается с полным сохранением функциональности, но уже обслуживается в пределах одного сервера.

При недоступности второго сервера, отправляются простые реинвайты с заменой медиа (как при аварийном сохранении разговора), в результате обработка медиа переносится на первый сервер. Разговор продолжается с полным сохранением функциональности.

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

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

VIRTUAL IP и недоступность SIP-ролей

Наконец, несколько слов про virtual-IP. При необходимости sip gate, выступающий фасадом для телефонов, может переезжать вместе с виртуальным адресом ноды. Это может быть актуальным, если устройства не поддерживают инвайты с реплейсом с других адресов или множественную регистрацию.

Здесь мы видим, что при недоступности sip-ролей на первом сервере они переезжают на второй вместе с виртуальным адресом 10.1.0.1. Таким образом, устройства получают реинвайты с того же адреса, с которым уже шло взаимодействие, им не требуется перерегистрация на резервном outbound proxy.

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