Adventures in Video Conferencing Part 1: The Wild World of WebRTC

You'll escape that by getting specialized hardware. There's just too much broken stuff on the PC. (There was once that thing that become widespread, people used to call them "telephones". Nobody has them anymore, what's a shame.)

Anyway, I don't really get what problem WebRTC solves, except for the non-problem of having to run specialized software on the clients. Instead it adds another set of broken mic settings...

you should try zoom or bluejeans, it's been extremely stable and consistent for us, we do conference calls from behind china's great firewall to palo alto with little to no lag, even has HD video.

https://github.com/jlaine/aiortc may be a better option than janus. It's a much simpler to use implementation and is python.

quick summary of the acronyms... STUN/TURN/ICE are all related to NAT traversal (ie. when you are behind a router or firewall of some kind and your computer's IP is different from your public IP). The reason you need this is because UDP is not connection-based like TCP. So STUN is a service that helps your computer find its public IP. ICE is a protocol for finding and reporting peer candidates (after they've learned their public IPs via STUN) so they can establish a peer-to-peer connection. TURN is when you reflect the connection off a public server instead of establishing a peer-to-peer connection.

SDP is session description...basically information on what media formats and other things each client will accept.

RTP is how the media (or other data) packets are framed RTCP is out of band reporting for things like packet loss and other info so that each side can adjust media properties

The nice thing about WebRTC is it takes care most of this stuff for you. If you're always connecting to a server with a public IP you'll just need a few things:

1) WebRTC server that can accept media data (like janus or aiortc) 2) Some signalling mechanism, Websockets work well for this 3) you _may_ need a STUN server, google has stun servers available but you could also use coturn for this.

The rest you shouldn't need to worry as much about because webrtc handles it all under the hood

This might be helpful for your project https://janus.conf.meetecho.com/

"ICE tries to find the best path to connect peers. It tries all possibilities in parallel and chooses the most efficient option that works. ICE first tries to make a connection using the host address obtained from a device's operating system and network card; if that fails (which it will for devices behind NATs) ICE obtains an external address using a STUN server, and if that fails, traffic is routed via a TURN relay server." (1)

Turn just proxies all the data instead of being p2p. p2p has to overcome NAT, which is why ice and stun exists. If it can't be p2p it'll be turn.

"STUN servers live on the public internet and have one simple task: check the IP:port address of an incoming request (from an application running behind a NAT) and send that address back as a response. In other words, the application uses a STUN server to discover its IP:port from a public perspective." (1)

[1] https://www.html5rocks.com/en/tutorials/webrtc/infrastructur...

It also took me several years to get up the gumption to actually learn WebRTC after having previously used wrapper libraries...

And it is annoying, but you can get the stab of it within a week or two. The most confusing thing is figuring out setRemoteDescription vs setLocalDescription - that took a bunch of playing around to finally get it to work.

All said and done, we were able to write a WebRTC adapter in less than 100LOC[1], and it is capable of doing inter-network signaling once peers have established connections. And the "signaling servers" that bootstrap non-WebRTC peers, those servers themselves can be decentralized as well.

If you don't want to deal with the fuss of it all, I highly recommend using EasyRTC, and/or studying their code to learn more:

https://github.com/priologic/easyrtc

[1] https://github.com/amark/gun/blob/master/lib/webrtc.js

I felt similarly when I’ve looked into it in the past. My suggestion is to just take a day or two and do a deep dive, use tutorials and it will all get better. Maybe not what I would have wanted to hear but after crossing the chasm to where I understand those things now it doesn’t seem like it was too much. It was just more than I expected from what I saw as a simple browser feature. The thing is that there is a lot to p2p communication when you consider local networks sharing the same up address, firewalls etc... Not just that but how to fallback when someone is behind a network that essentially blocks p2p. WebRTC is somewhat of a low level API that lets you navigate these waters but it expects you to do more work than I initially expected.

If you are more interested in a plug and play solution I’ve heard good things about https://tokbox.com/

Maybe they listed the highest market share? I didn't look but I wouldn't be suprised if these have the biggest. In order, too.

Or maybe they just listed the ones they use. If I did the same, it would look _very_ similar.

Maybe they want to be beyond suspicion of self-dealing.

Zoom's solution seems to be clunky software that works worse than Jitsi.

Zoom doesn't use WebRTC (which the article is about). They use websockets to send media through the pipes and decode using a webgl shader or similar.

I don't work for Zoom, but do work in the WebRTC space and read an article about it recently.

Anybody with the number can join your Zoom meeting and since there's very little indication of their presence you might not even notice. You can also command other people's rooms to join your meeting, if you can figure out how to contact them, and you can force their microphones to turn on, which in my opinion is pretty disturbing.

> in a conference with 80+ people

are that kind of meetings really useful by videochat ? Even in real life it's a pain.

GSuite customers can use Hangouts Meet, which should be better.