Трансляция конференций и вебинаров с использованием протокола SIP

от автора

Статья посвящена возможным вариантам организации взаимодействия между программным обеспечением для интеграции между сетями доставки контента и источниками контента с использованием протокола SIP.

При проведении корпоративных обучающих вебинаров, конференций или общественных собраний, митингов используются существующие сервисы и решения с поддержкой протокола SIP. Однако у таких сервисов, как правило, отсутствуют решения, направленные на массовое вещание (трансляции) в сети Интернет. Существующие сервисы, такие как Zoom.us, InterCall, Twilio, Vidyo, iMeet и так далее, а также другие программно-аппаратные решения и продукты других производителей — не предоставляют функционала конвертации конференции, организованной с использованием протокола SIP, в массовую трансляцию в сети Интернет.

Общая схема сервисов митингов в Интернете

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

Ниже будут рассмотрены возможные варианты интеграции между двумя серверами потокового видео Adobe Media Server и Wowza Streaming Engine, сервисами Twilio, Zoom.us, Vidyo, Lifesize, Blue Jeans, iMeet, софтфоном CounterPath Bria 4 и платформами Flashphoner Web Call Server 4 в различных сочетаниях.

Как отбирались кандидаты на тестирование

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

К основным требованиям к серверу, осуществляющему интеграцию между другими сервисами и ПО:

  • гибкий механизм настроек под различные интегрируемые сервисы и программные продукты;
  • наличие подробной документации;
  • наличие технической поддержки от производителя;
  • простота администрирования.

При выборе сервисов основной критерий состоял в том, чтобы: а) сервис мог бы предоставить тестовый период для использования программного обеспечения; б) сервис должен декларировать или подразумевать что существует поддержка подключения участников по протоколу SIP. Из этого правила нами были допущены ряд исключений с сервисом zoom.us и с Bria, так как с этим софтфоном и его возможностями и особенностями использования мы хорошо знакомы, а сервис zoom.us достаточно новый стартап с декларированными большими возможностями, поэтому-то мы и решили его протестировать (даже не смотря что подключение по протоколу SIP у этого сервиса платное).

Исходя из сформулированных критериев отбора, нашего опыта работы с различным интеграционным ПО и удобства пользование тем или иным программным обеспечением мы решили использовать Web Call Server 4 для проведения наших экспериментов, хотя возможно применение и другого ПО.

Схема проверочного эксперимента

Один из наиболее распространенных вариантов взаимодействия между источником (справа) и получателем контента (слева) отображен на схеме ниже:

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

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

Сервера потокового видео, использовавшиеся в эксперименте:

  • Wowza Streaming Engine
  • Adobe Media Server

Интеграционная платформа:

  • Flashphoner Web Call Server 4
  • REST консоль (Google Chrome)

Источники трансляции:

  • CounterPath Bria 4
  • сервис Twilio.com
  • сервис Zoom.us
  • сервис iMeet
  • сервис Vidyo
  • сервис Blue Jeans
  • сервис Lifesize

Программы для просмотра трансляции (или контента):

  • Flash Player

Программы для отправки RTMP потока на сервер:

  • Adobe Flash Media Live Encoder 3.2

Условия для проведения эксперимента

Необходимым условием проведения эксперимента является наличие корректно установленных и сконфигурированных программных продуктов, описанных выше.

На скриншоте ниже показана настройка Adobe Flash Media Live Encoder’а, который был установлен на локальном клиенте (вне локальной сети, в которой были запущены CDN платформы).

Adobe Flash Media Live Encoder  window

Трансляцию с Adobe Flash Media Live Encoder мы использовали в качестве проверочного источника аудио/видео потока через сервер потокового видео. Результирующий поток (после сервера потокового видео) проверялся с помощью Flash Player (показан на скриншоте ниже).

Необходимо крайне внимательно проверить настройки потока (IP адрес, порт, название потока) как у источника, так и у получателя (плеера).

Схема проверки трансляции (работоспособности серверов потокового видео) представленна ниже:

Схема проверки трансляции через Adobe Flash Live Encoder
Результирующая трансляция в окне Flash Player'a

После проверки того факта, что аудио/видео поток достигает RTMP сервер, что мы и видим через плеер, можно перейти непосредственно к тестированию.

