and WebRTC: An Interview With Varun Singh

January 16, 2014

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 is one of the vendors trying to tackle this topic.

Varun SinghI’ve ran into Varun Singh, Co Founder at 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 all about? 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. 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, 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 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 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 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

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. architecture

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.

You may also like

Two years of WebRTC Insights

Two years of WebRTC Insights

Your email address will not be published. Required fields are marked

  1. in the callstatsio have you overwrite the webkitRTCPeerConnection constructor in javascript?
    I have a server (server A) use WebRTC video call. If i use getStats() i need insert code into this server (server A).
    But I want create new server( server B) to monitor server A. ( i do not change code in server A).
    the callstatsio have support?

    1. Hi Duong,

      We have a network probe that passively monitors the flows, it does not require any code change on system A, just runs alongside it. However, it can write data locally or sends data to our measurement system and not to system B.

      Drop me an email at varun at callstats dot io.

      1. Thanks Varun Singh,

        Could you tell me about the “network probe”? Is this “only” build in by javascript ?

        Thanks alot,

        1. The network probe is in written in C, is a binary that runs beside your server. Where is it that you want to measure the performance? at the endpoints running your javascript app, in this case the callstats.js can integrate with your javascript app.
          In any case drop me an email, because I may be misunderstanding something.


          1. Hi Varun Singh,

            This is architecture:
            -Server A:
            -Server B:
            My project run with nodejs server.
            In server A:
            Server.js and webrtcClient.js are those file I do not change code. In webrtcClient.js file I have a variable named peerConnections that is a list of PeerConnection object.
            callstats.js is your lib .
            In myfile.js I want to reuse peerConnections variable (from webrtcClient.js file) to getstats() PeerConnection, then send data to Server B.
            How is the issue resolved? Can callstats.js lib help me resolve this problem?

          2. yes you pass the peer connection object to callstats.JS and it will send data to our backend, where you can observe the measurement data. The JS doesn’t send data to another third party server. We haven’t considered that use case yet.

  2. Hi Varun Singh,

    Thanks for your help.

    I still have a question: can i use callstats.js lib to “GET” peer connection object in webrtcClient.js (overwrite the peeconnection object)?

    Have any Callstats.js method or function to “get” peer connection object?

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}