Video conferencing guide for Voximplant developers.
Our team proudly presents a brand new video conference functionality, which includes:
- centralized server-based conferencing (SFU)
- up to 100 members (depends on bandwidth)
- Endpoints API
- managing each Endpoint’s media elements
- MediaRenderers inside Endpoints
The functionality provides vast opportunities to make one-to-many or many-to-many video conferences with the versatile management of media elements, streams etc. This article will help you to understand all features and advantages of the functionality: step by step, you’ll learn how to work with Endpoints and MediaRenderers, and how to create server-based video conferences.
You need Web SDK 4.3.0 or later to use this functionality.
Step 1 — Layout
First of all, let’s grab a simple demo to demonstrate all further concepts and tricks.
Note that in this demo we use HTML templates and normalize.css (in addition to the main style.css file).
We recommend using Web Server for Chrome as it makes development and debugging easier. Install and open the app, click “Choose folder” and specify the folder with your project. After that you’ll see the Web Server URL, that’s it.
Step 2 — Init and Login
To use Web SDK, you have to:
- create the Voximplant class instance;
- then initialize it;
- and connect to the Voximplant cloud.
We are also going to use two JS files: index.js and helper.js. The index.js will contain necessary code related to described concepts; the code which is not related to the theme is placed in helper.js
So, create index.js in the project’s root and add first lines there to create a logger and define variables to control form:
Next, we have to get the Voximplant SDK instance:
Add a handler for the submit action:
Then we have to add a condition to that handler to make our web client connect to the Voximplant cloud:
Finally, we have to log in. In case of login error, it will be mentioned in the log. To do this, add the following code to the same handler:
Step 3 — Call processing
There are methods and events in Web SDK to handle incoming calls. The following code allows to handle calls and do appropriate actions in case of call is disconnected or failed. The callForm initiates a call after submission while callDisconnecthangs up. Each call status reflects in a console (see the column under the forms).
Add the following blocks of code to the index.js to implement described logic. Start with making a new call and hanging up a call:
To handle incoming calls add this handler:
Great! There’s only one thing to do in this step — add the handlers for call’s states Connected, Disconnected and Failed:
Now web client is able to answer first incoming and decline other incoming calls while the first one is active. It also handles connected/disconnected/failed call’s states and provides logging.
Step 4 — VoxEngine: create cloud JS scenarios
Web SDK code can’t perform call management by itself, without cloud JS scenarios. That is why we have to create two scenarios.
The first scenario will create gateway sessions: handle incoming calls and connect them to the conference. Name it conf_call.js. The second scenario serves the conference itself, name it conf_local.js.
Go to the Scenarios tab of the VoxImplant control panel and add the conf_call scenario with the following code. Pay attention to the callConference call: the argument “myconf” will be used further.
Then create the conf_local scenario with the following blocks of code. Firstly load the conference module and define variables for a conference and participants’ counter:
Now add a handler for the very first call which creates a conference. Note that the conference creating executes once in a session.
Create another handler for further incoming calls. The handler answers a call and connects it to the conference. It also increases participants’ counter:
Put these lines to the same handler to create a function which stops a conference if there are no participants:
Step 5 — VoxEngine: set up Voximplant application
To make scenarios work with each other, we have to create an application and two rules in it. Go to the Applications tab, click Create application, type the name of a new application (“conference-app”, for example) and then click Create.
Then add a new rule to your conference-app application; you can name it Incoming call. Use the conf_call JS scenario in the rule and leave the default call pattern ( .* ).
It’s time to create another rule for this application; you can name it Conference. Use the conf_local JS scenario in this rule. Pay attention to the following details:
- The value in the Pattern field should be the same as an argument in the conf_call scenario. In our case, it is “myconf”. If a pattern isn’t the same, the conf_call scenario won’t be able to connect incoming calls to the conference.
- Select the Video conference checkbox to allow video streams in conferences.
That’s it! We have prepared the Voximplant cloud to serve video conferences.
Step 6 — Endpoint introduction
Endpoint is one of the new concepts in the latest release. It represents any remote media unit in a call. Endpoint can be:
Each call from Web SDK includes only Endpoints, which send audio/video stream to a call. That means there wouldn’t be ASR’s and Recorder’s Endpoints in a call from Web SDK. Voxengine conference in the cloud contains Endpoints for all participants:
Call from Web SDK also includes local audio/video and Endpoints with MediaRenderers:
There are events for Endpoints, which allows tracking Endpoints’ behavior. For example, we can catch the moment when another participant joined the conference and create the container for video rendering. Accordingly, we can delete this container when the participant left the conference.
Add a handler for the EndpointAdded event to the bindCallCallbacks function:
Then create the onEndpointAdded function which sets up a rendering container for a new participant:
And the second function which deletes rendering container:
Step 7 — Working with MediaRenderer
It is possible to create container for video rendering when web client started to receive remote video stream. Accordingly, we can delete this container when remote video stream is stopped.
When remote video is started, we have access to the MediaRenderer instance. Let’s use it for extended logging. Add the handlers for the RemoteMediaAdded and RemoteMediaRemoved events to the onEndpointAdded function:
When you subscribe to the RemoteMediaAdded event, Web SDK will no longer render remote audio/video stream automatically, so you have to call the MediaRenderer.render method with optional container parameter. To do so, add the following lines to the onRemoteMediaAdded function.
You can find the demo at https://demos03.voximplant.com/sdk4/endpoint/
