Six Things You Need to Know About WebRTC SFUs

Perhaps you read the title of this post and wondered, “What’s an SFU and why should I care?”

That’s a good place to start. A Selective Forwarding Unit (SFU) is a method for connecting users in real-time interactions, using a server to route media streams between those users.

When used, media and data is sent from one user or peer to a server that acts as a relay point for all the other peers connected to that server. The server then “multiplexes” the streams and distributes them to the receiving peers.

1. How is this different from a peer-to-peer connection model?

Peer-to-Peer WebRTC is a decentralized media protocol that allows media and data to be exchanged directly between peers. In a standard peer-to-peer (P2P) connection model, all participants connect to each other in what’s known as a mesh architecture. All of the processing of the media takes place on the hardware at either end of the connection.

This only works up to a point, when the processor starts to run out of capacity to handle all of the streams that are being sent and received from all of the other peers. Once you have too many endpoints connected to each other in this fashion things start to break down. For more information, please check out this excellent explanation by Tsahi Levent-Levi.

2. Should I always use an SFU?

The short answer is, “Nope.”

There are certainly times when a P2P connection is the best solution for specific use cases. However, there are also times when there’s no way to setup and manage an interaction without using a routed media server of some sort. There are different kinds of media routing methods. An SFU is just one.

There’s another method for routing media called TURN (a handy acronym for the following mouthful: “Traversal Using Relays around NAT”). Essentially, TURN helps make connections work when P2P connections would otherwise be blocked due to certain security settings.

And maybe that’s all you really need. On the other hand, there are some interactions and features you may want to support where using an SFU is required.

3. Bandwidth Management

A major drawback to a P2P meshed connection method is the amount of bandwidth delivered. Each peer connected to each other will upload media streams (audio, video, etc.) N-1 times (where N is the number of people in your call).

Using an SFU allows peers to upload media and data streams only once. The server then handles the distribution to the N-1 participants in the interaction. This essentially helps you throttle the bandwidth consumed by all of the participants in the interaction. Think of this as doing your part to be a good corporate citizen and improving everyone’s media experience by reducing network congestion.

4. Simulcast

Simulcast capability is another advantage of the SFU. By default, WebRTC will send and receive the highest quality, highest resolution video and audio streams it can, given network conditions. You *can* specifically ask that streams be restricted to a lower resolution, but if you have endpoints that can accept full HD 1080p video, maybe you’d like them to have the best experience they can? On the other hand, you don’t want to waste bandwidth on people who can’t appreciate it, like your uncle who refuses to upgrade from his iPhone 4 because he hasn’t yet (and will never) run out of space for his Frank Sinatra Mp3’s.

With an SFU and simulcast, one can use the SFU to send multiple resolutions of video streams (as an example) to endpoints connected to that SFU. For Bob, your uncle, you can send him a much lower resolution stream that won’t overburden his already struggling iPhone 4. His wife, who at least has a relatively recent and capable Chromebook, may have the ability to easily accept video up to 720p in resolution. The SFU can send a 720p stream to her. Simulcast allows you to optimize the amount of bandwidth required to support the endpoints with the right resolution for those devices.

5. Rich media experience AND multiparty

WebRTC is great because it makes real-time and multimedia interactions possible far more easily than other, older technologies.

At Temasys, we don’t put any limitations on what developers can do with our SDKs, but we do provide recommendations on what works best for specific situations. As we’ve mentioned, though, pure mesh P2P interactions don’t scale up to support “many-to-many” interactions very well. Typically, P2P mesh is safe to use for video and audio interactions with up to 4 endpoints or participants. (Note: Audio-only calls can work with far more than that, up to 30)

Thanks to optimizations in bandwidth management, an SFU allows the number of participants in video calls to be much larger than what’s normally supported P2P. Some of our customers have created apps that support calls with up to 15 participants. This is all dependent on configured video/audio settings (resolution, bitrate, and framerate) of course. Because the SFU is doing the heavy-lifting of sending many of the streams to all the participants, endpoints can handle larger call sizes. Also, using an SFU does not prevent the developer’s access to all the video streams independently to allow customization of layouts for each peer.  

6. Record and archive sessions

Is recording a feature you need to support your use case? Because the media sent through an SFU is centralized, SFU’s enable server-side recording. Recording is important to many vertical markets such as finance and healthcare, where a permanent record of the interactions must be kept for audit or long-term continuity purposes. When using Temasys’s SFU, application developers can assign specific peers the permissions to start and stop recordings. Or, the SFU can be setup to record and archive everything automatically. When a call ends, recordings are uploaded to your Amazon S3 bucket where they can be accessed for post-processing and sharing.

Conclusion

Remember that P2P might work just fine, but there are options available with Temasys and WebRTC that allow us to support many use cases that go well beyond a simple 2 party video call. And, an SFU may not be the right solution for everyone, but it is incredibly useful when you want to have interactions where more than just 3-4 people share audio and video. If you want true multiparty support, need to record and archive interactions, or send different resolutions of video and audio to different endpoints, an SFU is the way to go.

Want to learn more about how we can help you bring your ideas for real-time interactions into reality? Create a free developer account on the Temasys Platform today.

Want to get in touch? We’re ready to help you – Contact us!