Online meeting services tests

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.

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.

Content

1. Tests criteria
2. Testing with Twilio
3. Testing with Zoom.us
4. Testing with Vidyo
5. Testing with Blue Jeans
6. Testing with Lifesize
7. Tests’ results
8. Additional resources

Test criteria 

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.

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:

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

Testing 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:

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

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

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

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

Step 4. Assigning 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:

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

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.

Testing with Zoom

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:

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

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  and a viewer to participate in the meeting.

To connect to a meeting started form the zoom.us service, the certain request should be sent (that’s what we do in the REST console of Google Chrome). A request with the given parameters is sent to a special URI Web Call Server. 

After the request is processed, Web Call Server  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  and is redirected by it to streaing video servers. This is illustrated below:

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  can also do this.

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.

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

Therefore, using only two commands send via the REST console on Web Call Server  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.

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

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.

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

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:

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.

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

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

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.

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.

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

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.

Correspondingly, in the player we see a “picture” from the traffic source (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  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.

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.

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

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:

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.

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

The service software shows a window of the connected participant, and displays the number of participants.

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

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

Tests’ results 

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.

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;
• 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 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: