nnnoiseless VS element-call

1. So the SFUs we're currently looking at are yours, ion-sfu (and/or galene) and mediasoup. Honestly we haven't finished looking at how they compare for rate control, but the Pion team seems very interested in ensuring they have good rate control.

2. From context I think you're talking about noise cancellation here? I assumed that some of the more exotic ML-based ones ran serverside, which obviously is incompatible with E2EE. It sounds like there are a bunch of options for running WASM-based intelligent noise cancellation clientside though, especially with MediaStreamTrackProcessor and friends. rnnoiseless as a pure Rust->WASM port of rnnoise looks fun, for instance: https://github.com/jneem/nnnoiseless

3. True, although given Google are highly motivated to make AEC work properly in WebRTC, I guess I'm hoping that they'll continue improving it, much as they have been. I certainly never want to have to write or integrate one ever again :D

Very nice! I've just updated [`nnnoiseless`](https://github.com/jneem/nnnoiseless) to rustfft 5.0, and got a cool 20% overall improvement.

Let me know what you guys think. You can check out the github here and experiment with it via the first link.

Looks like there's an open protocol and an open source client implementation for video calls. https://github.com/vector-im/element-call

This is great! Jitsi has never clicked for me. I tried it a few times, and read about it, and was never excited about it. I just tried Element Call, albeit an empty room, and the UI feels right.

There's now also https://github.com/vector-im/element-call.

They have SFU support as of recently, so it should work scale similarly to Jitsi et al.

Would second recommending giving Matrix a try, native voip is actively being worked on in the form of Element Call. But to access it in Element you currently have to use the develop client. Otherwise you have to use 3rd party voip software in the form of Jitsi in the stable release.

Element Call github

With screening for unapproved callers, this would really replace every other platform!

Currently we don't force TURN, so in practice this means that voice packets go direct between the clients if possible, and so the IP addresses of the clients are necessarily exposed to each other.

However, this is utterly trivial to fix: matrix-js-sdk already exposes https://github.com/matrix-org/matrix-js-sdk/blob/96ba061732b... and we simply haven't exposed it as a setting in Element Call yet. I've filed a bug for it at https://github.com/vector-im/element-call/issues/251 - thanks for bringing it up!

In terms of moderation: this is no different to moderation in Matrix as a whole, where we're already busy working on shared greylists (MSC2313 and friends) - https://matrix.org/blog/2020/10/19/combating-abuse-in-matrix... has more details at the end.