Broadcast conferences and webinars using the SIP protocol

The article is devoted to possible options for organizing interaction between software for integration between content delivery networks and content sources using the SIP protocol.

When conducting corporate training webinars, conferences or public meetings, rallies, existing services and solutions that support the SIP protocol are used. However, such services, as a rule, do not have solutions aimed at mass broadcasting (broadcasting) on ​​the Internet. Existing services, such as, InterCall, Twilio, Vidyo, iMeet and so on, as well as other software and hardware solutions and products of other manufacturers, do not provide the functionality of converting a conference organized using the SIP protocol to mass broadcast on the Internet .

General scheme of rally services on the Internet

We set ourselves the goal of deciding which of the solutions we chose (by which we mean the combination of software products and services) will allow us to expand the audience of the event with minimal labor, as shown in the diagram above.

Below, we will consider possible integration options between the two streaming video servers Adobe Media Server and Wowza Streaming Engine, Twilio,, Vidyo, Lifesize, Blue Jeans, iMeet, CounterPath Bria 4 softphone and Flashphoner Web Call Server 4 platforms in various combinations.

How candidates for testing were selected

Having decided to test various services and software products for mutual compatibility and the ability to mass broadcast on the Internet, we selected services and products according to several criteria.

The basic requirements for a server that integrates between other services and software:

  • flexible settings mechanism for various integrated services and software products;
  • availability of detailed documentation;
  • availability of technical support from the manufacturer;
  • ease of administration.

When choosing services, the main criterion was that: a) the service could provide a test period for using the software; b) the service must declare or imply that there is support for connecting participants via SIP. We made a number of exceptions to this rule with the service and with Bria, since we are well acquainted with this softphone and its features and usage features, and the service is a fairly new startup with declared great features, that's why we decided to test it (even though the SIP connection for this service is paid).

Based on the selection criteria formulated, our experience with various integration software and the convenience of using this or that software, we decided to use Web Call Server 4 for our experiments, although other software is also possible.

Test experiment design

One of the most common options for interaction between the source (on the right) and the recipient of the content (on the left) is shown in the diagram below:

A common interaction between source and recipient of content

It should be noted that when checking various options for organizing interactions through the integration platform, we rearranged the indicated scheme depending on the needs of the experiment.

Streaming servers used in the experiment:

  • Wowza streaming engine
  • Adobe Media Server

Integration platform:

  • Flashphoner Web Call Server 4
  • REST console (Google Chrome)

Broadcast Sources:

  • CounterPath Bria 4
  • service
  • service
  • iMeet service
  • Vidyo service
  • Blue Jeans service
  • Lifesize service

Programs for viewing broadcasts (or content):

  • Flash player

Programs for sending RTMP stream to the server:

  • Adobe Flash Media Live Encoder 3.2

Conditions for the experiment

A prerequisite for the experiment is the presence of correctly installed and configured software products described above.

The screenshot below shows the setup of Adobe Flash Media Live Encoder, which was installed on the local client (outside the local network in which the CDN platforms were launched).

Adobe Flash Media Live Encoder window

We used the broadcast from Adobe Flash Media Live Encoder as a verification source for the audio / video stream through the streaming video server. The resulting stream (after the streaming video server) was checked using Flash Player (shown in the screenshot below).

It is imperative to carefully check the stream settings (IP address, port, stream name) both at the source and at the receiver (player).

The translation verification scheme (health of streaming video servers) is presented below:

Scheme for checking broadcasts through Adobe Flash Live Encoder

The resulting broadcast in the Flash Player window

After checking the fact that the audio / video stream reaches the RTMP server, which we see through the player, you can go directly to testing.

Also, at the time of testing Web Call Server with the Twilio service, it is necessary to establish what public IP address is assigned by the service provider for Web Call Server access to the Internet and register this address in the SIP domain settings. The same operation must be done for the public IP address, which is used to test the Twilio service with Bria (installed on the local computer).

Integration with service

