Whether it’s one bad connection degrading the quality of the entire conference, or problems with the underlying media server or conference call architecture, a poor conferencing experience is avoidable. For large scale video conferences, the Selective Forwarding Unit (SFU) architecture may be a good way to go.
SFU is a topology allowing for clients to send their encoded video stream to the centralized media server where it is then forwarded/routed to the other clients. The SFU topology is an attractive approach to addressing the server performance issue, as it doesn’t involve the compute expense of video decoding and encoding. Additionally, without encoding/decoding, the latency of the added SFU media server is minimal. Lastly, the clients with full correspondence with the SFU media server have complete control over the streams it receives, and because the client is receiving the streams it wants, it can have full control over the user interface flexibility.
While the SFU topology has become a popular choice among WebRTC communities, perhaps the most common overlooked shortcoming of SFU topology is the default to using the ‘least common codec’. This means every participant in the conference needs to use the same codec. For those multiparty conferences where all participants are using PC/laptops, the issue is negligible but introducing a mobile device that is hardware optimized for H.264 acceleration would be better suited using a different codec. The inability to transcode video streams can limit the type of clients that can be connected together.
Additionally, traditional SIP based platforms cannot handle the multiple streams produced by the SFU. For this reason, without a gateway function in the middle, the SFU topologies are restricted to WebRTC only.
However, since each architecture has its pros and cons, an architecture enabling both topologies could be better, depending on your application. I’ll talk more about the pros and cons of a hybrid architecture next week. Stay tuned.