Comment by SahAssar
5 years ago
E2E is on by default as in all P2P webrtc calls. What you can't do is use a SFU and still get E2E. Perhaps I'm just missing something but why would you want a SFU AND E2E? Why not just use TURN in those cases (if the problem the SFU is meant to fix is routing)?
An SFU lets your video/audio streams scale. If there were only ever two people, sure, you could use a TURN server if P2P failed, but if you invite 4 people on the call, an SFU will allow each person to upload their stream to the SFU which will then distribute it at various bitrates to the other people on the call.
Just to add some context for muggles such as myself who were unaware of what an SFU is, it stands for "Selective Forwarding Unit".
https://webrtcglossary.com/sfu/
https://stackoverflow.com/questions/60013467/one-to-many-liv...
Except that if the call is E2E then the SFU can't do things like reencode to a different bitrate. Also wouldn't the decryption keys need to be distributed to all the participants of the call via the centralized service anyway since the stream is already in progress? Or am I just being thick in not understanding how a SFU and E2E would bring all of the benefits of both?
The originating browser is responsible for encoding all the desired quality levels and sending them to the SFU to decide what to forward to the other participants - that is the difference between a SFU and a MCU, and why SFUs can scale. SVC-capable codecs are coming to WebRTC too, which makes this a lot more efficient for the browser to do.
Encryption keys are distributed out of band of the media, so it's the same as whatever the tradeoffs are for multi-party E2E-encrypted text chat there (I don't know what those are though!)