[beanjammin]

Interesting, I haven't tried Jami. If I am understanding it correctly it seems to provide calling features, which Zoom and other typical video conferencing type applications don't.

I'll also through Jitsi out there as a very capable FLOSS alternative to Zoom. If you tried it a few years ago it's changed dramatically in the last while. It's now WebRTC based and runs in browser without any download. It's not quite end to end encryption because the stream needs to be decoded on the server before being re-encoded for the other clients, but since you can easily self host it on a cheap VM I find this acceptable.

[sk7]

Jitsi does not re-encode video streams on the server, it's a SFU (selective forwarding unit) and just forwards (some) video streams to the other participators. When Simulcast is enabled, multiple resolutions of your video are streamed to the Jitsi server and it only sends those streams to clients which they asked for (participants can choose the quality of video they receive, in the UI)

[divbzero]

Can’t WebRTC support peer-to-peer video calls without running the stream through a server? I have vague recollection that it can but am not particularly familiar with the protocol.

[divbzero]

To answer my own question: Yes, WebRTC supports peer-to-peer video calls but does require a “signaling server” to help establish and close the peer-to-peer connection. [1]

[1]: https://www.html5rocks.com/tutorials/webrtc/basics/ "Getting Started With WebRTC"

[littlestymaar]

The signaling server is only useful for the connection initialization though, and it never has access to the video stream, only to metadata (like your IP address, the supported encodings of each party, etc.). And it doesn't even really need to access them: it just needs to forward them from one peer to another, so it could be end to end encrypted.

It also needs one or several STUN servers as part of the hole punching scheme, but this one doesn't even exchange anything with anyone, so there aren't many issues here (and you don't need to roll your own: you can use Google's one)

[tincholio]

It does, but when the number of users is >2, typically you will go through a TURN server.

[kelnos]

TURN doesn't have anything to do with number of participants; it's there for when NAT hole-punching completely fails and you need a relay. TURN is application-protocol agnostic and just forwards packets; it does not need to decrypt whatever it's relaying. Now, one could run a malicious TURN server that MitMs connections, but I'm not sure how obvious that would be to the end-parties.

For more than two users, you mainly have three options:

* MCU (Multipoint Control Unit), which IIRC does need to decrypt your video, as it will post-process it and possibly re-encode it to send a single stream to the other participants.

* SFU (Selective Forwarding Unit), which in theory doesn't need to decrypt your video, but does need some metadata about it in order to make smart decisions as to what streams to forward to whom (for example, forwarding only the stream of the person who is talking). In practice, I believe some (many?) SFUs will do decryption, thought it's not a strict requirement.

* Dumb peer-to-peer-to-peer-to-... multi-forwarding. You can of course theoretically stream your video to each other participant, and they can all do the same, but that quickly fails to scale. It might be ok for three, maybe four participants, but even then there will likely be problems.