Scaling Jitsi for 300–400+ Interactive Users: A Full Tutorial

Video conferencing at scale is deceptively complex. Jitsi is great for mid-sized meetings, but once you push past 200 participants, the architecture, bandwidth, and testing strategy must be carefully planned. Here’s a step-by-step guide to set up, configure, and stress-test Jitsi for 300–400+ interactive users.

1. Understanding Jitsi Limits

Jitsi uses an SFU (Selective Forwarding Unit) architecture:

• Each participant publishes their video/audio to a JVB (Jitsi Videobridge).
• The JVB forwards streams selectively to other participants.
• One JVB can reliably handle ~200–250 interactive participants at moderate video quality.

Implication: 300–400 interactive users require at least 2–3 JVBs and careful configuration.

Common mistakes at this scale:

• All participants sending HD video simultaneously.
• Ignoring LastN settings (JVB tries to forward all streams to all users).
• Using a single low-spec VM for the JVB.

2. Architecture for 300–400 Users

                 +----------------+
                 |   Jitsi Meet   |
                 +----------------+
                          |
                  +---------------+
                  |   Jicofo      |
                  +---------------+
                          |
         +----------------+----------------+
         |                |                |
      +------+         +------+         +------+
      | JVB1 |         | JVB2 |         | JVB3 |
      +------+         +------+         +------+
         |                |                |
    Participants    Participants     Participants
(100–150 per JVB)  (100–150 per JVB)  (optional)

Minimum deployment recommendations:

3. Server Configuration

JVB Configuration

/etc/jitsi/videobridge/jvb.conf:

videobridge {
  cc {
    bwe {
      max-bitrate = 1500000      # cap per participant to reduce overload
      start-bitrate = 500000
    }
  }
}

Jitsi Meet Config (client-side)

config.channelLastN = 3;          // Only receive video from last 3 active speakers
config.startWithAudioMuted = true;
config.startWithVideoMuted = true;
config.disableSimulcast = false;  // Keep simulcast for multiple resolutions

Pros:

• Limits forwarded streams → reduces JVB CPU and bandwidth.
• LastN keeps only active speakers visible, reducing client load.

Cons:

• Non-active speakers will appear blank until they talk.
• Some UX compromises (video switching delay).

4. Load Testing: jitsi-meet-torture

You cannot open 300 browser tabs manually. Use the official Jitsi torture framework.

Setup

git clone https://github.com/jitsi/jitsi-meet-torture.git
cd jitsi-meet-torture
mvn install

Example command

mvn test \
-DroomName=test300 \
-Dparticipants=50 \
-Dduration=1800

Scale strategy:

• Use 6 VMs × 50 users → 300 participants.
• Monitor CPU, memory, network, and JVB stats.
• Gradually ramp users to catch performance degradation.

5. Networking Considerations

• UDP 10000 open (JVB media)
• TCP 443 open (signaling)
• TURN ports 3478, 5349 for NAT traversal
• Ensure internal latency <20ms for JVBs and clients
• Bandwidth per JVB: ~1–1.5 Gbps for 150 active participants

6. Monitoring

Key metrics to track during tests:

• JVB CPU, memory, threads
• Packet loss and jitter
• Conference splits
• Join latency per participant

Tools: Prometheus + Grafana, colibri/stats endpoint.

7. Pre-Test Checklist

• VMs provisioned with correct specs
• TURN configured for external NAT users
• SSL certificates valid
• DNS resolves Jitsi domain
• Time sync via NTP
• LastN and simulcast enabled
• Audio/video policies set (muted on join)

8. Test Execution Plan

1. Phase 1: 50 users → check stability, CPU <50%
2. Phase 2: 150 users → observe video/audio latency
3. Phase 3: 300 users → monitor CPU, network, packet loss
4. Phase 4: 400 users (optional) → stress limit
5. Document failures, adjust bitrate and LastN

9. Optimization Tips

• Use multiple JVBs: distribute participants evenly
• Limit video quality: 720p or lower for 300+ users
• Mute unused participants: reduces upstream bandwidth
• Consider audio-only for 100+ users: preserves stability
• Enable adaptive LastN: automatically prioritizes active speakers

10. Common Pitfalls

• Overestimating a single VM → meeting splits or freezes
• Ignoring network bandwidth → UDP packet loss ruins call
• Not monitoring JVB stats → issues go unnoticed until production
• Trying full HD video for all users → crashes the bridge

Conclusion

Scaling Jitsi beyond 200 users is possible but requires discipline in architecture, configuration, and testing. By combining multiple JVBs, LastN, controlled bitrates, and systematic load testing, you can reliably handle 300–400 interactive users. Proper monitoring, network readiness, and pre-test planning are non-negotiable.