Также на момент тестирования Web Call Server’а с сервисом Twilio необходимо установить, какой публичный IP адрес выделен оператором связи для доступа Web Call Server’а в Интернет и прописать этот адрес в настройках SIP домена. Ту же самую операцию необходимо проделать для публичного IP адреса, который используется для тестировани сервиса Twilio с Bria (установленном на локальном компьютере).

Интеграция с сервисом zoom.us

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

Схема организации тестирования с использованием этого сервиса описана ниже:

Схема тестирования с использованием сервиса zoom.us

Для начала необходимо произвести настройку учетной записи и выполнить шаги по “иницииации” виртуальной учебной аудитории (см. cкриншот).

Инициация вируальной учебной аудитории в сервисе zoom.us

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

Каждой встрече присваивается уникальный девятизначный ID, сообщив который вместе с IP адресом сервиса, по которому ведется трансляция, можно пригласить “на встречу” сторонних участников. Последовательность действий показана на следующих скриншотах.

В конечном итоге, имея IP адрес и ID встречи, предоставляемые сервисом zoom.us мы можем настроить Web Call Server 4 и средство просмотра для того, чтобы поучаствовать “во встрече”.

Трансляция с сервиса zoom.us
Данные для дозвона в сервисе zoom.us

Запуск и конфигурирование Web Call Server 4

Несмотря на то что Web Call Server 4 является инструментом интеграции между различными источниками контента и серверами потокового вещания, каждая конференция (или иной источник) может иметь индивидуальные настройки, особенности и недокументированные требования к реализации стандартных протоколов SIP, RTMP.

В нашем конкретном случае оба сервера потокового вещания установлены на одном устройстве, поэтому первым шагом необходимо убедиться что одномоментно работает только один из серверов (AMS или WSE) — в ином случае (когда на под каждое ПО отдельное устройство) следующей операции нет необходимости.

Нам потребовалось принудительно останавливать один из них серверов потокового вещания, как показанно ниже:

Консоль

[root@wowza ams]# ./amsmgr server ams stop
Server: ams command: stop
NPTL 2.12
Stopping Adobe Media Server (please check /var/log/messages)
Server has shutdown…

[root@wowza ams]# service WowzaStreamingEngine start
WowzaStreamingEngine: starting…

В данном конкретном примере AMS остановлен (мы заранее знаем что он работал на 1936 порту), а на 1935 порту по адресу 45.101.139.105 работает Wowza Streaming Engine.

Далее необходимо убедиться что конфигурация Web Call Server 4 сервера соответствует параметрам используемого источника контента (в нашем примере – zoom.us), для этого, например через ssh можно обратиться к серверу на котором развернут Web Call Server 4 и в каталоге ./conf найти файл конфигурации, как это показанно на скриншоте ниже:

Папка с конфигурационным файлом Web Call Server 4

В самом файле необходимо изменить параметры codecs и ряд других, как указанно на скриншоте (при этом параметры, которые применимы для других сервисов можно просто “закомментировать”):

Листинг файла конфигурации Web Call Server 4

После сохранения новых параметров в конфигурационном файле необходимо перезапустить Web Call Server 4 (как показанно ниже):

Консоль

[root@SF1 conf]# service webcallserver stop

FlashphonerWebCallServer: stopping [OK]

[root@SF1 conf]# service webcallserver start

FlashphonerWebCallServer: starting [OK]

В результате всех указанных выше действий мы гарантированно имеем корректно функционирующие сервер потокового видео и Web Call Server 4 и можно приступать к непосредственному управлению Web Call Server 4 и источником трансляции.

Подключения через Web Call Server 4

Имея установленный и сконфигурированный, корректно работающий Web Call Server 4 мы должны иметь ввиду, что в общем случае, этот программный продукт выступает посредником между источником контента и сервером потокового вещания. В общем случае посредничество заключается в инициации вызова по протоколу SIP на источник контента, получении ответа от источника контента, получении самого контента и транслировании этого полученного контента на сервер потокового вещания.

Сам Web Call Server требует средств управления, реализация которого организованна через REST/JSON API команды. Такой механизм управления может быть интегрирован в любой существуюший программный продукт и обеспечить автоматическое управление Web Call Server’ом.

