Implementing P2P-SFU transitions in WebRTC

One of the more disruptive aspects of WebRTC is the ability of establishing P2P connections without any server involved in the media path.   However this doesn’t scale well for multiparty audio/video calls as the bandwidth and cpu required for a full mesh of N:N P2P connections is too much in most of the cases.

But the fact that you support multiparty calls doesn’t mean that you shouldn’t consider using P2P connections when there are only two participants in the room and switch back to the SFU when the third participant joins or when you need to enable some recording or broadcasting capabilities only available in the SFU.

In fact this approach of using P2P when only two participants are connected and switching to the SFU has been successfully implemented in many products in the last years (Jitsi, Hangouts, Facebook).   The implementation of this feature is not trivial but it provides enough advantages to be worth it:

• Minimise the network hops reducing the end to end delay and the chances of having congestion.   This is specially interesting in countries where you don't have datacenters or meetings inside corporate networks.
• Be able to use all the features included in WebRTC.  For example even if your SFU only supports REMB based congestion control you can use the newer transport feedback based congestion control at least while in P2P mode.
• Reduce the infrastructure costs (specially the bandwidth cost).

There are different ways to implement this feature but at a high level the biggest decision is probably: Are you still connected to the SFU while having the P2P connection or not?

Having the SFU connection always established makes the switching faster but on the other side not having that connection open all the time is more efficient both for the endpoints and the infrastructure.

I did a quick review of the most popular WebRTC services / platforms to see how they do it and this is what I saw:

As you can see there is no obvious winner based on the choices of those popular platforms and both approaches have its merits.
Note: I tested other services, platforms and opensource implementations and couldn’t find this feature.  If I’m wrong please let me know the name and I will update the table.

Apart from that decision about maintaining the SFU connection open or not you also need to decide when and how to do the switching and there are many optimisations that can be done here specially in mobile native apps to minimise the transition and make it as seamless as possible.  But that can be a topic for other day... :)