WebRTC won't fix your call quality. Observability will

Here’s a secret: WebRTC has the same call quality as other VoIP protocols.

The quality of WebRTC lies in its embedding in web browsers and the flourishing ecosystem around it. But we’re not here to discuss that. I recently had a discovery call with a potential client (now a client), where one of the things they wanted to flesh out is their use of a VoIP protocol.

They weren’t using WebRTC, and thought that switching to it may improve their call quality. But their real problem wasn’t the protocol - it was the lack of WebRTC observability: they couldn’t see what their calls were actually doing.

The wrong question

That’s the wrong question.

And that wrong question comes in different shapes and sizes:

• Should we use WebRTC or switch to X?
• Should we continue using X or switch to WebRTC?
• Might it be that we need to replace our SFU?
• Is it time for us to add an SFU? Maybe… remove it?
• We have quality issues with the Video API vendor we use. Who should we use instead?

It isn’t that these aren’t good questions. They are.

But they are the wrong ones. They hide the problem beneath - the reason for having the conversation in the first place.

If there’s a quality issue, wouldn’t it make sense first to try and figure out what the root cause is?

If calls don’t connect often enough, maybe we should check what causes too many calls to fail?

Switching technology, changing a configuration or an architecture without understanding the problem we’re fixing means we’re using the wrong lever.

-

With a recent client, during a meeting, I’ve “caught” a recent fix made that felt “off”. It just felt wrong deep in my gut.

So I suggested we pause for a bit, roll back the fix, and check the problem itself.

Try to figure out why this happened in the first place.

Because it might hide a deeper truth that will cause problems later on down the road.

And yes. The fix just hid the problem deeper.

-

In a way, that’s what observability is for. Finding the root causes and dealing with them instead of putting concealer on it so nobody knows what’s there.

Both stacks can hit the same quality

Using SIP? Great.

Using WebRTC? Also great.

Guess what? They BOTH use RTP to send the media.

In BOTH cases, you’re likely to be doing it over SRTP in 2026 and beyond. Security being more commonplace and important than it used to be…

Bandwidth issues? Affect them both. Same for jitter. Placement of infrastructure and TURN servers.

They can BOTH use the same codecs.

What does this mean?

From a quality point of view, picking SIP or WebRTC doesn’t really matter.

What matters is how good your implementation of it is.

Yes. I’d lean towards WebRTC these days. Not only because I’ve been its advocate for years. But because in the last decade, all energy and innovation have been turned towards WebRTC and in a way, away from SIP.

The more modern architectures and implementations are to be found with WebRTC.

Does that mean a WebRTC service is better in media quality than a SIP service? No.

It just means you’ll have more tools and options at your disposal. But they can both reach high media quality levels just the same.

You are blind by default

Asking SIP or WebRTC for media quality issues is the wrong question.

The main question that needs to guide you is what’s my current media quality and how do I improve and optimize it. And to answer this question you need more information - observability.

WebRTC gives us getStats() - a great API that virtually collects everything we need and packs it in a single call we can collect and analyze.

With SIP… we’re rather on our own. Simply because SIP is a protocol specification whereas WebRTC doubles as an API spec as well.

The main difference here is one of stance.

With SIP, most of the observability today is done on the server side. With WebRTC, the best practice is to collect it from the client by using getStats() - and if you ask me - the best way to do that is using rtcstats.com (and you can call me biased about it).

Why?

Server-side metrics are a guess on what the user felt. They hold half the story based on what the servers see and the feedback they may or may not be getting from the clients. If they are useful, it is mostly for understanding if something is wrong - not why. So using this to understand what can be optimized and improved is close to impossible.

Client-side metrics collection, as done in WebRTC applications (when done correctly), gives you the front row seat next to the user in understanding what he’s been going through - understanding his connection and media experience in ways no other method can achieve.

This client-side vantage point is important if you're running true observability and in root cause analysis, troubleshooting or optimization effort. Anything else is looking at ghost remains of what really happened.

What observability buys you that a faster transport never will

Observability then means:

• Collect metrics and telemetry from the client-side
• Be able to analyze and aggregate it at scale in your monitoring servers
• Drill down capabilities that can go to root causes

When you have this in place, spotting problems and trend changes in a deployment of a service goes down from days to minutes. It relies on monitoring and not on user complaints. Problems can be turned into root causes without the need to reach out to users for lengthy debugging sessions. You catch regressions before your users churn. You can argue with confidence (and data) with your CPaaS or Video API or infrastructure vendors.

That’s where you need to be with your service. Especially when users now expect immediate results.

Look before you re-architect

Got a problem that needs fixing?

Complaining customers. Poor quality. Limited connectivity.

Before you go about fixing things - go instrument the client code. In WebRTC, that means collecting getStats() across the whole call and from all calls. That information must be collected and preserved so you can actually make a decision that is grounded in data and not on feelings.

Don’t switch from P2P to an SFU or vice versa without that data.

Don’t go and adopt AV1 because it has better video quality before understanding why VP8 isn’t enough (it is - for many scenarios).

Stop looking to switch to another CPaaS vendor. Jumping from LiveKit, to Janus, to Jitsi, to mediasoup, to building your own, to whatever. Before understanding what’s wrong.

Don’t run after the latest fad (let’s call it MOQ?) if you don’t grok WebRTC enough to understand what it can and can’t do.

The first thing you need to do? Make sure you can SEE the problem. Have the ground solid below you before making the next step towards a new architectural decision.

The bottom line

And yes. The above is what I do for a living.

I invite you to contact me for an architecture review, consulting - or just to understand better what we do at rtcstats.com and how that can help you with your WebRTC application.