О проекте
К нам за помощью обратилась крупная нефтехимическая компания с большим количеством офисов по всей стране. В офисах используются IP-АТС различных производителей, в основном Cisco и Avaya, при этом часть задач помогает решать Skype For Business (SFB). Нам предстояло провести интеграцию системы телефонной связи компании со Skype For Business так, чтобы пользователи SfB могли осуществлять вызовы на стационарные телефоны и наоборот. Отказываться от одного из каналов связи и целиком переходить на другой заказчик не планировал. Требовалось настроить работу системы таким образом, чтобы на каждый входящий звонок пользователь имел возможность ответить как ему удобнее с телефона или со SfB. Разумеется, решение должно быть отказоустойчивым.
Для тех, кто не знаком близко с работой SIP-телефонии, кратко опишу ее базовые принципы. При звонке между клиентами возникает передача двух видов сетевого трафика: трафика сигнализации (SIP Session Initiation Protocol) и медиатрафика (RTP Real-time Transport Protocol и SRTP Secure Real-time Transport Protocol). По SIP передается информация, необходимая для начала и завершения сеанса разговора. В пакетах SIP присутствуют данные, например, о номерах телефонов или информация, когда абонент ответил на вызов, когда завершил его. Медиатрафик включает в себя непосредственно звук (голос), сжатый кодеками.
При настройке интеграции SfB c IP-АТС есть два возможных сценария:
- настройка SIP-транков (каналов связи между двумя системами) напрямую между IP-АТС и SfB;
- настройка взаимодействия между системами через SBC (Session Border Controller).
В нашем проекте используется второй сценарий по нескольким причинам.
- На площадках заказчика большое количество IP-АТС различных производителей с различными версиями прошивок. Не со всеми из них была техническая возможность установки прямого SIP-транка со SfB.
- Решение должно быть типовым на всех площадках.
- Одно из требований минимизация изменений в конфигурациях IP-АТС.
Планирование
В качестве SBC мы использовали решение от компании AudioCodes. В линейке решений этого производителя есть AudioCodes Mediant Virtual Edition (VE). В нашем случае оно подходило лучше остальных, так как на площадках уже имелись хосты виртуализации с достаточным количеством свободных мощностей. Если на каждой площадке развернуть по две виртуальные машины и разместить их на разных хостах, то мы получим отказоустойчивое решение на уровне сервиса это нам и было нужно. Такое решение избавляло от необходимости приобретения и установки дополнительного оборудования.
В итоге схема построения SIP-транков и размещения SBC была такой:
Размещение SBC на каждой площадке обусловлено несколькими причинами:
- в дальнейшем возможно использование SBC для интеграции с местными операторами связи;
- сбой на одной площадке никак не должен отражаться на работе остальных;
- администраторы площадки должны полностью управлять своими SBC, не влияя на остальные площадки.
Схема была согласована, и мы приступили к развертыванию стенда и тестированию.
Тестирование
При тестировании нам требовалось:
- найти рабочую конфигурацию оборудования для построения SIP-транка с каждым типом и версией прошивки IP-АТС заказчика;
- проверить работу требуемых сценариев звонков с каждым типом и версией прошивки IP-АТС;
- описать требуемые изменения.
Была развернута тестовая инфраструктура cо Skype for Business, несколько IP-АТС нужных версий и пользовательские станции. Мы приступили к конфигурированию. Прямые звонки между клиентами SfB и каждой IP-АТС заработали без проблем после настройки маршрутизации звонков. Тонкие моменты обнаружили при тестировании форкинга звонка (когда при звонке на стационарный телефон у пользователя звонок приходит и на телефон, и в клиент SfB). Для лучшего понимания форкинга звонка приведу пример. У нас есть пользователь 1 с номером телефона 201 и пользователь 2, у которого есть телефон с номером 202. Есть учётная запись в Skype For Business с номером 5202. Пользователь 1 решил позвонить пользователю 2 и набрал на телефоне номер 202. Далее звонок должен идти следующим образом.
- IP-АТС ищет абонента с номером 202 и находит его. В настройках этого абонента стоит одновременный звонок на номер 5202.
- Звонок уходит на телефон 202 и срабатывает маршрутизация звонка в SIP-транк с SBC.
- SBC направляет звонок в SfB.
- SfB находит пользователь с номером 5202 и направляет звонок на клиент SfB этого пользователя.
В итоге у пользователя 2 звонит и телефон, и SfB, и он сам решает где ему удобнее ответить на вызов.
Схема звонка с форкингом:
Подводные камни
Есть четыре возможных сценария обработки входящего вызова:
- пользователь снимает трубку на телефоне;
- пользователь отвечает в SfB;
- пользователь нигде не снимает трубку и звонок сбрасывается по таймауту;
- звонящий кладёт трубку до того, как будет принят вызов или звонок сбросится по таймауту.
И тут появляются подводные камни. При тестировании обнаружилось, что поведение системы практически всегда не соответствует ожиданиям. Я бы хотел остановиться на каждом сценарии более подробно, описать проблемы и предложить варианты решения.
Пользователь снимает трубку на телефоне
Проблема: В SfB вызов может отмечаться как пропущенный в журнале вызовов. Почему так происходит? Дело в том, что при форкинге IP-АТС направляет звонок сразу на два номера: абоненту IP-АТС и в SIP-транк. И когда звонок снимается на телефоне абонента, IP-АТС отправляет SIP-запрос CANСEL в сторону SfB, как бы говоря, что звонить больше не надо.
IP-АТС может не вложить в запрос CANCEL информацию о том, что трубка снята в другом месте. В этом случает SfB думает, что это звонок, который сбросил сам звонящий, и помечает его как пропущенный, а это не является правдой. При детальном разборе логов звонков и изучении документации было найдено RFC, в котором описывается заголовок Reason для запросов CANCEL. Именно в этом заголовке должна содержаться информация о том, что звонок был принят в другом месте.
Ссылка на RFC: https://tools.ietf.org/html/rfc3326
Большая часть IP-АТС заказчика не поддерживала RFC 3326.
Решение: Выяснилось, что чаще всего в последних версиях прошивок IP-АТС включена поддержка RFC 3326. После обновления до последней версии проблема пропала.
Для тех же IP-АТС, в которых нет поддержки RFC 3326, найдено обходное решение: SBC Audiocodes позволяет модифицировать отправляемые SIPпакеты. В этом сценарии нам необходимо добавлять в запросы CANCEL заголовок с информацией о том, что звонок был принят в другом месте. В нашем случае для этого необходимо было в Audiocodes создать новый Message Manipulations, который добавляет заголовок Reason со значением
'SIP;cause=200;text="Call
completed elswhere";ms-acceptedby="sip:OnPBX@domain.local"'
и привязать это правило на соответствующую IP Group.
Пользователь отвечает в SfB
В этом сценарии проблемы с отображением звонка как пропущенного не возникло.
Пользователь нигде не снимает трубку звонок сбрасывается по таймауту
Проблема: После сброса звонка по таймауту клиент SfB может продолжать звонить, хотя сессия звонящего с IP-АТС уже разорвана.
Это происходит потому, что при срабатывании таймаута на некоторых IP-АТС, они не отправляют никакую информацию в сторону SfB, и SfB не знает, что сессия уже завершена.
Решение: Изменить настройки так, чтобы время таймаута SfB было меньше, чем время таймаута на IP-АТС.В случае, если звонок завершается по таймауту со стороны SfB, звонок завершается и на телефоне. Информация о пропущенном звонке везде отображается корректно.
Звонящий кладёт трубку до того, как будет принят вызов или звонок сбросится по таймауту.
Проблема: Если звонящий положил трубку до ответа, и если звонок принят на телефоне IP-АТС без поддержки RFC 3326, то в сторону SfB отправляются абсолютно одинаковые SIP-запросы CANCEL. SBC обрабатывает эти запросы по правилу, которое было создано ранее, и на SfB звонок не появляется как пропущенный.
Решение: Использование IP-АТС с поддержкой RFC 3326.
В нашем проекте заказчик принял решение всё же временно использовать добавление заголовка Reason и в дальнейшем отказаться от использования IP-АТС без RFC 3326.
В итоге
Детальное предварительное тестирование решения со всеми видами IP-АТС позволило заранее узнать о большинстве тонких моментов. Внедрение прошло относительно быстро один-два дня на каждую площадку.
Хотя в статье был описан один кейс интеграции Skype For Business с телефонией, принципы и решения подходят для любых подобных интеграций. Например, аналогичные решения мы успешно применяли в проектах интеграции телефонии с Microsoft Teams. Надеюсь, описанные в статье решения помогут сэкономить вам время при внедрении.
