Maximum number of participants on a meeting on server

Will it be available on as well?

Yes, we are working on adding it to

Hey @damencho was just wondering where exactly this limit is set and if it’s still 75… Thanks!

For this is 100 at the moment.
This is setting a value of 101, here: jitsi-meet/mod_muc_max_occupants.lua at master · jitsi/jitsi-meet · GitHub
And whitelisting the transcribers and jibris.


@damencho - is this the same for custom deployments?

So my server, which hosts 5963 as of now without any changes to the internal components (mucs) can host up to 100 participants only per meeting ?

This module is not enabled by default. So basically your meetings are unlimited and will start to break down when your resources are not enough, normally the CPU of the prosody process hits 100 or the jvb hits the sky. To be able to host more people in one conference, you need OCTO and this why if a jvb starts to be overloaded a new one will be used for the rest of the participants.

1 Like

@damencho perfect! as of now, I am working on something like Multisharding + OCTO. I guess this is achievable.

Also a small question, using the module, how do we set the max number of participants to any x number?

I mean where do I add the x value in this line ?

local MAX_OCCUPANTS = module:get_option_number(“muc_max_occupants”, -1);

In prosody config.

any updates about the maximum participants at the same session audio/video ?

We are testing currently with 300 video senders and everything looks fine.


@damencho What is the server configuration(CPU and network) you are suggesting for 100 users?

Today we had a voice conference with 250 participants and all was pretty fine and with good quality (clear voice).
Some of organizators told me that in moment there was 350 participants, but it was a bit luggy.
But there also was a huge CPU load on a client side (Chrome and Electron app)
Jitsi team need to do something about that, @damencho


We’re now running our load tests at AVStack up to 300 video senders in a single conference regularly and it’s working really well thanks to recent Jitsi Meet updates.

You can avoid high client-side load by making sure the clients are not doing unnecessary work like decoding video streams that will not be visible or audio streams that will not be audible. In large meetings, a lot of the client-side load is coming from the browser’s WebRTC stack and audio & video codecs, not so much from Jitsi’s signalling.

For video, if you are using a custom frontend, make sure to signal which streams are visible. We often see custom frontends where this signalling is not being done properly and the client is wasting bandwidth receiving video that is not on screen and potentially wasting CPU cycles decoding it too.

For audio, consider using the route-loudest-only feature that was recently added to JVB to avoid forwarding audio packets for all but the N loudest speakers. Unfortunately there’s no support yet for signalling explicitly which audio senders you want to receive, which would be useful for some applications where you want to forward some set other than just the N loudest. I filed an issue about that and it’s on our roadmap to implement it if nobody beats us to it.


Thank you very much for your comment @jbg !

That’s sound awesome, think we need to set it up!

No, we are on vanila Jitsi meet. Clients are Rocket.Chat electron app, Chrome 92 and Rocket.Chat ReactNative mobile client.

Really nice to see comments like this! That means Jitsi team did a great job in performance for large calls.

This has proved to be bad news. Maybe upgrade to 93 and try again?

1 Like

Thank for that information, @Freddie !
Actually we started to deploy Chrome 93, so, I guess it will be standard for us in a week or so.
But anyway, majority of our Jitsi users use Rocket.Chat Electron app, which is on Chrome 91 I guess. And that update is only available on their side. And RC.RN same case.

In march 2020 we see

and now in September 2021 with stability for hundreds mostly audio and testing of 200 with video which suggests the reiterative approach and sharing of experiences means not only a BIG thank you, but take a collective bow for the advances seen here.

Nothing like a global disaster to see just what makes humans (who care) great !


Is this on default

Hi, We had tested the maximum number of participants in the new version by iFrame API,
but only 120+ people could enter the meeting with most of people close their voice,
only 5 or 10 open their voice and less than 5 of people open the video.
In the node, only 30% of CPU had been used.
I had check the log but there’s nothing to found.
Can you tell me what’s the problem or where could find the reason? bandwidth or memory? or something else.
Thanks for your help.

You are talking about your own deployment?