Thanks! It's true that on a 2 or 3 call participants P2P almost always ends up having better performance. But the problem comes when you try adding more partici

Thanks! It's true that on a 2 or 3 call participants P2P almost always ends up having better performance. But the problem comes when you try adding more participants. The limiting factor is that on a P2P mesh with N participants, each participant sends its stream to all other participants (to N-1 destinations) and receives the stream from all other participants (receives N-1 streams), which incurs on more network and CPU requirements. When we go above 4 participants the call model changes to Single-Forwarding-Unit (SFU) where there is a central server that dispatches the different streams to each user. That way, each participant would only upload their stream once, and download N-1 streams back. This server may also apply some other optimizations. You can learn more about P2P limitations from this blog post. [1] That said, as this CoBrowsing experience is not as bandwith intensive as a 30fps high-quality video, we can afford to use P2P with more than 4 participants. [1] https://bloggeek.me/webrtc-p2p-mesh/ https://bloggeek.me/webrtc-p2p-mesh/ Edit: btw, we use daily.co for the video and audio part of our product. They abstract very well all the complexity related with real-time video and audio.