Broadcasting conferences and webinars using the SIP protocol
The article is devoted to possible ways of 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 use existing services and solutions that support the SIP protocol. However, such services, as a rule, have no solutions aimed at broadcasting on the Internet. Existing services, such as Zoom.us, InterCall, Twilio, Vidyo, iMeet and so on, as well as other software and hardware solutions and products from other manufacturers do not provide the functionality of converting a conference organized using SIP to mass broadcast on the Internet .
')
We set a goal to determine which of our chosen solutions (by which we understand the combination of software products and services) will allow expanding the audience of the event with minimal effort, as shown in the diagram above.
The following are possible integration options between the two Adobe Media Server and Wowza Streaming Engine video streaming servers, Twilio, Zoom.us, Vidyo, Lifesize, Blue Jeans, iMeet, CounterPath Bria 4 softphone and Flashphoner Web Call Server 4 in various combinations.
Having decided to test various services and software products for mutual compatibility and the ability to perform mass broadcasting on the Internet, we selected services and products by several criteria.
The main requirements for a server that integrates between other services and software:
When selecting 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 the SIP protocol. From this rule, we made a number of exceptions with the zoom.us service and with Bria, since we know this softphone and its capabilities and usage features, and the zoom.us service is a fairly new start-up with many great features, so we we decided to test it (even though the SIP connection for this service is paid).
Based on the formulated selection criteria, our experience with various integration software and the convenience of using this or that software, we decided to use Web Call Server 4 to conduct our experiments, although it is possible to use other software.
One of the most common options for interaction between the source (right) and content recipient (left) is displayed in the diagram below:
It should be noted that when checking various options for organizing interaction through an integration platform, we restructured the specified scheme depending on the needs of the experiment.
The streaming video servers used in the experiment:
Integration platform:
Sources of translation:
Programs for viewing the broadcast (or content):
Programs for sending RTMP stream to server:
A necessary condition for the experiment is the presence of correctly installed and configured software products described above.
The screenshot below shows the setting of Adobe Flash Media Live Encoder, which was installed on the local client (outside the local network where the CDN platform was running).
We used the broadcast from Adobe Flash Media Live Encoder as a test source for an audio / video stream through a streaming video server. The resulting stream (after the streaming video server) was checked using Flash Player (shown in the screenshot below).
It is necessary to carefully check the stream settings (IP address, port, stream name) both at the source and at the recipient (player).
The scheme of verification of translation (health of streaming video servers) is presented below:
After checking the fact that the audio / video stream reaches the RTMP server, which we can see through the player, we can proceed directly to testing.
Also, at the time of testing Web Call Server with Twilio service, it is necessary to determine which public IP address is allocated by the service provider for Web Call Server access to the Internet and enter this address in the SIP domain settings. The same operation must be performed for the public IP address, which is used to test the Twilio service from Bria (installed on the local computer).
With the growing interest in distance learning and the territorially distributed exchange of audio / video information in real time, various services providing the necessary functionality are gaining popularity. One of these services is zoom.us.
The scheme of testing with the use of this service is described below:
First, you need to set up an account and perform the steps to “initiate” a virtual classroom (see screenshot).
After initiation, the local computer will launch the software provided by the service, which will capture voice from the microphone and video from the computer’s camera.
Each meeting is assigned a unique nine-digit ID, by informing which, together with the IP address of the service that is being broadcast, you can invite “participants” to the meeting. The sequence of actions is shown in the following screenshots.
Finally, having the IP address and meeting ID provided by zoom.us, we can configure Web Call Server 4 and the viewer in order to participate in the “meeting”.
Although Web Call Server 4 is a tool for integration between different content sources and streaming servers, each conference (or other source) may have individual settings, features and undocumented requirements for the implementation of 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 at the same time - otherwise (when there is no following operation for each software on a separate device).
We needed to forcibly stop one of these streaming servers, as shown below:
In this particular example, AMS is stopped (we know in advance that it worked on port 1936), and on port 1935, the Wowza Streaming Engine is running at 45.101.139.105.
Next, you need to make sure that the configuration of Web Call Server 4 server matches the parameters of the content source being used (in our example, zoom.us), for this, for example via ssh, you can contact 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:
In the file itself, it is necessary to change the codecs parameters and a number of others, as indicated in the screenshot (with parameters that are applicable for other services, you can simply “comment out”):
After saving the new parameters in the configuration file, you must restart Web Call Server 4 (as shown below):
As a result of all the above actions, we are guaranteed to have correctly functioning streaming video server and Web Call Server 4 and we can proceed to the direct management of Web Call Server 4 and the source of the broadcast.
Having installed and configured correctly functioning Web Call Server 4, we should keep 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 call using the SIP protocol to a content source, receiving a response from a content source, receiving the content itself and broadcasting this received content to a streaming server.
Web Call Server itself requires management tools, the implementation of which is organized through the REST / JSON API command. Such a control mechanism can be integrated into any existing software product and provide automatic control of the Web Call Server.
For our particular case, we use the REST console, through which requests are sent to Web Call Server with parameters, which in turn depend on the specific source of content to be integrated with the CDN.
For example, to join a meeting organized on the zoom.us service, you need to send the following request (which we will do via Google Chrome's REST console):
The request with the above parameters is sent to the special Web Call Server URI, as indicated below in the screenshot:
After completing the request from Web Call Server 4, WebCallServer will connect to an organized zoom.us meeting (while Web Call Server 4 will act as one of the “listeners”), at the same time a response (content of zoom.us) received by Web Call Server 4 - Web Call Server 4 will be redirected further to the streaming video servers (which we see in the screenshots below):
In this particular case with the zoom.us service, it is necessary to additionally connect to a specific “meeting” by transmitting to the zoom.us server a specific identifier (provided by the service) of the “meeting” (in our case, it is 311 705 123). One way is to use DTMF tone dialing (for example, on a softphone keyboard). The same operation can be performed by Web Call Server 4, as shown in the screenshot:
You can also send such a request via the REST console via the following command:
As a result, a specific “subscriber” will be connected to the broadcast of a specific “meeting”, as shown in the screenshot below. As can be seen in the screenshot, in the zoom.us interface window you can see the logo of Web Call Server, which in this case is one of the “listeners” of the “rally” launched.
At the same time, in the Wowza Flash Player window we see the broadcast, which was redirected via Web Call Server 4 from zoom.us to the Wowza Streaming Engine server (see screenshot).
Thus, by means of two commands transmitted via the REST console on Web Call Server 4, we were able to initiate participation in the meeting (“rally”) on the zoom.us service and redirect the content (“image” and audio stream) to the Wowza Streaming Engine server for further broadcasting via CDN network.
Web Call Server 4 can provide broadcast of any number of connections from the zoom.us service, which we tested in practice.
To do this, you need to configure your Bria account as shown in the following screenshots:
And you need to install sufficient codecs for audio and video:
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 general content through the CDN server.
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:
The results of executing requests through the REST console can also be viewed through the tools provided by the Google Developer Tools, as shown in the screenshot:
To test the flexibility of the Web Call Server 4 integration platform, we also tested interaction with the Twilio service.
The scheme of the organization of the experiment is shown in the diagram:
To start using the Twilio service, you need to set up an account on the service and create a domain to which the softphones will connect. The sequence of these actions is displayed on the following screenshots:
It is important to include in this list both the IP addresses of the subscriber devices (softphones) and the IP address of Web Call Server 4.
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 begin to configure the softphone, in our case - Bria 4.
In the settings of Bria, you need to create an account (account) to access Twilio, as shown in the screenshots below:
In the same place in the Bria settings, you must configure the use of audio codecs: G711 aLaw, uLaw and also the H.264 video codec.
After that, you can make a test call through Bria and listen to the voicemail recording provided by Twilio via a softphone.
If the domain on the service is configured correctly (and the voicemail recording is heard in Bria), you can start creating a control command for the Web Call Server.
When testing Twilio service with Web Call Server 4, you need to change the server settings. Such changes are made to the flashphoner.properties configuration file.
In particular, the set of used codecs and a number of other parameters are changing.
What and how to change in the configuration file is specified in the documentation for Web Call Server 4 provided by the manufacturer of the integration server.
After changing the configuration of Web Call Server, you need to restart the server for the changes to take effect:
As in the previous experiment, Web Call Server is managed by sending a REST command through the REST console of Google Chrome, as shown below:
The request is sent to the Web Call Server address: http: //107.179.239.129:9091/RESTCall/call.
As a result of the request, a call to the Twilio SIP domain is generated and in Flash Player you can listen to the response received from the Twilio service - or rather, you can hear the message playing from the Twilio answering machine.
Thus, as a result of testing Web Call Server 4 as an integration solution between Twilio and Bria, we were convinced that the integration server can interact with the Twilio service and softphones connected to this service.
To test the interaction with IP-PBX solutions, a test was conducted with the IP-PBX OpenSIPS server.
The organization of the test site is shown below:
In this case, Bria acts as a “service” that receives calls from third parties and responds to 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 below in the screenshots. In particular, you need to create an account for making calls to IP-PBX OpenSIPS:
As in previous cases, to demonstrate the ability to manage Web Call Server, we send a request:
You should pay attention to the fact 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, the call to the “subscriber” 10050 made via Web Call Server 4 was redirected to the streaming server and later heard through Flash Player.
Another service we tested was Vidyo.com. The need for mass broadcasting is connected with the fact that this service has a limited number of participants at each broadcast (rally) and, accordingly, it may be necessary to use the usual service (Vidyo) to hold an event for 50, 100 or more participants.
As is the case with other services - first you need to register for the service.
Further, after registration, you will need to install the software on your local computer and enter the data received during activation to connect to the service.
After entering the data, a connection to the service will occur and it will be possible to create a rally (a 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 you will see the data for connection, which must be communicated to other potential meeting participants.
The text of such a letter is shown below:
To test the data received from the Vidyo service, we created an account in the Bria softphone based on the data provided by the service:
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 where the connection will be made and (later) 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 must be included in Bria so that dialing is made to this service.
After dialing the number 1501005148 on the Bria keyboard, dialing will be made and connected 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:
Since our verification through Bria was a success, let's proceed to the verification of 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.
After sending the request, a new meeting participant will appear on the Vidyo web site (with the ID that we specified in the Web Call Server team).
And at the same time, in the player, through which we check the presence of the broadcast from the connected service, we can see a window with a picture that was transmitted by the rally initiator to the service as a replacement for the broadcast from the webcam.
Previously, we described the mechanism for launching streaming video servers and during this test we used both AMS and WSE, while the Web Call Server settings were used by those that we previously specified for the zoom.us service
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), first you need to register and create your account, as shown below:
After this step, as in the previous cases with similar services, it is necessary to install the software provided by the Blue Jeans service.
After installing Blue Jeans software on your computer, further actions are performed through this software.
Naturally, in order to connect someone to the meeting, you need to organize this meeting, and to do this, you need to create such a meeting in Blue Jeans software and, after creation, send these meetings to potential participants, in this case:
If the second participant that you want to invite, uses the same Blue Jeans software, Blue Jeans service suggests entering the code in a special window (“pairing code”) and you can “parallelize” your and its software. However, this function was not used for the purposes of our testing, we used those provided by the “meeting ID” and “passcode” services.
After receiving the data to connect to the virtual “room” where the meeting is being held, we, as before, decided to check the functioning of the service with the Bria softphone.
To do this, create an account in Bria as shown below:
It should be noted that we obtained the data for Domain from the Blue Jeans user community, since it’s proposed to use the IP address (as shown above) for dialing or the domain name bjn.vc.
The fact that you need to use the sip.bjc.vc notation to connect using SIP is scheduled in the community messages, as shown below:
After creating an account in Bria, we typed in the rally ID keypad and got the connection with the broadcast of the image (in our case, the video clip recorded earlier in ManyCam) in the rally and the broadcast of the rally data in Bria, as shown below:
Next, checking the integration capabilities between Blue Jeans and Web Call Server 4 using the REST console, we sent the following request to Web Call Server 4: http: //107.179.239.120:9091/RESTCall/call:
It should be noted that the request uses the rally ID as the callee field, and the data taken from the community as the sipDomain, that is, sip.bjc.vc.
After connecting, you can see several participants in the rally window (one of them is Bria Second Web Call Server 4), as shown below:
In the player, we can respectively observe the “picture” from the local computer (as shown below), that is, we see what “sees” the Blue Jeans software on the local computer. Next, Blue Jeans software sends this video to the service, and Web Call Server 4 already 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 'but.
According to the general impression, with the exception of the “default” that a specific domain should be used for a SIP connection, the general interaction with the Blue Jeans service turned out to be simple and relatively trouble-free.
Another of the available services, integration with which was tested is the service Lifesize.
Just like everything 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 an appointment (see the screenshot below):
For each meeting, contacts (data) are provided, through which a third party can dial (call) and participate in the meeting, as indicated below:
We used the data provided by the Lifesize service for dialing and were pleasantly surprised that each stage of connecting to the service was accompanied by visual information (and voice assistant, which, incidentally, is a common function for all similar services):
Web Call Server 4, as usual, using the REST console command, connected to the Lifesize service using the provided data (see above).
The service itself shows in its program a window of a connected participant:
And shows the number of participants:
And the response results were broadcast by Web Call Server to the streaming server (AMS or WSE).
According to the subjective sensations, this service is more demanding of the quality of the communication channel, however, this observation is not a confirmed fact, and is completely subjective.
The iMeet service provides a range of different solutions for organizing joint events on the Internet, including with the ability to connect participants using the phone.
The interface of the program, which must be downloaded and installed in order to use the service, is striking with the possibilities of colorful design and accompanying information (time, weather, etc.).
As before, the service provides data, but unlike the previous ones, the service provides a dialing address of the type URI: www.imeet.com/georgeb
Just like with previous services, there is the possibility of inviting third-party participants to a meeting (including by e-mail), and also, which is quite convenient, to call the service from the service to the phone number of the potential participant (that is, you do not need to dial the party, but you calls).
Using the link from the email invitation, we were able to participate in the meeting using a web browser (without the need to install software):
However, it was not possible to reach the rally from the Bria softphone, which, from our point of view, is explained by the service in the following comment:
Using the received recommendations and the following Bria settings, the connection with the rally did not occur anyway (the Domain parameter also changed to www.imeet.com/Vlad439323 and to www.imeet.com/Vlad439323 ):
We venture to assume that to connect using the SIP protocol, you need to test other software and a slightly different type of service provided by this service, for example, iMeetVRC:
What will be verified by us in subsequent tests.
In accordance with our selection criteria and experimental conditions, with varying degrees of success, which will be explained below, we were able to test the mutual compatibility of various services and software products. To my surprise, many services were seamlessly integrated to the Wowza Streaming Engine and Adobe Media Server streaming servers using the Web Call Server 4 middleware.
In particular, we managed to make sure that there is:
All tests were conducted with two streaming servers - Wowza Streaming Engine and Adobe Media Server.
The test results are summarized in the table below:
When examining candidates for testing, we were convinced that some of the services for which there are links do not exist or do not provide on-line versions of 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 shown by us will encourage other interested parties using this list: vsee.com/videoconference 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.
When conducting corporate training webinars, conferences or public meetings, rallies use existing services and solutions that support the SIP protocol. However, such services, as a rule, have no solutions aimed at broadcasting on the Internet. Existing services, such as Zoom.us, InterCall, Twilio, Vidyo, iMeet and so on, as well as other software and hardware solutions and products from other manufacturers do not provide the functionality of converting a conference organized using SIP to mass broadcast on the Internet .
')
We set a goal to determine which of our chosen solutions (by which we understand the combination of software products and services) will allow expanding the audience of the event with minimal effort, as shown in the diagram above.
The following are possible integration options between the two Adobe Media Server and Wowza Streaming Engine video streaming servers, Twilio, Zoom.us, Vidyo, Lifesize, Blue Jeans, iMeet, CounterPath Bria 4 softphone and Flashphoner Web Call Server 4 in various combinations.
Navigation
Basic requirements for an integration platform
Scheme verification experiment.
Conditions for the experiment.
Integration with zoom.us service.
Starting and configuring Web Call Server 4.
Connection initiation through Web Call Server 4.
Manage an established connection through Web Call Server 4.
Broadcast multiple connections from Zoom.us.
Analysis of possible problems with integration.
Integration with Twilio service.
Manage Web Call Server.
Integration with OpenSIPS.
Integration with Vidyo.
Integration with the Blue Jeans service.
Integration with Lifesize.
Integration with iMeet.
Final conclusions.
Resources used
Scheme verification experiment.
Conditions for the experiment.
Integration with zoom.us service.
Starting and configuring Web Call Server 4.
Connection initiation through Web Call Server 4.
Manage an established connection through Web Call Server 4.
Broadcast multiple connections from Zoom.us.
Analysis of possible problems with integration.
Integration with Twilio service.
- Set up a Twilio account and SIP domain.
- Set up Bria and connect to your Twilio domain.
- Changing Web Call Server configuration for use with Twilio.
Manage Web Call Server.
Integration with OpenSIPS.
Integration with Vidyo.
Integration with the Blue Jeans service.
Integration with Lifesize.
Integration with iMeet.
Final conclusions.
Resources used
How were candidates selected for testing?
Having decided to test various services and software products for mutual compatibility and the ability to perform mass broadcasting on the Internet, we selected services and products by several criteria.
The main requirements for a server that integrates between other services and software:
- flexible configuration mechanism for various integrated services and software products;
- availability of detailed documentation;
- availability of technical support from the manufacturer;
- ease of administration.
When selecting 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 the SIP protocol. From this rule, we made a number of exceptions with the zoom.us service and with Bria, since we know this softphone and its capabilities and usage features, and the zoom.us service is a fairly new start-up with many great features, so we we decided to test it (even though the SIP connection for this service is paid).
Based on the formulated selection criteria, our experience with various integration software and the convenience of using this or that software, we decided to use Web Call Server 4 to conduct our experiments, although it is possible to use other software.
Checkout Experiment Scheme
One of the most common options for interaction between the source (right) and content recipient (left) is displayed in the diagram below:
It should be noted that when checking various options for organizing interaction through an integration platform, we restructured the specified scheme depending on the needs of the experiment.
The streaming video servers used in the experiment:
- Wowza streaming engine
- Adobe Media Server
Integration platform:
- Flashphoner Web Call Server 4
- REST console (Google Chrome)
Sources of translation:
- CounterPath Bria 4
- Twilio.com service
- Zoom.us service
- iMeet service
- Vidyo service
- Blue Jeans service
- Lifesize service
Programs for viewing the broadcast (or content):
- Flash player
Programs for sending RTMP stream to server:
- Adobe Flash Media Live Encoder 3.2
Conditions for the experiment
A necessary condition for the experiment is the presence of correctly installed and configured software products described above.
The screenshot below shows the setting of Adobe Flash Media Live Encoder, which was installed on the local client (outside the local network where the CDN platform was running).
We used the broadcast from Adobe Flash Media Live Encoder as a test source for an audio / video stream through a streaming video server. The resulting stream (after the streaming video server) was checked using Flash Player (shown in the screenshot below).
It is necessary to carefully check the stream settings (IP address, port, stream name) both at the source and at the recipient (player).
The scheme of verification of translation (health of streaming video servers) is presented below:
After checking the fact that the audio / video stream reaches the RTMP server, which we can see through the player, we can proceed directly to testing.
Also, at the time of testing Web Call Server with Twilio service, it is necessary to determine which public IP address is allocated by the service provider for Web Call Server access to the Internet and enter this address in the SIP domain settings. The same operation must be performed for the public IP address, which is used to test the Twilio service from Bria (installed on the local computer).
Integration with zoom.us service
With the growing interest in distance learning and the territorially distributed exchange of audio / video information in real time, various services providing the necessary functionality are gaining popularity. One of these services is zoom.us.
The scheme of testing with the use of this service is described below:
First, you need to set up an account and perform the steps to “initiate” a virtual classroom (see screenshot).
After initiation, the local computer will launch the software provided by the service, which will capture voice from the microphone and video from the computer’s camera.
Each meeting is assigned a unique nine-digit ID, by informing which, together with the IP address of the service that is being broadcast, you can invite “participants” to the meeting. The sequence of actions is shown in the following screenshots.
Finally, having the IP address and meeting ID provided by zoom.us, we can configure Web Call Server 4 and the viewer in order to participate in the “meeting”.
Starting and configuring Web Call Server 4
Although Web Call Server 4 is a tool for integration between different content sources and streaming servers, each conference (or other source) may have individual settings, features and undocumented requirements for the implementation of 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 at the same time - otherwise (when there is no following operation for each software on a separate device).
We needed to forcibly stop one of these streaming servers, as shown below:
Console
[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 on port 1935, the Wowza Streaming Engine is running at 45.101.139.105.
Next, you need to make sure that the configuration of Web Call Server 4 server matches the parameters of the content source being used (in our example, zoom.us), for this, for example via ssh, you can contact 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:
In the file itself, it is necessary to change the codecs parameters and a number of others, as indicated in the screenshot (with parameters that are applicable for other services, you can simply “comment out”):
After saving the new parameters in the configuration file, you must restart Web Call Server 4 (as shown below):
Console
[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 we can proceed to the direct management of Web Call Server 4 and the source of the broadcast.
Connections via Web Call Server 4
Having installed and configured correctly functioning Web Call Server 4, we should keep 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 call using the SIP protocol to a content source, receiving a response from a content source, receiving the content itself and broadcasting this received content to a streaming server.
Web Call Server itself requires management tools, the implementation of which is organized through the REST / JSON API command. Such a control mechanism can be integrated into any existing software product and provide automatic control of the Web Call Server.
For our particular case, we use the REST console, through which requests are sent to Web Call Server with parameters, which in turn depend on the specific source of content to be integrated with the CDN.
For example, to join a meeting organized on the zoom.us service, you need to send the following request (which we will do via Google Chrome's REST console):
REST console
{
"CallId": "Xq2tlLcX89tTjaji", # arbitrary unique identifier of the call
"Callee": "10,000", # caller name (randomly selected)
"RtmpUrl": "rtmp: //45.101.139.105: 1935 / live", # broadcast address (platform CDN)
"RtmpStream": "lifestream1", # name of the stream being translated
"HasAudio": "true", # audio content attribute (is / is not)
"HasVideo": "true", # video content attribute (is / is not)
"Connection": # connection parameters
{
"SipLogin": "10000", # login
"SipPassword": "10,000,000", # password
"SipAuthenticationName": "10000", # name for authentication
“SipDomain”: “162.255.36.11”, # IP address of the meeting (provided by zoom.us)
“SipPort”: “5060”, # Port on which SIP broadcasting is performed
"SipRegisterRequired": "false", # domain registration attribute
AppKey: callApp
}
}
The request with the above parameters is sent to the special Web Call Server URI, as indicated below in the screenshot:
After completing the request from Web Call Server 4, WebCallServer will connect to an organized zoom.us meeting (while Web Call Server 4 will act as one of the “listeners”), at the same time a response (content of zoom.us) received by Web Call Server 4 - Web Call Server 4 will be redirected further to the streaming video servers (which we see in the screenshots below):
Manage an established connection through Web Call Server
In this particular case with the zoom.us service, it is necessary to additionally connect to a specific “meeting” by transmitting to the zoom.us server a specific identifier (provided by the service) of the “meeting” (in our case, it is 311 705 123). One way is to use DTMF tone dialing (for example, on a softphone keyboard). The same operation can be performed by Web Call Server 4, as shown in the screenshot:
You can also send such a request via the REST console via the following command:
REST console
/ Note: the syntax 1 ********** is a practical know-how when working with the zoom.us/ service
{
"CallId": "Xq2tlLcX89tTjaji", # the same ID as in the previous request
"Type": "RFC2833",
“Dtmf”: “1 ********** 311705123 #” # unique ID provided by zoom.us service
}
/ Note: the syntax 1 ********** is a practical know-how when working with the zoom.us/ service
As a result, a specific “subscriber” will be connected to the broadcast of a specific “meeting”, as shown in the screenshot below. As can be seen in the screenshot, in the zoom.us interface window you can see the logo of Web Call Server, which in this case is one of the “listeners” of the “rally” launched.
At the same time, in the Wowza Flash Player window we see the broadcast, which was redirected via Web Call Server 4 from zoom.us to the Wowza Streaming Engine server (see screenshot).
Thus, by means of two commands transmitted via the REST console on Web Call Server 4, we were able to initiate participation in the meeting (“rally”) on the zoom.us service and redirect the content (“image” and audio stream) to the Wowza Streaming Engine server for further broadcasting via CDN network.
Broadcast multiple connections from Zoom.us
Web Call Server 4 can provide broadcast of any number of connections from the zoom.us service, which we tested in practice.
To do this, you need to configure your Bria account as shown in the following screenshots:
And you need to install sufficient codecs for audio and video:
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 general content through the CDN server.
Analysis of possible problems with integration
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:
The results of executing requests through the REST console can also be viewed through the tools provided by the Google Developer Tools, as shown in the screenshot:
Integration with Twilio service
To test the flexibility of the Web Call Server 4 integration platform, we also tested interaction with the Twilio service.
The scheme of the organization of the experiment is shown in the diagram:
Setting 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 the softphones will connect. The sequence of these actions is displayed on the following screenshots:
Stage 1. Domain creation - in our case flashphoner2
Stage 2 - Creating an access list and determining access rights for a domain
Step 2.1 - Creating a list of IP addresses for which access to the domain is allowed.
It is important to include in this list both the IP addresses of the subscriber devices (softphones) and the IP address of Web Call Server 4.
Step 2.2. - Formation 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 begin to configure the softphone, in our case - Bria 4.
Set up Bria and connect to Twilio domain
In the settings of Bria, you need to create an account (account) to access Twilio, as shown in the screenshots below:
In the same place in the Bria settings, you must configure the use of audio codecs: G711 aLaw, uLaw and also the H.264 video codec.
After that, you can make a test call through Bria and listen to the voicemail recording provided by Twilio via a softphone.
If the domain on the service is configured correctly (and the voicemail recording is heard in Bria), you can start creating a control command for the Web Call Server.
Changing Web Call Server configuration for use with Twilio
When testing Twilio service with Web Call Server 4, you need to change the server settings. Such changes are made to the flashphoner.properties configuration file.
In particular, the set of used codecs and a number of other parameters are changing.
What and how to change in the configuration file is specified in the documentation for Web Call Server 4 provided by the manufacturer of the integration server.
After changing the configuration of Web Call Server, you need to restart the server for the changes to take effect:
Console
[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 managed by sending a REST command through the REST console of Google Chrome, as shown below:
REST console
{
"CallId": "Xq2tlLcX89tTjaji",
"Callee": "flashphoner2.sip.twilio.com",
"RtmpUrl": "rtmp: //45.100.109.105: 1936 / live",
"RtmpStream": "lifestream1",
"HasAudio": "true",
"HasVideo": "true",
"Connection": {
"SipLogin": "flashphoner2",
"SipPassword": "RadK2151312",
"SipAuthenticationName": "flashphoner2",
"SipDomain": "flashphoner2.sip.twilio.com",
"SipPort": "5060",
"SipRegisterRequired": "false",
AppKey: callApp
}
}
"CallId": "Xq2tlLcX89tTjaji",
"Callee": "flashphoner2.sip.twilio.com",
"RtmpUrl": "rtmp: //45.100.109.105: 1936 / live",
"RtmpStream": "lifestream1",
"HasAudio": "true",
"HasVideo": "true",
"Connection": {
"SipLogin": "flashphoner2",
"SipPassword": "RadK2151312",
"SipAuthenticationName": "flashphoner2",
"SipDomain": "flashphoner2.sip.twilio.com",
"SipPort": "5060",
"SipRegisterRequired": "false",
AppKey: callApp
}
}
The request is sent to the Web Call Server address: http: //107.179.239.129:9091/RESTCall/call.
As a result of the request, a call to the Twilio SIP domain is generated and in Flash Player you can listen to the response received from the Twilio service - or rather, you can hear the message playing from the Twilio answering machine.
Thus, as a result of testing Web Call Server 4 as an integration solution between Twilio and Bria, we were convinced that the integration server can interact with the Twilio service and softphones connected to this service.
OpenSIPS Integration
To test the interaction with IP-PBX solutions, a test was conducted with the IP-PBX OpenSIPS server.
The organization of the test site is shown below:
In this case, Bria acts as a “service” that receives calls from third parties and responds to 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 below in the screenshots. In particular, you need to create an account for making calls to IP-PBX OpenSIPS:
As in previous cases, to demonstrate the ability to manage Web Call Server, we send a request:
REST console
{
"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
}
}
You should pay attention to the fact 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, the call to the “subscriber” 10050 made via Web Call Server 4 was redirected to the streaming server and later heard through Flash Player.
Vidyo integration
Another service we tested was Vidyo.com. The need for mass broadcasting is connected with the fact that this service has a limited number of participants at each broadcast (rally) and, accordingly, it may be necessary to use the usual service (Vidyo) to hold an event for 50, 100 or more participants.
As is the case with other services - first you need to register for the service.
Further, after registration, you will need to install the software on your local computer and enter the data received during activation to connect to the service.
After entering the data, a connection to the service will occur and it will be possible to create a rally (a 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 you will see the data for connection, which must be communicated to other potential meeting participants.
The text of such a letter is shown 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
To test the data received from the Vidyo service, we created an account in the Bria softphone based on the data provided by the service:
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 where the connection will be made and (later) 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 must be included in Bria so that dialing is made to this service.
After dialing the number 1501005148 on the Bria keyboard, dialing will be made and connected 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:
Since our verification through Bria was a success, let's proceed to the verification of 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.
After sending the request, a new meeting participant will appear on the Vidyo web site (with the ID that we specified in the Web Call Server team).
And at the same time, in the player, through which we check the presence of the broadcast from the connected service, we can see a window with a picture that was transmitted by the rally initiator to the service as a replacement for the broadcast from the webcam.
Previously, we described the mechanism for launching streaming video servers and during this test we used both AMS and WSE, while the Web Call Server settings were used by those that we previously specified for the zoom.us service
Integration with Blue Jeans service
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), first you need to register and create your account, as shown below:
After this step, as in the previous cases with similar services, it is necessary to install the software provided by the Blue Jeans service.
After installing Blue Jeans software on your computer, further actions are performed through this software.
Naturally, in order to connect someone to the meeting, you need to organize this meeting, and to do this, you need to create such a meeting in Blue Jeans software and, after creation, send these meetings to potential participants, in this case:
- IP address (dial IP)
- Meeting ID
- Verification code (passcode)
If the second participant that you want to invite, uses the same Blue Jeans software, Blue Jeans service suggests entering the code in a special window (“pairing code”) and you can “parallelize” your and its software. However, this function was not used for the purposes of our testing, we used those provided by the “meeting ID” and “passcode” services.
After receiving the data to connect to the virtual “room” where the meeting is being held, we, as before, decided to check the functioning of the service with the Bria softphone.
To do this, create an account in Bria as shown below:
It should be noted that we obtained the data for Domain from the Blue Jeans user community, since it’s proposed to use the IP address (as shown above) for dialing or the domain name bjn.vc.
The fact that you need to use the sip.bjc.vc notation to connect using SIP is scheduled in the community messages, as shown below:
After creating an account in Bria, we typed in the rally ID keypad and got the connection with the broadcast of the image (in our case, the video clip recorded earlier in ManyCam) in the rally and the broadcast of the rally data in Bria, as shown below:
Next, checking the integration capabilities between Blue Jeans and Web Call Server 4 using the REST console, we sent the following request to Web Call Server 4: http: //107.179.239.120:9091/RESTCall/call:
REST console
{
«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»
}
}
It should be noted that the request uses the rally ID as the callee field, and the data taken from the community as the sipDomain, that is, sip.bjc.vc.
After connecting, you can see several participants in the rally window (one of them is Bria Second Web Call Server 4), as shown below:
In the player, we can respectively observe the “picture” from the local computer (as shown below), that is, we see what “sees” the Blue Jeans software on the local computer. Next, Blue Jeans software sends this video to the service, and Web Call Server 4 already 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 'but.
According to the general impression, with the exception of the “default” that a specific domain should be used for a SIP connection, the general interaction with the Blue Jeans service turned out to be simple and relatively trouble-free.
Lifesize Integration
Another of the available services, integration with which was tested is the service Lifesize.
Just like everything 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 an appointment (see the screenshot below):
For each meeting, contacts (data) are provided, through which a third party can dial (call) and participate in the meeting, as indicated below:
We used the data provided by the Lifesize service for dialing and were pleasantly surprised that each stage of connecting to the service was accompanied by visual information (and voice assistant, which, incidentally, is a common function for all similar services):
Web Call Server 4, as usual, using the REST console command, connected to the Lifesize service using the provided data (see above).
The service itself shows in its program a window of a connected participant:
And shows the number of participants:
And the response results were broadcast by Web Call Server to the streaming server (AMS or WSE).
According to the subjective sensations, this service is more demanding of the quality of the communication channel, however, this observation is not a confirmed fact, and is completely subjective.
IMeet integration
The iMeet service provides a range of different solutions for organizing joint events on the Internet, including with the ability to connect participants using the phone.
The interface of the program, which must be downloaded and installed in order to use the service, is striking with the possibilities of colorful design and accompanying information (time, weather, etc.).
As before, the service provides data, but unlike the previous ones, the service provides a dialing address of the type URI: www.imeet.com/georgeb
Just like with previous services, there is the possibility of inviting third-party participants to a meeting (including by e-mail), and also, which is quite convenient, to call the service from the service to the phone number of the potential participant (that is, you do not need to dial the party, but you calls).
Using the link from the email invitation, we were able to participate in the meeting using a web browser (without the need to install software):
However, it was not possible to reach 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 www.imeet.com/georgeb ) into an IM conversation to invite guests into your meeting. You can also download your iMeet URL directly from there! ”( Community.imeet.com/thread/1700 )
Using the received recommendations and the following Bria settings, the connection with the rally did not occur anyway (the Domain parameter also changed to www.imeet.com/Vlad439323 and to www.imeet.com/Vlad439323 ):
We venture to assume that to connect using the SIP protocol, you need to test other software and a slightly different type of service provided by this service, for example, iMeetVRC:
What will be verified by us in subsequent tests.
Final conclusions
In accordance with our selection criteria and experimental conditions, with varying degrees of success, which will be explained below, we were able to test the mutual compatibility of various services and software products. To my surprise, many services were seamlessly integrated to the Wowza Streaming Engine and Adobe Media Server streaming servers using the Web Call Server 4 middleware.
In particular, we managed to make sure that there is:
- the possibility of initiating a call to the service Zoom.us and call control;
- the ability to broadcast streaming content including multiple connections from the Zoom.us service;
- Web Call Server’s ability to dial Twilio service and subscribers connected to this service;
- the ability to manage calls from subscribers connected via IP-PBX OpenSIPS integration with the Vidyo service turned out to be simpler than with the zoom.us service, since the initiation and control of the connection to the Web Call Server was limited to one command;
- Lifesize subjectively demanded more bandwidth for high-quality video display in the service window, while Blue Jeans service was easy to use and made it possible to connect to the Bria rally and Web Call Server 4 at the same time in a few elementary steps;
All tests were conducted with two streaming servers - Wowza Streaming Engine and Adobe Media Server.
The test results are summarized in the table below:
When examining candidates for testing, we were convinced that some of the services for which there are links do not exist or do not provide on-line versions of 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 shown by us will encourage other interested parties using this list: vsee.com/videoconference 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
- Traffic Analyzer - www.wireshark.org
- Wowza Streaming Engine - www.wowza.com
- Adobe Media Server - www.adobe.com/products/adobe-media-server-family.html
- Web Call Server 4 - flashphoner.com
- www.zoom.us
- www.twilio.com
- www.lifesize.com
- www.bluejeans.com
- www.vidyo.com
- www.pgi.com
- CounterPath Software - www.counterpath.com/bria
- Software for processing video / audio content - manycam.com
Source: https://habr.com/ru/post/276487/
All Articles