Softobiz Technologies India | Insights | WebRTC Architecture: Everything You Need to Know
WebRTC Architecture
Technologies WebRTC

WebRTC Architecture: Everything You Need to Know

WebRTC Architecture

Back in the days of its inception, WebRTC was designed as a peer-to-peer communication technology. It was only meant to handle communication between two participants. However, as this technology advanced, complexities started arising. Handling communication between multiple participants became a challenge. To tackle this problem, several architectures were developed.

Today, three main WebRTC architectures exist: peer-to-peer, multipoint conferencing units, and selective forwarding units. Each architecture comes with its own upsides and downsides.

Wondering which one is better? Well, that’s exactly what we are going to do. We will discuss all these architectures in detail so that you can decide which one will work well for your business. Let’s begin:

Types of WebRTC Architecture

1. Peer-to-peer WebRTC Architecture

In the peer-to-peer WebRTC architecture, it is assumed that the media content is directly exchanged between two browsers.

Unfortunately, the direct exchange between two browsers is not possible as a browser is located behind a symmetric Network Address Translator (NAT). So, TURN servers located on the public Internet are used for forwarding media between browsers.

Advantages of Peer-to-Peer Architecture

  • Implementing the WebRTC infrastructure is easy in the peer-to-peer architecture.
  • A little backend infrastructure is needed for managing everything. Operating costs are low.
  • There is guaranteed end-to-end security in the communication between participants.

However, the problem with peer-to-peer WebRTC architecture is that it requires a significant amount of uplink bandwidth from participants. Also, a great amount of cost is involved for the client devices.

When it comes to practical use, peer-to-peer WebRTC is well-suited only for the smaller number of call participants.

2. Multipoint Conferencing Unit (MCU) Architecture

In MCU architecture, it is assumed that each participant is connecting with each other through a multi-point conferencing unit (MCU). The MCU decodes each received stream, re-scales it, composes a new stream from the received stream, and finally sends the new stream after encoding it.


  • Very little intelligence is needed in device endpoints as the MCU itself contains most of the logic.
  • MCU can generate output streams with different quality depending on their specific down-link conditions.

This is the reason why the multi-point conferencing unit (MCU) is considered as a good alternative to peer-to-peer WebRTC architecture.


  • Since MCU decodes and re-encodes streams to compose the final stream and significant computing power is required for doing so, MCU is very costly.
  • Since recomposing the message can be hampered by the packet loss on any link, encoding the frames may take time.

3. Selective Forwarding Unit

Selective Forwarding Unit (SFU) is an advanced version of multipoint conferencing units (MCU). In the SFU architecture, every participant sends his/her media stream to a centralized server (SFU) and receives streams from all other participants via the same central server. The architecture allows the call participants to send multiple media streams to the SFU where the SFU decides whether it should forward the media stream to the other call participants or not.

The best thing about the selective forwarding unit (SFU) is that it does not need to decode, and re-code received streams. It simply acts as a forwarder of streams between call participants. This means you can save a lot of time.


  • SFU can work with asymmetric bandwidth or higher downlink bandwidth than uplink bandwidth. This makes it suitable for asymmetric uplink/downlink networks like ADSL, mobile, and cable.
  • Another advantage of SFU WebRTC architecture is its scalability. We can easily add new streams depending on the need.
  • In the SFU architecture, every participant can send multiple versions of the same media stream, and the SFU forwards every single of them. As a result, providing support for various screen layouts is easy.

Which WebRTC Architecture is the Best?

There is no specific answer to this because every architecture comes with its own pros and cons. Peer to peer architecture is certainly the cheapest and the easiest to implement. However, it is certainly not well-suited for the scenarios when the number of participants increases. Peer-to-peer architecture also doesn’t work for legacy systems. You will need MCU and SFU WebRTC architectures for them.

However, the problem with SFU WebRTC architecture is that it cannot be used to support legacy endpoints because legacy endpoints usually work with different media encoding schemes. If the issue of legacy endpoints is not there, SFU architecture can provide better scaling opportunities. Also, even very little computing power is needed on the server. However, SFU architecture has higher requirements on the network bandwidth than the MCU architecture.

Another major concern about SFU and MCU is privacy. Both architectures don’t support end-to-end media encryption. This can be a major problem because privacy plays a crucial role in WebRTC.

Fortunately, another alternative called Privacy Enhanced RTP Conferencing (PERC) which guarantees end-to-end encryption of media streams sent over a media server without having to decrypt the media.

What else you can do?

Another great alternative is to merge all these architectures to form a new hybrid architecture – which is exactly what we did in case of EasyWebinar. Read the entire case study here!

We begin with a simple peer-to-peer architecture for calls that involve a lesser number of participants and then depending on the traffic, we upgrade it to MCU or SFU.

For example, when there are only two participants in the call and we don’t need a TURN server to communicate, we use the peer-to-peer WebRTC architecture. But the moment another participant joins the call on WebRTC, we upgrade the architecture to communicate using MCU or SFU. This saves a lot of costs. You can also follow the same approach.

In the end, you need to know that WebRTC is a promising technology that can make your business much more productive. But first, you need to under how well it is aligning with your business needs. Depending on your requirements, you need to choose the WebRTC architecture.

Still, if you need more guidance about WebRTC and how it can benefit your business, contact us. We will help you the best way possible.


The Importance of QA Testing in Software Development: Keeping Bugs at Bay!

Enterprise Application Development Challenges and How We Overcome Them

Remote Working is the future, but are you ready?

Harnessing the Power of GraphQL