With WebRTC, better stick as close as possible to the requirements, architecture and implementation of Google Meet

September 19, 2022

When developing with WebRTC, try to stick as close as possible to how Google Meet is designed and architected. That’s where love and attention is given to the source code.

[In this list of short articles, I’ll be going over some WebRTC related quotes and try to explain them]

This is something that I’ve been saying time and time again – when you are developing anything with WebRTC, the closer you are to the requirements, architecture and implementation of Google Meet, the easier your life is going to be.

Here’s why 👇

Browser support

Chrome is the biggest game in town when it comes to market share.

If you want your application to run well on browsers, then Chrome is the first one you’ll be looking at.

But it gets worse/better than that:

  • Edge = Chromium = Chrome – same WebRTC stack in there
  • Firefox uses libwebrtc internally, which is… the same WebRTC stack used by Chrome
  • Same thing for Opera
  • And same thing for Safari, which generally ports libwebrtc to work inside their WebKit browser stack

Which leads us to libwebrtc…


libwebrtc is the WebRTC implementation that Google has open sourced. It is also the one they are using themselves for Chrome and for their mobile applications.

Since it is the one you’ll be bumping into in ALL browsers, it is the one you will be working in front of most of the time assuming you are going to have browsers as part of your service.

What Google cares about

Google cares about Google.

Ignore open source. The open web. Search. People.

A company at the end of the day needs to deal with the fact that it is here to generate revenue for its shareholders. If open source or open web helps, then so be it. If it doesn’t, or there are other interests, then… well… that’s what gets done.

Google isn’t maintaining WebRTC out of the goodness of their heart. It is an essential part of the web, but is also a component they need for Google Meet and a few other, less important projects.

As such, the attention of the team maintaining libwebrtc is going to be almost always razor focused on what Google Meet needs in their roadmap. Their bugs. Their features.

Planning to do something Google Meet doesn’t need? Does libwebrtc/Chrome support it or is it clunky or broken in that area? If it is broken, then you are in a world of pain… because the team at libwebrtc probably won’t have the attention span to assist you with it.

When to go against the tide?

That’s a good question.

When should you go against the tide and develop something that is far remote from what Google Meet is doing, with requirements that are different and even go against the requirements of Google Meet on the part that deals with media processing?

I guess the answer is when your team is savvy enough and experienced enough with developing WebRTC products. Not just using open source tools, but in looking at the internals and low level components of WebRTC.

It also greatly helps if they are known in the industry as individuals and known to the team at Google maintaining libwebrtc. When you need things, such personal relationships will be really important.

Sadly, there aren’t many around with that kind of skill set.

👉 That’s part of the objective behind the new Low-level WebRTC protocols course we’ve just launched. Check it out

👉 You should also read about the state of open source WebRTC projects to get a better understanding of when to use something other than libwebrtc and what to do about the server side of your WebRTC application

You may also like

WebRTC predictions for 2023

WebRTC predictions for 2023

Your email address will not be published. Required fields are marked

  1. Tsahi,

    I feel like you are sub-blogging about me!

    But yeah, the teams who can go against the tide are rare. I am quite fortunate to know two 😉

  2. The premise of the article makes sense to
    me, but I feel like I'm missing something.
    WebRTC allows us to transport audio and
    video from one consumer electronic device
    over the Internet to another at real time
    speeds sufficient to facilitate conversations.
    What else is there? To put my question
    another way, what could someone try to do
    with WebRTC that is not close to the
    requirements architecture and
    implementation of Google Meet? Does
    anyone have any examples of what
    specifically the author is advising us not to do?

    1. Try to out-do Google Meet in video quality or voice quality for one. It is doable to some extent, but you’ll need to really know what you’re doing.

      Then there’s live streaming. Again, doable, but not in the main target focus of Google. So you need more expertise here.

      Cloud gaming. Especially now that Stadia has lots its shine for Google.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}