Русский
Русский
English
Статистика
Реклама

Skype

Интеграция Skype For Business с IP-АТС в крупной нефтехимической компании

18.05.2021 10:20:20 | Автор: admin
Использование программных продуктов для звонков, чатов и видеоконференций стало неотъемлемой частью работы практически любой компании. Всё чаще возникает ситуация, когда для связи между сотрудниками используются параллельно две системы IP-АТС и так называемая система объединенных коммуникаций (Skype for Business, Teams и другие). Возникает путаница: пользователям не всегда понятно, какой тип связи предпочтительнее использовать, где лучше организовать конференцию, куда приглашать внешних участников на встречу. В статье я расскажу об успешной интеграции телефонии и системы объединенных коммуникаций, реализованной ЛАНИТ-Интеграцией в крупной нефтехимической компании. И хотя кейс не является пошаговой инструкцией, уверен, он будет многим полезен.

Источник

О проекте


К нам за помощью обратилась крупная нефтехимическая компания с большим количеством офисов по всей стране. В офисах используются 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).

В нашем проекте используется второй сценарий по нескольким причинам.

  1. На площадках заказчика большое количество IP-АТС различных производителей с различными версиями прошивок. Не со всеми из них была техническая возможность установки прямого SIP-транка со SfB.
  2. Решение должно быть типовым на всех площадках.
  3. Одно из требований минимизация изменений в конфигурациях 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. Далее звонок должен идти следующим образом.

  1. IP-АТС ищет абонента с номером 202 и находит его. В настройках этого абонента стоит одновременный звонок на номер 5202.
  2. Звонок уходит на телефон 202 и срабатывает маршрутизация звонка в SIP-транк с SBC.
  3. SBC направляет звонок в SfB.
  4. SfB находит пользователь с номером 5202 и направляет звонок на клиент SfB этого пользователя.

В итоге у пользователя 2 звонит и телефон, и SfB, и он сам решает где ему удобнее ответить на вызов.

Схема звонка с форкингом:


Подводные камни


Есть четыре возможных сценария обработки входящего вызова:

  1. пользователь снимает трубку на телефоне;
  2. пользователь отвечает в SfB;
  3. пользователь нигде не снимает трубку и звонок сбрасывается по таймауту;
  4. звонящий кладёт трубку до того, как будет принят вызов или звонок сбросится по таймауту.

И тут появляются подводные камни. При тестировании обнаружилось, что поведение системы практически всегда не соответствует ожиданиям. Я бы хотел остановиться на каждом сценарии более подробно, описать проблемы и предложить варианты решения.

Пользователь снимает трубку на телефоне


Проблема: В 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. Надеюсь, описанные в статье решения помогут сэкономить вам время при внедрении.
Подробнее..

Зачем мы создали свою собственную систему видеосвязи с блэкджеком и фичами

20.01.2021 18:14:16 | Автор: admin

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

Отдельной болью для нас стали видеозвонки. И началось: Ой, а давайте в Скайпе, Дискорде, Телеграме, Зуме. А потом то девайсы программное обеспечение криво поддерживают, то технические сбои, то аккаунты вне доступа, то обновление софта и еще вагон проблем. Уходила куча времени, чтобы просто связаться и провести совещание.

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

Чем нас не устроил Zoom и другие приложения

Буквально за несколько месяцев после начала карантина количество пользователей Zoom увеличилось в 30 раз. В декабре 2019 года ежедневно сервисом пользовались 10 млн людей, а в апреле 2020 уже 300 млн.

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

А потом мы узнали о массивной утечке данных. В апреле 2020 хакеры взломали базы данных Zoom и в сеть утекли данные свыше 500 000 аккаунтов. Логины, пароли, email, URL личных чатов, коды администраторов для управления конференциями.

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

Насчет удобства использования сторонних сервисов, все также было не очень гладко. При обсуждении рабочих вопросов один на один или малыми группами чаще всего использовали Skype или Facebook Messenger. Для встреч по отделам и общих конференций Zoom. И самым проблемным оказалось отсутствие единой базы записей видеозвонков. Попытка пересмотреть обсуждение какого-нибудь вопроса превращалась в квест.

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

Да и в целом организационные моменты подталкивали на разработку своего софта для видеозвонков. С той лишь разницей, что мы видели его не как отдельное решение, а встроенный в нашу CRM видеочат для обсуждения рабочих задач и проектов, уже заведенных в систему. Тем более, что идеи уже были. Нам нужно было добиться стабильной работы на всех ОС и мобильных платформах.

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

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

Разработка как прогулка по полю с граблями

