The video transmitted over webrtc srtp is natively dtls encrypted between peers.
This platform - and jitsi/janus/zoom/whatever - all use an SFU for more than a handful of participants.
The product I work on signals this to the user, and asks for confirmation before "upgrading" to an SFU.
I don't know what Mediasoup does, was just commenting on what webrtc can do re the "the current state of webrtc" subject.
Im just saying that this library (and similar platforms) ARE the cutting edge of webrtc. At small number of participants, they use full mesh (which is e2ee), but at larger scale, they need to use an SFU (which is not e2ee without jumping through some crazy hoops - but this is being worked on)
> You don't even need servers if you go full p2p
If you have N participants into the same "room", and do not have a central SFU that relays streams to others, then you have a full mesh network with all participants sending audio and video to all the others. Is that the "go full p2p" you meant?. Well, try it, and you'll see how your CPU burns when the browser/app tries to encode your webcam video source N times. And of course, you'd need N x uplink.
You would still need some form of STUN server (but there are a number of 'freely accessible' ones, even configured as defaults in some browsers) to get your reachable address/port/proto. You cant, AFAIK, handle this manually - it is handled internally as part of ICE. Then you would need to manually handle the signalling of these as well.
Thats the bare minimum you have to do to peer over webrtc under ideal circumstances, but its certainly doable.
So you do that for each peer. If you (or a peer) change streams you will do the same thing all over again
edit: cant reply to your comment fulafel, but on that project you posted: https://github.com/cjb/serverless-webrtc/blob/master/serverl... Also, note that even if this wasnt defined, some browsers contain defaults. You 100% need STUN, but you can handle the signalling manually - as I stated.
edit2: cant reply to your comment ibc, but I was explaining the bare minimum 'serverless' webrtc case still required a STUN server. I appreciate that mediasoup SFU uses ice-lite instead.
If you say it's different with media channels, I'll believe you.
WebRTC can tell you your ip address without any external server, that only breaks if you are dealing with NAT.
edit: to clarify the NAT-less use case, i'm thinking of apps that can rely on/require p2p supporting IPv6 connectivity.
So you don't know what mediasoup does but you assure that "no need to use a SFU". Too much free time to comment maybe?
e2ee makes sense in one-to-one and N-to-N scenarios. It's just more complex in N-to-N scenarios because you DO need a centralized server so each participant just sends its audio/video once (to the server) and the server distributes it to others given whichever application policy/logic. That's a SFU, and that's what mediasoup does.