GUEST POST: WebRTC.ventures is a custom design & development agency focused on building WebRTC applications. They are part of AgilityFeat, which is one of our development partners at TokBox. Jean Lescure from their team wanted to share their experiences using our new API for detecting call quality.
Back in August TokBox announced their new Pre-Call API, for testing out bandwidth conditions, and posted a repository on github with a proof of concept. At WebRTC.ventures we saw a great opportunity to build upon that project and got working on creating a demo app out of it, including a server implementation in NodeJS which is compatible with Heroku.
In this article I’m going to guide you through what we did to extend the Pre-Call test into this working app which is currently up and running:
https://tokbox-quality.herokuapp.com/
(if you’re lucky you might run into one of us there).
Based on the Pre-Call test documentation we knew that we’d have the ability to understand whether a user has enough bandwidth to stream video and audio, just audio, or nothing at all. So the easiest implementation that came to mind was to have our app initiate a call and turn a user’s video on and off depending on the test results. As the name of the API states, we’d have to run the bandwidth test prior to the call, so we ended up with a workflow that looks like this: 
Testing bandwidth using OpenTok
The following code was created based off of TokBox’s Pre-Call Test repository: https://github.com/opentok/opentok-precall-test
The final app code is available at: https://github.com/agilityfeat/OpenTok-Precall-JS-Demo
There are three major components that encompass this app:
- OpenTok Session Id and Token server (
server.jsfile) - Bandwidth testing module (
app.jsfile) - Call module (
call.jsfile)
First things first, when we looked at the Pre-Call test code, everything worked great, except that we needed to create sessions and tokens any time we wanted someone new to try out the app. So the first thing we came up with was a quick NodeJS server implementation that would take care of serving up the client files, but more importantly, it would also take care of generating a single Session Id per app and multiple Tokens per user and serve them as requested. When the server is started up, it first generates two Session Id’s, one for testing bandwidth and another for the actual calls. The code for the Session Id’s creation looks like this:
Once our Session Id’s are ready for action, we used Express.js to respond to HTTP requests in this manner:
As you can see, aside from configuring the routes to serve the files, we also set up four routes for serving Session Id’s and Tokens, which are:
- ‘/quality.session.id’
- ‘/session.id’
- ‘/quality.token’
- ‘/token’
And again I’ll stress that we generate the Session Id’s just once during the app’s life cycle and serve it from memory. This is what allows multiple users to join a single call. It should be noted that this code could easily be extended to serve unique Session Id’s on demand, and even storing them, so that multiple simultaneous calls can coexist without interfering with one another. Moving on, there was little to be changed from the Pre-Call test code to allow for using server generated Session Id’s and Tokens, the following is what we extended:
Only 22 lines of added and refactored code are all that’s needed to piece together, what was originally a proof of concept, with an actual implementation.
Last but not least, in order to drive the actual calls, we used a separate set of Session Id and Tokens, but only if there’s enough bandwidth to at least join and stream audio. Below you can see what the call module ended up looking like. Aside from the Session Id and Token retrieval, only one line (51) completely changes perceived call quality thanks to the Pre-Call quality test API provided by TokBox.
As you can see from the screen-grab, when a user’s bandwidth falls below a set threshold, they’ll stream audio only, when they join the call.
On a final note, there’s plenty of room for extensibility on this demo app, and still, we’ve learned time and time again while utilizing TokBox technologies successfully with our clients, that possibilities are not only virtually endless, but easy to implement.
Contact WebRTC.ventures to learn more about their design and development services for your web or mobile application!