Для нашего конкретного случая мы используем REST консоль, через которую в Web Call Server отправляются запросы с параметрами, которые в свою очередь зависят от того, какой именно источник контента необходимо интегрировать с CDN.

Например для присоединения ко встрече, организованной на сервисе zoom.us необходимо отправить следующий запрос (что мы и сделаем через REST консоль Google Chrome):

REST консоль

{  
   «callId»:«Xq2tlLcX89tTjaji», # произвольный уникальный идентификатор звонка
   «callee»:«10000», # имя звонящего (выбранно произвольно)
   «rtmpUrl»:«rtmp://45.101.139.105:1935/live», # адрес трансляции (CDN платформы)
   «rtmpStream»:«lifestream1», # имя траслируемого потока
   «hasAudio»:«true», # атрибут аудио контента (есть/нет)
   «hasVideo»:«true», # атрибут видео контента (есть/нет)
   «connection»: # параметры соединения
{  
      «sipLogin»:«10000», # логин
      «sipPassword»:«10000000», # пароль
      «sipAuthenticationName»:«10000», # имя для аутентификации
      «sipDomain»:«162.255.36.11», # IP адрес встречи (предоставляется zoom.us)
      «sipPort»:«5060», # Порт, на котором ведется вещание по SIP
      «sipRegisterRequired»:«false», # атрибут регистрации в домене
      «appKey»:«callApp»
   }
}

Запрос с указанными выше параметрами отправляется на специальный URI Web Call Server’a, как это указанно ниже на скриншоте:

Скриншот REST консоли с адресом для запроса

После выполнения запроса со стороны Web Call Server 4 произойдет подключение WebCallServer к организованной zoom.us встрече (при этом Web Call Server 4 будет выступать как один из “слушателей”), одновременно ответ (контент сервиса zoom.us), полученный Web Call Server 4 – будет перенаправлен Web Call Server 4 далее на сервера потокового видео (что мы и видим на скриншотах ниже):

Трансляция результата после отправки запроса на zoom.us

Управление установленным подключением через Web Call Server

В данном конкретном случае с сервисом zoom.us неодходимо дополнительно подключиться к конкретной “встрече”, передав на сервер zoom.us конкретный идентификатор (предоставленный сервисом) “встречи” (в нашем случае это 311 705 123 ). Одним из способов является тоновый набор DTMF (например на клавиатуре софтфона). Такую же операцию может осуществить Web Call Server 4, как это показанно на скриншоте:

Скриншот REST консоли для DTMF запроса

Отправить такой запрос можно также через REST консоль через следующую комманду:

REST консоль

{
«callId»:«Xq2tlLcX89tTjaji», # тот же ID, что и в предыдущем запросе
«type»:«RFC2833»,
«dtmf»:«1**********311705123#» # уникальный ID, предоставленный сервисом zoom.us
}

/Прим: синтаксис 1********** является практическим ноу-хау при работе с сервисом zoom.us/

В результате произойдет подключение конкретного “абонента” к трансляции конкретной “встречи”, как показанно на скриншоте ниже. Как видно на скриншоте, в окне интерфейса zoom.us виден логотип Web Call Server’а, который в данном случае является одним из “слушателей” запущенного “митинга”.

Результат подключения к сервису zoom.us со стороны Web Call Server 4
Трансяция с сервиса zoom.us в сервера Adobe Media Server или Wowza Streaming Engine

В тоже время в окне Wowza Flash Player мы видим трансляцию, которую через Web Call Server 4 была перенаправлена с zoom.us на сервер Wowza Streaming Engine (см. скриншот).

Таким образом посредством двух команд, переданных через REST консоль на Web Call Server 4 нам удалось инициировать участие во встрече (“митинге”) на сервисе zoom.us и перенаправить контент (“картинку” и аудиопоток) на сервер Wowza Streaming Engine для последующего вещания через сеть CDN.

Трансляция нескольких подключений из Zoom.us

Web Call Server 4 может обеспечить трансляцию любого количества подключений из сервиса zoom.us, что мы и проверили на практике.
Для этого необходимо выполнить конфигурацию учетной записи Bria так, как это показанно на нижеследующих скриншотах:

