With WebRTC, don’t expect Google to be your personal outsourcing vendor

Understanding how WebRTC is governed in reality will enable you to make better decisions in your development strategy.

If you are correct or not is something we can argue about. What we can’t argue is that the expectation that a company who is maintaining an open source library doesn’t owe you anything.

Free is worth exactly what you pay for it. 0️⃣

And there lies the whole issue – if you aren’t paying for WebRTC, then what gives you the right to complain? (btw – this is different from the other side of it – could Google do a better job of maintaining WebRTC for everyone at the same or lower effort, while increasing external contributions to it).

Why this article?

To. Many, Times. People. Complain. About. Google.

I do that as well 😀

If you are complaining, at least know that you’re complaining about something that is reasonable…

One of the more recent cases comes from Twilio (or more accurately a customer of theirs):

There was a minor change in Google’s implementation of WebRTC. For some reason, they decided to be less lenient with how they parse iceServers in peer connections to be more “spec compliant”.

Yes. It is nitpicking.

Yes. It is a useless change.

Yes. They could have decided not to do it.

But they did. And in a weird way, it makes sense to do so.

And there’s a process in place already for dealing with that – Canary and Beta versions of Chrome that vendors (like Twilio) can use to catch and handle these things beforehand. Or they can… well… register to the WebRTC Insights 😉

Twilio had to fix their code (and they did by the way), and yet there are those who blame Google here for making changes in Chrome. Changes that one can say are needed.

I’d add a few more thoughts here before I continue to dive in to this topic properly:

• When you make an omelet you break a few eggs. Every change done in Chrome is going to break someone’s code
• Chrome is used by billions of users, on countless different devices, using implementations of an endless stream of companies and developers. If YOU think that you can create code that is flawless that won’t break for someone in the next upgrade, then do let me know – I am not hiring, but for you, I’ll definitely make an exception

Who “owns” WebRTC?

WebRTC is an open standard governed by the W3C and an open source library which confusingly is also named “webrtc”. I prefer to call it libwebrtc.

The WebRTC open source standard is somewhat split in “ownership” between the W3C and the IETF. W3C is in charge of the API surface we use in the browser for WebRTC and the IETF on the network protocol itself – what gets sent over the network.

WebRTC as an open source library is… well… it depends. Google develops and maintains libwebrtc – that’s the source code that goes into Chrome. And Edge. And Firefox. And Safari. Yes – all of them. And then there are other alternative libraries you can use.

The thing is this – you can’t really use a different WebRTC implementation in the browser, because browsers come with libwebrtc “built-in”. And in many cases, if you don’t need a browser, you may still want to use libwebrtc just to be as close as possible to the browser implementation.

Does that mean that Google owns the WebRTC implementation? To some degree it does – while there are alternatives, none of them are truly usable for many of the use cases.

That said, anyone can fork the Google WebRTC implementation and create his own project – open source or otherwise – and continue from there. Apple could do it. So could Microsoft and Mozilla. And yet they all decided to stick with libwebrtc as is.

Why is that?

I can think of two main reasons:

1. Why “waste” resources (engineers, time, money, etc) when you can get it for free and have Google develop it for you?
2. If you need to end up interoperating or having your application run on Chrome (=the Internet for non-iPhone users), then your best bet is to stick as close as possible to the source – which is libwebrtc

So in a way, Google owns WebRTC without really owning it. At least as long as Chrome is the undisputed and dominant form in which we consume the internet (are you reading this on a Chrome browser?)

I usually place a global market share graph at this stage. This time, I’ll share this website’s visitors distribution:

A few words about libwebrtc

libwebrtc is maintained by Google for Google. It is open sourced and you can use it. You can even contribute back, which isn’t a simple process.

By Google for Google means that prioritization of features, testing and bug fixes is done based on Google’s needs. These needs include Google Meet, a few other Google services and the need to support and maintain the larger ecosystem.

Who sets the tone here? What decides if your bug is more important to deal with than Google Meet or another vendor’s problems?

Put yourself in the shoes of the Google product manager for WebRTC and you’ll know the answer – it would be Google Meet first. The others later.

This also sets the tone as to the build system and code structure of libwebrtc. It is highly geared towards its use inside Chrome. Less elsewhere. And this in turn means that adopting it as a library inside your own application means dealing with code that isn’t meant to be a classic generic purpose SDK – you’ll need to figure your way through it (and with a bit less documentation than you’d like).

Vendors in the WebRTC ecosystem

There are now hundreds if not thousands of vendors using WebRTC in the ecosystem. They do it directly or indirectly via CPaaS vendors and other tooling and solutions. You can find many of them in my WebRTC Developer Tools Lanscape. Most of them view WebRTC as free. Not only that, it seems like many treat WebRTC as a human right – it needs to be there for them, it must be perfect, and if there’s something ”wrong” with it, then humanity has the obligation to fix it for them.

So… WebRTC is free. But what does that mean exactly? What is the SLA associated with it? What can you expect of it and come back to complain if it isn’t met?

Here are a few additional interesting questions, If WebRTC is cardinal and strategic to your application:

• Have you invested anything in returning back to the community around WebRTC? Should you?
• Do you have someone working part time or full time on the libwebrtc codebase itself? Is that work done in the public library or in your proprietary in-house fork?
• If you run into an issue, can you ask Google to help you out and will they spend the time and resources to do so?
• Can you pay Google (or anyone else) a support fee for solving your specific issues? (no)
• Are you here only to take or also to give?

👉 To be clear – there are no right or wrong answers here – just make sure you position your expectations based on your answers as well

Putting your money where your mouth is

Philipp Hancke has been doing WebRTC for a long time and is renowned for his bug reports. He even got Google to fix quite a few of them. Some bugs stayed open for years however, like this bug about TURN relay servers being used sometimes in cases where using STUN will be just fine. A bug here has an impact on the percentage of calls that get relayed via TURN servers which has a negative impact on call quality (at times) but also increases the cost to run those.

This bug has been open for since 2016. Quite a few Googlers took a look but without finding anything that stood out. The crucial hint of what goes wrong came in 2021 in another bug report. In the end, Philipp had to acquire the skills necessary to fix the bug (which will hopefully happen before the end of 2023).

This takes time and time is not cheap – especially that of engineers. Microsoft as his employer apparently decided it was important enough for him to spend time on fixing this and other issues.

Please Google add a feature for me!

HEVC encoding and decoding in WebRTC seems to be a topic some folks get excited about. It would be great to know why.. 

There is a bug report about it in the WebRTC issue tracker which gets fairly frequent updates. And yet… Google does nothing! How can that be?

One would say that’s because it is out of the requirements of what Google needs for Google. There are other contributing factors as well here:

1. It is also not simple to implement and maintain
2. Testing this is a headache, especially considering all potential edge cases, hardware, devices, …
3. Patents. HEVC is a legal minefield. Chrome supports HEVC only when the underlying hardware does. Why would Google go further into that minefield for you?
4. This isn’t a feature in WebRTC. Not a mandatory one. Even as an optional one you can argue that it is somewhat controversial

How to think about support in WebRTC?

There’s this modern concept of zero trust in cloud computing these days.

Here’s my suggestion to you wrt WebRTC and your stance:

Zero expectations.

Don’t expect – and you won’t be disappointed.

But more importantly – understand how this game is played:

• Use WebRTC. Take what you are given and make the most of it
• If you need to modify the source code:
  • Be sure to invest time and thought into how to do it in a way that will let you upgrade to later releases of libwebrtc
  • Upgrade frequently. 4 times a year is great. Less is going to be an issue
  • Follow up on security issues to patch in-between releases if needed. We keep track of these in WebRTC Insights
• Test frequently
  • Test against the beta and canary releases
  • If things break – report back. Make sure to add as much useful information as possible (follow these suggestions for submitting a WebRTC bug in Chrome)
  • If things break – don’t wait for Google to fix it. See if there’s something on your end you can do to fix things and work around the issue
• Have means to update your application
  • If you end up with an incompatibility with Chrome, you need a way to upgrade your application. Which will take time. You are in a race against the Chrome release train here
  • A way to release a hotfix to whatever it is your customers are using. Something that can be deployed within hours or days
• Browsers have a release cadence of a version per month. Think about that. And then plan accordingly
• Assume things will break. It is not a matter of if – just of when and how
• Things can be handled and managed better by the Google team for WebRTC. But it isn’t. Nothing you can really do about it

And yes – we’re here to help – you can use WebRTC Insights to get ahead of these issues in many ways.