(Jitsi Dev here) Yes you are correct. Cookie delete is indeed something that would trigger a new user count. So far we haven't seen this happen but if you believe your users would be massively cleaning cookies, we are happy to have a conversation and find a work around for you.

FWIW, me and my team would likely be super into paying for a hosted Jitsi if there was another pricing structure. We run our own but keeping it running smoothly takes away dev energy. Counting usage like this just seems very ripe for abuse by anybody who wishes to harm the group.

Please do reach out to us, we just got started and are happy to discuss.

Do consider pricing on the peak number of simultaneous streams (like Pusher.com does)

(Jitsi Dev here) Most of our customers are actually developers and that's how the service is intended. Hope this helps

Signaling is indeed over HTTPS and media is encrypted with DTLS-SRTP. No browsers today support end-to-end encryption for multiparty calls. The advantage that Jitsi offers there is that you can stand it up on your own server in just a few minutes and get protection that is equivalent to end-to-end encryption.

Coincidentally, the edit I made to my comment is nearly identical to your comment. But now I’m outside the 1 hour window of being able to edit.

To be accurate: no tool that relies on webrtc is end-to-end encrypted. So, no, it isn't. It is encrypted on the wire, just like the other tools mentioned here.

Are you saying that the developer's claims in this issue discussion are wrong?

https://github.com/nextcloud/spreed/issues/37

He says that video/audio in calls are end-to-end encrypted when the server is using the default PHP backend, but not the high-performance backend (an optional paid and proprietary enterprise upgrade).

> video/audio is already end-to-end encrypted

> By default with the internal signaling backend audio/video calls (no matter if 1:1 or group) are end-to-end encrypted.

> and without the HPB its always paar-to-peer [sic] and therefor end-to-end encrypted.

> Chat is currently not end-to-end encrypted, only the audio/video of calls are.

Someone mentioned Jitsi's statement and the developer responded:

>> But I don't understand why the Jitsi people write, "WebRTC today does not provide away of conducting multiparty conversations with end-to-end encryption." That would only be true if I decided to use an additional HPB solution, wouldn't it? But not out of the box.

> Exactly, I guess for better user experience and performance they have a SFU or MCU in place (our HPB is an SFU), and therefor it stops being end-to-end encrypted

Jitsi Videobridge has both of those.

Jitsi only does the audio portion. There's no support for layouts/video mixing.

"Jitsi Videobridge does not mix the video channels into a composite video stream, but only relays the received video channels to all call participants."

Joe, this is actually not true. At least not for Jitsi where we have things like last N and possibilities to have 1:m or n:m sessions ...

There's also absolutely no usage of SDP Offer/Answer in Jitsi Videobridge