I don't understand "WebRTC doesn't support it". What do you mean?
WebRTC uses an external signalling channel to negotiate ICE candidates, codecs, and necessary information to establish a media communication. Once this is done, the visio/audio conference is P2P and encrypted from the caller to the callee: how is this not E2E? (Genuinely curious, not criticizing)
That is, if you're not using a TURN relay server, which is easy enough to know.
Maybe you meant that multi-party (one-to-many or many-to-many) calls are not E2E. Again I'm not too sure I understand: it is possible to have multi-party conf calls: each participants can encrypt its media stream and send it to the N-1 other participants. Obviously this costs a lot of CPU (for multiple encryption) and a lot of uplink because the same stream is sent N-1 times. But it is __possible__, and certainly viable with only 3 or 4 participants, provided people have a decent connection (WebRTC uses adapative bitrate streaming [0] to compensate for bandwith usage).
Then again, I know that generally, with WebRTC people would use MCU [1] when dealing with many-to-many conf calls, and then I agree it breaks E2E.
But for the other mentioned cases, WebRTC is E2E, isn't it?
Again, I'm genuinely curious about this, not trying to criticize or undermine.
> WebRTC does not (yet) provide a way of conducting multi-party conversations with end-to-end encryption. Unless you consistently compare DTLS fingerprints with your peers vocally, the same goes for one-to-one calls. As a result, your stream is encrypted on the network but decrypted on the machine that hosts the bridge when using Jitsi Meet.
> The Jitsi Meet architecture allows you to deploy your own version, including all server components. In that case, your security guarantees will be roughly equivalent to a direct one-to-one WebRTC call. This is the uniqueness of Jitsi Meet in terms of security.
WebRTC uses an external signalling channel to negotiate ICE candidates, codecs, and necessary information to establish a media communication. Once this is done, the visio/audio conference is P2P and encrypted from the caller to the callee: how is this not E2E? (Genuinely curious, not criticizing)
That is, if you're not using a TURN relay server, which is easy enough to know.
Maybe you meant that multi-party (one-to-many or many-to-many) calls are not E2E. Again I'm not too sure I understand: it is possible to have multi-party conf calls: each participants can encrypt its media stream and send it to the N-1 other participants. Obviously this costs a lot of CPU (for multiple encryption) and a lot of uplink because the same stream is sent N-1 times. But it is __possible__, and certainly viable with only 3 or 4 participants, provided people have a decent connection (WebRTC uses adapative bitrate streaming [0] to compensate for bandwith usage).
Then again, I know that generally, with WebRTC people would use MCU [1] when dealing with many-to-many conf calls, and then I agree it breaks E2E. But for the other mentioned cases, WebRTC is E2E, isn't it?
Again, I'm genuinely curious about this, not trying to criticize or undermine.
Thank!
[0]: https://www.wikiwand.com/en/Adaptive_bitrate_streaming
[1]: https://www.wikiwand.com/en/Multipoint_control_unit