Audio conferencing functionality offered by VoxImplant is one of the most advanced and flexible audio conferencing implementations you can find. Developers have full control of every call connected to the conference via VoxEngine.
For example, it's possible to record particular calls connected to the conference or the whole conference, developers can record only one audio stream that goes to the conference (if you need to get the audio a from particular participant). It's possible to play the audio file (or TTS) into the conference or to a particular participant (call connected to the conference), mute/unmute participants, and even join different conferences together.
Our Web SDK lets developers create web client applications for the conference in minutes (WebRTC will be used Chrome/Firefox/Opera or Flash in IE/Safari), same with Mobile SDKs. It's possible to implement convenient conference controls using messaging functionality (inside the call). In addition, SIP software and devices can be connected to the conference. It's hard to imagine an audio conferencing service you can't build using VoxImplant.
There are only few things we haven't finished yet - wideband audio support and voice activity detection (both are being developed by our brilliant engineering team, so they should become available soon).
There are two types of conferences that can be created, let's call them Local and Standalone. The main difference between them is in the type of calls that can be connected to the conference.
Local conferences represent the “one-to-many” principle: one incoming call initiates a conference, then our cloud calls up to 49 participants and adds them to the conference. There cannot be any incoming calls to that conference except for the initial one. Local conferences are often used in scenarios when you need to add additional participants on-the-fly during the call, such as adding a supervisor call for call whisper in a contact center scenario.
Standalone conferences represent the “many-to-many” principle: it takes up to 100 endpoints (incoming and outgoing). A conference scenario processes inbound calls from the gateway and initiates outbound calls; all the calls are eventually connected to the conference. Note that if you want incoming PSTN/SIP calls, the conference will require an additional gateway scenario to accept incoming calls and forward them to a conference.
We have created this image to help understand the difference between two types of conferences:
The following example shows VoxEngine scenario where conference created after the session was started by call:
And another example where conference created after the session was started by an HTTP request:
Developers have full control of all calls in the conference. For example, if we need to mute one of the participants
or if we want to play some audio file to the participant
If we need to play audio to all conference participants we will need something like that:
Of course, there is a way to record the conference (or particular calls):
Let's see how Standalone conference can be created.
It can be done either by StartConference request to HTTP API, where you have to specify the name of the conference or by forwarding call to the conference using VoxEngine.callConference. In both cases, the conference will be created in a new session (if the conference doesn't exist) where all calls can be processed on VoxEngine scenario level.
A standalone conference requires one or two scenarios, depending on a usage case.
Standalone: One Scenario
If your users will be joining a conference only via SDK-based clients, you need only one scenario, a Conference Manager (see the code in the next section).
Standalone: Two Scenarios
If you want incoming PSTN/SIP calls, the conference will require a Conference Gatekeeper (to forward calls to the conference) and a Conference Manager (where inbound calls from the gatekeeper can be processed and connected to the conference, and where outbound calls can be initiated and connected to the conference). In addition to the scenarios, we will need to create appropriate Voximplant application rules that will be used for launching the required scenarios.
Create a Conference Gatekeeper scenario with the following code (pay attention to the argument passed to the callConference call):
It's pretty straightforward - we just forward an incoming call to our conference. Now we need to create a rule for incoming calls: specify a rented Voximplant number in the Pattern field and assign the Conference Gatekeeper scenario.
If you want to start the conference by making a real call to a rented phone number, don't forget to bind this number to the application. To do so, go to the the Numbers tab with the Attached and Available sections. Switch to Available, select your number, and click Attach. In the window opened, specify Conference Gatekeeper, then click Attach.
Next, create a Conference Manager scenario with the following code:
Now create a rule for this scenario with the following settings. Here, the Pattern filed should contain the same value as was passed to the callConference call in the previous scenario. In our case, it's "conferenceId":
That's it. These scenarios can be modified according to developer needs. For example, to create an outbound call and join it to the conference remotely, we could use media_session_access_url and make a call to the existing conference session:
Adding different standard conferencing features is easy - write some JS code to add access code and passcode check, authorization by Caller ID, or web management interface. Check our GitHub page to get ready-to-use audio conferencing service scenarios and interfaces.