Впервые идея создать собственную платформу видеосвязи появилась у нас в 2015 году.

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

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

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

И хорошо, что мы тогда не стали искать выходы. Было бы печально вложить кучу денег во второстепенную функцию, а через 5 лет узнать, что все нужно делать заново, потому что Flash отключают.

***

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

Разработка первоначальной версии велась буквально на коленке. Сначала выбрали OpenVidu, который нас максимально устраивал и был доступен в плане лицензии. А затем буквально в течение нескольких недель собрали MVP и попытались интегрировать его в CRM Мегаплана.

Опенсоурсная версия получилась рабочей, но у нее было несколько серьезных проблем:

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

  2. Вылез целый ряд багов и проблем, решение которых мы в процессе первичной разработки не нашли. Среди них:

    a. Отсутствие записи трансляции. Наши специалисты так и не смогли придумать, как реализовать запись без слишком больших переделок или без использования сторонних утилит;

    b. У технологии не было мультиплексирования, поэтому использование видеосвязи слишко быстро сажало аккумуляторы смартфонов. Для ее решения нужны были специализированные хардварные решения, к которым мы были не готовы.

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

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

  4. Стоимость использования OpenVidu считается за одно серверное ядро в минуту. Для небольших решений она приемлема, но это крайне затрудняет масштабирование сервиса все упирается в деньги, много денег.

Количество минусов перекрывало все перспективы использования технологии. Поэтому мы решили от нее отказаться.

Janus Gateway: именно то, что нужно

Для передачи видеоданных мы используем стандартный протокол WebRTC. Стабильная платформа для видеосвязи, на которой можно реализовать все хотели и свистелки, которые нам нужны.

Но обычного p2p соединения нам недостаточно, ведь нужно было реализовать возможность записи трансляции на сервер. Поэтому решили использовать ретранслятор Janus Gateway.

В целом выбирали между тремя платформами: OpenVidu, которую оставили как контрольный образец, Jitsi и Janus. В результате чтения аналитики выяснили, что OpenVidu сильно проседает по качеству картинки трансляции (как будто и так вопросов было мало), а у Jitsi во время нагрузки качество плавает. Не то, чтобы мы планировали делать конференции из 200-300 пользователей, но стабильность работы видеосвязи для нас ключевой момент.

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

У Janus есть куча полезных фич, которые не реализованы или платные в OpenVidu. К примеру, контроль качества связи и автоматическое выставление битрейта в зависимости от него. Или же поддержка кодеков VP9 и режима симулькаста.

Janus имеет ничтожное влияние на процессор и память сервера. Всё упирается только в пропускную способность сети. Поэтому можно брать не самые мощные сервера, а много маленьких и пару больших для декодирования и склейки записанных видеозвонков. Мы не стали прибегать к сторонним решениям, вроде Janus cloud, где узким местом и точкой входа всё равно является janus-proxy, а сделали балансировку на уровне продукта.

Михаил Пирогов, руководитель отдела эксплуатации и администрирования Мегаплана

С Janus все также получилось не слишком гладко. Для реализации WebRTC используется библиотека React Native WebRTC. У нас нет разработчиков, которые хорошо знают React Native, поэтому чтобы устранить проблемы совместимости протокола с софтом сервера, ушло довольно много времени.

Были сложности и со сборкой. Компилятор Metro bundler хорошо работает в веб-версии, но не подтягивает дополнительные библиотеки в мобильной, из-за чего мобильная версия была нестабильной и падала.

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

Пришлось сильно заморочиться с решением проблемы, разделив потоки на отдельные экраны и оптимизировав рендер и отрисовку видео участников в реальном времени. Кому интересно, можем дать ссылку на код.

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

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

Бета-версия и что дальше

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

Сохранять записи звонков. Эту фичу мы планировали, но она пока в стадии реализации и тестирования.

Нужно предоставить возможность скачать запись только участнику с наибольшими правами в конференции, чтобы она не ушла на сторону. Проигрывание записи через встроенный плеер тоже будет актуальным, чтобы клиент не использовал сторонний софт.

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

Добавить вебинарную комнату самый популярный запрос. Чтобы можно было, к примеру, проводить отчетные мероприятия. То есть, клиенты хотят не просто совершать звонки, а получить универсальный инструмент для организации рабочего процесса. Им его не хватает.

Правда, с вебинарной комнатой у нас немного затык. Нужно добавить инструмент работы со слайдами без демонстрации экрана и вайтборд для рисования маркерами.

Если у вас есть идеи, как это сделать в рамках Janus с минимальным количеством вытекающих проблем с радостью послушаем.

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

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

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

Подробнее..

Категории

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

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru