SFU vs MCU vs P2P: WebRTC Architectures Explained
Tags: webdev, javascript, devops, webrtc
Published: 2024-06-17 13:09:21

There are different WebRTC architecture available today, these are SFU, MCU and P2P, selecting one depends on many factors these include

### **Network Conditions**

### **Bandwidth availability**

* High Bandwidth
    

If participants have good quality bandwidth then SFU and peer to peer calling will work for them

* Variable Bandwidth
    

If the participants do not have good quality bandwidth and there are a lot of participants than going with a MCU would be a good idead

### **Latency Sensitivity**

* Low Latency Required
    

If the situation requires low latency then going with an SFU and/ or peer to peer is a good idea

* Latency Tolerance
    

If there is a tolerance for latency and latency is not that important then MCU can also be considered. MCU processes the streams which creates latency. But in return for latency MCU reduces the number of streams that must be given to each meeting user and thus reduces requirement for client resources

### **Server Capacity**

### **Server Resources**

* Limited Resources
    

In peer to peer connections and SFU there is less CPU requirement on the server and more on the client. In MCU there is large CPU requirement on the server side and less on the client side

If you have limited resources on the client side then it is adviseable to go with MCU. In large meetings with multiple streams using IoT devices could be a good use case for MCU

* Moderate Resources
    

If you have moderate resources on the client side like mobile phones, and smart devices and the meetings are not huge like 1000s of people then going with the SFU is a good idea.

If provides good quality streams that you don't get with MCU and is moderately resource intensive on the client as well as on the server

* High Resources
    

If you have devices that can handle high resource requirements such as 4G connection smart phones etc then you can consider peer to peer as well

peer to peer has minimal load on the server but provides all the streams to the client devices and the client devices itself has to send all the streams to all the other devices that are connected to the meeting

### **Use Cases**

* One to One calls
    

Peer to peer is a good use case for one to one call as it does not require a lot of resouces and individual devices can directly communicate with each other using a TURN server

* Small Group Meetings
    

Here SFU as well as MCU as well as peer to peer work. It depends on the number of users in the meeting also the client device capabilities including bandwidth and CPU capacity to deal with incoming and outgoing streams

* Large Webinars/ Conferences
    

SFU are perfect for this as the SFU streamlines the income streams and directs the stream to specific devices that need the stream

* Interactive Live Events
    

For this SFU and MCU both can be considered. MCU is going to cost a lot more as compared to SFU because it processes the incoming streams and creates a single stream that is then broadcast to all the users.

## **Quick Comparison Table between SFU, MCU and P2P**

| **Feature** | **SFU (Selective Forwarding Unit)** | **MCU (Multipoint Control Uni)** | **P2P (Peer-to-Peer)** |
| --- | --- | --- | --- |
| Scalability | Highly Scalable | Moderately Scalable | Low Scalability, suitable for small groups |
| Latency | Low to Moderate | High, because of mixing and processing of streams | low to moderate |
| bandwidth usage | Efficient, streams are selectively forwarded | High usage, because all streams are forwarded to all users | Variable, it depends on how many users are connected |
| Steam Quality | Excellent quality | Excellent quality | Excellent Quality |
| Implementation Cost | Moderate | High | low |
| Server Load | Moderate load | High load | Minimum load |

## **SFU ( Selective Forwarding Unit) in Detail**

SFU or a Selective Forwarding Unit, is a server component in the WebRTC ecosystem.

SFU recieves multiple media streams from different participants but selectively forwards the stream to other participants without mixing them.

One thing to note is that the SFU does not process the streams, it just routes them to participants based on the need

### **How does SFU work**

* **Stream Reception**
    

Each participant in the SFU model sends their stream to the SFU

* **Stream Selection**
    

The SFU analyses all the incoming streams and decides which streams needs to be send to which partcipant

* **Stream Forwarding**
    

Based on its decision the SFU forwards the streams to each participant, thus optimizing bandwidth and CPU load

* **Adaptive Bitrate Streaming**
    

SFU have the ability to implement adaptive bitrate streaming, this means that SFU can adjust the quality to the stream based on the bandwidth and CPU power of the recieving participant.

This makes sure that the participants that have a lower bandwidth or CPU power can also take part in the meeting.

* **Simulcast**
    

Simulcast is also an innovative technology that is implemented by the SFUs, Here a participant client device sends multiple streams of different quality.

then SFU forwards the streams that are most appropriate for each participant based on the recieving participants bandwidth and CPU availability.

### **Advantages**

1. Scalability
    

SFU can handle a large number of users efficiently by forwarding streams, and can work with a lot of streams in fairly small server size. This makes it a good solution for using it with multiplw simultaneous users in webinars and meetings

1. Lower Latency
    

The SFUs does not mix or process the streams hence there is not a lot of latency when working with SFUS

1. Efficient resource use
    

SFUs require comparatively less server resources and lower server costs in handling a large number of users

## **Exploring MCU (Multipoint control Unit)**

The MCU is a server component in the WebRTC. It receives multiple media streams from multiple participants then mixes these streams and combines them to create a single stream which it then streams back to the participants

### **How does MCU work**

* Stream Reception
    

Each participant sends their stream to the MCU.

* Stream Processing
    

The MCU then gets all the streams from all the participants that are in a meeting, then processes the streams and creates a single audio and video stream

* Stream Distribution
    

Then the MCU sends this single stream to all the participants that are connected in the meeting

### **Advantages**

* **Reduced bandwidth and CPU requirements for the client in large meetings:**
    

