BlogGeek.me

ok I didn't know that this was john nagle. that's intimidating.

i'm still highly alarmed, both by John & the general level of discourse going on all throughout this thread. i posted replies to a number of others too. there is wild unsubstantiated & mean-spirited speculation running rampant through this, imo, good news. no one talks to how or why they think this is going to help spy on us, or reduce our ability to block ads, yet it's a very popular & trendy opinion. it seems widely assumed that this is all for bad, and everyone seems to want to believe that mis-information.

i find it distressing that the world would be so paranoid & crazy as this. after years of IETF hard work & discussion, after countless engineers work tirelessly to maximize privacy & security, after countless points are raised & tackled, the world greets what we think is a real & significant improvement with disdain, distrust, & belittling. this feels like the kind of easy-to-spread paranoia & madness that is part & parcel to the disinformation that has grown a threat to civil order, a threat to reason. it's too easy to knock things down[1], done so casually, & people seem to want to hear it too much. i realize i haven't been helping, haven't been waging an effective campaign to try to promote a healthier course for us, better discourse, but i want to. i want to not be overwhelmed & saddened by unsupported unreason.

touching back to @animats' post:

> The real motivation is probably to merge ads into…

Zoom also use the Selective Forwarding Unit (SFU) architecture. Or a central server that kind of "mix" streams and send them to all participants, if you will.

Jitsi Videobridge does this by receiving simulcast streams from each participant. This server individually picks out streams and qualities that will fit in each recipient's downstream pipe based on measured bandwidth and configured priorities (e.g. you could choose to give more bandwidth to those who are actively speaking, or shut down all but the last N speakers video streams).

Yes, the available network bandwith on a Jitsi Videobridge could be a bottleneck. Each meeting need to fit on a single bridge instance. However, using common servers connected at 1 Gbps or 10 Gbps, it shouldn't be any problem to have meetings with substantially more than 2-4 people. Say a HD stream from most webcameras outputs 3 Mbps at full blast, with 50% overhead due to the simulcasting. That's over 2000 participants on a single server connected at 10 Gbps, all receiving all video streams in full quality.

For meetings with 2 participants the streams run peer to peer, so here you get the best possible latency and quality.

We've set up Jitsi on a VPS instance at a nearby provider, and have not seen any problems with meetings of 10-15 people. Stability and performance also outperforms all the other solutions I've tried. There's currently a bug in Firefox's simulcast implementation, so if you have any participant using this browser, this…

Thanks! It's true that on a 2 or 3 call participants P2P almost always ends up having better performance. But the problem comes when you try adding more participants.

The limiting factor is that on a P2P mesh with N participants, each participant sends its stream to all other participants (to N-1 destinations) and receives the stream from all other participants (receives N-1 streams), which incurs on more network and CPU requirements.

When we go above 4 participants the call model changes to Single-Forwarding-Unit (SFU) where there is a central server that dispatches the different streams to each user. That way, each participant would only upload their stream once, and download N-1 streams back. This server may also apply some other optimizations. You can learn more about P2P limitations from this blog post. [1]

That said, as this CoBrowsing experience is not as bandwith intensive as a 30fps high-quality video, we can afford to use P2P with more than 4 participants.

[1] https://bloggeek.me/webrtc-p2p-mesh/

Edit: btw, we use daily.co for the video and audio part of our product. They abstract very well all the complexity related with real-time video and audio.

I do a significant amount of work with Hospitals and secure environments (Military, etc). TURN is needed 100% of the time. P2P traffic is not allowed. All IP addresses need to be known and kept static upfront for firewall whitelisting.

This means products which help alleviate WebRTC infrastructure such as AWS Kinesis are not allowed (due to how they allocate turn servers with unknown IP addresses) and a company needs to manage their own infrastructure / TURN servers (which allows you to cherry pick where server locations are (HIPAA, country legal for what is streamed)) or accept Twillio's, or their competitors etc, large IP ranges (and don't have server location flexibility / increased commercial and market growth restrictions).

Whichever route you go down it is quite an undertaking!

P.s. Tsahi Levent-Levi is truly exceptional in this area. I highly recommend reading his blog and training courses: https://bloggeek.me/, https://webrtccourse.com/, AND he runs an amazing testing product https://www.testrtc.com. if you build your own infrastructure testRTC is a must.

Why is the web client (on Chrome, etc) so bad on Zoom ? I mean, people are building Google Earth on the browser .Its not just the bad video experience - even the product experience is seriously broken.

For example, the default audio setting when you sign in to the web video client is to connect using PHONE AUDIO. In case you figure out how to click the tab to use computer audio...it breaks down a couple of time in asking for browser permissions (camera, mic). It is unusually bad for something that is supposed to be that good.

there are all these articles about the comparisons - https://webrtchacks.com/zoom-avoids-using-webrtc/

https://bloggeek.me/webrtc-vs-zoom-video-quality/

hangouts still rules when it comes to web based video conferencing. And for countries with massive linux based usage (like India), Zoom is not a very viable option.

Indeed, Jingle is for establishing connections, P2P when possible, but there are lot of extensions around it.

I've proposed a specification for SFU hosting (check https://bloggeek.me/webrtcglossary/sfu/ if you don't know what's a SFU), and wrote a component based on the excellent Galène SFU, as well as client implementation (in Libervia) as part of a NLNet/NGI grant (https://nlnet.nl/project/Libervia-AV/).

XMPP council (disclaimer: I'm a council member for the current term) asked me to some modifications and to re-propose, which I'm about to do. I couldn't find the time so far (cause I'm working on ton on stuffs), but will go back to it very soon.

To sum-up: this is very much worked on.