We’ve zoomed past the first half of 2023 with a whirlwind of change. In the past few months we’ve gone above and beyond to harness the new tools now at our disposal to bring you an exciting list of updates and enhancements across our suite of products and services. Trust me, you’re in for a treat!
Table of contents
Analysis
- Consolidating notifications section. testingRTC and watchRTC share similar UI. That said, their notifications sections were different, so we worked towards having the same look and feel in both, while polishing it for better clarity at the same time – check it out
- Incoming RTT is *sometimes* available. For that to work, you need the media server you use to support it (See RRTR). If it is there, we now collect, calculate and visualize it as well
- GetUserMedia() responses are now better tracked and analyzed in testRTC. Specifically, failure reasons are now displayed as part of the Advanced WebRTC Analytics view
Client defined IP addresses
You can now have your own geolocation “service”. This means that you can provide us with a static file of IP addresses and their “location”, and we will use them to resolve geolocation information prior to using our own geolocation service. This is great if your service runs behind a VPN/firewall or if you want to name your media servers and other infrastructure in watchRTC and/or qualityRTC. Read more about client-defined IP addresses.
testingRTC
- Scaling up
- Non-standard statistics
- New MOS expectation
Scaling up
We are investing heavily in our stress testing capabilities and the ability to scale it up. Part of that effort is in understanding the behaviour of IaaS vendors and how they treat an ad-hoc request for a large number of machines. The cloud isn’t infinite and isn’t infallible, which led us in the past to go with a best effort approach – large tests will run even if not all probes asked for could be allocated for them.
We’ve changed this approach so that the test will run only if less than 5% of the probes asked for can’t be allocated. In other words, if the percentage of probes that cannot be allocated is greater than or equal to 5%, the test will not be conducted. This ensures that a high proportion of probes can be successfully allocated before proceeding.
This 5% threshold is configurable.
Non-standard statistics
Google recently introduced additional non-standard statistics available via getStats(). These are only there if Chrome gets invoked via CLI with –enable-features=WebRtc-ExposeNonStandardStats option.
If and when this happens, we also collect these stats and show them as part of our Advanced WebRTC Analytics view.
You can enable this in testingRTC by adding #chrome-cli:enable-features=WebRtc-ExposeNonStandardStats in our run options.
New MOS expectation
You can now check for MOS in rtcSetTestExpectation().
qualityRTC
We have introduced a new capability in qualityRTC – a Chrome extension called testRTC companion.
If the user running the test has the Chrome extension installed, and your qualityRTC configuration is enabled for this feature, we will be collecting more information about the user’s machine and make it available in the log.
Here’s how this looks like:
Interested in learning more about this? Reach out to our support team.
probeRTC
- In probeRTC, you can now copy to clipboard any of the graphs, making it easy to embed and share in your own reports
- THROUGHPUT graphs can now be plotted either by bitrate or by calculation. The graph looks the same, but the Y axis changes accordingly
watchRTC
On the watchRTC front we’re hard at work scaling our service to meet the growing use we are seeing.
A few features added in this round include also:
- Ability to set alerts based on MOS score and user ratings
- Deprecated mapStream(), replacing it with mapTrack() to be in-line with where the WebRTC spec is going