In traditional webrtc systems like peer 2 peer or SFU all the streams are provided to all the participants. If there is a large meeting then each participant gets a lot of streams from other participants which takes away resources like bandwidth and CPU from the client devices.

In MCU this is avoided because each client gets a single stream from the MCU thus optimizing client bandwidth and CPU time which is precious

* **Consistent streaming quality:**
    

In the MCU all the participants get the same quality stream from the MCU. This is not the case with p2p because different quality streams are provided by the peers and these streams are then provided to all the peers.

### **Disadvantages**

* **Server load considerations:**
    

In the MCU all the streams are directed towards the MCU which then processes all the streams and combines them and creates a new stream. This requires a lot CPU processing power on the server

So the MCU requires a lot of power on the server, but reduces load on the client devices

* **Scalability challenges**
    

Because MCU offloads all the processing on the server, there are scalability challenges.

MCU are perfect for video calling on client devices that are low on CPU and bandwidth requirements like mobile devices or IoT devices. But scaling the video to large number of participants creates exponential requirements of compute and bandwidth on the server.

## **Exploring P2P (Peer-to-Peer)**

Peer to Peer is a webrtc communication model where media streams that is audio, video and data. These streams are send from client to client directly but many times relayed through a TURN server so as to traverse the NAT

This Model provides direct communication between clients facilitating efficient and low latency communication


![Metered TURN servers](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/aelyie288vyt4oav7mqq.png)


## [**Metered TURN servers**](https://www.metered.ca/stun-turn)

1. **API:** TURN server management with powerful API. You can do things like Add/ Remove credentials via the API, Retrieve Per User / Credentials and User metrics via the API, Enable/ Disable credentials via the API, Retrive Usage data by date via the API.
    
2. **Global Geo-Location targeting:** Automatically directs traffic to the nearest servers, for lowest possible latency and highest quality performance. less than 50 ms latency anywhere around the world
    
3. **Servers in all the Regions of the world:** Toronto, Miami, San Francisco, Amsterdam, London, Frankfurt, Bangalore, Singapore,Sydney, Seoul, Dallas, New York
    
4. **Low Latency:** less than 50 ms latency, anywhere across the world.
    
5. **Cost-Effective:** pay-as-you-go pricing with bandwidth and volume discounts available.
    
6. **Easy Administration:** Get usage logs, emails when accounts reach threshold limits, billing records and email and phone support.
    
7. **Standards Compliant:** Conforms to RFCs 5389, 5769, 5780, 5766, 6062, 6156, 5245, 5768, 6336, 6544, 5928 over UDP, TCP, TLS, and DTLS.
    
8. **Multi‑Tenancy:** Create multiple credentials and separate the usage by customer, or different apps. Get Usage logs, billing records and threshold alerts.
    
9. **Enterprise Reliability:** 99.999% Uptime with SLA.
    
10. **Enterprise Scale:** With no limit on concurrent traffic or total traffic. Metered TURN Servers provide Enterprise Scalability
    
11. **5 GB/mo Free:** Get 5 GB every month free TURN server usage with the Free Plan
    
12. Runs on port 80 and 443
    
13. Support TURNS + SSL to allow connections through deep packet inspection firewalls.
    
14. Supports both TCP and UDP
    
15. Free Unlimited STUN
    

### **How does Peer to Peer work**

* Connection Establishment with Signalling
    

In peer to peer connection a signalling server is required which is used to exchange information such as the peer IP address and port number so that peers can identify each other and start the process of connection

* ICE and TURN server for connection establishment
    

WebRTC uses the ICE framework to find the best path to connect the peers directly. The ICE frameworks first tries to connect the peers using the STUN server if that fails then it tries to connect the peers using the TURN server.

* Stream Transmission
    

When the connection is established the media stream are transmitted between peers either directly or as in most cases through a TURN server.

Data passing through a TURN server is end to end encrypted, thus no one not even the TURN server know what data is passing through it

### **Advantages**

* Minimal latency
    

The main advantage of peer to peer connection is minimum latency that is because the connection is established directly, so there is minimum latecy

* Direct Communication
    

In the peer to peer connection the connection is direct from one peer to another, sometimes a TURN server is used which also does not process the streams just forwards it to other participants

### **Technical Deep Dive**

* TURN
    

TURN server is Traversal using relays around NAT which is a server that relays the traffic from one peer to another

Here is an article on TURN server that explain in detail what are turn servers and how do they work

* STUN
    

STUN server is called as the Session traversal utilities for NAT helps client devices descover their own external IP address and port number. The client devices do not know what their external IP address and port number is this because the NAT obfuscates this. The client device sends a request to the STUN server when then replies back with the external IP address and port number of the incoming request thus the device knows what the external IP address and port number is.

If you are interested in learning more about how STUN servers work you can refer to the article:  
[**Stun Server: What is Session Traversal Utilities for NAT?**](https://www.metered.ca/tools/openrelay/stun-servers-and-friends/)

* ICE Framework
    

ICE Framework is a webrtc framework that finds out which is the best path to connect to devices directly in order to create a webrtc connection

the ICE framework first tries to create a direct connection using STUN server and if that fails it tries to create a connection using the TURN servers

There are many ICE servers available in the market today. If you like to learn more about [**ICE servers**](https://www.metered.ca/blog/interactive-connectivity-establishment-ice-server-the-complete-guide/) then here is a guide.

* NAT Issues
    

NAT does not elt the devices connect directly with each other, it blocks incoming connections (some types of NAT allow connections others do not) does not let teh devices know what their external IP address and port number is and create other issues

There are different types of NAT some allow external connections and others do not. There are also firewall rules that block incoming connections from external devices

For these purposes you need a TURN server