Selecting the Proper Connection Type in LiveSwitch

LiveSwitch is one of very few WebRTC solutions that offer more than one connection type. It can be a massive advantage if used correctly. The following article helps address which connection types to use and when. If you are still confused, get in touch with us, and we will happily walk you through your options! 

Whether you are a new or existing customer of LiveSwitch, when you first start a project, you will be greeted by choice: “How will my users connect?” By this, I don't mean the devices that users use, such as cellphones and laptops; but rather which of the four connections types is best for them to connect with - SFU (selective forwarding unit), MCU (multi-point control unit), P2P (peer to peer) and Hybrid (SFU/MCU)? 

In most cases, SFU (Selective Forwarding Unit) is the appropriate choice among the connection types. LiveSwitch recommends defaulting to SFU unless your use case falls into one of the exceptions below. 

When to use MCU? 

MCU (Multi-point Control Unit) is the second most popular connection type, next to SFU. However, we have seen this being misused a lot of times. MCU is best used for scenarios where you have to support medium-sized conferences, with some users using lower-powered devices. MCU is a good approach because instead of sending multiple SFU streams to each user, it mixes all the streams on the server and only sends a single downstream to each user. In short, it offloads most of the work to the server, alleviating the device load. 

It sounds great, right? Yes, however, it also has drawbacks for your application. Because MCU mixes the streams on the server, it gives you little control over your UI and has a lower participant capacity in desktop and web applications than SFU. We can work around these limitations using a “hybrid” approach, which I will discuss later in this article.

When to use Peer-to-Peer?

LiveSwitch doesn't track nearly as much peer-to-peer usage anymore because of its inability to handle scale properly and its issue with home routers that cause double-NAT environments where the data flows through a TURN server. The small percentage that still uses peer-to-peer calls is usually for scenarios where you need to connect two peers in the same city, with both participants known to each other.  Generally, if you pick peer-to-peer connections, you must understand the limitations and strengths of directly connecting peers; otherwise, we recommend choosing SFU, as it's a much safer connection type. 

The hybrid MCU/SFU connection type

Hybrid MCU/SFU Connections is a complex but super effective method to combine the benefits of both SFU and MCU in the same room. It requires you to understand a little about your end user, mainly the power and bandwidth of their devices, but once you have a good understanding of that, you can decide for the user what connection type to use. In a hybrid connection room, you always use SFU to send upstreams, full stop. On the receiving side, you open SFU Downstreams for every participant (ideally) or a single MCU downstream containing all the other SFU Upstreams mixed (low-powered device).  

Examples

Use Case # 1: I run a company that caters mostly to web traffic; however, we also have Android and iOS applications. We want to launch an online meeting application for our staff members to meet once a week in teams of 12. Do you still recommend SFU? 

Yes, well, sort of. All of the upstreams in this use case would be SFU. The web participants would also use SFU for their downstream(s). Mobile users may use MCU for their downstream depending on the age of the device. Newer devices can handle 12 SFU downstreams, as long as they are properly scaled for bitrate and resolution. 

Use Case # 2: I have an educational application that caters to smaller and underserved populations. We have classrooms of 30 students and mixed devices. 

This use case is perfect for the hybrid use case, but probably not how you’d guess. The approach to this problem we’ve taken in the past is to limit users to one SFU upstream and 2-3 SFU Downstreams, one larger bitrate stream from the teacher, and bandwidth permitting two very small downstreams from their favourite students. LiveSwitch can use Server Side Simulcast to create thumbnail-sized streams of their friends while providing a high-resolution copy for the teacher if required. Depending on their device, the teacher may receive a MCU mix of all 30 students, then if they need to see one student in a larger view, open a single downstream of that student at the same time in a higher resolution. 

In summary:

• In the majority of cases, SFU should be used.
• When in doubt, start with SFU.
• Hybrid architectures allow you to connect devices with SFU and bring in an MCU connection when required.
• MCU supports lower-powered devices that otherwise couldn't handle the number of participants in a meeting. 
• Both MCU and P2P have several drawbacks that can be resolved using SFU. 
• Peer-to-peer should only be considered when you understand the strengths and weaknesses of the connection type and make sure they align with your application.

Need assistance in architecting the perfect WebRTC application? Let our team help out! Get in touch with us today!