Short answer: it's not currently possible to do true end-to-end encryption through media servers with a key that is inaccessible from user space.
Longer answer...
WebRTC was designed as a fundamentally peer-to-peer protocol. The spec defines (and basically mandates) the use of end-to-end encryption. Which is great! Among other things, this means that browsers can implement e2e in a standardized and provably secure way.
On top of WebRTC's fundamental peer-to-peer-ishness, you can build an architecture to forward or process media and data streams through media servers. This is what Cloudflare has done, and what every major WebRTC platform/project does in order to scale up participant counts, improve performance by moving routing closer to the network edge, and implement things like recording. But there's no support (yet) in the WebRTC spec for encrypting media streams so that they can be handled and routed by a media server without decrypting them.
There's ongoing work on this. Here's a nice blog post covering how the early working group effort was being organized: callstats.io/blog/2018/06/01/examining-srtp-double-encryption-procedures-for-selective-forwarding-perc
Thank you for this long answer. Actually, I have always wondered why it isn't possible to treat the stream as arbitrary data, so it can be encrypted and decrypted in "userspace". Something like how Firefox Send works, with a key as a URL fragment. E2EE with intermediate forwarding peers unable to decrypt the contents.
Longer answer...
WebRTC was designed as a fundamentally peer-to-peer protocol. The spec defines (and basically mandates) the use of end-to-end encryption. Which is great! Among other things, this means that browsers can implement e2e in a standardized and provably secure way.
On top of WebRTC's fundamental peer-to-peer-ishness, you can build an architecture to forward or process media and data streams through media servers. This is what Cloudflare has done, and what every major WebRTC platform/project does in order to scale up participant counts, improve performance by moving routing closer to the network edge, and implement things like recording. But there's no support (yet) in the WebRTC spec for encrypting media streams so that they can be handled and routed by a media server without decrypting them.
There's ongoing work on this. Here's a nice blog post covering how the early working group effort was being organized: callstats.io/blog/2018/06/01/examining-srtp-double-encryption-procedures-for-selective-forwarding-perc