Список аккаунтов в софтфоне Bria
Настройка аккаунта для Zoom.us

И установить необходимо достаточные кодеки для аудио и видео:

Используемые аудио кодеки для сервиса Zoom.us в Bria
Используемые видео кодеки для сервиса Zoom.us в Bria

Далее при наборе уникального ID комнаты, в которой происходит “митинг” произойдет подключение к общей конференции с трансляцией общего контента через CDN сервер.

Набор номера митинга предоставленного сервисом zoom.us

Анализ возможных проблем с интеграцией

В качестве источника знаний о возможных причинах сбоев при взаимодействии между Web Call Server 4 и другими программными продуктами и сервисами – рекомендуется обратиться к log файлам на сервере, где установлен Web Call Server 4, как показанно на скриншотах:

Log файл Web Call Server'a
Manager log файл

Результаты исполнения запросов через REST консоль можно посмотреть также через инструменты, предоставляемые Google Developer Tools, как это показанно на скриншоте:

Список ошибок при работе REST консоли в Google Chrome

Интеграция с сервисом Twilio

Для проверки гибкости интеграционной платформы Web Call Server 4 мы протестировали также взаимодействие с сервисом Twilio.
Схема организации эксперимента отображена на схеме:

Схема организации эксперимента с Twilio

Настройка учетной записи Twilio и SIP домена

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

Этап 1. Создание домена — в нашем случае flashphoner2

Скришот сервиса Twilio с доменом flashphoner2

Этап 2 — Создание списка доступа и определение прав доступа для домена

Страница сервиса Twilio с настройками домена
Шаг 2.1 — Формирование списка IP адресов, для которых разрешен доступ к домену.

Важно включить в этот список как IP адреса абонентских устройств (софтфонов), так и IP адрес Web Call Server 4.

Страница со списком IP адресов и пользователями
Список IP адресов
Шаг 2.2. — Формирование прав доступа

Спосок прав доступа

После того, как создан домен в сервисе Twilio, сформированны права доступа и список IP адресов, для которых разрешен доступ — можно приступить к конфигурированию софтфона, в нашем случае — Bria 4.

Настройка Bria и подключение к домену Twilio

В настройках Bria необходимо создать учетную запись (эккаунт) для доступа к Twilio, так, как показанно на скриншотах ниже:

Настройки аккаунтов Bria для доступа к Twilio
Аккаунт Twilio в Bria

Там же в настройках Bria надо сконфигурировать использование аудиокодеков: G711 aLaw, uLaw а также видеокодека H.264.

Аудио-кодеки для Twilio
Видео-кодеки для Twilio

После чего можно совершить тестовый звонок через Bria и прослушать через софтфон запись автоответчика, предоставленную Twilio.
Если домен на сервисе скофигурирован правильно (и запись автоответчика слышна в Bria), можно приступать к созданию управляющей команды для Web Call Server’а.

Изменение конфигурации Web Call Server для использования с Twilio

При тестировании сервиса Twilio с участием Web Call Server 4 требуется изменить настройки сервера. Такие изменения вносятся в конфигурационный файл flashphoner.properties.

Консоль с папкой где расположен конфигурационный файл Web Call Server

В частности меняется набор использемых кодеков и ряд других параметров.

Изменяемые параметры в конфиге Web Call Server

Что и как менять в конфигурационном файле — указанно в документации на Web Call Server 4, предоставляемой производителем интеграционного сервера.

После изменения кофигурации Web Call Server’а необходимо провести перезагрузку сервера чтобы изменения вступили в силу:

Консоль

[root@SF1 conf]# service webcallserver stop

FlashphonerWebCallServer: stopping [OK]

[root@SF1 conf]# service webcallserver start

FlashphonerWebCallServer: starting [OK]

Управление Web Call Server

Как и в предыдущем эксперименте, управление Web Call Server’ом осуществляется через отправку REST команды через REST консоль Google Chrome, так, как показанно ниже:

REST консоль

{
«callId»:«Xq2tlLcX89tTjaji»,
«callee»:«flashphoner2.sip.twilio.com»,
«rtmpUrl»:«rtmp://45.100.109.105:1936/live»,
«rtmpStream»:«lifestream1»,
«hasAudio»:«true»,
«hasVideo»:«true»,
«connection»:{
«sipLogin»:«flashphoner2»,
«sipPassword»:«RadK2151312»,
«sipAuthenticationName»:«flashphoner2»,
«sipDomain»:«flashphoner2.sip.twilio.com»,
«sipPort»:«5060»,
«sipRegisterRequired»:«false»,
«appKey»:«callApp»
}
}

Запрос отправляется на адрес Web Call Server’а: http: //107.179.239.129:9091/RESTCall/call.

В результате исполнения запроса генерируется звонок на SIP домен сервиса Twilio и во Flash Player’е можно прослушать ответ, поступивший от сервиса Twilio — вернее можно услышать проигрывание сообщение от автоответчика Twilio.

Таким образом в результате тестирования работы Web Call Server 4 как интеграционного решения между Twilio и Bria мы убедились что интеграционный сервер умеет взаимодействовать с сервисом Twilio и софтфонами, подключенными к этому сервису.

Интеграция с OpenSIPS

Для проверки возможности взаимодействия с IP-PBX решениями, был проведен тест с сервером IP-PBX OpenSIPS.

Схема организации тестовой площадки показана ниже:

Схема организации теста для OpenSIPS

В данном случае Bria выступает в роли “сервиса”, принимающего звонки от сторонних абонентов и отвечающего на вызовы контентом. В связи с этой иной ролью, в которой в данном конкретном случае выступает Bria, необходимо изменить настройки так, как показанно ниже на скриншотах. В частности необходимо создать эккаунт для осуществления звонков на IP-PBX OpenSIPS:

Конфигурация Bria для звонков через OpenSIPS

Как и в предыдущих случаях для демонстрации возможности управления Web Call Server’ом — отпрвляем запрос:

REST консоль

{
«callId»:«Xq2tlLcX89tTjaji»,
«callee»:«10050»,
«rtmpUrl»:«rtmp://45.101.139.105:1935/live»,
«rtmpStream»:«lifestream1»,
«hasAudio»:«true»,
«hasVideo»:«true»,
«connection»:{
«sipLogin»:«10051»,
«sipPassword»:«15001»,
«sipAuthenticationName»:«10051»,
«sipDomain»:«87.222.225.52»,
«sipPort»:«5080»,
«sipRegisterRequired»:«false»,
«appKey»:«callApp»
}
}

Следует обратить внимание на то, что вызов осуществляется через эккаунт 10051, созданный на OpenSIPS сервере, а “номер” вызываемого абонента указывается в поле “callee”.

В результате произведенный через Web Call Server 4 вызов на “абонента” 10050 был перенаправлен на сервер потокового вещания и в последующем прослушан через Flash Player.

Интеграция с Vidyo

Еще одним сервисом, тестирование с которым мы произвели, является Vidyo.com. Потребность в массовой трансляции связанна с тем что данный сервис имеет ограниченное количество участников каждой трансляции (митинга) и соответственно может возникнуть потребность пользуясь привычным сервисом (Vidyo) провести мероприятие на 50, 100 или больше количество участников.

Как и в случае с другими сервисами — для начала требуется регистрация на сервисе.

Начальная страница на сервисе Vidyo
Страница регистрации на сервисе Vidyo

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

Страница с настроенным аккаунтом Vidyo
Внешний вид интерфейса ПО Vidyo на локальном компьютере
Настройки конкретного аккаунта с номером комнаты

После ввода данных произойдет подключение к сервису и появится возможность создать митинг (комнату для проведения вирутальной встречи). На скриншоте видно что каждому зарегистрировавшемуся и подключившемуся к сервису предоставляется уникальный добавочный номер (Extension).

Для подключения других участников к встрече ( к комнате ), потребуется послать приглашение другим участникам, например по электронной почте.

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

Let’s meet via Vidyo!

— To join from your desktop or mobile device: Click join.vidyo.com/flex.html?roomdirect.html&key=1sQAgMIbOVihE3SFKKjl47oryI

— To join from your H.323/SIP video conferencing system inside the US: 75.98.89.60 and 1501005148 and PIN (If required)

— To join from your H.323/SIP video conferencing system outside the US: 31.186.235.56 and 1501005148 and PIN (If required)

