[Мессенджеры, Разработка систем связи] Интеграция Skype For Business с IP-АТС в крупной нефтехимической компании
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Использование программных продуктов для звонков, чатов и видеоконференций стало неотъемлемой частью работы практически любой компании. Всё чаще возникает ситуация, когда для связи между сотрудниками используются параллельно две системы — 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).
В нашем проекте используется второй сценарий по нескольким причинам.
- На площадках заказчика — большое количество 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. Надеюсь, описанные в статье решения помогут сэкономить вам время при внедрении.
===========
Источник:
habr.com
===========
Похожие новости:
- [Сетевые технологии, Беспроводные технологии, Разработка систем связи, Интернет вещей] Гетерогенные PLC/RF модемы для систем сбора данных
- [Разработка систем связи, Исследования и прогнозы в IT] Как обстоят дела со строительством новых широкополосных линий связи в развитых странах
- [IT-инфраструктура, Разработка систем связи, Облачные сервисы, IT-компании] Подразделение Google Cloud заключило контракт со SpaceX на использование Starlink
- [Мессенджеры, Программирование, IT-стандарты, Kotlin, Управление сообществом] Социальный эксперимент: порядок из хаоса
- [Разработка под AR и VR, Научно-популярное, AR и VR, Будущее здесь] Для чего военные используют технологии AR/VR
- [Мессенджеры, Платежные системы, JavaScript, Node.JS] Оплата в телеграм боте — Платежи 2.0 — Сбербанк + Telegraf + Node.js
- [Разработка систем связи, Стандарты связи] Цифровой стандарт радиосвязи Волновая сеть — от локальной группы до региональной сети оперативной связи
- [Asterisk, Разработка систем связи] Yet another Asterisk monitoring: поддержка Prometheus
- [Мессенджеры, IT-компании, Видеоконференцсвязь] Дуров пообещал групповые видеозвонки в Telegram в мае
- [Тестирование IT-систем, Разработка под Windows] FlaNium: как сделать тестирование Desktop-приложений под Windows проще
Теги для поиска: #_messendzhery (Мессенджеры), #_razrabotka_sistem_svjazi (Разработка систем связи), #_lanit (ланит), #_lanitintegratsija (ланит-интеграция), #_skype, #_sistemy_svjazi (системы связи), #_blog_kompanii_gk_lanit (
Блог компании ГК ЛАНИТ
), #_messendzhery (
Мессенджеры
), #_razrabotka_sistem_svjazi (
Разработка систем связи
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:09
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Использование программных продуктов для звонков, чатов и видеоконференций стало неотъемлемой частью работы практически любой компании. Всё чаще возникает ситуация, когда для связи между сотрудниками используются параллельно две системы — 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-АТС есть два возможных сценария:
В нашем проекте используется второй сценарий по нескольким причинам.
Планирование В качестве SBC мы использовали решение от компании AudioCodes. В линейке решений этого производителя есть AudioCodes Mediant Virtual Edition (VE). В нашем случае оно подходило лучше остальных, так как на площадках уже имелись хосты виртуализации с достаточным количеством свободных мощностей. Если на каждой площадке развернуть по две виртуальные машины и разместить их на разных хостах, то мы получим отказоустойчивое решение на уровне сервиса – это нам и было нужно. Такое решение избавляло от необходимости приобретения и установки дополнительного оборудования. В итоге схема построения SIP-транков и размещения SBC была такой:  Размещение SBC на каждой площадке обусловлено несколькими причинами:
Схема была согласована, и мы приступили к развертыванию стенда и тестированию. Тестирование При тестировании нам требовалось:
Была развернута тестовая инфраструктура cо Skype for Business, несколько IP-АТС нужных версий и пользовательские станции. Мы приступили к конфигурированию. Прямые звонки между клиентами SfB и каждой IP-АТС заработали без проблем после настройки маршрутизации звонков. Тонкие моменты обнаружили при тестировании форкинга звонка (когда при звонке на стационарный телефон у пользователя звонок приходит и на телефон, и в клиент SfB). Для лучшего понимания форкинга звонка приведу пример. У нас есть пользователь №1 с номером телефона 201 и пользователь №2, у которого есть телефон с номером 202. Есть учётная запись в Skype For Business с номером 5202. Пользователь №1 решил позвонить пользователю №2 и набрал на телефоне номер 202. Далее звонок должен идти следующим образом.
В итоге у пользователя №2 звонит и телефон, и 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. Надеюсь, описанные в статье решения помогут сэкономить вам время при внедрении. =========== Источник: habr.com =========== Похожие новости:
Блог компании ГК ЛАНИТ ), #_messendzhery ( Мессенджеры ), #_razrabotka_sistem_svjazi ( Разработка систем связи ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:09
Часовой пояс: UTC + 5