With the growing interest in distance learning and the spatially distributed exchange of audio / video information in real time, various services providing the necessary functionality are gaining popularity. One such service is

The organization of testing using this service is described below:

Testing scheme using service

First you need to set up your account and follow the steps to “initiate” the virtual classroom (see screenshot).

Initiation of a virtual classroom in service

After initiation, the software provided by the service will be launched on the local computer, which will capture voice from the microphone and video from the computer’s camera.

Each meeting is assigned a unique nine-digit ID, informing which, together with the IP address of the service that is being broadcast, you can invite third-party participants to the meeting. The sequence of actions is shown in the following screenshots.

Ultimately, with the IP address and meeting ID provided by, we can configure Web Call Server 4 and the viewer to participate in the “meeting.”

Broadcast from service

Data for dialing in service

Starting and Configuring Web Call Server 4

Despite the fact that Web Call Server 4 is an integration tool between different content sources and streaming servers, each conference (or other source) can have individual settings, features and undocumented requirements for implementing standard SIP, RTMP protocols.

In our particular case, both streaming servers are installed on the same device, so the first step is to make sure that only one of the servers (AMS or WSE) is working simultaneously - otherwise (when there is a separate device for each software) the next operation is not necessary.

We needed to force stop one of them streaming servers, as shown below:

[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 ...

In this particular example, AMS is stopped (we know in advance that it worked on port 1936), and the Wowza Streaming Engine works on port 1935 at address

Next, you need to make sure that the configuration of the Web Call Server 4 server matches the parameters of the content source used (in our example,, for this, for example, through ssh, you can access the server on which Web Call Server 4 is deployed and find the file in the ./conf directory configuration, as shown in the screenshot below:

Web Call Server 4 configuration file folder

In the file itself, you need to change the codecs parameters and a number of others, as indicated in the screenshot (in this case, the parameters that are applicable to other services can simply be “commented out”):

Web Call Server 4 configuration file listing

After saving the new settings in the configuration file, restart Web Call Server 4 (as shown below):

[root @ SF1 conf] # service webcallserver stop

FlashphonerWebCallServer: stopping [OK]

[root @ SF1 conf] # service webcallserver start

FlashphonerWebCallServer: starting [OK]

As a result of all the above actions, we are guaranteed to have correctly functioning streaming video server and Web Call Server 4, and you can proceed to direct control of Web Call Server 4 and the broadcast source.

Connections via Web Call Server 4

Having installed and configured, correctly working Web Call Server 4, we must bear in mind that in general, this software product acts as an intermediary between the content source and the streaming server. In the general case, mediation consists in initiating a SIP call to a content source, receiving a response from the content source, receiving the content itself and broadcasting this received content to the streaming server.

The Web Call Server itself requires management tools, the implementation of which is organized through the REST / JSON API commands. Such a management mechanism can be integrated into any existing software product and provide automatic management of Web Call Server.

For our specific case, we use a REST console through which requests with parameters are sent to the Web Call Server, which in turn depend on which content source needs to be integrated with the CDN.

For example, to join a meeting organized on, you need to send the following request (which we will do through the Google Chrome REST console):

REST console
   "CallId": "Xq2tlLcX89tTjaji", # arbitrary unique call identifier
   "callee": "10000", # name of the caller (randomly selected)
   "rtmpUrl": "rtmp: // 1935 / live", # broadcast address (Platform CDN)
   “rtmpStream”: “lifestream1”, # name of the streamed stream
   “hasAudio”: “true”, # attribute of audio content (yes / no)
   “hasVideo”: “true”, # attribute of video content (yes / no)
   “Connection”: # connection parameters
      “sipLogin”: “10000”, # login
      “sipPassword”: “10000000”, # password
      “sipAuthenticationName”: “10000”, # name for authentication
      “sipDomain”: “”, # IP address of the meeting (provided by
      “SipPort”: “5060”, # Port on which SIP broadcasting is
      “sipRegisterRequired”: “false”, # registration attribute in the
      “appKey” domain : “callApp”

A request with the above parameters is sent to a special Web Call Server URI, as indicated below in the screenshot:

Screenshot of the REST console with the address for the request

After the request from Web Call Server 4 is completed, WebCallServer will be connected to the meeting organized by (in this case, Web Call Server 4 will act as one of the “listeners”), at the same time the response (content of the service) received by Web Call Server 4 - Web Call Server 4 will be redirected further to the streaming video server (as we see in the screenshots below):

Translation of the result after sending a request to

Manage an established connection through a Web Call Server

In this particular case, with the service, it is necessary to additionally connect to a specific “meeting” by sending to the server a specific identifier (provided by the service) of the “meeting” (in our case it is 311 705 123). One way is DTMF tone dialing (for example, on a softphone keyboard). Web Call Server 4 can perform the same operation, as shown in the screenshot:

Screenshot of REST console for DTMF request

You can also send such a request via the REST console through the following command:

REST console
"CallId": "Xq2tlLcX89tTjaji", # the same ID as in the previous request
"type": "RFC2833",
"dtmf": "1 ********** 311705123 #" # unique ID, provided by service

/ Note: syntax 1 ********** is practical know-how when working with

As a result, a specific “subscriber” will be connected to the broadcast of a specific “meeting”, as shown in the screenshot below. As you can see in the screenshot, in the window of the interface the Web Call Server logo is visible, which in this case is one of the “listeners” of the launched “rally”.

The result of connecting to the service from Web Call Server 4

Transition from to Adobe Media Server or Wowza Streaming Engine

At the same time, in the Wowza Flash Player window we see a broadcast that was redirected from to the Wowza Streaming Engine server via Web Call Server 4 (see screenshot).

Thus, by means of two commands transmitted through the REST console to Web Call Server 4, we managed to initiate participation in the meeting (“rally”) on and redirect the content (“picture” and audio stream) to the Wowza Streaming Engine server for subsequent broadcasting through CDN network.

Broadcast multiple connections from

Web Call Server 4 can provide translation of any number of connections from the service, which we tested in practice.
To do this, you need to configure your Bria account as shown in the screenshots below:

List of accounts in the Bria softphone

Account setup for

And you need to install sufficient codecs for audio and video:

Used audio codecs for service in Bria

Used video codecs for service in Bria

Further, when dialing a unique ID of the room in which the rally takes place, a connection will be made to the general conference with the broadcast of the common content via the CDN server.

Dialing a meeting number provided by

Analysis of possible integration issues

As a source of knowledge about the possible causes of failures in the interaction between Web Call Server 4 and other software products and services, it is recommended to refer to the log files on the server where Web Call Server 4 is installed, as shown in the screenshots:

Log file Web Call Server'a

Manager log файл

The results of query execution through the REST console can also be viewed through the tools provided by Google Developer Tools, as shown in the screenshot:

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

Integration with Twilio Service

To test the flexibility of the Web Call Server 4 integration platform, we also tested the interaction with the Twilio service.
The organization of the experiment is shown in the diagram:

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

Setting up a Twilio account and SIP domain

To start using the Twilio service, you need to set up an account on the service and create a domain to which softphones will connect. The sequence of these actions is shown in the following screenshots:

Stage 1. Creating a domain - in our case, flashphoner2

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

Stage 2 - Creating an Access List and Defining Access Rights for a Domain

Страница сервиса Twilio с настройками домена

Step 2.1 - Creating a list of IP addresses for which domain access is allowed.

It is important to include in this list both the IP addresses of subscriber devices (softphones) and the IP address of Web Call Server 4.

Страница со списком IP адресов и пользователями

Список IP адресов

Step 2.2 - Creation of access rights

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

After the domain is created in the Twilio service, the access rights and the list of IP addresses for which access is allowed are generated - you can start configuring the softphone, in our case, Bria 4.

Configuring Bria and joining a Twilio domain

In Bria settings you need to create an account (account) to access Twilio, as shown in the screenshots below:

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

Аккаунт Twilio в Bria

In the same place in Bria settings it is necessary to configure the use of audio codecs: G711 aLaw, uLaw as well as the H.264 video codec.

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

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

After that, you can make a test call through Bria and listen through the softphone to an answering machine record provided by Twilio.
If the domain on the service is configured correctly (and the answering machine is audible in Bria), you can start creating a control command for Web Call Server.

Change Web Call Server configuration for use with Twilio

When testing the Twilio service with Web Call Server 4, you need to change the server settings. Such changes are made to the configuration file.

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

In particular, the set of used codecs and a number of other parameters are changing.

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

What and how to change in the configuration file is indicated in the documentation for Web Call Server 4 provided by the manufacturer of the integration server.

After changing the configuration of Web Call Server, it is necessary to reboot the server so that the changes take effect:

[root @ SF1 conf] # service webcallserver stop

FlashphonerWebCallServer: stopping [OK]

[root @ SF1 conf] # service webcallserver start

FlashphonerWebCallServer: starting [OK]

Web Call Server Management

As in the previous experiment, Web Call Server is controlled by sending a REST command through the Google Chrome REST console, as shown below:

REST console

The request is sent to the Web Call Server address: http: //

As a result of executing the request, a call is generated to the Twilio SIP domain of the service and in Flash Player you can listen to the response received from the Twilio service - or rather, you can hear the message from the Twilio answering machine playing.

Thus, as a result of testing the operation of Web Call Server 4 as an integration solution between Twilio and Bria, we were convinced that the integration server is able to interact with the Twilio service and the softphones connected to this service.

Integration with OpenSIPS

To test the possibility of interaction with IP-PBX solutions, a test was conducted with the IP-PBX OpenSIPS server.

The layout of the test site is shown below:

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

In this case, Bria acts as a “service” that receives calls from third-party subscribers and answers calls with content. In connection with this other role, in which Bria acts in this particular case, it is necessary to change the settings as shown in the screenshots below. In particular, you need to create an account to make calls to IP-PBX OpenSIPS:

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

As in previous cases, to demonstrate the ability to control Web Call Server, we send a request:

REST console

It should be noted that the call is made through the account 10051 created on the OpenSIPS server, and the “number” of the called subscriber is indicated in the “callee” field.

As a result, a call made to Web subscriber 4 to the “subscriber” 10050 was redirected to the streaming server and subsequently listened via Flash Player.

Integration with Vidyo

Another service we tested with is The need for mass broadcasting is related to the fact that this service has a limited number of participants in each broadcast (rally) and, accordingly, there may be a need to use the usual service (Vidyo) to hold an event with 50, 100 or more number of participants.

As is the case with other services, registration on the service is required first.

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

Страница регистрации на сервисе Vidyo

Further, after registration, you will need to install the software on your local computer and enter the data obtained upon activation to connect to the service.

Страница с настроенным аккаунтом Vidyo

Внешний вид интерфейса ПО Vidyo на локальном компьютере

Настройки конкретного аккаунта с номером комнаты

After entering the data, a connection will be made to the service and it will be possible to create a meeting (room for a virtual meeting). The screenshot shows that each registered and connected to the service is provided with a unique extension number (Extension).

To connect other participants to the meeting (to the room), you will need to send an invitation to other participants, for example by e-mail.

After clicking on the corresponding icon in the program window, a draft message will be created in the program for processing e-mail, where connection data will be visible, which must be reported to other potential participants in the meeting.
The text of such a letter is shown below:

Let's meet via Vidyo!

— To join from your desktop or mobile device: Click

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

— To join from your H.323/SIP video conferencing system outside the US: 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

To check the operability of the data received from the Vidyo service, we created an account in the Bria softphone based on the data provided by the service:

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

When creating an account in Bria, we proceeded from the fact that the username and password can be chosen arbitrarily and only the IP address that will be connected to and (in the future) the number that will be dialed to connect to the meeting in the room is critical.

Please note that only the account created for the Vidyo service should be included in Bria so that the dialer will be made in this service.

After dialing the number 1501005148, the Bria keyboard will dial and connect to the virtual “room” where the meeting will be held.

In the program window, you can see that a new participant has appeared in the meeting, as shown in the screenshot below:

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

Since our test through Bria was successful, we will begin to test the integration of Web Call Server 4 with the Vidyo service.

To do this, create a command in the REST console, as shown in the screenshots below, and send a request to Web Call Server 4.

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

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

After sending the request, a new meeting participant will appear on the Vidyo service website (with the ID that we specified in the Web Call Server command).

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

And at the same time, in the player through which we check the availability of broadcasts from the connected service, you can see a window with a picture that was transmitted by the rally initiator to the service as a replacement for broadcasting from a web camera.

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

The mechanism for starting streaming video servers was described earlier and during this test we used both AMS and WSE, while the settings for Web Call Server were used as we specified for

Blue Jeans Integration

One of the relatively well-known services for organizing conferences on the Internet is the Blue Jeans service, the integration with which we also decided to check.

This service also offers a fairly simple mechanism for organizing a meeting (rally), for a start you need to register and create your account, as shown below:

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

After this step, as in previous cases with similar services, you must install the software provided by the Blue Jeans service.

Этапность регистрации на сервисе Blue Jeans

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

After installing the Blue Jeans software on your computer, further steps are performed through this software.

Naturally, in order to connect someone to the meeting, you need to organize this meeting, and for this in Blue Jeans software you need to create such a meeting and after creating it - send the meeting data to potential participants, in this case:

  • IP address (dial IP)
  • Meeting ID
  • Verification Code (passcode)

If the second participant whom you want to invite uses the same Blue Jeans software, the Blue Jeans service offers to enter the code in a special window (“pairing code”) and you can “parallelize” your and his software. However, such a function was not used for the purposes of our testing, we used the meeting ID and passcode provided by the service.

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

After receiving the data for connecting to the virtual “room” where the meeting is held, we, as before, decided to check the operation of the service with the Bria softphone.

To do this, create an account in Bria as shown below:

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

It should be noted that we collected data for Domain from the Blue Jeans community, as it is proposed to use the IP address (as shown above) for dialing or the domain name directly when creating the room.

The fact that you need to use the notation to connect using SIP is described in the messages of the community, as shown below:

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

After creating an account in Bria, we typed the rally ID on the keyboard and got connected with broadcasting the picture (in our case, a video clip recorded earlier in ManyCam) into the rally and broadcasting the rally data in Bria, as shown below:

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

Further, checking the integration capabilities between Blue Jeans and Web Call Server 4, we sent the following request to the address of Web Call Server 4 using the REST console: http: //

REST console

It should be noted that in the request, the rally ID is used as the callee field, and the data taken from the community is used as sipDomain, that is,

After connecting to the Blue Jeans software window, you can see that several participants appeared in the rally (one of them is Bria , second Web Call Server 4), as shown below:

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

In the player, we can accordingly observe the “picture” from the local computer (as shown below), that is, we see what the “Blue Jeans” software “sees” on the local computer. Next, Blue Jeans software sends this video to the service, and Web Call Server 4 initiates and receives a response from the Blue Jeans service and redirects the service response to the streaming video server (AMS or WSE, in our experiment), which we see in the Flash Player window 'a.

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

By the general impression, with the exception of the “default” that a specific domain must be used for SIP connection, the general interaction with the Blue Jeans service turned out to be simple and relatively hassle-free.

Lifesize Integration

Another available service, the integration with which was tested, is the Lifesize service.

Just like everyone with the previous services, you can use the service after registering on the site, downloading and installing the software provided by the service, and this is exactly what we did.

After installing the software on the local computer, you can say “as usual”, you need to create a meeting (see the screenshot below):

Встречи созданные в сервисе Lifesize

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

For each meeting, contacts (data) are provided, by which a third-party participant can make a call (appeal) and participate in the meeting, as follows:

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

Доп данные для подключения в сервис Lifesize

Телефоны дозвона в сервис Lifesize

We used the data provided by the Lifesize service for dialing and were pleasantly amazed that each stage of connecting to the service is accompanied by visual information (and a voice assistant, which, incidentally, is a common function for all similar services):

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

Web Call Server 4, as usual, using a command through the REST console, established the connection with the Lifesize service according to the provided data (see above).

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

The service itself shows in its program the window of the connected participant:

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

And shows the number of participants:

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

And the response results were broadcast by Web Call Server to the streaming server (AMS or WSE).

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

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

According to subjective feelings, this service is more demanding on the quality of the communication channel, however, this observation is not some kind of confirmed fact, and is completely subjective.

Integration with iMeet

IMeet service provides a line of various solutions for organizing joint events on the Internet, including with the ability to connect participants using the phone.

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

The interface of the program, which must be downloaded and installed in order to use the service, is striking in its colorful design and accompanying information (time, weather, etc.).

As before - the service provides data, but unlike the previous ones, the URI of the type is provided as a dial-up address:

Внешний вид локального ПО iMeet

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

As with the previous services, there is the possibility of inviting third-party participants to the meeting (including by e-mail), and also, quite conveniently, dialing from the service to the phone number of the potential participant (that is, not the participant needs to call, but you need the service calling).

Using the link from the email invitation, I was able to participate in the meeting using a web browser (without the need to install software):

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

Участники встречи  в iMeet

However, it was not possible to get through to the rally from the Bria softphone, which, from our point of view, is explained by the service in the following comment:

"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 (eg ) 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! ”( )

Using the recommendations received and the following Bria settings, there was still no connection with the rally (the Domain parameter was changed to both and ):

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

We dare to assume that to connect using the SIP protocol it is necessary to test other software and a slightly different type of service provided by this service, for example iMeetVRC:

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

Which will be verified by us in subsequent tests.

Final conclusions

In accordance with our selection criteria and experimental conditions, we were able to test the mutual compatibility of various services and software products with varying degrees of success, which will be explained below. Surprisingly, many services were seamlessly integrated with the Wowza Streaming Engine and Adobe Media Server using the middleware Web Call Server 4.

In particular, we were able to verify that there are:

  • the ability to initiate a call to the service and call control;
  • возможность трансляции потокового контента в том числе с несколькими подключениями с сервиса;
  • возможности Web Call Server’а дозваниваться до сервиса Twilio и абонентов, подключенных к этому сервису;
  • способность управлять вызовами у подключенных через IP-PBX OpenSIPS абонентов интеграция с сервисом Vidyo оказалась более простой, чем с сервисом, так как инициация и управление соединением в Web Call Server ограничилось одной командой;
  • сервис Lifesize субъективно потребовал большей пропускной способности для качественного отображения видео в окне сервиса, в то время как сервис Blue Jeans в использовании оказался простым и позволил практически в несколько элементарных шагов осуществить одновременное подключение к митингу Bria и Web Call Server 4 ;

All tests were conducted with two streaming servers - Wowza Streaming Engine and Adobe Media Server.

Testing results are summarized by us in the table below:

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

When examining the candidates for testing, we were convinced that some of the services, links to which are available, do not exist or do not provide an online version of the services (and require installing software on the server), some of the services turned out to be highly functional “messengers” or did not support the SIP protocol.

We would like to assume that the result of mutual testing of services and software that we showed will encourage other interested parties using this list: to conduct independent testing of other services with the same or a different set of software and it would be interesting to know what conclusions and the results will come from the results of such a new experiment.

Resources used

  1. Traffic Analyzer -
  2. Wowza Streaming Engine -
  3. Adobe Media Server -
  4. Web Call Server 4 -
  11. CounterPath Software -
  12. Video / audio content processing software -

Also popular now: