[throwaway99797]

WebRTC is end-to-end encrypted to the peer. So you're right, when you do actual peer to peer WebRTC between you and another user in a browser, you have end-to-end encrypted communication. When you go through a server, it's just another peer. So the word end maybe doesn't fit anymore, because it's a server that is the peer and they can decrypt the stream. Transcoding is pretty common at that stage because it's helpful for scaling.

[kevincox]

That isn't necessarily true. I guess it is a bit opaque but when you negotiate a WebRTC connection you get a key and a list of network endpoints that you can use. It is entirely possible to add a proxy server in that list of endpoints without giving the proxy server a key as far as I am aware.

That being said for big calls you start wanting to do selective forwarding and you probably need to drop down to a lower layer in the WebRTC stack to manage this and allowing the Selective Forwarding Unit (SFU) to be allowed to drop chunks without messing up the connection. However it is definitely possible to do all of this over WebRTC with full E2E encryption (see Jitsi Meet).

[kwindla]

With today's browser implementations of WebRTC, you can proxy through a TURN server while still maintaining end-to-end encryption, but you can't proxy through any kind of customized endpoint/server, because each endpoint necessarily has the encryption keys as part of the session negotiation.

Chrome implements experimental user-space media stream processing APIs that allows you to build "end-to-end encryption" at the javascript level. But, to me at least, it's a bit hand-wavy to call that "end-to-end encryption" because the keys are created, managed, and accessible from user-space. And neither Safari nor Chrome yet support these APIs.

There's ongoing work on this: https://datatracker.ietf.org/wg/perc/documents/