CallStats.io and WebRTC: An Interview With Varun Singh

Monitoring a WebRTC deployment.

So, you’ve developed your video calling service with WebRTC, and now people are doing calls with it all day long. There are thousands of them. Millions. Do you know how well your service works for them? The next step in the chapter of WebRTC is dealing seriously with aspects like performance monitoring, and callstats.io is one of the vendors trying to tackle this topic.

I’ve ran into Varun Singh, Co Founder at callstats.io a couple of times, and I think the story of his new company is an interesting one – very different than most video performance monitoring solutions that are out there for non-WebRTC deployments already.

Here’s what he had to say.

What is callstats.io all about?

callstats.io provides performance monitoring services for WebRTC systems. Speaking with several WebRTC application developers, we found that 1) they have inadequate tools to measure performance of the video calls served by their service, 2) not all of them understand or have sufficient knowledge to understand video performance, and 3) have the expectation that the underlying system should just work as they intend it to.

callstats.io as a first step provides APIs that are integrated into an WebRTC application to help monitor the performance of the media flows. Our system is built bottom-up, we observe each flow in a conference, aggregate the performance of all participants in a conference, and lastly, the service level. As a second step, callstats.io provides guidance to the application developer or WebRTC service provider to better manage the multimedia experience. We are working on a notification and a diagnostic system to help with deployment and operational issues.

We are excited about callstats.io and are working with:

• Application developers building WebRTC applications.
• WebRTC SDK providers.
• Infrastructure and service providers (MVNOs, ISPs, equipment manufacturers).

What excites you about working in WebRTC?

I have personally been working with congestion control for video telephony for the last 8 years and have waited a long time for video telephony to become a first class citizen of the Internet. Our general belief is, WebRTC will commoditize multimedia communication and instead of being the focus of the app, it will be a feature.  One concrete example of this is: imagine being able to talk to potential apartment renters or house owners on Airbnb, you don’t have to reveal anything more than your Airbnb identity. Airbnb is just an example, any marketplace would benefit from such a communication as a service, and they would expect the underlying technology to work without tinkering too much with it.

We are contributing to standards where we can and are collaborating with people across the industry to help WebRTC deliver on the promise of ubiquity, high quality and performance.

You went for a hosted monitoring solution. How did the idea come up?

In the last 12 months, while building WebRTC applications, we realized that one of the challenges apart from building complex features is to measure the performance of the video calls (or lack of measuring it). At the time, there was no StatsAPI (or webrtc-internals://) and we built a system outside the browser to monitor the performance of the media flow(s), today we offer this as a component to measure performance of media flows at a middle-box (media gateway, TURN server or conference bridge).

Meanwhile, many WebRTC developers and service providers faced similar performance issues and they contacted us. The issues were mainly at two levels: service-level and endpoint/users-level. Diagnosing at the endpoint or user level can be done locally; however, the service level needs to be done at a centralized point (in the cloud). By offering this service as a hosted solution, we take the pain of performance and diagnosis away from the application developers so that they can focus on building the product or complex call features. The callstats.io dashboard currently displays service level engagement, network metrics and user experience, and the possibility to drill down to diagnose issues with individual users.

Can you share a bit more about the architecture you use for getting the data from WebRTC clients into your backend?

The communication between an endpoint and the backend is over HTTP/Web sockets. We provide two components: a client library for WebRTC endpoints and a connection monitor for middle-boxes. We currently provide callstats.js (a javascript client library) that communicates with our backend, gathers metrics and exposes an API to send user events (muting, hangup, etc.). The callstats.js will be accessible at the beginning of 2014.

The backend collects per flow statistics and puts them through an aggregation and summarization process to produce conference-level statistics (useful for multiparty calls) and service level statistics. Additionally, the developers can input their application constraints and let callstats.io derive the best set of optional constraints for each user based on past experience. In this way, we provide a mechanism for a consistent user experience for each user.

The backend also produces a dashboard for each customer, from which they can gauge the performance of their service at various levels. In early-2014, we will release our in-network monitoring module (as a binary module); it will provide an additional measurement point besides the endpoints and help with diagnosing potential performance issues.

Where do you see WebRTC going in 2-5 years?

There are currently many minor operational issues that need to be ironed out in 2014 for WebRTC to be ready for Internet scale deployments, for example, transports (DSCP markings, congestion control, circuit breakers). In 2 to 5 years, I foresee that many of these WebRTC apps will migrate from being video calling/conferencing apps to be components or features of other web apps.

Data channels present an exciting opportunity and possibly even become a “transport protocol”. At the moment we are observing a re-advent in peer-to-peer/overlays/BitTorrent-like apps, but envisage these types of applications to mature quickly. There is also the Internet of things (IoT) over data channels

If you had one piece of advice for those thinking of adopting WebRTC, what would it be?

Developers building yet another SDK or video calling application should look at their competitors and think hard about what or where they can provide value. There are enough MCUs, SDKs and various video-calling services already out there. Therefore, developers should try and integrate WebRTC into the flow of their web application, i.e., the video call should not necessarily start and end by pressing a button, but the participants in the call should be provided adequate context, prior and after the call to make the user experience frictionless.

What’s next for callstats.io?

A lot of exciting things are planned, we hope to deliver the components in the colour blue in early 2014, stay posted for the updates.

The first will be callstats.js, it will be released in the coming weeks, developers will be able to integrate it into their WebRTC application and they will be able to access the app- and media-level metrics from the dashboard. Complementing the JS will be the API documentation to help with the integration. We’ve had a busy fall and foresee a hectic spring. Happy New Year!

–

The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.