How the stats and monitoring of WebRTC changed the monitoring of VoIP

Today we are publishing a translation about the next trend of WebRTC, thanks for that to consultant Tzachi. What changes does the WebRTC technology bring to the world of VoIP and how is the approach to statistics changing? By the way, you may remember that Tzachi Levent-Levy came to our conference Intercom 2017 - then he read a report on the history and impact of WebRTC on modern communications; however, at our nearest confer , alas, it will not. But bloggeek.me blog is always available, and we are trying to make it even more accessible with our translations :) So, we are talking about collecting statistics from video calls through clients, please under the cat.

---

To collect statistics WebRTC monitoring is now shifted from the server to the client side.

WebRTC decentralizes everything related to VoIP. The significance of the backend begins to give way to the significance of the end devices. Although WebRTC is not much different from other VoIP solutions, we still use it and design services using it in a completely different way.
')
The main example is for group calls, we shifted the focus from the MCU mixing model to the SFUT routing model. And then - suddenly - only the desire to deploy the MCU began to look ridiculous. I know what I'm talking about - I worked for a company where more than 60% of calls went through the MCU.

The transition to SFU means that we rely more on the capabilities and performance of the end device, giving it more privileges to markup the display (rather than doing this hard work on the backend using the MCU). The next step will be multiply connected networks, but I do not think that this will be realized in the near future.

Actually, what I was leading to: something similar happens with VoIP performance statistics (more precisely, with WebRTC statistics). We stop collecting statistics on the back end, but prefer to take it directly from the browser / device.

Statistics fees and VoIP monitoring

If you are not familiar with statistics collection and VoIP monitoring, here’s a short explanation:

VoIP is based on compatibility. Developers create a product, and then test it according to the specification and for the sake of compatibility. Further, those who are engaged in deployment, collect and run the service. Sometimes this leads to the fact that one vendor is used, but more often the products of different vendors work in the same assembly.

There is no specification or standard for how to do monitoring or what statistics can / should / will be collected. There are several ways to collect statistics, the most common is to use HEP / EEP . As the specification says:

“The Extensible Encapsulation Protocol” (“EEP”) provides you with the data transmission protocol. TCP / SCTP connections for remote collection. This is an overview of the data transmissions containing additional arbitrary data. This is not the case. For the method of transporting data, it’s not necessary to use it.

In simple language: media packs are duplicated to send duplicates for analysis to the monitoring service.

Duplication of packets occurs on the back end, through the media servers of the VoIP-network. Here’s how this is illustrated on the HOMER / SIPCAPTURE website :


HOMER receives data straight from the servers - OpenSIPS, FreeSWITCH, Asterisk, Kamailio - these are not user devices, only backend servers.

The rest of the systems rely on switches, routers and network devices, which again are in the backend infrastructure. Since in VoIP networks we almost always direct media through back-end servers, it is logical to assume that it is easier to collect data here than from user devices.

This works fine, but it is not necessary or useful for WebRTC.

Statistics gathering and monitoring WebRTC

There are few browsers that work with WebRTC (4 browsers, to be exact), and they all work with a similar API (actually, with WebRTC). These browsers have a getstats () method that returns the same as chrome: // webrtc-internals .

Many implementations are peer-to-peer uses, in which the media is transmitted
directly via the Internet without affecting the backend. Google Hangouts started doing this 2 years ago. Jitsi has added this feature under the name Jitsi P2P4121 . How do these services monitor quality for their users?

If you look at other services, you will realize that they are only a few years old. And WebRTC is already 6 years old. So everyone has already focused on functionality and stability; Quality and monitoring are no longer in the spotlight.

This led to the fact that applications on WebRTC collect statistics straight from browsers and end devices and do not try to get it from media servers.

Final result? Open-sourced projects - for example, rtcstats - and commercial services like callstats.io . They are based on WebRTC statistics (compiled using the getstats () API in the interval from 1 to several seconds), which is sent to the server for monitoring - there statistics are collected, stored and analyzed. We use a similar scheme in testRTC to collect, analyze and visualize the results of our measurements.

What does this give us?

1. Exact performance data from the end user - since the statistics are collected from the client device, there is no more loss of information due to the backend.
2. Easy access to information, because they use common methods to collect information. In addition, they can be embedded in native mobile and desktop applications that use WebRTC.
3. Trust in end devices is a trend in WebRTC that we see everywhere.

What's next?

WebRTC changes a lot in the way we used to think about VoIP networks. Specifically, the approach of collecting statistics, why and how this was done - I did not see this actively discussed, so I wanted to talk about it.

I have three reasons for this:

1. Some people asked me about it here in recent days, so it made sense to write a detailed answer.
2. At testRTC, we are thinking about offering a “local” passive monitoring service. If you want to collect, store and analyze your WebRTC statistics without giving it to a third-party cloud service, then write to us .
3. My WebRTC online course is currently being updated, plus I am preparing new seminars. This will be in April (on the day of publication, the course had an update from September 2017, details on bloggeek.me - an interpreter ). Sign up for a course if you want to learn WebRTC.