Jitsi works with 2 people but not with 3: how to fix it

Short answer

Two eligible participants can use P2P; a third participant normally moves their media to Jitsi Videobridge. If the call fails at that change, check the actual JVB path: its UDP listener and published port, advertised ICE address, cloud/router rules and any TURN relay. UDP 10000 is the default, not proof of the port your deployment uses. [N1][N2]

Scope: Docker settings checked at stable-11248 and its bundled lib-jitsi-meet source; Debian/Ubuntu differences are noted below. The symptom suggests a media-path investigation, not one proven cause for every black screen. [N1][N2]

Why it happens

  • Two eligible people: Jitsi can establish P2P and use it for media. P2P depends on configuration and participant/features; it is not guaranteed. A JVB session can also be relevant to a two-person call. [N1]
  • A third person joins: the usual P2P-to-JVB transition can reveal a bridge path that the working P2P media did not exercise. The default JVB UDP port is 10000. TURN can relay a participant’s traffic to that bridge when a suitable direct path is unavailable. [N1][N2][N3]

Do a controlled two-person comparison with P2P disabled, then test with three people. The one-way audio guide describes the supported Docker/package settings. Record and restore your original setting after the comparison; changing the web configuration affects clients that load it. Use a test environment or a planned maintenance window. [N1][N2]

Result Next investigation
Two-person P2P works, but the bridge-only test fails JVB availability, candidates and packet path. [N1][N2]
One network fails, while another works through the bridge That network’s path to JVB or a working TURN relay. [N3]
ICE connects but only one direction is audible Compare RTP counters, capture/mute state and playback before changing firewall rules. [N4]

If the camera or microphone never works locally, start with device permissions and capture checks.

Fix 1: open 10000/udp everywhere

First confirm the intended UDP port and the matching cloud firewall, router forwarding and host/container policy. For an unchanged default deployment, the host firewall rule is: [N2][N5]

The server firewall:

Terminal
sudo ufw allow 10000/udp
sudo ufw status

The cloud/router layer: permit or forward the same UDP media path for your intended participants. A TCP rule for port 10000 does not cover UDP. With Docker bridge networking, published-port traffic can bypass the UFW chains you expected; a green UFW status alone is not a complete test. See ports and firewall diagnostics. [N2][N5]

Docker stable-11248: these read-only checks show the service and its UDP publication. Keep your normal project/Compose arguments; substitute the container port if you changed JVB_PORT. [N2][N6]

Terminal
docker compose ps jvb
docker compose port --protocol udp jvb 10000

Fix 2: advertise the public IP

On an internet-facing server behind NAT, clients need a reachable advertised address and port. Check the actual JVB ICE candidates, not just the address used by the website. An HTTPS page loading successfully does not exercise the UDP media path. [N2][N7]

If your observed candidate address is wrong, Docker stable-11248 supports the following .env input. Replace the documentation address with the real reachable IP; preserve other environment entries. [N2]

Config
JVB_ADVERTISE_IPS=203.0.113.10

Apply the correction during maintenance. Recreating JVB can interrupt meetings: [N2]

Terminal
docker compose up -d --force-recreate jvb

Then inspect the newly advertised candidates and verify the corresponding route. A correct-looking setting is not proof the external forwarding works. Debian/Ubuntu: Docker .env names do not configure package installs; inspect the installed release’s /etc/jitsi/videobridge/jvb.conf and its ICE/mapping configuration instead. [N7]

Fix 3: check the videobridge is healthy

Terminal
docker compose ps
docker compose logs --tail 100 jvb
docker compose logs --tail 100 jicofo

Look for bridge startup, XMPP connection/registration and Jicofo availability errors. A missing bridge is not necessarily an authentication failure: use the actual error to distinguish service startup, network and credential problems. Compare secrets privately; do not paste passwords, ICE credentials or full meeting logs into a public report. [N2][N7]

Fix 4: corporate networks that block UDP

