Context
We run a self-hosted Jitsi deployment for online classrooms:
- ~10 JVB servers
- ~30 concurrent classes (conferences)
- ~15 students per class (plus 1 teacher)
We use the default bridge selection (SingleBridgeSelectionStrategy / least stress). Octo is not enabled — one conference stays on one JVB for its lifetime.
Problem
Teachers often join early (sometimes alone). At that moment Jicofo picks the lowest-stress JVB and sticks the conference there.
What happens in practice:
- Some classes get students joining soon → those JVBs report higher stress.
- Other classes still only have the teacher → they look “light” and several new rooms get packed onto the same low-stress JVB.
- When class time starts and everyone joins at once, that JVB (which received many “light” rooms early) becomes heavily overloaded (high bitrate / CPU), while other JVBs still have headroom.
So load looks roughly balanced by stress at allocate time, but not by number of conferences, and there is no rebalancing when rooms fill up later.
Question
Is there a supported way to distribute new conferences more evenly across JVBs, for example:
- Round-robin by conference (room 1 → JVB1, room 2 → JVB2, …)?
- Prefer the JVB with the fewest active conferences (not lowest stress)?
- Or any recommended config (
max-bridge-participants, stress tuning, custom BridgeSelectionStrategy, etc.) for this “many similar-sized rooms, staggered teacher join” pattern?
We understand sticky assignment (no mid-conference move without Octo) is expected — we mainly want fairer initial placement when rooms are created.
What we already know
From reference.conf, built-in strategies are roughly:
SingleBridgeSelectionStrategy (least loaded, no Octo) — what we use
SplitBridgeSelectionStrategy / RegionBasedBridgeSelectionStrategy / IntraRegionBridgeSelectionStrategy (Octo-related)
None of these look like round-robin by conference count. Happy to implement a custom strategy if that’s the intended path — just want to confirm best practice before doing that.
Thanks!
Context
We run a self-hosted Jitsi deployment for online classrooms:
We use the default bridge selection (
SingleBridgeSelectionStrategy/ least stress). Octo is not enabled — one conference stays on one JVB for its lifetime.Problem
Teachers often join early (sometimes alone). At that moment Jicofo picks the lowest-stress JVB and sticks the conference there.
What happens in practice:
So load looks roughly balanced by stress at allocate time, but not by number of conferences, and there is no rebalancing when rooms fill up later.
Question
Is there a supported way to distribute new conferences more evenly across JVBs, for example:
max-bridge-participants, stress tuning, customBridgeSelectionStrategy, etc.) for this “many similar-sized rooms, staggered teacher join” pattern?We understand sticky assignment (no mid-conference move without Octo) is expected — we mainly want fairer initial placement when rooms are created.
What we already know
From reference.conf, built-in strategies are roughly:
SingleBridgeSelectionStrategy(least loaded, no Octo) — what we useSplitBridgeSelectionStrategy/RegionBasedBridgeSelectionStrategy/IntraRegionBridgeSelectionStrategy(Octo-related)None of these look like round-robin by conference count. Happy to implement a custom strategy if that’s the intended path — just want to confirm best practice before doing that.
Thanks!