pthatcherg

Author here.

Jitsi is compatible with e2ee. For group calls, almost all of the work for e2ee is in the clients. And Jitsi can work with such clients.

Author here.

All of these things are built around WebRTC to some degree, which was built on previous open source work and standards. We all benefit from many contributions over many years.

Author here.

Jitsi and MediaSoup both seemed to have good congestion control at the time.

And, yes, as mentioned, the primary reason for writing a new one was performance/scalability.

Author here.

I guess if there is enough interest from users, we could look into adding a full mesh mode. It's been a year so far with group calls and no one has asked for it, probably because there isn't really much to be gained. Even 1:1 calls, which are p2p, sometimes need to be relayed through a TURN server.

Author here.

It's on the long list of things to do, yes. But we have many things before it on the list :).

Author here.

The server doesn't know who is in the call. It can't build any graph.

Author here.

MediaSoup was one of the two SFUs that did seem have congestion control at the time. Sorry if that wasn't clear.

Hi, I work at Signal on calling. Opening the mic while not in a call would be a serious bug, so I looked into it. I ran Micro Snitch and verified that it only sees the mic as active when you are in a call with someone (if you're in a group call and alone, keeps the mic off; if you're calling someone and they haven't answered yet, it keeps the mic off).

So I don't think it's an issue with calling.

However, if I hit the "record audio message" button and then hit cancel, I can get it to stay open until I close the app and restart it. I will report this bug to my coworkers at Signal that work in that area of the code.

Could you try and see if this problem is caused by the voice recording feature? For example, if you quit Signal and start back up, does the bug go away? If you start a voice recording and cancel it, does it come back?

Update: you can track the progress of the bug at https://signalmessenger.atlassian.net/browse/DESKTOP-2406

And if you have new information, please put it there.

Does anyone know where LiveKit's implementation of congestion control is? I can't find it looking through their code and to me that's a major sign of the maturity or completeness of an SFU. For example, Jitsi, Signal's SFU, and (I think) MediaSoup have it. But I've not yet seen a pion-based implementation of congestion control and I'm hoping that LiveKit has fixed that. But I can't find it.

That's a well written article covering the basics of simulcast.

If you're interested in seeing an implementation of an SFU doing simulcast forwarding written in Rust, we (at Signal) recently open sourced our SFU:

https://github.com/signalapp/Signal-Calling-Service/blob/mai...

We rotate the keys whenever someone joins or leaves, although the mechanism is more efficient when someone joins than one someone leaves.

I don't think we've made the SFU repository public yet, so I don't think I can comment on that yet. Likely I'll be able to in the future.

I work at Signal on group calls. We're being careful with rollout. The limit will hopefully be increased soon.

I work at Signal and wrote much of that code, so I'm familiar with it :).

Yes, it uses a server for media distribution and uses encryption keys that the server does not know.

You don't need to use STUN and TURN for client->server use cases, but you do need ICE, DTLS, and SCTP.

That's in a separate doc. Search for "RTCQuicTransport".

If anything, an increase in the use of QUIC will reduce the amount of UDP blocking, which would be good for WebRTC.

There pain point is running ICE, DTLS, and SCTP on the server.

The effort to bring QUIC to WebRTC is the kind of the same effort. The WebTransport is an outgrowth of that effort. They are not unrelated.

As for "too many protocols": QUIC is already in the browser. This is just giving you an API to it. Think of it like WebSockets for the HTTP3 world.

I did a presentation last year that sort of answers that from a gaming perspective (gaming was the topic of the workshop):

https://vimeo.com/350908362

Why not just use ICE connectivity checks? That's what they are for.

And I have proposed additions to the WebRTC API to allow control of when ICE checks are sent and how long a particular ICE candidate pair should stay alive (you could set it to "forever"):

https://github.com/w3c/webrtc-ice/pull/22

Hey, I used to work on this :).

It's complicated :).

