Click here to Skip to main content
14,420,861 members

Useful code and examples of managing integration server between RTMP streaming software and content sources like IP PBX or online meeting services

Rate this:
5.00 (3 votes)
Please Sign up or sign in to vote.
5.00 (3 votes)
16 Feb 2016CPOL
We have established a goal to decide, what solution (as in a combination of software and services) among those we chose allows extending the audience of an event with minimum efforts.

Introduction

Conducting of corporate educational webinars, conferences or meetings uses existing SIP-based services and solutions. However, such services usually lack wide Internet broadcasting capabilities. Existing services, such as Zoom.us, InterCall, Twilio, Vidyo, iMeet and so on, as well as various hardware and software solutions and products by other vendors do not offer ways to convert a SIP conference to wide broadcasting via Internet.

Below we review possible ways to integrate two stream video servers, namely Adobe Media Server and Wowza Streaming Engine, Twilio, Zoom.us, Vidyo, Lifesize, Blue Jeans, iMeet services, CounterPath Bria 4 softphone and Flashphoner Web Call Server 4 platform in different combinations.

Internet meeting general diagram

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Our original code samples could show simple way which can help you manage out one of the known integration software - Web Call Server. It is important key moment of having useful code with proven functionality in case that you need to embed this code into your application. 

Below we review possible ways to integrate two stream video servers, namely Adobe Media Server and Wowza Streaming Engine, Twilio, Zoom.us, Vidyo, Lifesize, Blue Jeans, iMeet services, CounterPath Bria 4 softphone and Flashphoner Web Call Server 4 platform in different combinations.

Using the code

At the end of this article you will be able to download whole html file with useful code, but before that a few key explanations about what really our code can do. 

Two functions below could collect all necessary data for the further REST query, which is in particular, URL (of the Web Call Server), data (command parameters for the 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");

                }

            });

        }

Function above will return "REST successfully done" in case of success. 

Next key function help you establishing call between Web Call Server and any content source (like online meeting service, softphone etc) with mandatory parameters (usually provided by the content sources)

//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);

        }

Pay attention that URL should not have  ./call   part at the end, because this part of URL will be added automatically by the function.

So, for the purpose of the further simple and clear explanations in this article we will show  how to use above code in a few examples with different services and cases in 'manual' mode, but you can embed this code into your applications and use it in an automatic mode.

Test conditions

When we decided to test various services and software for mutual compatibility and wide Internet broadcasting capabilities, we picked several services and products based on certain criteria.

Basic requirements to the software-service integration server are:

  • flexible configuration to match various integrated services and software;
  • thorough documentation;
  • technical support from the manufacturer;
  • ease of administration.

The main selection criterion when picking services was: а) the service provides a software evaluation period; б) the service declares or implies connection of participants via the SIP protocol. We have made exclusions for the Zoom.us service and Bria. We know the softphone and its capabilities and features very well, while Zoom.us is a new startup service with a lot of declared functions, so we decided to test it anyway (even though SIP connection is paid in this service). Based on the above stated criteria of selection, our experience with various integration software and easy of use of the given software, we decided to use Web Call Server 4 to conduct our study. However, usage of other software is possible too.

Layout of the experiment

One of the most common ways of interaction between the source (on the right) and the recipient of the content (on the left) is displayed on the diagram below:

A common way of interaction between removed source and recipient

Note, that while testing various ways of interaction using the integration platform we modified the above diagram depending on requirements of the experiment.

Stream video 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
  • Twilio.com service
  • Zoom.us service
  • iMeet service
  • Vidyo service
  • Blue Jeans service
  • Lifesize service

Software to view broadcast (or content):

  • Flash Player

Software to send RTMP stream to the server:

  • Adobe Flash Media Live Encoder 3.2

The requirement to the experiment is correctly installed and configured software products described above. The screenshot below shows configuring Adobe Flash Media Live Encoder installed to a local client (outside of the local network where the CDN platforms run).

Adobe Flash Media Live Encoder window

We used Adobe Flash Media Live Encoder broadcast as a reference source of audio/video stream through the streaming video server.

The resulting stream (past the streaming video server) was checked with Flash Player (shown on the screenshot below).

