pthatcherg

9 ms·

31.
by pthatcherg 5y ago
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.
32.
by pthatcherg 5y ago
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.
33.
by pthatcherg 5y ago
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.
34.
by pthatcherg 5y ago
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.
35.
by pthatcherg 5y ago
Author here. It's on the long list of things to do, yes. But we have many things before it on the list :).
36.
by pthatcherg 5y ago
Author here. The server doesn't know who is in the call. It can't build any graph.
37.
by pthatcherg 5y ago
Author here. MediaSoup was one of the two SFUs that did seem have congestion control at the time. Sorry if that wasn't clear.
38.
by pthatcherg 5y ago
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
39.
by pthatcherg 5y ago
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
40.
by pthatcherg 5y ago
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:/&#x2
41.
by pthatcherg 6y ago
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
42.
by pthatcherg 6y ago
I work at Signal on group calls. We're being careful with rollout. The limit will hopefully be increased soon.
43.
by pthatcherg 6y ago
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.
44.
by pthatcherg 6y ago
You don't need to use STUN and TURN for client->server use cases, but you do need ICE, DTLS, and SCTP.
45.
by pthatcherg 6y ago
That's in a separate doc. Search for "RTCQuicTransport".
46.
by pthatcherg 6y ago
If anything, an increase in the use of QUIC will reduce the amount of UDP blocking, which would be good for WebRTC.
47.
by pthatcherg 6y ago
There pain point is running ICE, DTLS, and SCTP on the server.
48.
by pthatcherg 6y ago
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
49.
by pthatcherg 6y ago
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
50.
by pthatcherg 6y ago
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
51.
by pthatcherg 6y ago
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&#x
52.
by pthatcherg 6y ago
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&#x2
53.
by pthatcherg 6y ago
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.
54.
by pthatcherg 6y ago
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 whe
55.
by pthatcherg 6y ago
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".
56.
by pthatcherg 6y ago
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.
57.
by pthatcherg 7y ago
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@s
58.
by pthatcherg 7y ago
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.
59.
by pthatcherg 7y ago
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
60.
by pthatcherg 7y ago
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 hav

More ›