— To join from telephone: (800) 916-5971, Conference ID 1501005148, and PIN (If required)

NOTE: Any video, audio and/or materials viewed during this conference may be recorded.

Need help getting started? Check out the Vidyo Knowledge Center at www.vidyo.com/knowledge-center

Для проверки работоспособности полученных от сервсиа Vidyo данных мы создали эккаунт в софтфоне Bria на основании предоставленных сервисом данных:

Настройки Bria для тестирования совместно с Vidyo

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

Обратите внимание что в Bria должен быть включен только эккаунт, созданный для сервиса Vidyo чтобы дозвон был произведен именно в этот сервис.

После набора номера 1501005148 на клавиатуре Bria будет осуществлен дозвон и подключение к виртуальной “комнате”, где будет проводиться встреча.

В окне программы можно увидеть что во встрече появился новый участник, как показанно на скриншоте ниже:

Два участника подключены к комнате в Vidyo

Так как наша проверка через Bria увенчалась успехом, приступим к проверке интеграции Web Call Server 4 с сервисом Vidyo.

Для этого создадим в REST консоли команду, как показанно на скриншотах ниже и отправим запрос на Web Call Server 4.

Скриншот REST консоли с адресом запроса на Web Call Server
Сам запрос к Web Call Server через REST консоль

После отправки запроса на web-сайте сервиса Vidyo появится новый участник встречи (с ID, который мы указали в команде Web Call Server’у).

Скриншот с несколькими участниками подключенными к сервису Vidyo

А при этом в плеере, через который мы проверяем наличие трансляции с подключаемого сервиса — видно окно с картинкой, которая была передана инциатором митинга в сервис как замена трансляции с web-камеры.

Проверочное видео в Flash Player полученное через сервер потокового вещания после запроса от Web Call Server к Vidyo

Ранее был описан механизм запуска серверов потокового видео и при проведении этого теста мы использовали как AMS так и WSE, при этом настройки Web Call Server’а были использованы те, которые мы ранее указывали для сервиса zoom.us

Интеграция с сервисом Blue Jeans

Одним из относительно известных сервисов для организации конференций в Интернете является сервис Blue Jeans, интеграцию с которым мы также решили проверить.

Этот сервис также предлагает достаточно простой механизм организации встречи (митинга), для начала необходимо зарегистрироваться и создать свой эккаунт, как показанно ниже:

Начальная страница сервиса Blue Jeans

После этого шага, как и в предыдущих случаях с аналогичными сервсиами, необходимо проинсталлировать программное обеспечение, предоставляемое сервисом Blue Jeans.

Этапность регистрации на сервисе Blue Jeans
Страница загрузки ПО с сервиса Blue Jeans

После инсталляции программного обеспечения Blue Jeans на ваш компьютер, дальнейшие действия совершаются через это программное обеспечение.

Естественно чтобы подключить кого-то ко встрече, необходимо эту встречу организовать, а для этого в ПО Blue Jeans такую встречу необходимо создать и после создания — отправить потенциальным участникам данные встречи, в данном случае:

  • IP адрес (dial IP)
  • ID встречи (meeting ID)
  • Код верификации (passcode)

Если второй участник, которого вы хотите пригласить, пользуется таким же ПО Blue Jeans, сервис Blue Jeans предлагает ввести код в специальном окне (“pairing code”) и можно “запараллелить” ваше и его программное обеспечение. Впрочем такая функция для целей нашего тестирования не использовалась, мы использовали предоставленные сервисом “meeting ID” и “passcode”.

Информация для подключения к сервису Blue Jeans со стороны

После получения данных для подключения к виртуальной “комнате”, где проводиться встреча, мы, как и ранее, решили проверить функционирование сервиса с софтфоном Bria.

Для этого создали эккаунт в Bria как показанно ниже:

Настройка Bria для тестирования Blue Jeans

Необходимо отметить, что данные для Domain мы почерпнули из комьюнити пользователей Blue Jeans, так как непосредственно при создании комнаты предлагается использовать IP адрес (как показанно выше) для дозвона или доменное имя bjn.vc.

То что необходимо использовать нотацию sip.bjc.vc для подключения с использованием SIP — расписанно в сообщениях комьюнити, как показанно ниже:

Скриншот страницы коммьюнити где мы нашли данные о правильном SIP домене для сервиса Blue Jeans

После создания эккаунта в Bria мы набрали на клавиатуре ID митинга и получили подключение с трансляцией картинки (в нашем случае — записанный ранее в ManyCam видеофрагмент) в митинг и трансляции данных митинга в Bria, как показанно ниже:

Трансляция результата подключения к сервису Blue Jeans

Далее, проверяя возможности интеграции между Blue Jeans и Web Call Server 4 мы с использованием REST консоли отправили на адрес Web Call Server 4: http: //107.179.239.120:9091/RESTCall/call следующий запрос:

REST консоль

{
«callId»:«100501Cxbsf»,
«callee»:«5322844144»,
«rtmpUrl»:«rtmp://45.101.139.105:1935/live»,
«rtmpStream»:«livestream1»,
«hasAudio»:«true»,
«hasVideo»:«true»,
«connection»:{
«sipLogin»:«100501»,
«sipPassword»:«9354»,
«sipAuthenticationName»:«100501»,
«sipDomain»:«sip.bjn.vc»,
«sipPort»:«5060»,
«sipRegisterRequired»:«false»,
«appKey»:«callApp»
}
}

Надо отметить что в запросе в качестве поля callee используется ID митинга, а в качестве sipDomain — данные взятые из комьюнити, то есть sip.bjc.vc

После подключения в окне ПО Blue Jeans можно увидеть что в митинге появились несколько участников (один из них Bria, второй Web Call Server 4), как показанно ниже:

Два участника присоединились к митингу в Blue Jeans

В проигрывателе мы соответственно можем наблюдать “картинку” с локального компьютера (как показанно ниже), то есть мы видим то, что “видит” ПО Blue Jeans на локальном компьютере. Далее ПО Blue Jeans отправляет это видео на сервис, а уже Web Call Server 4 инициирует и получает ответ от сервиса Blue Jeans и перенаправляет ответ сервиса на сервер потокового видео (AMS или WSE, в нашем эксперименте), которое мы и видим в окне Flash Player’а.

Трансляция от сервера потокового видео после обработки запроса от Web Call Server

По общему впечатлению, за исключением “умолчания” о том что для SIP соединения нужно использовать специфичный домен, общее взаимодействие с сервисом Blue Jeans оказалось простым и относительно беспроблемным.

Интеграция с Lifesize

Еще одним из доступных сервисов, интеграция с которым проверялась является сервис Lifesize.

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

После установки программного обеспечения на локальный компьютер, можно сказать “как обычно”, нужно создать встречу (см. скриншот ниже):

Встречи созданные в сервисе Lifesize
Внешний вид ПО Lifesize на локальном компьютере

Для каждой встречи предоставляется контакты (данные), по которым сторонний участник может осуществить дозвон (обращение) и поучаствовать во встрече, как указанно ниже:

Данные для подключения ко встрече в тч IP адрес для подключения например через Bria
Доп данные для подключения в сервис Lifesize
Телефоны дозвона в сервис Lifesize

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

Подсказки в локальном ПО Lifesize

Web Call Server 4, как обычно, с помощью команды через REST консоль, установил по предоставленым данным (см. выше) соединение с сервисом Lifesize.

Скриншот запроса к серверу Lifesize через Web Call Server

Сам сервис показывает в своей программе окно подключившегося участника:

Несколько участников в комнате митинга Lifesize

И показывает количество участников:

Демонстрация количества участников

И результаты ответа были транслированны Web Call Server на сервер потокового вещания (AMS или WSE).

Трансляция ответа от Lifesize полученного через сервер потокового вещания
Видео от сервиса Lifesize полученное через сервер потокового вещания

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

Интеграция с iMeet

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

Этапы регистрации в сервисе iMeet

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

Также как и раньше — сервис предоставляет данные, но в отличие от предыдущих сервисом в качестве адреса дозвона предоставляется URI типа: www.imeet.com/georgeb

<img src=«andyastahov2006.1apps.com/habrahabr/70-imeet_comp_panel.pngalign=»center" border=«0» alt=«Внешний вид локального ПО iMeet»>

Данные для подключения к iMeet

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

