openj-gate.com

lechoixdeslibraires.com

open4u.co.uk

argosnear.me

sarf3omlat.com

opencities.ca

australia-opening-times.com

Организация трансляции SIP звонка на RTMP сервер

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

Simple SIP/RTMP interaction scheme

Ниже будут рассмотрены шаги для тестирования возможности указанной выше интеграции и трансляции аудио/видео трафика, а также дополнительно будут предоставлены данные о тестировании Web Call Server’а с реально существующими сервисами видеокоференций. 

 

 

Содержание 

  1. Общий план эксперимента
  2. Создание и конфигурирование REST клиента
  3. Конфигурирование Web Call Server
  4. Анализ возможных проблем интеграции
  5. Проверка работоспособности RTMP сервера
  6. Интеграция Web Call Server c IP PBX
  7. Использованные ресурсы

 

Общий план эксперимента

Мы задались целью поставить эксперимент по проверке возможностей Web Call Server’а осуществить взаимодействие с источником трафика и перенаправить этот трафик на RTMP сервер. При этом взаимодействие с источником трафика будет осуществляться с использованием протокола SIP.

Эксперимент можно разбить на следующие шаги:

  1. Тестирование инструмента управления Web Call Server’ом 
  2. Конфигурирование Web Call Server’а в соответствии с параметрами эксперимента
  3. Оценка возможностей анализа проблем в процессе интеграции Web Call Server’а с другим программным обеспечением
  4. Проверка работоспособности имеющегося RTMP сервера
  5. Непосредственно интеграция Web Call Server’а с IP PBX 
  6. Оценка полученных результатов 

 

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

sequence_diagram

 

Создание и конфигурирование REST клиента

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

Следующая функция агрегирует в себе необходимые для отправки управляющего REST запроса на Web Call Server

 

function sendREST(url, data) {
console.info("url: " + url);
console.info("data: " + data);
$.ajax({
url: url,
type: 'POST',
contentType: 'application/json',
data: data,
success: function () {
alert('REST request has been sent. Please check Developer Tools > Console output.');
console.info("REST successfully done");
}
});
}

Функция возвращает значение «REST successfully done» в случае успешного выполнения.

 

Еще одна функция содействует установлению соединения между Web Call Server’ом и источником аудио/видео трафика:

//Star a new call based on call details and connection details in the RESTCallForm and ConnectionDetailsForm
function startCall() {
var url = document.getElementById("resturl").value + "/call";
var connectionDetailsFormObject = $('#ConnectionDetailsForm').serializeObject();
var RESTCallFormObject = $('#RESTCallForm').serializeObject();
RESTCallFormObject.connection = connectionDetailsFormObject;
var data = JSON.stringify(RESTCallFormObject);
sendREST(url, data);
}

Обратите внимание что в качестве URL не следует использовать без ./call  части.

Полностью  файл с оригинальным кодом для управления Web Call Server через отправку REST запросов можно скачать тут

Для целей проверки работоспособности указанного выше кода были проведены тестирования кода «в ручном режиме» (с использованием REST консоли Google Chrome), через которую в Web Call Server отправляются запросы с параметрами, которые в свою очередь зависят от того, какой именноисточник контента необходимо интегрировать с CDN. Иногда для присоединения ко встрече необходимо отправить следующий запрос (что мы и сделаем через REST консоль Google Chrome):

 

{  
"callId":"Xq2tlLcX89tTjaji",
# arbitrary unique call id
"callee":"10000",
# callee name (random example)
"rtmpUrl":"rtmp://45.101.139.105:1935/live",
# broadcast address (CDN platform)
"rtmpStream":"lifestream1",
# stream name
"hasAudio":"true",
# audio content attribute (has audio, yes/no)
"hasVideo":"true",
# video content attribute (has video, yes/no)
"connection":
# connection parameters
{
 
"sipLogin":"10000",
# login
"sipPassword":"10000000",
# password
"sipAuthenticationName":"10000",
#  authentication name
"sipDomain":"162.255.36.11",
# IP address of the meeting (provided by
"sipPort":"5060",
# SIP server port number
"sipRegisterRequired":"false",
# domain registration attribute
"appKey":"callApp"
 
}
 
}  

 

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

REST console Chrome with query to the Web Call Server

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

DTMF answer from zoom.us

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

REST query DTMF to the zoom.us

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

{

"callId":"Xq2tlLcX89tTjaji",                   # same with previous request ID
"type":"RFC2833",
"dtmf":"1311705123#"                           # here 311705123 is unique ID, provided by  certain service

}

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

Web Call Server call to RTMP server

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

Конфигурирование Web Call Server

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

В рамках проведения эксперимента   оба сервера потокового вещания (и Adobe Media Server и Wowza Streaming Engine) были установлены на одном устройстве, поэтому первым шагом необходимо убедиться что одномоментно работает только один из серверов (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…

Web Call Server config folder

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

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

config file Web Call Server

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

После сохранения новых параметров в конфигурационном файле необходимо перезапустить 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 и источником трансляции.

 

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

Log file Web Call Server

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

manager log file

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

 

Проверка работоспособности RTMP сервера

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

Источником проверочного аудио/видео трафика был выбран Adobe Flash Media Live Encoder.

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

 

Adobe Encoder test scheme

 

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

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

Adobe Flash Media Encoder

 

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

 

Flash player screenshot from Adobe Encoder

 

Интеграция Web Call Server с IP PBX 

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

 

2-twilio_zoom_us_IP-PBX_WebCallServer_AMS_WSE 

Были проведены  теста по интеграции Web Call Server’а, серверов потокового вещания AMS и WSE и IP PBX были создан виртуальный стенд из следующих компонентов:

Сервера потокового видео:

  • Wowza Streaming Engine 
  • Adobe Media Server

 

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

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

 

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

  • CounterPath Bria 4
  • IP PBX OpenSIPS

 

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

  • Flash Player 

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

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

 

OpenSIPS and Web Call Server interaction scheme

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

Bria Account for 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 вызов на “абонента” 10050 был перенаправлен на сервер потокового вещания и в последующем прослушан через Flash Player.

Результаты тестирования с широко распространенными сервисами видеоконференций (online meeting services) и виртуальными IP PBX сервисами.

Результаты тестирования сервисов видеоконференций приведены на следующей странице, доступной по этой ссылке. 

 

Загрузить Web Call Server 5

Системные требования: Linux x86_64, 1 core CPU, 2 Gb RAM, Java

    Загрузить WCS5   

Установка:

  1. wget https://flashphoner.com/download-wcs5.2-server.tar.gz
  2. Распаковать и установить с помощью скрипта 'install.sh'
  3. Запустить сервер с помощью команды 'service webcallserver start'
  4. Открыть веб-интерфейс https://host:8444 и активировать вашу лицензию

 

Если вы используете серверы Amazon EC2, то скачивать ничего не нужно.

WCS5 на Amazon EC2

 

Ежемесячная подписка Web Call Server 5

$145 в месяц

 

    Купить