Basically, WebRTC is a combination of a bunch of protocols: ICE, DTLS, SCTP, and RTP. You could theoretically reduce that to ICE + QUIC for p2p use cases and just QUIC for client/server use cases.

For p2p, there is RTCQuicTransport (see https://developers.google.com/web/updates/2019/01/rtcquictra...)

For client/server, there is QuicTranport (see https://web.dev/quictransport/)

Of course, you'll probably want to be able to encode and decode some audio and video as well to make that useful. For that, there is WebCodecs (see https://github.com/WICG/web-codecs or https://www.chromestatus.com/feature/5669293909868544)

For use cases like live streaming and cloud gaming, I did a presentation about the combination of WebTransport + WebCodecs: https://www.w3.org/2018/12/games-workshop/slides/21-webtrans...

And then there is the work happening in the IETF along these same lines: https://datatracker.ietf.org/wg/ript/documents/

I recently read through a the code bases of a bunch of these, and I would add several to the list:

https://github.com/jitsi

https://github.com/pion/ion

https://github.com/peer-calls/peer-calls

https://www.irif.fr/~jch/software/sfu/

Out of those, it seems Jitsi and Mediasoup to be better as SFUs than the rest because they have what appears to be decent-looking congestion control, bitrate allocation, and support for simulcast. The rest apparently do not (at least I couldn't find anywhere in the code where it happened).

Also interesting to note is that so many of the newer ones are written in Go based on Pion. If Pion ever gains the ability to do decent congestion control (perhaps based on transport-cc like Jitsi and Mediasoup do), that could improve things for all of those.

I work on calling for Signal, and the last few months we have been working on desktop calling. It's nearly ready and will hopefully be in public beta in a matter of weeks, and (again, hopefully) fully available in a few months.

I work at Signal on calling.

Non-group desktop calls are coming soon (hopefully hitting beta in a few weeks).

We're working on desktop group calls as well. That will take a bit longer, though. I don't have a good estimate of when it will be available

I work at Signal on video calls, and we're working on adding video conferencing so that Signal can be the "Signal of video conferencing".

Disregarding non-IP candidates is exactly what we've chosen to do (and which the new versions of the app do).

The downside of disregarding all candidates until the call is accepted is that post-accept connectivity would be much slower.

Going through a server to hide your IP is an option in the settings in the app, but it can potentially lead to higher call latency, so there is a trade-off.

To prevent issues like this in the future we are taking more control of WebRTC's behavior with a fork of WebRTC (Signal uses WebRTC) and are providing patches to upstream WebRTC as well.

(I work at Signal on calling)

I work on calling at Signal. If Signal worked for calling your dad in India, would use it instead of Duo? If so, would you mind helping us improve it by providing feedback for new builds and that sort of thing? If so, email me at peter@signal.org. Detailed feedback from you might help a lot.

Yeah, I was just trying to point out that there is a feature vs. privacy/security tradeoff. Although I think e2e encryption is usually much more valuable.

Lots of video conferencing systems already work this way (the SFU way). Compared to just sending the full resolution all the time, adding the smaller resolutions doesn't add that much bandwidth and compression because they are so much smaller.

It depends on what you mean by "WebRTC". There's the mobile/native library (at webrtc.org) and the standard (at https://www.w3.org/TR/webrtc/). The library does support it (although you have to write your own signaling and media forwarding server). The standard does not (yet). But it's being worked on ine the W3C (for example, Insertable Media Processing like this: https://www.w3.org/2019/09/18-mediaprocessing-harald-inserta... or something more low-level like this: https://github.com/WICG/web-codecs/blob/master/explainer.md).

But the web standard not being there yet doesn't prevent someone from making a mobile or desktop app with e2ee conferencing, like Duo does: https://support.google.com/duo/answer/9280240?hl=en.

(I used to work at Google on WebRTC, Duo, Hangouts, and WebCodecs, but now work on video calling at Signal).