Some networks block the direct UDP path. TURN over TLS on an allowed TCP port can help, but TCP 443 is not guaranteed to pass every proxy, inspection policy or network restriction. The relay also needs its own working UDP path to JVB. See setting up a TURN server with coturn. [N3]

A gathered relay candidate proves an allocation was obtained; it does not establish that the call selected that path or that return traffic works. Follow the active RTP transport’s selected candidate pair and verify media in both directions. [N4]

Verify

Join a disposable meeting from three independent clients, including a separate external network where possible. Verify each participant sends and receives the intended audio/video, and that the active bridge transport has a successful selected ICE pair with advancing RTP counters. Repeat after the third joins/leaves. An open port, populated participant list or successful TURN allocation is not a complete media test. [N1][N4]

What our checks establish

On 20 October 2026, a pinned stable-11248 JVB image returned a UDP 10000 candidate in an isolated private REST allocation. A separate coturn 4.18.0 fixture relayed 20 synthetic packets each way over client TCP and peer UDP. When the peer intentionally stopped replying, it still received 20 packets but the client received none; restoring replies restored the test traffic. These were component checks, not a Jitsi meeting, TLS test or audio/video reproduction. This revised guide has not been production-tested.

Sources and open questions

Reviewed 20 October 2026. Full three-client browser media, restrictive-network TLS and production firewall behavior remain to be tested for any particular deployment.

Still broken?

If the call remains connected but video freezes, compare lower video quality and audio-only mode. This can help isolate a quality problem; it does not replace the bridge checks above.

Send us sanitized diagnostic details, or read about private Jitsi hosting.

Written by the Jitsi Help engineering team

Jitsi infrastructure engineers who deploy and run Jitsi Meet servers in production. Last updated . How we write our guides

Stuck on something this page does not cover? Ask a question below. Jitsi Help engineers read every one.

Did this fix it?

Something on this page is outdated or wrong?

Collect debug info

These commands gather what an engineer needs to diagnose a Jitsi server. Copy them, run them, and keep the output.

Terminal
# Run on the server, from your docker-jitsi-meet folder

# 1. Every service should be "running" (or "healthy")
docker compose ps

# 2. Which images and release tags are running
docker compose images

# 3. Recent logs from the core services
docker compose logs --tail=200 web prosody jicofo jvb

# 4. The settings most fixes depend on
grep -E '^(PUBLIC_URL|JVB_ADVERTISE_IPS|ENABLE_LETSENCRYPT|ENABLE_AUTH|AUTH_TYPE)=' .env

# 5. Is anything listening for media on UDP 10000?
sudo ss -ulnp | grep 10000

Installed with the Debian packages instead of Docker? Read the service logs with:

Terminal
sudo journalctl -u prosody -u jicofo -u jitsi-videobridge2 --since "1 hour ago"

Remove passwords, secrets and tokens before you share any output.

Send the output to an engineer

Frequently asked questions

Why does Jitsi work with two people but not three?

Two eligible participants can use P2P, while a third normally moves media to the bridge. That can expose a broken bridge path. Two-person calls can also use JVB, so confirm the active connection instead of assuming P2P from the participant count.

Which port does the Jitsi videobridge use?

UDP 10000 by default. Check the actual configured listener, Docker publication or router mapping, and the address and port advertised to clients. A custom deployment can use another port.

What is JVB_ADVERTISE_IPS?

A Docker Jitsi setting that tells the videobridge which IP address to give clients. On servers behind NAT, such as cloud instances, set it to the public IP when automatic detection picks the private one.

Discussion

    Stuck, or would rather not do this by hand?

    Deploy it in one click

    A private Jitsi server in your own AWS account with SSL, your domain and optional recording, transcription and JWT. Free 15 minute trial.

    Start free trial

    Talk to a Jitsi engineer

    Setup, fixes, branding, recording, scaling. Tell us what is happening and we reply with a plan and a quote.

    Get expert help

    Related

    Recently updated