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.
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 simple and clear explanations 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.
There
is available code which can be used for making flash player which could
be used for showing streaming content from famous meeting services
either IP PBX.
So, below some code sample,
which can be used as an illustration of what parameters is necessary
for connection between self-made flash player (compiled from available
code) and streaming software, such is Adobe Media Server, Wowza
Streaming Engine etc.
/**
*
**************************
* CONNECT / DISCONNECT
*
**************************
**/
private function
connect():void{
var splittedUrl:Array =
connectUrl.text.split("/");
streamName =
splittedUrl[splittedUrl.length-1];
var url:String =
connectUrl.text.substring(0,connectUrl.text.indexOf(splittedUrl[splittedUrl.length-1])-1);
Logger.info("CONNECT:
"+url);
nc = new NetConnection();
nc.client = this;
nc.addEventListener(NetStatusEvent.NET_STATUS,
handleConnectionStatus);Â
nc.connect(url);
}
//disconnect
private function
disconnect():void{
Logger.info("Disconnect");
nc.close();
nc = null;
}
In attachment could be found files
with whole code which can be used for managing Web Call Server through REST query and
flash player.
Therefore with previously mentioned functions from REST query it is
important to know valid parameters for each connected service either
online meeting service or IP-PBX.
In the purpose of
proving mentioned above code features, 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:
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
- Adobe Media
Integration platform:
Flashphoner Web
Call Server
REST console
(Google Chrome)
Broadcast sources:
CounterPath
Bria
Twilio.com
service
Zoom.us
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
Conditions of
the experiment
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).
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).
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 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.
At first, you should
configure the account and go through steps of virtual class
"initialization". This process is typical and no need to go
deeper in it.
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.
Running and
configuring Web Call Server 4
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.
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:
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, next 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
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.
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.
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.
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.
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 connections 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
And we need to install
required codecs for audio and video.
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.
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.
You can see results of
your requests sent via the REST console, you can use Google Developer
Tools.
As a conclution, we can say that integration with other
online meeting services, IP-PBX more or less are similar to the
described above
from Envato Forums - Latest posts http://ift.tt/1VLA4mY
via IFTTT
No comments:
Post a Comment