rtcStats compared to the alternatives
There is more than one reasonable way to get visibility into WebRTC calls in production, and some of them are not rtcStats. These pages say what each alternative actually does, where it genuinely fits better than we do, and what the trade-off costs you either way. We build rtcStats, so read them knowing that.
rtcStats vs callstats.io
callstats.io no longer exists. This page says what happened and how rtcStats compares.
Where callstats.io fits better: Nowhere. The service is shut down and the domain now redirects to an unrelated site. If you are still shipping callstats.js, it is dead code.
rtcStats vs ObserveRTC
Two open-source approaches. The difference is whether you want the pipeline or the answer.
Where ObserveRTC fits better: You want to write the analysis logic yourself, or you are embedding monitoring inside something you ship to other people.
rtcStats vs watchRTC
The most established commercial option in this set. A cloud service, now presented by Cyara as CyaraRTC.
Where watchRTC fits better: You need testing and monitoring from one vendor, on one contract.
rtcStats vs building it yourself
The collection layer is open source, so building is a real option. The analysis layer is the part that never finishes.
Where building it yourself fits better: You have the team and the appetite, or monitoring sits close enough to your product that owning the logic outright is strategic.
rtcStats vs webrtc-internals
Chrome's built-in debugging tool. Free, always there, and limited to the browser in front of you.
Where webrtc-internals fits better: You are debugging on your own machine, right now, and the call is happening in the tab you have open.