webrtcHacks

We started our journey with Janus about three months ago and I can just fully recommend it. It is an amazing well-written piece of software which is just as flexible and integrative as developers wish. E.g. Slack used Janus, at least in 2016 [0]. It is important to understand: Janus offers the ingredients for building great WebRTC applications (examples [1]), whereas Jitsi is more like a ready-to-go solution and got much more attentation as Janus did.

Lorenzo and his colleagues are doing a really great job.

In the space of SFU/MFU, one really needs to decide beforehand what kind of solution is suitable for which requirement. I have chosen Janus because we could integrate it by 100% in our software. For example, I was also looking into Jitsi. But compared to Janus it feeled so much more complicated and not suited for that specific job.

However, it is important to point out, that this is no a ready-to-go solution. There is a long list of things you will have to dig into:

- ICE (a way to connect if you switch between WIFI and LAN or to punch a hole into your fw) [2]

- Cross-browser compatibility (Thank you iOS [4])

- TURN/STUN (Which matrix of udp/tcp and ports is needed for Hole Punching?), I recommend coturn.

- Scalability: How many clients are planned? In my experience, CPU and bandwith are bottlenecks, we went with horizontal scaling

- How do you gonna test your WebRTC application? So far great results with https://testrtc.com, but you probably also could accomplish…

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.

https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/
For STUN/TURN

https://docs.bigbluebutton.org/support/faq.html
For implementation details like average network usage and storage and other things

http://www.aosabook.org/en/jitsi.html
Outdated but seemed the most relevant so had to include

https://webrtchacks.com/sfu-cascading/
By a jitsi dev apparently

I'm no expert but have gotten into this whole thing trying to get one set up for my university.
One problem I've come to find is that no one seems to discuss about is the total network usage if you are hosting this on cloud. The egress on this seem bankruptable on any of the major cloud providers. How are people doing self hosting if they don't have an idle Intel xeon on prem?
Where else can I get affordable egress pricing on ~35 TB/ month / 250 users?

There was a bunch of abuse that already happened with host candidates, was fixed recently though! [0] Tor also did a bunch of really great work figuring out all the ways you can be fingerprinted.[1]

When I shared [2] a lot of people gave me flack for enabling malware. I don't come from that background, so hard to think 'how can people abuse this technology'

It is too late now to roll back all the WebRTC stuff in the browser now though :) Definitely would be mind blowing how much data is flowing because of it (and how much money is being made because of it).

[0] https://webrtchacks.com/dear-ny-times/

[1] https://trac.torproject.org/projects/tor/wiki/doc/Snowflake/Fingerprinting

[2] https://github.com/pion/offline-browser-communication

Actually, if you are using 4+ rooms, we will in many cases be better than some other webrtc services because we for these bigger rooms use a server in the middle to distribute all the streams. That will result in lower resource use. You only encode and send once, and it is distributed by the server. But if other webrtc kills CPU on 4 or less, we probably won't be much better.

This "more than 4 room" is not p2p and end-to-end encrypted, since the server (SFU) needs to read and change some headers. So it is a tradeoff. There's now "insertable streams" which allow you to do encryption on the media client side, but it's a test for now: https://webrtchacks.com/true-end-to-end-encryption-with-webrtc-insertable-streams/

You are wrong. This is the current state of webrtc.

Without considerable hacks (patent-encumbered unaccelerated wasm ffmpeg encoding of pixel data, rolling your own SRTP-like encrypted stream over datachannels and full mesh distribution of keys) this is not currently possible for anything other than a full mesh. Whenever an SFU (effectively a MITM) is involved (needed for more than a small number of participants) e2e encryption is lost.

If/when Insertable Streams are commonplace, this will be possible without so many hacks.

Edit: I see I was downvoted for correcting you, but there was an article on this very subject yesterday: https://webrtchacks.com/you-dont-have-end-to-end-encryption-e2ee/