4 fine up to 4 users [b]
5 fine with video; up to 20 audio only [f]
>5 performance gets problems [a]
50 seems to work with high performance backend [f]
8 fine, few crashes [c]
19 fine with students [g]
45 worked well, some issues with slow internet. It can handle much more users if users muted & turn off video [d]
>100 for presentation; complicated if >25 users use video [e]
See reply for sources
Sources for BigBlueButton and NextCloud Talk: Performance & Maximum Users
Additionally, here also some information in the #BigBlueButton FAQ:
"How many simultaneous users can BigBlueButton support?"
* BBB "server should be able to support 150 simultaneous users, such as 3 simultaneous sessions of 50 users, 6 x 25, etc."
* "We recommend no single sessions exceed one hundred (100) users."
@gerald_leppert What are the specs of your hardware?
@sphyphes I compiled the information on performance of Jitsi Meet, BigBlueButton and NextCloud Talk from several sources. Please see the conversation of the toots for the links.
I have seen but not tried Jami, because I have read about connection, video & audio quality issues. What is your experience and what about performance/users of Jami?
Thanks for pointing to the webrtc leaks issue. As far as I understood the issue, any other website can identify the IP adress. It is less an issue if the webrtc server can identify the IP address which it needs for p2p webrtc anyways, Is this correct?
If so, a Firefox addon could help such as https://addons.mozilla.org/de/firefox/addon/happy-bonobo-disable-webrtc
I think there's a bit of confusion around #webrtc leaks.
Either you are having a video call where you want best connection quality and shortest path to your peers, in which case you want to communicate directly, obviously revealing your IP just as you reveal it to the the server.
Or you want to hide your IP for anonymity, but then you're using Tor and definitely not having video calls with people and don't care about shortest path.
Different usage scenarios...
In a quick search, I found this regarding the performance and number of participants in Jami video conferences:
It depends on the internet/computer of the host. The master/host needs 1Mbps per participant to get a good quality. For participants 1 Mpbs is enough.
This user mentions that "We have tested with up to sixteen members but it could potentially go higher"
@gerald_leppert Yes, that's true. I experienced this first-hand today, after a session where I experienced some problems. Mostly problems with audio lagging, though. Wired connection for the host will hopefully do the trick.
I'm no expert in #webrtc protocols as such. But, yes I believe you're right. However, if you're using a #vpn, the server shouldn't (need to) know you're real IP. But by using/enabling webrtc, that could still happen. Finding trustworthy instances is therefore important. Or self-hosting.
@vcrkhl Thanks. What is the number of participants in a Jami videoconference, where you still can have stable audio and video?
@gerald_leppert I don't actually know, and haven't seen any official documentation about that specifically. But based on my own testing and real-world usage, I'd say audio will work equally as good as #bbb, #nextcloudtalk and #jitsi. Don't know for sure about video. #jami seems to be a bit more demanding for any device to run. It's quite power hungry. So, performance with, say, 5+ participants might depend a lot on everyone's hardware (and connection, of course), not least the host's.
For video conferences, we recommend 4 for now. The thing is there is no conference management (split streams/mute someone/raise hand) for now. We can handle more, but the grid is ugly.
For the bandwith, the master will need 1Mbps up/down per participant to get a good quality. Peers needs 1Mbps up/down because the stream is mixed by the master
@AmarOk @gerald_leppert Also: great work on #jami! It can be a bit buggy outside of GNU/Linux, though. One minor, but reoccurring, thing is that it won't shut down properly but need to be force shut. In my experience it seems also to be a bit unstable during videoconferences. But I'm guessing that's been caused by the peer's connections. Reconnecting has most often solved it.
But overall, I'm so glad it exists, especially in times like these. Really hope more people get to learn about it.
About , quit. Or in general settings, disable the systray option. Elsewhere the close option acts like minimize.
Finally, for video conferences, we did a lot of patches recently. So be sure to use latest version. However there is still some issues (with audio mainly). Any bug report with reproductive steps as precise as possible is welcome (via https://git.jami.net if possible as I am not a bug tracker soft)
I'll try to make sure that everyone I conference with use the latest version!
And yes, I thought about filing a bug report, but the problems I've experienced have occurred on and off, and seems to primarily depend on the participants' setup. But I'm not sure. Will try to pin-point the problem!
@gerald_leppert By the way, great work compiling sources and info about some different videoconferencing applications. 👌 💚 I was doing something similar myself, with the intention of publishing on a basic web site (haven't done that yet, though). I mostly gathered info/experiences about basic functionalities, requirements, and security/privacy. Just wanted to let you know, in case that might be of interest or help to you.