Maximum number of participants on a meeting on meet.jit.si server

You can host your conference with 100+ people, but watch out the bandwidth and the CPU consumption. Memory Consumption is not a big one to watch out …

You can also set a limit on the number of users in the conference with muc_max_occupants

1 Like

Thanks for responding…
Yes the CPU & Bandwidth are in check…

But i’ve still not got how to limit the users… can you share any doc… or steps here by which i can limit the muc to certain number…

Thanks

I will be launching my first webinar with JitSi on Monday May 4th with 25 participants. I will give you some feedback…

1 Like

Share the location where we can increase the limit.

can you share image or complete path for the same.

Thanks for sharing the experiences guys. I am planning a conference fpr 120 folks and I am hoping it will work well for them.

Also a point to note- when changes are made to /etc/jitsi/meet/*-config.js, the service will need to be restarted to ensure the changes take effect. For the most recent Ubuntu 18.04 quick installation this is:

  • sudo systemctl restart prosody.service
  • sudo systemctl restart jicofo.service
  • sudo systemctl restart jitsi-videobridge2.service
2 Likes

with 120 people do follow the advice of @srinivas and start all participants with audio and video muted and lower the video resolution.

By profiling the JVB server we have noticed that it is configured to do some excessive logging, that takes the server down when load increase, you can disable the JVB server logging and improve JVB server performance by changing the following in /etc/jitsi/videobridge/logging.properties

much of the excessive logging on the JVB server started to appear when end users are overloaded so you may want to recuce the load on the clients as well by performing the following tweaks:

7 Likes

Hi damencho, a question about octo configuration, i have a setup with a machine where is installed full jitsi-meet and two other machines with jvb installed respectively communicating in MUC. So far so good, if i want to implement octo the configs exposed in your tutorial must be made in the JMS server only or also in other JVB? I mean the video-bridge config where you call:

Hi, all JBV servers need to be configured.
Milan

is this limit per bridge?

We are targeting a 300+ participants conference (webinar style).
For the moment we have stack a bunch of massive servers (64 cores + 256g) configured with OCTO and MUC.
The prosody server will be even bigger as we only plan for one for this time.
Most of the participants will have their video off, audio off.
Any other recommendations?

To the community: happy to share our experience once done.

6 Likes

Hi, how many servers are you using as JVBs?

I have about 12 servers in 4 zones (not all the zone have the same amount of servers)

:slight_smile: nice. Are you using VM to share 64 cores? It seem good strategy is to do as many as possible VMs with 8-12 CPU 12-16GB RAM each. I was able to make 80 participants presentation on one JVB, all CAMs an MICs off but presenters. I haven’t tested OCTO splitbridge strategy yet, maybe tomorrow.

1 Like

sounds like a good architecture too. I’m more brutal for the moment.
We should compare our results to see which strategy is better. I think that your approach makes a lot of sense too. Especially if a system crashes, you are impacting a lower number of users.

1 Like

Failover works fine, and after switching to JDE8 we had not a single crash. :slight_smile:

1 Like

Hi @migo - I’d be interested in hearing how your SplitBridge test goes. I’ve done testing in the last few days with SplitBridge strategy and it seems to work - users are split over two regions, but the video quality is low as soon as we hit 3 users (probably p2p turning off), as if it is only using the thumbnail stream. Also the E2E RTT stats are failing, so I’m almost sure its some sort of misconfiguration on our part. Still debugging.

Hi @blivingston, I’ve setup octo just now. When using bind_address=10.10.10.x it doesn’t work = only people on the same JVB can see each other, like we had two separate conferences with the same name.

Changing bind_address to public address resolved this problem, I thing it is because jicofo uses public addresses for relayId:

Jicofo 2020-05-12 20:51:20.155 INFO: [30] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Creating an Octo participant for Bridge[jid=jvbbrewery@internal.auth.domain/6e01078b-a171-4213-b0ef-c82aa89e6d1b, relayId=19.x.x.15:4096, region=UK, stress=0.01] in JitsiMeetConferenceImpl[id=ff0dd8, name=migo@conference.meet.domain]
Jicofo 2020-05-12 20:51:20.155 INFO: [30] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Creating an Octo participant for Bridge[jid=jvbbrewery@internal.auth.domain/0b4864ed-b468-4760-b358-19d4d8b40fb4, relayId=19.x.x.9:4096, region=UK, stress=0.21] in JitsiMeetConferenceImpl[id=ff0dd8, name=migo@conference.meet.domain]

Is it same for you, or you have working it properly with local addresses? We had 6 video participants an video quality was satisfactory I think.

Thank you,

Milan

jitsi session password is valid till the session is going on. Once it end the password is removed… During session a participant can add/remove password. it will be problem for other participant. jitsi have not a host/administrator power. jitshi have not a pre-planning (schedule a meeting) rights.
So overall security is not good of jitsi.

Thank you @migo - I’ll try with the public address for the bind_address.
Interestingly, I discovered that with Octo completely disabled we were still getting the low-resolution video, so it seems that might be a different issue.

Hi @blivingston, it sounds familiar to me :slight_smile: I think your connection to control channel of JVB is not working! Run developer console in browser and look at errors there.

Milan