Статья посвящена возможным вариантам организации взаимодействия между программным обеспечением для интеграции между сетями доставки контента и источниками контента с использованием протокола 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 для проведения наших экспериментов, хотя возможно применение и другого ПО.
Один из наиболее распространенных вариантов взаимодействия между источником (справа) и получателем контента (слева) отображен на схеме ниже:
Надо отметить что при проверке различных вариантов организации взамиодействия через интеграционную платформу мы перестраивали указанную схему в зависимоти от потребностей эксперимента.
Сервера потокового видео, использовавшиеся в эксперименте:
Интеграционная платформа:
Источники трансляции:
Программы для просмотра трансляции (или контента):
Программы для отправки RTMP потока на сервер:
Необходимым условием проведения эксперимента является наличие корректно установленных и сконфигурированных программных продуктов, описанных выше.
На скриншоте ниже показана настройка Adobe Flash Media Live Encoder'а, который был установлен на локальном клиенте (вне локальной сети, в которой были запущены CDN платформы).
Трансляцию с Adobe Flash Media Live Encoder мы использовали в качестве проверочного источника аудио/видео потока через сервер потокового видео. Результирующий поток (после сервера потокового видео) проверялся с помощью Flash Player (показан на скриншоте ниже).
Необходимо крайне внимательно проверить настройки потока (IP адрес, порт, название потока) как у источника, так и у получателя (плеера).
Схема проверки трансляции (работоспособности серверов потокового видео) представленна ниже:
После проверки того факта, что аудио/видео поток достигает RTMP сервер, что мы и видим через плеер, можно перейти непосредственно к тестированию.
Также на момент тестирования Web Call Server’а с сервисом Twilio необходимо установить, какой публичный IP адрес выделен оператором связи для доступа Web Call Server’а в Интернет и прописать этот адрес в настройках SIP домена. Ту же самую операцию необходимо проделать для публичного IP адреса, который используется для тестировани сервиса Twilio с Bria (установленном на локальном компьютере).
С ростом интереса к дистанционному обучению и терреториально распределенному обмену аудио/видео информацией в режиме реального времени — набирают популярность различные сервисы, предоставляющие необходимый функционал. Одним из таких сервисов является zoom.us.
Схема организации тестирования с использованием этого сервиса описана ниже:
Для начала необходимо произвести настройку учетной записи и выполнить шаги по “иницииации” виртуальной учебной аудитории (см. cкриншот).
После инициации на локальном компьютере будет запущено программное обеспечение, предоставленное сервисом, которое захватит голос с микрофона и видео с камеры компьютера.
Каждой встрече присваивается уникальный девятизначный ID, сообщив который вместе с IP адресом сервиса, по которому ведется трансляция, можно пригласить “на встречу” сторонних участников. Последовательность действий показана на следующих скриншотах.
В конечном итоге, имея IP адрес и ID встречи, предоставляемые сервисом zoom.us мы можем настроить Web Call Server 4 и средство просмотра для того, чтобы поучаствовать “во встрече”.
Несмотря на то что Web Call Server 4 является инструментом интеграции между различными источниками контента и серверами потокового вещания, каждая конференция (или иной источник) может иметь индивидуальные настройки, особенности и недокументированные требования к реализации стандартных протоколов SIP, RTMP.
В нашем конкретном случае оба сервера потокового вещания установлены на одном устройстве, поэтому первым шагом необходимо убедиться что одномоментно работает только один из серверов (AMS или WSE) — в ином случае (когда на под каждое ПО отдельное устройство) следующей операции нет необходимости.
Нам потребовалось принудительно останавливать один из них серверов потокового вещания, как показанно ниже:
В данном конкретном примере AMS остановлен (мы заранее знаем что он работал на 1936 порту), а на 1935 порту по адресу 45.101.139.105 работает Wowza Streaming Engine.
Далее необходимо убедиться что конфигурация Web Call Server 4 сервера соответствует параметрам используемого источника контента (в нашем примере – zoom.us), для этого, например через ssh можно обратиться к серверу на котором развернут Web Call Server 4 и в каталоге ./conf найти файл конфигурации, как это показанно на скриншоте ниже:
В самом файле необходимо изменить параметры codecs и ряд других, как указанно на скриншоте (при этом параметры, которые применимы для других сервисов можно просто “закомментировать”):
После сохранения новых параметров в конфигурационном файле необходимо перезапустить 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):
Запрос с указанными выше параметрами отправляется на специальный URI Web Call Server’a, как это указанно ниже на скриншоте:
После выполнения запроса со стороны Web Call Server 4 произойдет подключение WebCallServer к организованной zoom.us встрече (при этом Web Call Server 4 будет выступать как один из “слушателей”), одновременно ответ (контент сервиса zoom.us), полученный Web Call Server 4 – будет перенаправлен Web Call Server 4 далее на сервера потокового видео (что мы и видим на скриншотах ниже):
В данном конкретном случае с сервисом zoom.us неодходимо дополнительно подключиться к конкретной “встрече”, передав на сервер zoom.us конкретный идентификатор (предоставленный сервисом) “встречи” (в нашем случае это 311 705 123 ). Одним из способов является тоновый набор DTMF (например на клавиатуре софтфона). Такую же операцию может осуществить Web Call Server 4, как это показанно на скриншоте:
Отправить такой запрос можно также через REST консоль через следующую комманду:
В результате произойдет подключение конкретного “абонента” к трансляции конкретной “встречи”, как показанно на скриншоте ниже. Как видно на скриншоте, в окне интерфейса zoom.us виден логотип Web Call Server'а, который в данном случае является одним из “слушателей” запущенного “митинга”.
В тоже время в окне Wowza Flash Player мы видим трансляцию, которую через Web Call Server 4 была перенаправлена с zoom.us на сервер Wowza Streaming Engine (см. скриншот).
Таким образом посредством двух команд, переданных через REST консоль на Web Call Server 4 нам удалось инициировать участие во встрече (“митинге”) на сервисе zoom.us и перенаправить контент (“картинку” и аудиопоток) на сервер Wowza Streaming Engine для последующего вещания через сеть CDN.
Web Call Server 4 может обеспечить трансляцию любого количества подключений из сервиса zoom.us, что мы и проверили на практике.
Для этого необходимо выполнить конфигурацию учетной записи Bria так, как это показанно на нижеследующих скриншотах:
И установить необходимо достаточные кодеки для аудио и видео:
Далее при наборе уникального ID комнаты, в которой происходит “митинг” произойдет подключение к общей конференции с трансляцией общего контента через CDN сервер.
В качестве источника знаний о возможных причинах сбоев при взаимодействии между Web Call Server 4 и другими программными продуктами и сервисами – рекомендуется обратиться к log файлам на сервере, где установлен Web Call Server 4, как показанно на скриншотах:
Результаты исполнения запросов через REST консоль можно посмотреть также через инструменты, предоставляемые Google Developer Tools, как это показанно на скриншоте:
Для проверки гибкости интеграционной платформы Web Call Server 4 мы протестировали также взаимодействие с сервисом Twilio.
Схема организации эксперимента отображена на схеме:
Для начала использования сервисом Twilio необходимо настроить учетную запись на сервисе и создать домент, к которому будут подключаться софтфоны. Последовательность этих действий отображенна на следующих скриншотах:
Важно включить в этот список как IP адреса абонентских устройств (софтфонов), так и IP адрес Web Call Server 4.
После того, как создан домен в сервисе Twilio, сформированны права доступа и список IP адресов, для которых разрешен доступ — можно приступить к конфигурированию софтфона, в нашем случае — Bria 4.
В настройках Bria необходимо создать учетную запись (эккаунт) для доступа к Twilio, так, как показанно на скриншотах ниже:
Там же в настройках Bria надо сконфигурировать использование аудиокодеков: G711 aLaw, uLaw а также видеокодека H.264.
После чего можно совершить тестовый звонок через Bria и прослушать через софтфон запись автоответчика, предоставленную Twilio.
Если домен на сервисе скофигурирован правильно (и запись автоответчика слышна в Bria), можно приступать к созданию управляющей команды для Web Call Server’а.
При тестировании сервиса Twilio с участием Web Call Server 4 требуется изменить настройки сервера. Такие изменения вносятся в конфигурационный файл flashphoner.properties.
В частности меняется набор использемых кодеков и ряд других параметров.
Что и как менять в конфигурационном файле — указанно в документации на Web Call Server 4, предоставляемой производителем интеграционного сервера.
После изменения кофигурации Web Call Server’а необходимо провести перезагрузку сервера чтобы изменения вступили в силу:
Как и в предыдущем эксперименте, управление Web Call Server’ом осуществляется через отправку REST команды через REST консоль Google Chrome, так, как показанно ниже:
Запрос отправляется на адрес Web Call Server’а: http: //107.179.239.129:9091/RESTCall/call.
В результате исполнения запроса генерируется звонок на SIP домен сервиса Twilio и во Flash Player’е можно прослушать ответ, поступивший от сервиса Twilio — вернее можно услышать проигрывание сообщение от автоответчика Twilio.
Таким образом в результате тестирования работы Web Call Server 4 как интеграционного решения между Twilio и Bria мы убедились что интеграционный сервер умеет взаимодействовать с сервисом Twilio и софтфонами, подключенными к этому сервису.
Для проверки возможности взаимодействия с IP-PBX решениями, был проведен тест с сервером IP-PBX OpenSIPS.
Схема организации тестовой площадки показана ниже:
В данном случае Bria выступает в роли “сервиса”, принимающего звонки от сторонних абонентов и отвечающего на вызовы контентом. В связи с этой иной ролью, в которой в данном конкретном случае выступает Bria, необходимо изменить настройки так, как показанно ниже на скриншотах. В частности необходимо создать эккаунт для осуществления звонков на IP-PBX OpenSIPS:
Как и в предыдущих случаях для демонстрации возможности управления Web Call Server’ом — отпрвляем запрос:
Следует обратить внимание на то, что вызов осуществляется через эккаунт 10051, созданный на OpenSIPS сервере, а “номер” вызываемого абонента указывается в поле “callee”.
В результате произведенный через Web Call Server 4 вызов на “абонента” 10050 был перенаправлен на сервер потокового вещания и в последующем прослушан через Flash Player.
Еще одним сервисом, тестирование с которым мы произвели, является Vidyo.com. Потребность в массовой трансляции связанна с тем что данный сервис имеет ограниченное количество участников каждой трансляции (митинга) и соответственно может возникнуть потребность пользуясь привычным сервисом (Vidyo) провести мероприятие на 50, 100 или больше количество участников.
Как и в случае с другими сервисами — для начала требуется регистрация на сервисе.
Далее, после регистрации, потребуется проинсталировать программное обеспечение на ваш локальный компьютер и ввести полученые при активации данные для подключения к сервису.
После ввода данных произойдет подключение к сервису и появится возможность создать митинг (комнату для проведения вирутальной встречи). На скриншоте видно что каждому зарегистрировавшемуся и подключившемуся к сервису предоставляется уникальный добавочный номер (Extension).
Для подключения других участников к встрече ( к комнате ), потребуется послать приглашение другим участникам, например по электронной почте.
После нажатия на соответствующую иконку в окне программы — будет создан черновик сообщения в программе для обработки электронной почты, где будут видны данные для подключения, которые необходимо сообщить другим потенциальным участникам встречи.
Текст подобного письма приведен ниже:
Для проверки работоспособности полученных от сервсиа Vidyo данных мы создали эккаунт в софтфоне Bria на основании предоставленных сервисом данных:
При создании эккаунта в Bria мы исходили из того, что имя пользователя и пароль могут быть выбраны произвольным образом и критически важным является только IP адрес, по которому будет производиться подключение и (в дальнейшем) номер, который будет набираться чтобы подключиться ко встречи в комнате.
Обратите внимание что в Bria должен быть включен только эккаунт, созданный для сервиса Vidyo чтобы дозвон был произведен именно в этот сервис.
После набора номера 1501005148 на клавиатуре Bria будет осуществлен дозвон и подключение к виртуальной “комнате”, где будет проводиться встреча.
В окне программы можно увидеть что во встрече появился новый участник, как показанно на скриншоте ниже:
Так как наша проверка через Bria увенчалась успехом, приступим к проверке интеграции Web Call Server 4 с сервисом Vidyo.
Для этого создадим в REST консоли команду, как показанно на скриншотах ниже и отправим запрос на Web Call Server 4.
После отправки запроса на web-сайте сервиса Vidyo появится новый участник встречи (с ID, который мы указали в команде Web Call Server’у).
А при этом в плеере, через который мы проверяем наличие трансляции с подключаемого сервиса — видно окно с картинкой, которая была передана инциатором митинга в сервис как замена трансляции с web-камеры.
Ранее был описан механизм запуска серверов потокового видео и при проведении этого теста мы использовали как AMS так и WSE, при этом настройки Web Call Server’а были использованы те, которые мы ранее указывали для сервиса zoom.us
Одним из относительно известных сервисов для организации конференций в Интернете является сервис Blue Jeans, интеграцию с которым мы также решили проверить.
Этот сервис также предлагает достаточно простой механизм организации встречи (митинга), для начала необходимо зарегистрироваться и создать свой эккаунт, как показанно ниже:
После этого шага, как и в предыдущих случаях с аналогичными сервсиами, необходимо проинсталлировать программное обеспечение, предоставляемое сервисом Blue Jeans.
После инсталляции программного обеспечения Blue Jeans на ваш компьютер, дальнейшие действия совершаются через это программное обеспечение.
Естественно чтобы подключить кого-то ко встрече, необходимо эту встречу организовать, а для этого в ПО Blue Jeans такую встречу необходимо создать и после создания — отправить потенциальным участникам данные встречи, в данном случае:
Если второй участник, которого вы хотите пригласить, пользуется таким же ПО Blue Jeans, сервис Blue Jeans предлагает ввести код в специальном окне (“pairing code”) и можно “запараллелить” ваше и его программное обеспечение. Впрочем такая функция для целей нашего тестирования не использовалась, мы использовали предоставленные сервисом “meeting ID” и “passcode”.
После получения данных для подключения к виртуальной “комнате”, где проводиться встреча, мы, как и ранее, решили проверить функционирование сервиса с софтфоном Bria.
Для этого создали эккаунт в Bria как показанно ниже:
Необходимо отметить, что данные для Domain мы почерпнули из комьюнити пользователей Blue Jeans, так как непосредственно при создании комнаты предлагается использовать IP адрес (как показанно выше) для дозвона или доменное имя bjn.vc.
То что необходимо использовать нотацию sip.bjc.vc для подключения с использованием SIP — расписанно в сообщениях комьюнити, как показанно ниже:
После создания эккаунта в Bria мы набрали на клавиатуре ID митинга и получили подключение с трансляцией картинки (в нашем случае — записанный ранее в ManyCam видеофрагмент) в митинг и трансляции данных митинга в Bria, как показанно ниже:
Далее, проверяя возможности интеграции между Blue Jeans и Web Call Server 4 мы с использованием REST консоли отправили на адрес Web Call Server 4: http: //107.179.239.120:9091/RESTCall/call следующий запрос:
Надо отметить что в запросе в качестве поля callee используется ID митинга, а в качестве sipDomain — данные взятые из комьюнити, то есть sip.bjc.vc
После подключения в окне ПО Blue Jeans можно увидеть что в митинге появились несколько участников (один из них Bria, второй Web Call Server 4), как показанно ниже:
В проигрывателе мы соответственно можем наблюдать “картинку” с локального компьютера (как показанно ниже), то есть мы видим то, что “видит” ПО Blue Jeans на локальном компьютере. Далее ПО Blue Jeans отправляет это видео на сервис, а уже Web Call Server 4 инициирует и получает ответ от сервиса Blue Jeans и перенаправляет ответ сервиса на сервер потокового видео (AMS или WSE, в нашем эксперименте), которое мы и видим в окне Flash Player’а.
По общему впечатлению, за исключением “умолчания” о том что для SIP соединения нужно использовать специфичный домен, общее взаимодействие с сервисом Blue Jeans оказалось простым и относительно беспроблемным.
Еще одним из доступных сервисов, интеграция с которым проверялась является сервис Lifesize.
Примерно также как и все с предыдущеми сервисами воспользоваться сервисом можно после регистрации на сайте, скачивания и установки программного обеспечения, предоставленного сервисом и именно это мы и сделали.
После установки программного обеспечения на локальный компьютер, можно сказать “как обычно”, нужно создать встречу (см. скриншот ниже):
Для каждой встречи предоставляется контакты (данные), по которым сторонний участник может осуществить дозвон (обращение) и поучаствовать во встрече, как указанно ниже:
Предоставленные сервисом Lifesize данные мы использовали для дозвона и приятно были поражены тем, что каждый этап подключения к сервису сопровождается визуальным информированием (и голосовым помощником, что впрочем, является общей функцией для всех аналогичных сервисов):
Web Call Server 4, как обычно, с помощью команды через REST консоль, установил по предоставленым данным (см. выше) соединение с сервисом Lifesize.
Сам сервис показывает в своей программе окно подключившегося участника:
И показывает количество участников:
И результаты ответа были транслированны Web Call Server на сервер потокового вещания (AMS или WSE).
По субъективным ощущениям данный сервис более требовательный к качеству канала связи, однако данное наблюдение не является каким-то подтвержденным фактом, и полностью субъективно.
Сервис iMeet предоставляет линейку различных решений для организации совместных мероприятий в сети Интернет, в том числе с возможностью подключения участников с использованием телефона.
Интерефейс программы, которую надо скачать и установить, чтобы воспользоваться сервисом, поражает возможностями красочного оформления и сопровождающей информации (время, погода и т.п.).
Также как и раньше — сервис предоставляет данные, но в отличие от предыдущих сервисом в качестве адреса дозвона предоставляется URI типа: www.imeet.com/georgeb
Также как и у предыдущих сервисов — существует возможность приглашения сторонних участников во встречу (в том числе и по электронной почте), а также, что достаточно удобно, дозвона из сервиса на номер телефона потенциального участника (то есть не участнику надо дозваниваться, а вам сервис звонит).
Воспользовавшись ссылкой из приглашения, пришедшего по электронной почте, удалось поучаствовать во встрече с помощью веб браузера (без необходимости установки ПО):
Однако дозвониться в митинг с софтфона Bria не удалось, что с нашей точки зрения поясняется сервисом в следующем комментарии:
С использованием полученных рекомендаций и следующих настроек Bria соединения с митингом все равно не происходило (при этом параметр Domain менялся и на www.imeet.com/Vlad439323 и на www.imeet.com/Vlad439323):
Рискнем предположить что для подключения с использованием SIP протокола необходимо протестировать другое программное обеспечение и несколько иной вид услуг, предоставляемый этим сервисом, например iMeetVRC:
Что и будет проверенно нами в последующих тестах.
В соответствии с нашими критериями отбора и условиями эксперимента нам с разной степенью успешности, которая будет пояснена ниже, смогли протестировать взаимную совместимость различных сервисов и программных продуктов. На удивлление многие сервисы достаточно беспроблемно были интегрированы к серверам потокового вещания Wowza Streaming Engine и Adobe Media Server с использованием промежуточного ПО Web Call Server 4.
В частности нам удалось удостовериться в том, что существует:
Все тесты были проведены с двумя серверами потокового вещания — Wowza Streaming Engine и Adobe Media Server.
Результаты тестирования сведены нами в таблицу ниже:
При рассмотрении кандидатов на тестирование мы убеждались что часть сервисов, ссылки на которые имеются, не существуют или же не предоставляют он-лайн версии сервисов (и требую устанавливать ПО на сервер), часть сервисов оказались узкофункциональными “мессанджерами” или же не поддерживали SIP протокол.
Нам бы хотелось предположить, что показанный нами результат взаимного тестирования сервисов и программного обеспечения побудит других заинтересованных лиц используя этот список: vsee.com/videoconference провести самостоятельное тестирование других сервисов с тем же или другим набором программного обеспечения и было бы интересно узнать, к каким выводам и результатам удастся прийти по результатам такого нового эксперимента.
При проведении корпоративных обучающих вебинаров, конференций или общественных собраний, митингов используются существующие сервисы и решения с поддержкой протокола 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 в различных сочетаниях.
Навигация
Основные требования к интеграционной платформе
Схема проверочного эксперимента.
Условия для проведения эксперимента.
Интеграция с сервисом 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.
Заключительные выводы.
Использованные ресурсы.
Схема проверочного эксперимента.
Условия для проведения эксперимента.
Интеграция с сервисом zoom.us.
Запуск и конфигурирование Web Call Server 4.
Инициация подключения через Web Call Server 4.
Управление установленным подключением через Web Call Server 4.
Трансляция нескольких подключений из Zoom.us.
Анализ возможных проблем с интеграцией.
Интеграция с сервисом Twilio.
- Настройка учетной записи Twilio и SIP домена.
- Настройка Bria и подключение к домену Twilio.
- Изменение конфигурации Web Call Server для использования с 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 мы использовали в качестве проверочного источника аудио/видео потока через сервер потокового видео. Результирующий поток (после сервера потокового видео) проверялся с помощью Flash Player (показан на скриншоте ниже).
Необходимо крайне внимательно проверить настройки потока (IP адрес, порт, название потока) как у источника, так и у получателя (плеера).
Схема проверки трансляции (работоспособности серверов потокового видео) представленна ниже:
После проверки того факта, что аудио/видео поток достигает RTMP сервер, что мы и видим через плеер, можно перейти непосредственно к тестированию.
Также на момент тестирования Web Call Server’а с сервисом Twilio необходимо установить, какой публичный IP адрес выделен оператором связи для доступа Web Call Server’а в Интернет и прописать этот адрес в настройках SIP домена. Ту же самую операцию необходимо проделать для публичного IP адреса, который используется для тестировани сервиса Twilio с Bria (установленном на локальном компьютере).
Интеграция с сервисом zoom.us
С ростом интереса к дистанционному обучению и терреториально распределенному обмену аудио/видео информацией в режиме реального времени — набирают популярность различные сервисы, предоставляющие необходимый функционал. Одним из таких сервисов является zoom.us.
Схема организации тестирования с использованием этого сервиса описана ниже:
Для начала необходимо произвести настройку учетной записи и выполнить шаги по “иницииации” виртуальной учебной аудитории (см. cкриншот).
После инициации на локальном компьютере будет запущено программное обеспечение, предоставленное сервисом, которое захватит голос с микрофона и видео с камеры компьютера.
Каждой встрече присваивается уникальный девятизначный ID, сообщив который вместе с IP адресом сервиса, по которому ведется трансляция, можно пригласить “на встречу” сторонних участников. Последовательность действий показана на следующих скриншотах.
В конечном итоге, имея IP адрес и ID встречи, предоставляемые сервисом zoom.us мы можем настроить Web Call Server 4 и средство просмотра для того, чтобы поучаствовать “во встрече”.
Запуск и конфигурирование 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 найти файл конфигурации, как это показанно на скриншоте ниже:
В самом файле необходимо изменить параметры codecs и ряд других, как указанно на скриншоте (при этом параметры, которые применимы для других сервисов можно просто “закомментировать”):
После сохранения новых параметров в конфигурационном файле необходимо перезапустить 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, как это указанно ниже на скриншоте:
После выполнения запроса со стороны Web Call Server 4 произойдет подключение WebCallServer к организованной zoom.us встрече (при этом Web Call Server 4 будет выступать как один из “слушателей”), одновременно ответ (контент сервиса zoom.us), полученный Web Call Server 4 – будет перенаправлен Web Call Server 4 далее на сервера потокового видео (что мы и видим на скриншотах ниже):
Управление установленным подключением через Web Call Server
В данном конкретном случае с сервисом zoom.us неодходимо дополнительно подключиться к конкретной “встрече”, передав на сервер zoom.us конкретный идентификатор (предоставленный сервисом) “встречи” (в нашем случае это 311 705 123 ). Одним из способов является тоновый набор DTMF (например на клавиатуре софтфона). Такую же операцию может осуществить Web Call Server 4, как это показанно на скриншоте:
Отправить такой запрос можно также через REST консоль через следующую комманду:
REST консоль
/Прим: синтаксис 1********** является практическим ноу-хау при работе с сервисом zoom.us/
{
«callId»:«Xq2tlLcX89tTjaji», # тот же ID, что и в предыдущем запросе
«type»:«RFC2833»,
«dtmf»:«1**********311705123#» # уникальный ID, предоставленный сервисом zoom.us
}
/Прим: синтаксис 1********** является практическим ноу-хау при работе с сервисом zoom.us/
В результате произойдет подключение конкретного “абонента” к трансляции конкретной “встречи”, как показанно на скриншоте ниже. Как видно на скриншоте, в окне интерфейса zoom.us виден логотип Web Call Server'а, который в данном случае является одним из “слушателей” запущенного “митинга”.
В тоже время в окне 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 так, как это показанно на нижеследующих скриншотах:
И установить необходимо достаточные кодеки для аудио и видео:
Далее при наборе уникального ID комнаты, в которой происходит “митинг” произойдет подключение к общей конференции с трансляцией общего контента через CDN сервер.
Анализ возможных проблем с интеграцией
В качестве источника знаний о возможных причинах сбоев при взаимодействии между Web Call Server 4 и другими программными продуктами и сервисами – рекомендуется обратиться к log файлам на сервере, где установлен Web Call Server 4, как показанно на скриншотах:
Результаты исполнения запросов через REST консоль можно посмотреть также через инструменты, предоставляемые Google Developer Tools, как это показанно на скриншоте:
Интеграция с сервисом Twilio
Для проверки гибкости интеграционной платформы Web Call Server 4 мы протестировали также взаимодействие с сервисом Twilio.
Схема организации эксперимента отображена на схеме:
Настройка учетной записи Twilio и SIP домена
Для начала использования сервисом Twilio необходимо настроить учетную запись на сервисе и создать домент, к которому будут подключаться софтфоны. Последовательность этих действий отображенна на следующих скриншотах:
Этап 1. Создание домена — в нашем случае flashphoner2
Этап 2 — Создание списка доступа и определение прав доступа для домена
Шаг 2.1 — Формирование списка IP адресов, для которых разрешен доступ к домену.
Важно включить в этот список как IP адреса абонентских устройств (софтфонов), так и IP адрес Web Call Server 4.
Шаг 2.2. — Формирование прав доступа
После того, как создан домен в сервисе Twilio, сформированны права доступа и список IP адресов, для которых разрешен доступ — можно приступить к конфигурированию софтфона, в нашем случае — Bria 4.
Настройка Bria и подключение к домену Twilio
В настройках Bria необходимо создать учетную запись (эккаунт) для доступа к Twilio, так, как показанно на скриншотах ниже:
Там же в настройках Bria надо сконфигурировать использование аудиокодеков: G711 aLaw, uLaw а также видеокодека H.264.
После чего можно совершить тестовый звонок через Bria и прослушать через софтфон запись автоответчика, предоставленную Twilio.
Если домен на сервисе скофигурирован правильно (и запись автоответчика слышна в Bria), можно приступать к созданию управляющей команды для Web Call Server’а.
Изменение конфигурации Web Call Server для использования с Twilio
При тестировании сервиса Twilio с участием Web Call Server 4 требуется изменить настройки сервера. Такие изменения вносятся в конфигурационный файл flashphoner.properties.
В частности меняется набор использемых кодеков и ряд других параметров.
Что и как менять в конфигурационном файле — указанно в документации на 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»
}
}
«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.
Схема организации тестовой площадки показана ниже:
В данном случае Bria выступает в роли “сервиса”, принимающего звонки от сторонних абонентов и отвечающего на вызовы контентом. В связи с этой иной ролью, в которой в данном конкретном случае выступает Bria, необходимо изменить настройки так, как показанно ниже на скриншотах. В частности необходимо создать эккаунт для осуществления звонков на IP-PBX 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 или больше количество участников.
Как и в случае с другими сервисами — для начала требуется регистрация на сервисе.
Далее, после регистрации, потребуется проинсталировать программное обеспечение на ваш локальный компьютер и ввести полученые при активации данные для подключения к сервису.
После ввода данных произойдет подключение к сервису и появится возможность создать митинг (комнату для проведения вирутальной встречи). На скриншоте видно что каждому зарегистрировавшемуся и подключившемуся к сервису предоставляется уникальный добавочный номер (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 мы исходили из того, что имя пользователя и пароль могут быть выбраны произвольным образом и критически важным является только IP адрес, по которому будет производиться подключение и (в дальнейшем) номер, который будет набираться чтобы подключиться ко встречи в комнате.
Обратите внимание что в Bria должен быть включен только эккаунт, созданный для сервиса Vidyo чтобы дозвон был произведен именно в этот сервис.
После набора номера 1501005148 на клавиатуре Bria будет осуществлен дозвон и подключение к виртуальной “комнате”, где будет проводиться встреча.
В окне программы можно увидеть что во встрече появился новый участник, как показанно на скриншоте ниже:
Так как наша проверка через Bria увенчалась успехом, приступим к проверке интеграции Web Call Server 4 с сервисом Vidyo.
Для этого создадим в REST консоли команду, как показанно на скриншотах ниже и отправим запрос на Web Call Server 4.
После отправки запроса на web-сайте сервиса Vidyo появится новый участник встречи (с ID, который мы указали в команде Web Call Server’у).
А при этом в плеере, через который мы проверяем наличие трансляции с подключаемого сервиса — видно окно с картинкой, которая была передана инциатором митинга в сервис как замена трансляции с web-камеры.
Ранее был описан механизм запуска серверов потокового видео и при проведении этого теста мы использовали как AMS так и WSE, при этом настройки Web Call Server’а были использованы те, которые мы ранее указывали для сервиса zoom.us
Интеграция с сервисом 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”.
После получения данных для подключения к виртуальной “комнате”, где проводиться встреча, мы, как и ранее, решили проверить функционирование сервиса с софтфоном Bria.
Для этого создали эккаунт в Bria как показанно ниже:
Необходимо отметить, что данные для Domain мы почерпнули из комьюнити пользователей Blue Jeans, так как непосредственно при создании комнаты предлагается использовать IP адрес (как показанно выше) для дозвона или доменное имя bjn.vc.
То что необходимо использовать нотацию sip.bjc.vc для подключения с использованием SIP — расписанно в сообщениях комьюнити, как показанно ниже:
После создания эккаунта в Bria мы набрали на клавиатуре ID митинга и получили подключение с трансляцией картинки (в нашем случае — записанный ранее в ManyCam видеофрагмент) в митинг и трансляции данных митинга в Bria, как показанно ниже:
Далее, проверяя возможности интеграции между 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 отправляет это видео на сервис, а уже Web Call Server 4 инициирует и получает ответ от сервиса Blue Jeans и перенаправляет ответ сервиса на сервер потокового видео (AMS или WSE, в нашем эксперименте), которое мы и видим в окне Flash Player’а.
По общему впечатлению, за исключением “умолчания” о том что для SIP соединения нужно использовать специфичный домен, общее взаимодействие с сервисом Blue Jeans оказалось простым и относительно беспроблемным.
Интеграция с Lifesize
Еще одним из доступных сервисов, интеграция с которым проверялась является сервис Lifesize.
Примерно также как и все с предыдущеми сервисами воспользоваться сервисом можно после регистрации на сайте, скачивания и установки программного обеспечения, предоставленного сервисом и именно это мы и сделали.
После установки программного обеспечения на локальный компьютер, можно сказать “как обычно”, нужно создать встречу (см. скриншот ниже):
Для каждой встречи предоставляется контакты (данные), по которым сторонний участник может осуществить дозвон (обращение) и поучаствовать во встрече, как указанно ниже:
Предоставленные сервисом Lifesize данные мы использовали для дозвона и приятно были поражены тем, что каждый этап подключения к сервису сопровождается визуальным информированием (и голосовым помощником, что впрочем, является общей функцией для всех аналогичных сервисов):
Web Call Server 4, как обычно, с помощью команды через REST консоль, установил по предоставленым данным (см. выше) соединение с сервисом Lifesize.
Сам сервис показывает в своей программе окно подключившегося участника:
И показывает количество участников:
И результаты ответа были транслированны Web Call Server на сервер потокового вещания (AMS или WSE).
По субъективным ощущениям данный сервис более требовательный к качеству канала связи, однако данное наблюдение не является каким-то подтвержденным фактом, и полностью субъективно.
Интеграция с iMeet
Сервис iMeet предоставляет линейку различных решений для организации совместных мероприятий в сети Интернет, в том числе с возможностью подключения участников с использованием телефона.
Интерефейс программы, которую надо скачать и установить, чтобы воспользоваться сервисом, поражает возможностями красочного оформления и сопровождающей информации (время, погода и т.п.).
Также как и раньше — сервис предоставляет данные, но в отличие от предыдущих сервисом в качестве адреса дозвона предоставляется URI типа: www.imeet.com/georgeb
Также как и у предыдущих сервисов — существует возможность приглашения сторонних участников во встречу (в том числе и по электронной почте), а также, что достаточно удобно, дозвона из сервиса на номер телефона потенциального участника (то есть не участнику надо дозваниваться, а вам сервис звонит).
Воспользовавшись ссылкой из приглашения, пришедшего по электронной почте, удалось поучаствовать во встрече с помощью веб браузера (без необходимости установки ПО):
Однако дозвониться в митинг с софтфона 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):
Рискнем предположить что для подключения с использованием SIP протокола необходимо протестировать другое программное обеспечение и несколько иной вид услуг, предоставляемый этим сервисом, например iMeetVRC:
Что и будет проверенно нами в последующих тестах.
Заключительные выводы
В соответствии с нашими критериями отбора и условиями эксперимента нам с разной степенью успешности, которая будет пояснена ниже, смогли протестировать взаимную совместимость различных сервисов и программных продуктов. На удивлление многие сервисы достаточно беспроблемно были интегрированы к серверам потокового вещания 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.
Результаты тестирования сведены нами в таблицу ниже:
При рассмотрении кандидатов на тестирование мы убеждались что часть сервисов, ссылки на которые имеются, не существуют или же не предоставляют он-лайн версии сервисов (и требую устанавливать ПО на сервер), часть сервисов оказались узкофункциональными “мессанджерами” или же не поддерживали SIP протокол.
Нам бы хотелось предположить, что показанный нами результат взаимного тестирования сервисов и программного обеспечения побудит других заинтересованных лиц используя этот список: vsee.com/videoconference провести самостоятельное тестирование других сервисов с тем же или другим набором программного обеспечения и было бы интересно узнать, к каким выводам и результатам удастся прийти по результатам такого нового эксперимента.
Использованные ресурсы
- Анализатор трафика — www.wireshark.org
- Wowza Streaming Engine — www.wowza.com
- Adobe Media Server — www.adobe.com/products/adobe-media-server-family.html
- Web Call Server 4 — flashphoner.com
- www.zoom.us
- www.twilio.com
- www.lifesize.com
- www.bluejeans.com
- www.vidyo.com
- www.pgi.com
- ПО CounterPath — www.counterpath.com/bria
- ПО для обработки виде/аудио контента — manycam.com