Воспользовавшись ссылкой из приглашения, пришедшего по электронной почте, удалось поучаствовать во встрече с помощью веб браузера (без необходимости установки ПО):

Несколько участников во встрече организованной через iMeet
Участники встречи  в iMeet

Однако дозвониться в митинг с софтфона Bria не удалось, что с нашей точки зрения поясняется сервисом в следующем комментарии:

«While iMeet does not have a direct integration with SIP/SIMPLE or XMPP, iMeet provides each host with a personal online meeting room, so you can also simply put in your URL (e.g. www.imeet.com/georgeb) into an IM conversation to invite guests into your meeting. You could also store your iMeet URL in your Salesforce profile and allow people to connect to your iMeet directly from there!» ( community.imeet.com/thread/1700 )

С использованием полученных рекомендаций и следующих настроек Bria соединения с митингом все равно не происходило (при этом параметр Domain менялся и на www.imeet.com/Vlad439323 и на www.imeet.com/Vlad439323):

Настройки аккаунта Bria для работы с iMeet

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

Сервис iMeetVRC который возможно работает с SIP телефонами

Что и будет проверенно нами в последующих тестах.

Заключительные выводы

В соответствии с нашими критериями отбора и условиями эксперимента нам с разной степенью успешности, которая будет пояснена ниже, смогли протестировать взаимную совместимость различных сервисов и программных продуктов. На удивлление многие сервисы достаточно беспроблемно были интегрированы к серверам потокового вещания Wowza Streaming Engine и Adobe Media Server с использованием промежуточного ПО Web Call Server 4.

В частности нам удалось удостовериться в том, что существует:

  • возможность иницииации вызова на сервис Zoom.us и управление вызовом;
  • возможность трансляции потокового контента в том числе с несколькими подключениями с сервиса Zoom.us;
  • возможности Web Call Server’а дозваниваться до сервиса Twilio и абонентов, подключенных к этому сервису;
  • способность управлять вызовами у подключенных через IP-PBX OpenSIPS абонентов интеграция с сервисом Vidyo оказалась более простой, чем с сервисом zoom.us, так как инициация и управление соединением в Web Call Server ограничилось одной командой;
  • сервис Lifesize субъективно потребовал большей пропускной способности для качественного отображения видео в окне сервиса, в то время как сервис Blue Jeans в использовании оказался простым и позволил практически в несколько элементарных шагов осуществить одновременное подключение к митингу Bria и Web Call Server 4 ;

Все тесты были проведены с двумя серверами потокового вещания — Wowza Streaming Engine и Adobe Media Server.

Результаты тестирования сведены нами в таблицу ниже:

Сравнительная таблица по результатам всех тестов серверов потокового вещания Adobe Media Server Wowza Streamin Engine софтфона Bria сервисов ZoomUS Twilio Vidyo Blue Jeans iMeet Lifesize OpenSIPS c использованием Web Call Server 4

При рассмотрении кандидатов на тестирование мы убеждались что часть сервисов, ссылки на которые имеются, не существуют или же не предоставляют он-лайн версии сервисов (и требую устанавливать ПО на сервер), часть сервисов оказались узкофункциональными “мессанджерами” или же не поддерживали SIP протокол.

Нам бы хотелось предположить, что показанный нами результат взаимного тестирования сервисов и программного обеспечения побудит других заинтересованных лиц используя этот список: vsee.com/videoconference провести самостоятельное тестирование других сервисов с тем же или другим набором программного обеспечения и было бы интересно узнать, к каким выводам и результатам удастся прийти по результатам такого нового эксперимента.

Использованные ресурсы

  1. Анализатор трафика — www.wireshark.org
  2. Wowza Streaming Engine — www.wowza.com
  3. Adobe Media Server — www.adobe.com/products/adobe-media-server-family.html
  4. Web Call Server 4 — flashphoner.com
  5. www.zoom.us
  6. www.twilio.com
  7. www.lifesize.com
  8. www.bluejeans.com
  9. www.vidyo.com
  10. www.pgi.com
  11. ПО CounterPath — www.counterpath.com/bria
  12. ПО для обработки виде/аудио контента — manycam.com

ссылка на оригинал статьи https://habrahabr.ru/post/276487/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *