Independent, self-managed infrastructure Read the production requirements
BBBNode
Configure server

Field diagnostics

Diagnose BigBlueButton audio and WebRTC failures

When the interface loads but audio does not, the useful boundary is signalling versus media. A disciplined test narrows browser permission, client network, TURN, NAT and server faults without random restarts.

6 min read Reviewed July 1, 2026 4 primary & community sources
01 Browser HTTPS, permission, device and supported version
→
02 Client network UDP policy, proxy, VPN and captive portal
→
03 TURN / NAT Relay reachability and public address mapping
→
04 BBB media stack Ports, services, CPU and logs
Follow the media path from the user outward.

Executive brief

What matters

  1. 01

    Capture timestamp, affected users, browser, network, error code and meeting ID before changing the server.

  2. 02

    A working web page proves HTTPS signalling, not UDP media reachability.

  3. 03

    Use TURN over an allowed transport for restrictive networks, but fix server NAT and firewall errors rather than masking them.

01

Classify the blast radius

Ask whether one user, one network, one meeting or every meeting is affected. Test listen-only and microphone separately from two devices on different networks. Record any 1007/ICE or 1020 media error and the exact time. A mobile hotspot is a useful comparator, not a production fix.

02

Check the client edge

Confirm a supported current browser, trusted HTTPS, operating-system input selection and browser microphone permission. Disable VPN or filtering extensions only as a controlled test. Corporate proxies may allow the application while blocking WebRTC UDP; their network team needs destination and transport evidence.

03

Validate network and server

Verify TCP 80/443 and the documented UDP media range, public IP/NAT mapping and hairpin behaviour where applicable. Run bbb-conf checks and inspect logs around the timestamp. High CPU can present as broken or degraded audio even when firewall rules are correct.

04

Prove the repair

Retest the failing network, not only an administrator laptop. Verify direct and relayed paths, microphone and listen-only, reconnection and a second simultaneous meeting. Record the root cause and monitoring signal so the next incident starts with evidence.

Evidence base

Sources and further reading

We prefer project documentation and first-party product guidance. Community links are included where they reveal recurring operational questions rather than establish product guarantees.

  1. BigBlueButton troubleshooting (opens in a new tab)
  2. BigBlueButton firewall configuration (opens in a new tab)
  3. bbb-conf diagnostic commands (opens in a new tab)
  4. BigBlueButton installation ports (opens in a new tab)

Practical answers

Questions teams ask

What does WebRTC error 1007 usually indicate?

It is associated with ICE negotiation failure. Investigate UDP reachability, NAT, firewall and TURN from the affected client path.

Why can some users connect while others cannot?

Their networks may enforce different UDP, proxy or VPN policies. Compare affected and unaffected connection paths.

Will restarting BigBlueButton fix audio?

A restart may hide symptoms and disrupt classes. Collect evidence and use documented checks first unless a confirmed service failure requires it.

Continue the research

Related guides and infrastructure

Browse all resources →
Troubleshooting

Webcam and screen sharing troubleshooting

Fix BigBlueButton camera and screen-share problems by isolating permissions, browser, network, media services and capacity.

Read next → Technical guide

BigBlueButton firewall ports and network prerequisites

Understand BigBlueButton firewall requirements including TCP 80/443, UDP 16384–32768, HTTPS, WebRTC and TURN planning.

Read next → Planning & architecture

Requirements for a production virtual classroom

Define functional, technical, accessibility, privacy and operational requirements for a production virtual classroom.

Read next →