All You Need to Know About WebRTC in 2023

8 min read
September 30, 2022

WebRTC is one of these tech-industry terms that gets hurled around a lot when the topic of building or integrating a web app comes up. 

There are more misconceptions about it than there is accurate information. If you are involved in a company that uses web applications, or general work-from-home tech, getting a grip on WebRTC and knowing some general trends can help clear up the fog of misinformation, and make you a valuable source of insight for your company and colleagues.

Table of contents

  1. What exactly is WebRTC?
  2. Some quick history of why WebRTC was invented
  3. The way WebRTC works
  4. Is WebRTC good?
  5. Where is WebRTC going?
  6. What motivates Google to keep supporting WebRTC?
  7. Are there any WebRTC alternatives on the horizon?
  8. Throwing our hat into the ring

What exactly is WebRTC?

It’s better to clear up what WebRTC is not. It is not a protocol! It is not a product. It is not an out-of-the-box solution.

WebRTC is a project.

Specifically, it’s a project or technology owned by Google that acts as a compatibility layer between clients (usually web browsers, but potentially discrete applications), so that the clients can communicate in real-time with one another.

You may, when working with coders, you may hear WebRTC referred to as a library. This is practically correct, but also kind of a misconception. A libwebrtc library contains a set of tools for implementing WebRTC that is officially released, but the library is not the project.


WebRTC as an open project is basically an initiative by Google to get web browsers to be able to support peer-to-peer web applications, like VoIP, live video, potentially some games, and more. It’s a critical step in the development of the internet itself reaching back to the early 2010’s when Net 2.0 had its genesis.

Particularly, this project allows a lot more utilisation of mobile devices by cloud services– like Google. This is why it is in Google’s strategic, long-term interest to have sponsored this technology, in particular, to be widely adopted.

Some quick history of why WebRTC was invented

Clients such as web browsers can talk to web servers easily. That’s what they’re initially built to do. They visit web pages, take HTML CSS and maybe javascript from a server somewhere, and assemble that code into a web page that regular humans can look at with their eyeballs and interact with.

This is all that web browsers were all the way back to the advent of Netscape… Up until about 2009, when the internet really began to expand to include fundamentally different interactions than computers talking to web servers.

Digital Samba Embedded In-room video api

What if a client wants to talk to another client? 

This is called peer-to-peer– and it’s also been around for ages. Many online chat programs were DCC (Direct Client to Client), and CTCP (Client to Client Protocol). BitTorrent is also peer-to-peer. Many early online game clients were strictly peer-to-peer, where clients would connect to other clients via IP addresses.

The problem with peer-to-peer applications was configuration. This was addressed by using discrete, pre-configured applications that handled these configuration problems. There was no widely adopted general way of establishing peer-to-peer connections for generic use around the web– and this is the problem that webRTC addressed.

The way webRTC works

Let’s say we have two clients that want to establish a peer-to-peer connection. Well. First off… How do they know about each other? How do they discover each other on the internet?

This problem of clients discovering one another is called signalling. As in, they are signalling to each other “Hey. I’m right here, and I am looking for a connection!” WebRTC itself does not handle any provisions for signalling; it hands that responsibility off to an application server. So both clients connect to a known server, and the server tells them what other clients are available to connect to.

When two clients want to connect, the signalling server acts as a middle-man. Both clients have to exchange configuration data in order to accept a peer-to-peer connection with one another. The technical term for this data is a Session Description Protocol (SDP) token. It basically tells the other connection things like window size, where to address peripherals like microphones, earphones, webcams, and other generic resources like video drivers or available video codecs that one client may have. 



After the signalling server facilitates both clients exchanging their SDP tokens, it’s time for the clients to connect. The clients use ICE to implement a data stream to one another, but there are two main ways that the actual connection gets made between the clients. Either by STUN or by TURN. You can think of ICE as a cable, and STUN, or TURN as the plugs that are on either end of that cable.

STUN servers are part of the clients themselves, which list their public network addresses for the other client to connect to. Sometimes, firewalls and other network settings prevent these types of connections from being used directly. For that, there is the TURN type connection, which a trusted public server is connected to that essentially bypasses the two clients from having to address or ‘plug into each other directly.

WebRTC trends in 2022 video api thrends

WebRTC connections go through the following operations to work:

  1. Signalling
  2. SDP token exchange through the signalling server
  3. Setting up STUN or TURN as their connection type
  4. Using ICE to establish a peer-to-peer data-stream

If this sounds confusing; it’s because there is a lot of complexity that WebRTC has to handle in order to act as an effective compatibility layer across countless device types and configurations in hardware, software, and networking!

Is WebRTC good?

It depends. There are pros and cons to WebRTC. Here are some to consider:




Widely used by many apps 

 Controlled by a single company (Google) 

Generally mature technology 

 Can be complicated to develop with 

Stable and supported 

 CPaaS may be better 

Open source, and fully auditable codebase  

 Potential for security vulnerabilities 

Contributed to and supported by Apple, Google, Microsoft, etc.

 Passed its peak in adoption

Certainly, many generic peer-to-peer web applications choose WebRTC as their toolset to develop with– and this will continue to be the case well into the future. But, there are two major reasons for the unquestionable dominance of WebRTC to wane a little into the future.

Mainly, the fact that it has peaked in adoption– meaning that next year and going into the foreseeable future there will be less applications made using WebRTC than there were before at its peak… And secondly, the advent of Communications Platforms as a Service (CPAAS).

Where is WebRTC going?

No one has a crystal ball, and the future is never completely certain. However, that said, the trends for WebRTC can be clearly interpreted.

Trend #1: Passed the peak of WebRTC

While more applications will be made and continue to be made using WebRTC directly; the peak rate at which WebRTC applications get launched is now behind us. While new apps powered by WebRTC will come online; new apps will be coming online at a slower rate.

Trend #2: The era of differentiation

Differentiation is a nice word for competition. CPaaS API’s that may or may not be based on WebRTC are going to come up as alternatives for application developers of the future to implement peer-to-peer functionality. This trend will only accelerate moving forward.

Trend #3: Headed (slowly) towards a more obscure direction

There are many protocols, projects, and tools that were at one point all the rage that stick around as legacy ware. WebRTC is an open source project that will play a role– but a more diminishing role for the internet more broadly moving forward. This will eventually call into question the security of its maintenance by its owner, Google. Though these eventualities are very far off, the trend is moving in this direction for WebRTC.

What motivates Google to keep supporting WebRTC?

WebRTC does enhance the overall function of the internet and was strategically pivotal for mobile internet usage. However, beyond that, WebRTC is an excellent technology for data collection. Moving forward, Google will only have the consideration of data collection as a commodity to justify its considerable maintenance investment in WebRTC. 

The internet has already fundamentally shifted, and WebRTC as a technology has matured. Google also owns it as a project and determines what will happen with WebRTC in the future.

This does call into consideration whether WebRTC will eventually go the way of something like Adobe Flash.

WebRTC trends in 2022

Are there any WebRTC alternatives on the horizon?

Communication Platforms as a Service (CPaaS) solutions exist as boutique solutions that can greatly simplify application development or peer-to-peer functionality integration with existing systems through API’s.

No one singular CPaaS is a ‘threat’ to WebRTC on its own– but the trend of CPaaS adoption does hinder the growth of WebRTC, as more infrastructure is deployed in order to serve greatly simplified services through API’s that are much cheaper and easier for developers to work with.

For large institutional software users, or software companies seeking to sell products with functionality such as live video, file-sharing, or other roles that peer-to-peer connectivity through WebRTC was developed to provide, it may make sense to use a CPaaS and have a relationship with a software vendor or service provider company rather than use Google’s open source project to brew up an in-house solution on their own.

CPaaS fills needs that are just infeasible to fill using WebRTC in many cases.

Now, will these cases accelerate and eventually take over WebRTC entirely? No.

Many, if not most of these CPaaS solutions actually use WebRTC under the hood on their back end They just build out infrastructure to implement functions that WebRTC can support, and then wrap that implementation in an easy-to-use API while making design and configuration choices that may enhance things like security, or deliver a polished UI for a functional end-product that is much more readily available to software consumers.

Aside from that trend, there is no one project, or protocol initiative that is a singular threat to WebRTC. It may be around and last indefinitely; filling a role that there never ceases to be a need for.

But, going forward, the trend is clear that more options will become available for developers to fill the functionality that WebRTC initially was designed to fill. It may get pushed further into the back-end of the web, as less developers will be working directly with it over time.

CPaaS and other cloud services may accelerate in how they now tend to fill the role with application developers that WebRTC directly filled in the early to mid 2010’s in the same way that Amazon Web Services and Digital Ocean as services have largely replaced the practice of elf-hosting your own physical servers in order to have and operate a website.

The internet does tend to consolidate, and that would be a clear trend in line with general consolidation.


Throwing our hat into the ring

Digital Samba is a CPaaS, with an API back-end that allows application developers to embed, implement, and scalably deliver live video without the hassle of having to home-brew an in-house solution using WebRTC directly.

If the possibility of scalable peer-to-peer connectivity with some server-configurable controls and features intrigues you, you can talk to one of our experts with your questions about what our particular CPaaS can do.

We can and do eliminate a huge portion of the development overhead (and operational liabilities) of working with these base technologies on your own.

Get Email Notifications