Трансляція конференцій і вебінарів з використанням протоколу 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 в різних поєднаннях.

НавігаціяОсновні вимоги до інтеграційної платформи
<a href="#A2>Схема контрольного експерименту.
Умови для проведення експерименту.
Інтеграція з сервісом zoom.us.
Запуск і конфігурування Web Call Server 4.
Ініціація підключення через Web Call Server 4.
Управління встановленим підключенням через Web Call Server 4.
Трансляція декількох підключень з Zoom.us.
Аналіз можливих проблем з інтеграцією.
Інтеграція з сервісом Twilio.
Управління Web Call Server.
Інтеграція з OpenSIPS.
Інтеграція з Vidyo.
Інтеграція з сервісом Blue Jeans.
Інтеграція з Lifesize.
Інтеграція з iMeet.
Заключні висновки.
Використані ресурси.

Як відбиралися кандидати на тестування
Вирішивши протестувати різні сервіси та програмні продукти на взаємну сумісність і можливість здійснювати масову трансляцію в мережі Інтернет, ми відібрали сервіси і продукти за кількома критеріями.

До основним вимогам до сервера, здійснює інтеграцію між іншими сервісами та ЗА:

  • гнучкий механізм налаштувань під різні інтегровані сервіси і програмні продукти;
  • наявність докладної документації;
  • наявність технічної підтримки від виробника;
  • простота адміністрування.
При виборі сервісів основний критерій полягав у тому, щоб: а) сервіс міг би надати тестовий період для використання програмного забезпечення; б) сервіс повинен декларувати або неявним що існує підтримка підключення учасників по протоколу 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&#39;a

Після перевірки того факту, що аудіо/відео потік досягає RTMP сервер, що ми і бачимо через плеєр, можна перейти безпосередньо до тестування.

Також на момент тестування Web Call Server'mssql а з сервісом Twilio необхідно встановити, який публічний IP адреса виділено оператором зв'язку для доступу Web Call Server'mssql а в Інтернет і прописати цю адресу у налаштуваннях SIP домену. Ту ж саму операцію необхідно виконати для публічного IP-адреси, яка використовується для тестування сервісу Twilio з Bria (встановленому на локальному комп'ютері).

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

Схема організації тестування з використанням цього сервісу описана нижче:

Схема тестування з використанням сервісу zoom.us

Для початку необхідно зробити налаштування облікового запису і виконати кроки по «иницииации» віртуальної навчальної аудиторії (див. скріншот).

Ініціація віртуальної навчальної аудиторії в сервісі 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]

У результаті всіх зазначених вище дій ми гарантовано маємо коректно функціонують сервер потокового відео і Веб 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'mssql 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», # ідентифікатор, що і в попередньому запиті
«type»:«RFC2833»,
«dtmf»:«1**********311705123#» # унікальний ID, наданий сервісом zoom.us
}
/Прим: синтаксис 1********** є практичним ноу-хау при роботі з сервісом zoom.us/

В результаті відбудеться підключення конкретного «абонента» до трансляції конкретної «зустрічі», як показанно на скріншоті нижче. Як видно на скріншоті, у вікні інтерфейсу zoom.us видно логотип Web Call Server'mssql а, який в даному випадку є одним із «слухачів» запущеного «мітингу».

Результат підключення до сервісу 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&#39;mssql 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'mssql а.

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

Консоль з папкою де розташований конфігураційний файл Web Call Server

Зокрема змінюється набір использемых кодеків і ряд інших параметрів.

Змінні параметри в конфіги Web Call Server

Що і як змінювати в конфігураційному файлі — зазначено у документації на Web Call Server 4, наданої виробником інтеграційного сервера.

Після зміни кофигурации Web Call Server'mssql а необхідно провести перезавантаження сервера щоб зміни вступили в силу:

Консоль
[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'mssql а: 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 на локальному комп&#39;ютері

Налаштування конкретного облікового запису з номером кімнати

Після введення даних відбудеться підключення до сервісу і з'явиться можливість створити мітинг (кімнату для проведення вирутальной зустрічі). На скріншоті видно що кожному зареєструвався і підключився до сервісу надається унікальний номер розширення (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'mssql у).

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

А при цьому в плеєрі, через який ми перевіряємо наявність трансляції з підключається сервісу — видно вікно з картинкою, яка була передана инциатором мітингу в сервіс як заміна трансляції з веб-камери.

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

Раніше був описаний механізм запуску серверів потокового відео і при проведенні цього тесту ми використовували як AMS так і WSE, при цьому налаштування Web Call Server'mssql а були використані ті, які ми раніше зазначали для сервісу 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 на локальному комп&#39;ютері

Для кожної зустрічі надається контакти (дані), за яким цей учасник може здійснити дозвон (звернення) і взяти участь у зустрічі, як показано нижче:

Дані для підключення до зустрічі в тч 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

Зовнішній вигляд локального ЗА 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'mssql а додзвонюватися до сервісу 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 Wowza Media Server Streamin Engine софтфона Bria сервісів ZoomUS Twilio Vidyo Blue Jeans iMeet Lifesize OpenSIPS з використанням 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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.