"Cutting-edge" implies that these guys managed to apply secure E2E encryption, but I can't find any references to it on the website. Correct me if I'm wrong.

You are wrong. This is the current state of webrtc.

Without considerable hacks (patent-encumbered unaccelerated wasm ffmpeg encoding of pixel data, rolling your own SRTP-like encrypted stream over datachannels and full mesh distribution of keys) this is not currently possible for anything other than a full mesh. Whenever an SFU (effectively a MITM) is involved (needed for more than a small number of participants) e2e encryption is lost.

If/when Insertable Streams are commonplace, this will be possible without so many hacks.

Edit: I see I was downvoted for correcting you, but there was an article on this very subject yesterday: https://webrtchacks.com/you-dont-have-end-to-end-encryption-...

The video transmitted over webrtc srtp is natively dtls encrypted between peers.

Yes, that is the "full mesh" that I mention in my comment...

This platform - and jitsi/janus/zoom/whatever - all use an SFU for more than a handful of participants.

But thats very doable. And no need for the unaccelerated ffmpeg wasm afaics, and no need to use a "sfu".

I don't know what Mediasoup does, was just commenting on what webrtc can do re the "the current state of webrtc" subject.

Do you have any examples of a webrtc video conferencing platform that provides a sufficient user experience over full mesh with 4 or more participants on disparate internet connections?

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)

No (but i hope they exist, havent looked) - however not all webrtc apps are general videoconf platforms. You don't even need servers if you go full p2p.

You still need servers to handle the signalling, perform ICE and TURN where applicable.

Only if you need to support users without full internet connectivity. Again webrtc can be used in many different requirement contexts.

You can certainly manually handle the signalling to set up the offer/answer. e.g. read them out to your peer(s).

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

STUN is not needed if the participants have full internet connectivity, only if you have to work around NAT.

As mentioned, you cant manually set up your listening ports - this is handled internally by ICE, which needs to connect to a STUN server to get (at a minimum) your public IP address.

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.