It is crucial to carefully configure stream settings (IP address, port, stream name) both of the source and of the recipient (player).

Broadcast testing diagram (or the streaming server operation diagram) is shown below:

Adobe Flash Live Encoder broadcast testing diagram

Resulting broadcasting in Flash Player

After we check the fact that the audio/video stream reaches the RTMP server (that's basically what we see in the player), we can start the test. Before testing the Web Call Server tandem with the Twilio service, we should find out the public IP address allocated by the service provider for Web Call Server to access the Internet.

This address should be specified in the SIP domain settings. The same operation must be done for the public IP address we use to test Twilio with Bria installed on the local computer.

 

Integration cases

Integration with zoom.us

The growth of interest to remote education and geo-distributed audio/video information real-time exchange gives birth to various services providing the required functions. One of such services is zoom.us. The testing diagram for this service is as follows:

Testing diagram for zoom.us

 

 

 

 

 

 

 

 

 

 

 

 

 

 

At first, you should configure the account and go through steps of virtual class "initialization" (see the screenshot).

Virtual class initialization in zoom.us

 

After initialization, the software provided by the service is launched. It captures voice from the microphone and video from the camera. A unique 9-digit ID is assigned to each meeting. By telling this ID along with the IP address of the broadcasting service, you can invite other participants to the meeting. The steps are shown on the screenshots below.

As a result, if we have the IP address and the ID of the meeting provided by zoom.us, we can configure Web Call Server 4 and a viewer to participate in the meeting.

Zoom.us broadcasting

Dial data for zoom.us

Running and configuring Web Call Server

Inspite of Web Call Server 4 is an integration tool to couple various content sources with streaming servers, each conference (or other source) can have individual settings, specifics and undocumented requirements to implementation of standard SIP and RTMP protocols.

In our reference case both streaming servers are installed on the same device, so first we need to make sure only one of them is working at a time (AMS or WSE). Otherwise, (if each server runs on its own device) the next step is not necessary.

We had to force one of the streaming servers to stop, 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 case, AMS is stopped (we know it worked on the port 1936), and Wowza Streaming Engine works on the port 1935 and IP 45.101.139.105.

Then, we need to make sure Web Call Server 4 server configuration matches parameters of the content source we use (in this case - zoom.us). To do this, we can ask the server where Web Call Serverv 4 is deployed via ssh and in the ./conf folder locate a configuration file, as it is shown below:

Folder with the Web Call Server 4 configuration file

In the file, we need to adjust codecs parameters and some others as shown on the picture. Comment out parameters that should apply to other services:

Web Call Server 4 configuration file

As soon as all new parameters are saved in the configuration file, restart Web Call Server 4 (shown below):

[root@SF1 conf]# service webcallserver stop

FlashphonerWebCallServer: stopping [OK]

[root@SF1 conf]# service webcallserver start

FlashphonerWebCallServer: starting [OK]

As a result, we have correctly functioning streaming video server and Web Call Server 4, so we can start managing Web Call Server 4 and the broadcast source.

Initializing connection via Web Call Server 4

Now, as we have installed, configured and correctly working Web Call Server 4, we should take into account this software is an agent between the source of the content and the streaming server. Generally, the mediation is about initiating a call to the source of content via SIP, receiving the answer from the source of content, receiving the content and broadcasting the content to the streaming server.

Web Call Server itself requires certain controls. This is implemented with REST/JSON API commands. Such a mechanism can be easily embedded to any existing product and provide automatic control over Web Call Server.

In our case, we use the REST console to send parametrized requests to Web Call Server. Requests, in turn, may vary depending on which specific source of content has to be integrated to CDN. For example, to connect to a meeting started form the zoom.us service, the following request should be sent (that's what we do in the REST console of 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 zoom.us)
              "sipPort":"5060",                        # SIP broadcasting port
              "sipRegisterRequired":"false",           # domain registration attribute
              "appKey":"callApp"
              }
}

A request with the given parameters is sent to a special URI Web Call Server, as shown on the picture:

 REST console with the address for requests

After the request is processed, Web Call Server 4 connects to the meeting started by zoom.us as one of listeners. Simultaneously, the response of the zoom.us content service is received by Web Call Server 4 and is redirected by it to streaing video servers. This is illustrated below:

Broadcasting results after sending a request to zoom.us

Managing the connection with Web Call Server 4

In case of zoom.us, you need to additionally connect to the given meeting by sending to zoom.us a specific identifier of the meeting (provided by the service). In our case the id is 311 705 123. Among ways to accomplish this is DTMF dialing (for instance, using softphone keyboard). Web Call Server 4 can also do this as shown on the screenshot:

REST console for a DTMF request

You can also send this request with the following command in the REST console:

{

"callId":"Xq2tlLcX89tTjaji",       # the same ID as in the previous request

"type":"RFC2833",

"dtmf":"1**********311705123#"     # the unique ID provided by the zoom.us service

}

                                   Note: 1********** syntax is a know-how technique specific to zoom.us

As a result, the given callee connects to the broadcasting of the given meeting as shown below. As you see, the zoom.us interface shows Web Call Server logo, which is one of listeners of the running meeting.

Results of connecting Web Call Server 4 to zoom.us

Broadcasting from zoom.us to Adobe Media Server or Wowza Streaming Engine

At the same time, in the Wowza Flash Player window we can see the broadcasting redirected through Web Call Server 4 from zoom.us to the Wowza Streaming Engine server. (see the screenshot).

Therefore, using only two commands send via the REST console on Web Call Server 4 we were able to initiate participation in a meeting on the zoom.us service and redirect content (both the picture and sound) to the Wowza Streaming Engine server for further broadcasting via the CDN network.

Broadcasting several Zoom.us connections

Web Call Server 4 can deliver broadcasting of any number of connections from the zoom.us service as our example illustrates. To do this, you need to configure Bria account as shown on the following screenshots:

Bria softphone account list

Setting up an account for Zoom.us

And we need to install required codecs for audio and video:

Used audio codecs for the Zoom.us service in Bria

 Used video codecs for the Zoom.us service in Bria

Then, after you enter the unique ID of a meeting room, connection is established to the conference and the content is broadcast via the CDN server.

Dialing the meeting number provided by zoom.us

 

Analyzing possible integration problems

To find out possible reasons of errors an failures during cooperation between Web Call Server 4 and other software and services, we recommend to take a look at log files on the Web Call Server 4 installation server, as shown on the pictures below:

Log file of Web Call Server

Manager log file

You can see results of your requests sent via the REST console, you can use Google Developer Tools, as shown below:

The list of REST console errors in Google Chrome

Integration with Twilio

To test flexibility of the Web Call Server 4 integration platform we also ran tests to check cooperation with the Twilio service. The layout of the experiment is shown on the diagram:

Twilio experiment diagram

Configuring a Twilio account and a SIP domain

Before using Twilio, we need to configure the account at the service and create a domain softphone will connect to. The steps needed to do this are shown below:

Step 1. Create a domain, in our case - flashphoner2

Twilio account page with the flashphoner2 domain

Step 2 - Create an access control list and define domain permissions

Twilio account page with domain settings

Step 2.1 - Build a list of IP addresses that are allowed to access this domain.

It is crucial that you included both IP addresses of person's devices (softphone) and the IP address of Web Call Server 4.

The list of IP addresses and users

The list of IP addresses

Step 2.2. - Assigning permissions

The list of permissions

After the domain is created in the Twilio service, permissions are set and the list of allowed IP addresses is ready, we can start configuring the softphone, in our case - Bria 4.

Configuring Bria and connecting it to the Twilio domain

In Bria settings, you should create an account to access Twilio as shown on the pictures below:

Configuring Bria accounts to access Twilio

Twilio account in Bria

Also, in Bria settings we should configure audio codec usage: G711 aLaw, uLaw, as well as the videocodec H.264.

Audio codecs for Twilio

Video codecs for Twilio

Now, we can make a test call using Bria and listen Twilio's auto-responder message. If the domain on the service is configured properly (and you can hear the auto-responder in Bria), it is time to create the control command for Web Call Server.

Changing Web Call Server configuration to work with Twilio

To test Twilio and Web Call Server 4 configuration we need to change server settings. Changes are made to the flashphoner.properties configuration file.

The console with the opened folder where the Web Call Server config file is located.

In particular, we change the set of used codecs and a number of other parameters.

Changing parameters in the Web Call Server config.

What and how to change in the config is specified in Web Call Server 4 documentation supplied by the manufacturer of the integration server.

After modifying the configuration of Web Call Server, reboot of the server is required to make changes take effect:

[root@SF1 conf]# service webcallserver stop

FlashphonerWebCallServer: stopping [OK]

[root@SF1 conf]# service webcallserver start

FlashphonerWebCallServer: starting [OK]

Managing Web Call Server As in the previous experiment, Web Call Server is managed by sending REST commands via the REST console in Google Chrome. This is shown below:

{

"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"

                     }

}
The request is sent to the Web Call Server address: http: //107.179.239.129:9091/RESTCall/call.

As a result, a call to the SIP domain of the Twilio service is initiated, and the Flash Player allows listening the response received from Twilio. Specifically, you can hear Twilio's auto-responder message.

Therefore, as a result of the Web Call Server 4 operation testing, when Web Call Server 4 was an integration solution to couple Twilio with Bria, we made sure that the integration server can cooperate with the Twilio service and softphone connected to it.

Integration with OpenSIPS

To test cooperation with IP-PBX solutions, we have conducted a test with IP-PBX Open SIPS. Testing framework layout is shown below:

OpenSIPS testing diagram

In this case, Bria works as a "service" accepting calls from third-party persons and responding with content. Due to the changed role of Bria, we need to change settings as shown on the screenshots below. In particular, we need to create an account for calls to IP-PBX OpenSIPS:

Configuring Bria for calls via OpenSIPS

Like in all previous cases, to see if there's an ability to control Web Call Server, we send a request:

{

"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"

                      }

}

Note, that the call goes through the account 10051 created on the OpenSIPS server, and the "number" of the callee is specified in the field of the same name.

As a result, the call made via Web Call Server 4 to the "account" 10050 was redirected to the streaming server and played via Flash Player.

Integration with Vidyo

One more service we tested is Vidyo.com. The need to perform wide broadcasting is caused by the limitation of this service on the maximum number of participants each broadcast (meeting) can have. Therefore, to run a meeting for 50, 100 or more participants with this service requires another solution.

As with other services, first, we sign up to the service.

Vidyo welcome page

Vidyo sign up page

Then, after signing up, we need to install software to the local computer and enter data you received upon activation of your account to connect to the service.

Vidyo page with the account already set up

Vidyo software interface

Account settings with the room number

After you enter data, the service connects and allows creating a meeting (room). The screenshot shows that each signed in and connected user is assigned with a unique extension number.

To connect other participants to the meeting (room) you need to invite other participants, for instance, by e-mail.

When you click the corresponding icon in the program window, a draft message is created in the e-mail client already containing data you need to tell to other potential participants of the meeting. The text of such a message is listed below:

Let's meet via Vidyo!
- To join from your desktop or mobile device: Click https: //join.vidyo.com/flex.html roomdirect.htmlATkey=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 http://www.vidyo.com/knowledge-center/
 

To test how the data acquired from the Vidyo service perform, we created an account in the Bria softphone based on the data provided by the service:

Bria settings to test in cooperation with Vidyo

When we created an account in Bria, we assumed a user name and a password can be arbitrary and only crucial things are the IP address to connect and (later) the number to dial to connect to the meeting room.

Note that only the Bria account specifically created for the Vidyo service must be enabled, so that the call was made to this specific service.

After the number 1501005148 is dialed on the Bria's keyboard, the dialing starts and Bria connects to the virtual meeting room.

In the program window you can see a new participant has arrived, as shown on the screenshot below:

Two participants are connected to the toom in Vidyo

Since our test through Bria was successful, let's try to test integration of Web Call Server 4 with the Vidyo service.

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

REST console with request to Web Call Server URI

The call to Web Call Server in the REST console

After sending a request, a new participant of the meeting (with the ID we specified in our command to Web Call Server) appears on the website of the Vidyo service.

Multiple participants connected to Vidyo

Meanwhile, in the player we use to test if broadcast goes or not, we can see a picture transmitted by the initiator of the meeting to the service as a placeholder for web camera broadcasting.

Test video in Flash Player received through the streaming server after Web Call Server has sent a request to Vidyo

Previously, we described a mechanism to launch streaming video server, and while conducting this test we used both AMS and WSE. Web Call Server settings are the same we set when tested the zoom.us service.

Integration with Blue Jeans

One of relatively popular web conference services is Blue Jeans. We decided to test integration with this service too.

This service offers quite a simple mechanism to start a meeting. First, you need to sign up and create an account as shown below:

Blue Jeans welcome page

After this step, as before, we need to install software provided by Blue Jeans.

Steps to sign up to Blue Jeans

Download page of Blue Jeans software

After Blue Jeans software is installed, all other activity is channelled through it.

Apparently, to connect someone to the meeting you should start this meeting first. In Blue Jeans software, create a meeting and send meeting data to potential participants. In our case:

  • IP address (dial IP)
  • Meeting ID
  • Passcode

If the second participant you want to invite also uses the same Blue Jeans software, the service allows entering the code in a special window ("pairing code"), so you could parallel your software and the software of the second participant. However, we didn't use this option in our test. Instead, we used the meeting ID and the passcode provided by the service.

Information to connect to the Blue Jeans service

To get data required to connect to the virtual meeting room, we decided to test how the service cooperates with the Bria softphone, just like we did before.

So, we created a Bria account:

Configuring Bria for Blue Jeans testing

Please note, that we acquired the Domain data from Blue Jeans community, because when you create a room, the service offers using an IP address (as shown above) to dial or the bjn.vc domain name.

The required notation to connect via SIP is sip.bjc.vc as described in messages of community members shown below:

A community page where we found correct SIP domain data for the Blue Jeans service

After we created a Bria account, we entered the ID of the meeting on the keyboard. This resulted in the picture (in our case this was a video fragment previously recorded in ManyCam) being broadcast to the meeting, while the data of the meeting were broadcast to Bria as shown below:

Resulting broadcast after connecting to Blue Jeans

Then, we tested integration of Blue Jeans and Web Call Server 4 using the REST console. We sent to Web Call Server 4 address: http: //107.179.239.120:9091/RESTCall/call the following request:

{

"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"

                     }

}

 

Note that we put the ID of the meeting to the callee field of the request, and the data we've found in the community (sip.bjc.vc) to the sipDomain field.

After the connection is established, you can see in the Blue Jeans program window that several new participants has arrived (one of them is Bria, and the other one is Web Call Server 4). This is shown below.

Two participants have joined the meeting in Blue Jeans

Correspondingly, in the player we see a "picture" from the local computer (as shown below). That is, we see what Blue Jeans software "sees" locally. Then, Blue Jeans software sends this video to the service, and Web Call Server 4 initiates sending and receives a response from the Blue Jeans service, then redirect the response to the streaming video server (AMS or WSE in our case).

Finally, Flash Player displays this video.

Broadcasting a video from the streaming server after processing the request from Web Call Server

Generally, aside from the lack of information about the correct domain for the SIP connection, our overall impression about Blue Jeans was positive, working with the service is easy and relatively effortless.

Integration with Lifesize

One more service we checked the integration with is Lifesize.

The same way as with other services, you can start using Lifesize after signing up on the website and installing the software provided by the server. That's what we did.

After installing the software locally, you should create a meeting as usual (see the screenshot below):

Meetings created in the Lifesize service

Lifesize software interface on a local computer

For each meeting, the service provides contacts (data) a third-party participant can use to make a call and join the meeting, as shown below:

Data to connect to the meeting including the IP address needed to connect, for example, through Bria

Additional connection data in Lifesize

Lifesize telephones to call

We used the data provided by Lifesize to dial and was pleasantly surprised that each connection stage is accompanied by visual informing in addition to the voice assistant which is pretty standard for all competitive solutions:

Hints in the local Lifesize software

As usual, Web Call Server established a connection to the Lifesize server via the REST console using the provided data.

A request to the Lifesize server through Web Call Server

The service software shows a window of the connected participant:

Several participants in the same meeting room in Lifesize

And displays the number of participants:

The number of participants

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

Broadcasting Lifesize response received through the streaming server

Lifesize video received through the streaming server

Subjectively, this service is more particular about quality of the connection, but we have no any specific evidences of that.

Integration with iMeet

The iMeet service offers a range of solutions to conduct public events in the Internet, also for participants connecting using their telephones.

iMeet sign up steps

The interface of the software a user should download and install to use the service strikes with great visual appearance and a lot of accompanying information (time, whether forecast and so on).

Just like with previously reviewed services, this service provides data to connect, but in the form of URI: http://www.imeet.com/georgeb

iMeet software interface on a local computer

Data to connect to iMeet

Similar to other services is the ability to invite third-party participants to the meeting (also by e-mail). Plus, there's a convenient option to make the service make a call to the phone number of a participant (the service dials you, not you dial the service).

Using the invitation link received via e-mail we were able to participate in a meeting from a web browser (without installing software):

Multiple participants in a meeting started with iMeet

Meeting participants in iMeet

However, we were not able to dial to the meeting using the Bria softphone, which is supposedly explained by the following comment at the service:

"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!" ( https://community.imeet.com/thread/1700 )

Even with the provided recommendations and the below Bria configuration the connection to the meeting still wasn't established (we tried to set the Domain parameter both to www.imeet.com/Vlad439323 and http://www.imeet.com/Vlad439323):

Bria settings to work with iMeet

We daresay that SIP connection requires other software and other services offered by iMeert, for example, iMeetVRC:

iMeetVRC should supposedly work with SIP telephones

We will test this in future tests.

Conclusions

Based on chosen criteria of selection and experimental conditions we more or less successfully (explained below) managed to test mutual compatibility of various services and software products. Surprisingly, many services integrated with Wowza Streaming Engine and Adobe Media Server more or less effortlessly thanks to usage of third-party software Web Call Server 4.

In particular, we managed to make sure of the following capabilities:

  • ability to initiate a call to the Zoom.us service and manage the call;
  • ability to broadcast streaming content, including multiple Zoom.us connections;
  • Web Call Server's ability to call to Twilio and persons connected to this server;
  • ability to manage calls of OpenSIPS persons connected via IP-PBX. Integration with Vidyo turned out to be simpler than zoom.us, because connection initialization and management came down to just one command in Web Call Server;
  • Lifesize subjectively required higher bandwidth to display the video with proper quality, while Blue Jeans turned out to be the simplest service of all and allowed connection to the meeting of both Bria and Web Call Server 4 with just a few elementary steps.;

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

 

Testing results are summarized in the table below:

 Adobe Media Server, Wowza Streaming Engine, Bria softphone, ZoomUS, Twilio, Vidyo, Blue Jeans, iMeet, Lifesize, OpenSIPS services with Web Call Server 4 test comparison table

When we chose candidates for testing we realized that some services are not available any more. Others do not offer online versions of the service and require installing server software. Some services are niche messengers or simply do not support SIP.

We hope this test of various services and software will inspire others to take this list https://vsee.com/videoconference and conduct their own study with the same or other set of software. It would be interesting to know results and conclusions of such an experiment.

References

  1. Traffic analyzer - https://www.wireshark.org
  2. Wowza Streaming Engine - https://www.wowza.com
  3. Adobe Media Server - http://www.adobe.com/products/adobe-media-server-family.html
  4. Web Call Server 4 - http://flashphoner.com
  5. www.zoom.us
  6. www.twilio.com
  7. www.lifesize.com
  8. www.bluejeans.com
  9. www.vidyo.com
  10. www.pgi.com
  11. CounterPath software - http://www.counterpath.com/bria/
  12. Video/audio processing software - https://manycam.com

Link to the useful file

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Andy South
Software Developer
Russian Federation Russian Federation
No Biography provided

Comments and Discussions

 
QuestionWowza Audio Stream connection to a sip call Pin
Member 1412977725-Jan-19 3:19
MemberMember 1412977725-Jan-19 3:19 
QuestionSnippets Pin
Nelek17-Feb-16 2:27
protectorNelek17-Feb-16 2:27 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Article
Posted 12 Feb 2016

Stats

15K views
68 downloads
7 bookmarked