Webkonferenzsystem BigBlueButton
Nicht ins Blaue hinein
Veröffentlicht in Ausgabe 08/2026 - SCHWERPUNKT
Im Gegensatz zu reinen Videokonferenztools liegt der Fokus bei BigBlueButton (BBB) [1] auf Kollaboration: Whiteboard, Umfragen, Breakout-Räume und die tiefe Integration in Lernmanagementsysteme (LMS) gelten als die Kernkompetenzen dieser Umgebung. Um allerdings ein Maximum aus BBB heraus- zuholen, ist Finetuning erforderlich.
Zusammenspiel verschiedener Dienste
BBB ist kein monolithischer Block, sondern basiert auf dem komplexen Zusammenspiel verschiedener Dienste. Der Nginx-Webserver agiert als zentraler Einstiegspunkt und stellt SSL/TLS-gesicherte Verbindungen bereit. Hinter "bbb-web" verbirgt sich eine Java-basierte API-Schnittstelle, die Meetingzustände verwaltet und mit Drittsystemen wie Moodle oder Greenlight kommuniziert. FreeSWITCH [2] übernimmt die VoIP-Abwicklung: Audiostreams werden hier gemischt und via WebRTC an die Clients verteilt. Das Herzstück der Videoverarbeitung bildet der Media-Server: Während ältere BBB-Versionen primär auf den Kurento Media Server (KMS) [3] setzten, nutzt BBB ab Version 2.6 zunehmend das performantere mediasoup [4] für SFU-Szenarien (Selective Forwarding Unit). Redis [5] und Akka [6] stellen das interne Messaging-Rückgrat sowie die Echtzeit-Synchronisation des Whiteboards sicher.
Mit BBB 3.0 wurde der Wechsel zu mediasoup als primärem Video-SFU weitgehend abgeschlossen. Kurento ist in 3.x nur noch für Legacy-Fallbacks aktiv. Die aktuelle Version zeichnet sich durch weitere Neuerungen aus. So löst das neue React-basierte Frontend das alte vollständig ab. Doch Vorsicht: Wer von 2.7 auf 3.x migriert, muss mit Breaking Changes bei Drittanbieter-Plug-ins und veränderten Konfigurationspfaden rechnen.
In Kürze
- BigBlueButton ist eine leistungsfähige Open-Source-Alternative zu proprietären Webkonferenzsystemen mit besonderer Stärke im Bildungsbereich, verlangt aber sorgfältige Dimensionierung und Konfiguration.
- Für den produktiven Betrieb sind ein korrekt eingerichteter TURN-Server, konsequente Sicherheitshärtung und aktives Monitoring keine Kür, sondern Pflicht.
- Wer mehr als 150 bis 200 gleichzeitige Nutzer erwartet, kommt um ein Cluster-Setup mit Scalelite nicht herum.
Im Gegensatz zu reinen Videokonferenztools liegt der Fokus bei BigBlueButton (BBB) [1] auf Kollaboration: Whiteboard, Umfragen, Breakout-Räume und die tiefe Integration in Lernmanagementsysteme (LMS) gelten als die Kernkompetenzen dieser Umgebung. Um allerdings ein Maximum aus BBB heraus- zuholen, ist Finetuning erforderlich.
Zusammenspiel verschiedener Dienste
BBB ist kein monolithischer Block, sondern basiert auf dem komplexen Zusammenspiel verschiedener Dienste. Der Nginx-Webserver agiert als zentraler Einstiegspunkt und stellt SSL/TLS-gesicherte Verbindungen bereit. Hinter "bbb-web" verbirgt sich eine Java-basierte API-Schnittstelle, die Meetingzustände verwaltet und mit Drittsystemen wie Moodle oder Greenlight kommuniziert. FreeSWITCH [2] übernimmt die VoIP-Abwicklung: Audiostreams werden hier gemischt und via WebRTC an die Clients verteilt. Das Herzstück der Videoverarbeitung bildet der Media-Server: Während ältere BBB-Versionen primär auf den Kurento Media Server (KMS) [3] setzten, nutzt BBB ab Version 2.6 zunehmend das performantere mediasoup [4] für SFU-Szenarien (Selective Forwarding Unit). Redis [5] und Akka [6] stellen das interne Messaging-Rückgrat sowie die Echtzeit-Synchronisation des Whiteboards sicher.
Mit BBB 3.0 wurde der Wechsel zu mediasoup als primärem Video-SFU weitgehend abgeschlossen. Kurento ist in 3.x nur noch für Legacy-Fallbacks aktiv. Die aktuelle Version zeichnet sich durch weitere Neuerungen aus. So löst das neue React-basierte Frontend das alte vollständig ab. Doch Vorsicht: Wer von 2.7 auf 3.x migriert, muss mit Breaking Changes bei Drittanbieter-Plug-ins und veränderten Konfigurationspfaden rechnen.
Richtig dimensionieren
Bevor Sie sich an die Inbetriebnahme von BBB machen, sollten Sie verschiedene Vorüberlegungen anstellen. Ein häufiger Fehler ist die Unterdimensionierung. WebRTC ist CPU-hungrig, da jeder Videostream verarbeitet und weitergeleitet werden muss. Shared-CPU-Instanzen oder überbuchte VM-Umgebungen führen zuverlässig zu Audio-Aussetzern und eingefrorenen Videos. Als Richtwerte für einen adäquat ausgestatteten Server gelten folgende Daten:
- CPU: Für eine produktive Instanz mit etwa 100 bis 150 gleichzeitigen Nutzern sind 16 dedizierte Kerne das Minimum. Shared Hosting oder vCPUs gelten als kontraproduktiv.
- RAM: 32 GByte sorgen für ausreichend Puffer, insbesondere wenn Aufzeichnungen auf dem Server verarbeitet werden.
- Storage: Beim Einsatz von BBB ist eine NVMe-SSD Pflicht, denn die Schreiblast beim Caching von Videostreams und der Konvertierung von Präsentationen via LibreOffice ist erheblich.
- Netzwerk: BBB benötigt eine eigene öffentliche IPv4-Adresse. Der Betrieb hinter NAT erfordert einen STUN/TURN-Server. Außerdem sind folgende Ports freizugeben: TCP 80/443 (HTTP/HTTPS) sowie UDP 16384–32768 (RTP-Audio- und Videostreams).
Installation auf dem Ubuntu-Weg
BBB unterstützt offiziell Ubuntu 22.04 LTS. Eine Installation unter anderen Distributionen ist aufgrund der tiefen Sys-temintegration nicht zu empfehlen. Vor der Installation müssen Sie den FQDN korrekt setzen:
bashsudo apt update && sudo apt upgrade -y
sudo hostnamectl set-hostname bbb.beispiel.de
Das offizielle Installationsskript "bbb-install.sh" automatisiert Paketquellen, die Firewallkonfiguration und die Zertifikatsausstellung via Let‘s Encrypt:
bashwget -qO- https://ubuntu.bigbluebutton.org/bbb-install.sh | bash -s -- -v jammy-270 -s bbb.beispiel.de -e admin@beispiel.de -g
Der Parameter "-v jammy-270" installiert die stabile 2.7-Linie, "-s" setzt den öffentlichen Hostnamen und "-e" liefert die E-Mail-Adresse für die automatische Zertifikatserneuerung. Der Parameter "-g" installiert das Frontend Greenlight als Docker-Container. In der Regel ist die Installation nach etwa zehn bis 15 Minuten abgeschlossen. Für eine Installation von BBB 3.x ersetzen Sie den Parameter "-v jammy-270" durch "-v jammy-30". Da ein direktes In-Place-Upgrade von 2.7 nicht unterstützt wird, ist stets eine Neuinstallation auf einem frischen Ubuntu-22.04-System erforderlich.
Nach der Installation empfiehlt sich ein kurzer Checkup. Dazu führen Sie nach jeder Installation den Befehl
bashsudo bbb-conf --checkaus. Dieses Tool prüft, ob alle Dienste laufen, ob die IP-Adressen in den Konfigurationsdateien konsistent sind und ob potenzielle Sicherheitslücken wie ein offenes API-Secret vorliegen. Mitbbb-conf --statuserhalten Sie zudem eine schnelle Momentaufnahme der laufenden Linux-Dienste. Den initialen Greenlight-Administrator legen Sie wie folgt an:bashdocker exec greenlight-v3 bun dle exec rake admin:create["admin@ beispiel.de","SuperSecretPass word","Admin"]
Frontendoptionen: Greenlight, Moodle & Co.
BBB ist ein reines Backend – das Frontend ist austauschbar. Je nach Einsatzszenario empfehlen sich unterschiedliche Ansätze. Greenlight ist die einfachste Lösung für Organisationen ohne LMS. Greenlight läuft als Docker-Container. Wenn Sie bereits eine Moodle-Umgebung betreiben, benötigen Sie Greenlight nicht. Das offizielle "mod_bigbluebutton"-Plug-in integriert BBB direkt in Kurse. Nutzerauthentifizierung, Raumzuweisung und Recording-Verlinkung laufen vollständig über Moodle. Über das offene BBB-API lässt sich jedes System anbinden, das HTTP-Requests senden kann.
Damit stellt sich die Frage, welche Option die passende ist. Greenlight eignet sich für schnelle Deployments ohne eine bestehende Infrastruktur. Wenn Sie eine eigene Nutzerauthentifizierung via LDAP oder SAML benötigen, sollten Sie Greenlight mit dem entsprechenden Provider konfigurieren oder direkt auf das API setzen.
Pflegen Sie in der Greenlight-Umgebungsdatei "/root/greenlight/.env" unbedingt die SMTP-Parameter ("SMTP_SERVER", "SMTP_PORT", "SMTP_USERNAME", "SMTP_PASSWORD"), da sonst Passwort-Reset-E-Mails nicht zugestellt werden können; für Updates des Containers führen Sie "docker pull bigbluebutton/greenlight:v3" gefolgt von "docker-compose up -d" aus.
Für die LDAP-Anbindung tragen Sie in "/root/greenlight/.env" die Variablen "LDAP_SERVER", "LDAP_PORT", "LDAP_BIND_DN", "LDAP_BASE" und "LDAP_AUTH=true" ein; für "SAML-SSO" setzen Sie "OMNIAUTH_PROVIDER=saml" sowie die zugehörigen Zertifikat- und Endpunktvariablen, sodass Nutzer sich über Ihr bestehendes Identity-Management authentifizieren können.
Konfiguration und Härtung
Die Standardkonfiguration ist funktional, doch für den professionellen Einsatz zu offen. Im ersten Schritt sollten Sie sich den Meetingparametern widmen. In der Datei "/etc/bigbluebutton/bbb-web.properties" definieren Sie die Begrenzungen, die verhindern, dass ein einzelnes Meeting den Server destabilisiert:
propertiesmaxParticipants=100
endWhenNoModerator=true
endWhenNoModeratorDelayInMinutes=5
Jedes Produktivsystem benötigt das Shared Secret. Das rufen Sie mit
bashsudo bbb-conf --secret ab. Speichern Sie das Secret niemals in Klartext; außerdem sollen Sie nicht in Git-Repositorys einchecken und nach der Kompromittierung sofort rotieren:sudo bbb-conf --setsecret <Neues-Secret>. Anschließend müssen Sie alle angebundenen Systeme aktualisieren. Um die Sicherheit weiter zu verbessern, sollten Sie die Nginx Rate-Limiting anpassen. Sie sollten insbesondere den BBB-API-Endpunkt gegen Enumeration und Brute-Force-Angriffe absichern. Dazu nehmen Sie in "/etc/nginx/sites-available/bigbluebutton" folgende Anpassungen vor:nginxlimit_req_zone $binary_remote_addr zone=bbb_api:10m rate=10r/s;
location /bigbluebutton/api {
limit_req zone=bbb_api burst=20 nodelay;
proxy_pass http://127.0.0.1:8090;
}
Mit "fail2ban" sichern Sie wiederholte Fehlversuche ab. Dazu ist eine Ergänzung in "/etc/fail2ban/jail.local" notwendig:
ini[sshd]
enabled = true
maxretry = 5
bantime = 3600
[nginx-limit-req]
enabled = true
filter = nginx-limit-req
logpath = /var/log/nginx/error.log
maxretry = 10
Wenn Sie BBB auf Ubuntu ausführen, kommt Ihnen zugute, dass das Linux-System mit ufw (Uncomplicated Firewall) eine Firewall besitzt, mit der Sie einfach und zuverlässig exakt die Ports öffnen können, die die Konferenzumgebung benötigt. Dazu legen Sie ein minimales Regelwerk an:
bashsudo ufw default deny incoming
sudo ufw allow 22/tcp && sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 16384:32768/udp
sudo ufw enable
Um das BBB-System DSGVO-konform zu machen, sollten Sie zudem die IP-Protokollierung in der Webserver-Konfiguration "/etc/nginx/nginx.conf" anonymisieren:
nginxmap $remote_addr $remote_addr_anon {
~(?P<ip>\d+\.\d+\.\d+)\. $ip.0;
default 0.0.0.0;
}
Ergänzen Sie die Systemabsicherung um SSH-Hardening ("PermitRootLogin no" und "PasswordAuthentication no" in "/etc/ssh/sshd_config") sowie die Netzwerkperformance-Parameter "net.core.rmem_max=134217728" und "net.core.wmem_max=134217728" in "/etc/sysctl.conf", die die UDP-Puffergrößen für WebRTC-Streams erheblich verbessern.
Coturn: TURN-Server einrichten
In Unternehmensnetzwerken blockieren Firewalls häufig UDP-Ports. In diesem Fall können Sie sich mit einem TURN-Server behelfen; der tunnelt Audio und Video über TCP 443, wenn direkte UDP-Verbindungen scheitern. Coturn [7] ist der quelloffene TURN- und STUN-Server, der für diese Zwecke bestens geeignet ist. Allerdings sollten Sie Coturn auf einer separaten Maschine mit ausreichend Bandbreite betreiben:
bashsudo apt install coturn -y
sudo systemctl enable coturn
Die Grundkonfiguration erfolgt in der Datei "/etc/turnserver.conf". Diese passen Sie wie folgt an:
conflistening-port=3478
tls-listening-port=5349
external-ip=<ÖFFENTLICHE-IP>
realm=turn.beispiel.de
use-auth-secret
static-auth-secret=<Langes- zufälliges-Secret>
cert=/etc/letsencrypt/live/turn. <beispiel.de>/fullchain.pem
pkey=/etc/letsencrypt/live/turn. <beispiel.de>/privkey.pem
no-multicast-peers
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=192.168.0.0-192.168.255.255
Jetzt bedarf es nur noch der Verknüpfung mit BBB in "/etc/bigbluebutton/turn-stun-servers.xml":
xml<beans>
<bean id="turn0" class="org.big bluebutton.web.services.turn.Turn Server">
<constructor-arg index="0" value= "<Langes-zufälliges-Secret>"/>
<constructor-arg index="1" value="turns:turn.beispiel. de:443?transport=tcp"/>
<constructor-arg index="2" value="86400"/>
</bean>
</beans>
Nach der Konfigurationsanpassung starten Sie BBB neu:
sudo bbb-conf --restart. Prüfen Sie die Erreichbarkeit des TURN-Servers regelmäßig mitturnutils_uclient -T -p 443 turn.beispiel.de und richten Sie einen einfachen externen Health-Check ein – ein ausgefallener TURN-Server fällt sonst erst auf, wenn Nutzer aus Firmennetzwerken keine Verbindung mehr aufbauen können.Videoperformance optimieren
Eine der zentralen Herausforderungen in Videokonferenzsystem ist die Videoperformance. Klagen die Nutzer über ruckelnde Videos, liegt das häufig an der konfigurierten Bitrate. Diese können Sie in "/etc/bigbluebutton/bbb-html5.yml" optimieren:
yamlpublic:
kurento:
cameraProfiles:
- id: low
label: "Niedrig"
default: false
bitrate: 100
- id: medium
label: "Mittel"
default: true
bitrate: 200
- id: high
label: "Hoch"
default: false
bitrate: 500
Für Umgebungen mit vielen Teilnehmern empfiehlt es sich, das Medium-Profil als Standard zu setzen und "High" nur auf Anfrage freizugeben. Jeder aktive Videostream belastet den Server unabhängig von der Gesamtteilnehmerzahl: 50 aktive Kameras mit je 500 KBit/s ergeben bereits 25 MBit/s ausgehender Last, zuzüglich der CPU-Verarbeitungslast durch mediasoup.
Updatestrategie nötig
Die enge Verzahnung von BBB und Ubuntu verlangt behutsam abgestimmte Upgradestrategien. BBB-Updates greifen tief in das Linux-System ein und können Konfigurationsdateien überschreiben. Daher ist ein strukturiertes Vorgehen Pflicht. Wenn Sie Minor-Updates, zum Beispiel von Version 2.7.x auf 2.7.y, planen, sollten Sie wie folgt vorgehen:
bashsudo bbb-conf --check # Ausgangszustand dokumentieren
sudo apt update && sudo apt upgrade -y
sudo bbb-conf --restart && sudo bbb-conf --check
Bei Major-Updates, also von Version 2.7 auf 3.x, wird ein direktes In-Place-Upgrade nicht unterstützt. In diesem Fall schlagen Sie einen anderen Weg ein: Bauen Sie eine neue Instanz parallel auf, migrieren Sie die Konfigurationen und Recording und führen Sie einen DNS-Cutover durch. Die alte Instanz sollten Sie solange behalten, bis Sie sicher sind, dass sie durch die neue Instanz vollständig abgelöst wird.
Das Überschreiben bei BBB-Updates wirkt sich insbesondere auf folgende Bereiche aus: Docker-Einstellungen von Greenlight (dem Benutzerfrontend), individuelle Nginx-Konfigurationen (zum Beispiel eigene Weiterleitungsregeln), selbst gesetzte BBB-Parameter wie maximale Teilnehmerzahlen, sowie Plug-ins von Drittanbietern, die nicht zum offiziellen BBB-Paket gehören. Nach jedem Update sollten Sie zwei Aspekte prüfen: Stellen Sie mit "bbb-conf --check" sicher, dass alle Dienste wieder sauber laufen, und werfen Sie einen Blick in die Logdateien unter "/var/log/bigbluebutton/", ob dort Fehlermeldungen auftauchen. Daher sollten Sie vor jedem Update einen Snapshot der virtuellen Maschine erstellen.
Scalelite als Loadbalancer
Ein einzelner BBB-Server stößt bei etwa 150 bis 200 gleichzeitigen Nutzern mit aktiviertem Video an seine Grenzen. Überall dort, wo mit einem höheren Aufkommen zu rechnen ist, wird ein Cluster-Setup erforderlich. Hierfür bietet sich insbesondere Scalelite [8] an. Dabei handelt es sich um einen quelloffenen Loadbalancer, der die Last intelligent auf mehrere BBB-Instanzen verteilt. Scalelite überwacht die Last der einzelnen Nodes und weist neue Meetings dem Server mit den meisten freien Ressourcen zu. Der Vorteil: Die horizontale Skalierbarkeit ist durch einfaches Hinzufügen neuer Nodes gegeben. Die Hochverfügbarkeit bei einem Node-Ausfall und zentrales Recording-Management stellen Sie via NFS-Share oder S3-Bucket sicher:
bash./scalelite-recording-importer add-server
--url https://bbb2.beispiel.de/ bigbluebutton/api
--secret <BBB2-Secret>
Laufende Meetings auf einem ausgefallenen Node brechen allerdings ab. In produktiven Umgebungen sollten Sie mindestens zwei TURN-Server in unterschiedlichen Rechenzentren betreiben und beide in "turn-stun-servers.xml" eintragen. Für ein vollständiges Scalelite-Setup starten Sie den Loadbalancer als Docker-Container (
docker-compose up -d) und binden den gemeinsamen Recording-Speicher als NFS-Share unter "/mnt/scalelite-recordings" ein. Beachten Sie, dass auch die Scalelite-eigene PostgreSQL-Datenbank in Ihre Backupstrategie aufgenommen werden muss, da sie die gesamte Node-Registrierung und Meetingzuordnung enthält.Aufzeichnungen: Workflow, Formate und Speicherplanung
Recordings sind eines der leistungsstärksten, aber auch ressourcenintensivsten Features. Die Verarbeitung läuft in drei Phasen: "raw" (Rohaufzeichnung während des Meetings), "process" (Nachbearbeitung, Transkodierung) und "publish" (fertige Aufzeichnung, abrufbar im Front-end). BBB unterstützt mehrere Ausgabeformate: "presentation" (Folien mit Audio/Video, Standard), "video" (direktes MP4-Encoding) und "podcast" (nur Audio). Welches Format aktiv ist, steuern Sie über "/usr/local/bigbluebutton/core/scripts/bigbluebutton.yml."
Wichtig für Ihre Speicherplanung: Eine Stunde Meeting mit 30 aktiven Nutzern erzeugt im Rohformat rund 2 bis 5 GByte Daten. Bei intensiver Nutzung können die Ordner unter "/var/bigbluebutton/recording/raw" schnell mehrere TByte erreichen. Daher ist für Produktivumgebungen ein separates Volume oder eine S3-Anbindung unerlässlich. Beachten Sie außerdem, dass ein volles Speichermedium die gesamte Recording-Pipeline beendet, ohne dass BBB eine deutliche Fehlermeldung ausgibt. Speicherplatz-Monitoring ist also Pflicht. Sie sollten zudem die Aufbewahrungsfristen aktiv verwalten. Alte Recordings können Sie gezielt löschen:
sudo bbb-record --delete <recording-id>
Für eine automatisierte Bereinigung em-pfiehlt sich ein Cronjob, der Recordings ab einem definierten Alter entfernt und so unkontrolliertes Speicherwachstum verhindert.
Monitoring, Backup und Troubleshooting
Ein zuverlässiger BBB-Betrieb steht und fällt mit aktivem Monitoring. Für Prometheus und Grafana existieren passende Exporter; die Entwickler empfehlen hierfür das Dashboard "BigBlueButton Statistics". Kritische Schwellenwerte sind klar definiert: CPU über 80 Prozent, RAM über 75 Prozent und UDP-Paketverlust über fünf Prozent signalisieren akute Probleme, während bereits niedrigere Werte als Warnstufe gelten. Die Anzahl aktiver Meetings und Nutzer ist kontextabhängig zu bewerten. Wichtig: Audio-Probleme sind fast immer das erste Anzeichen für Überlastung. Befehle wie
bbb-conf --status liefern schnelle Einblicke, entscheidend ist jedoch kontinuierliches Monitoring statt reaktiver Fehlerbehebung.Für das BBB-Monitoring benötigen Sie zwei separate Komponenten. Den allgemeinen System-Exporter installieren Sie per
apt install prometheus-node-exporter; er liefert CPU-Last, RAM-Auslastung und Netzwerkmetriken. Den BBB-spezifischen Prometheus-Exporter [9] deployen Sie zusätzlich als Docker-Container gemäß der Repository-Dokumentation – er stellt BBB-eigene Metriken wie aktive Meetings, Teilnehmerzahlen und WebRTC-Verbindungen bereit. Binden Sie beide Exporter in Ihre "prometheus.yml" ein und importieren Sie anschließend das Grafana-Dashboard über die ID 13470, das die Metriken des BBB-Exporters voraussetzt. Ergänzen Sie außerdem "/etc/logrotate.d/bigbluebutton" um eine tägliche Rotation mit 14-tägiger Aufbewahrung, damit die Logdateien unter "/var/log/bigbluebutton/" den Festplattenplatz nicht unkontrolliert belegen.Für Backup und Disaster Recovery müssen drei Datenbereiche gesichert werden: die Konfigurationen, die Datenbanken (PostgreSQL) und die Recordings. Mit automatisierten Skripts sorgen Sie dafür, dass im Ernstfall eine vollständige Wiederherstellung möglich ist. Ein minimales Tagesbackup sichert Konfigurationen (
tar -czf /backup/bbb-config.tar.gz /etc/bigbluebutton /etc/nginx), die Greenlight-Datenbank (pg_dump -U postgres greenlight > /backup/greenlight-$(date +%F).sql) und synchronisiert Recordings auf ein externes Volume (rsync -a /var/bigbluebutton/published/ backup-server:/bbb-recordings/2) – diese drei Befehle genügen für eine vollständige Wiederherstellung.Typische Fehler lassen sich systematisch eingrenzen: ICE-Fehler (1004/1007) deuten meist auf blockierte UDP-Ports oder fehlende TURN-Erreichbarkeit hin. Eine hohe CPU-Last einzelner Prozesse wie FreeSWITCH oder Kurento Media Server weist auf Überlastung hin – hier hilft oft nur leistungsstärkere Hardware, da WebRTC-Prozesse kaum parallelisierbar sind. Fehlende Präsentationskonvertierung liegt meist an fehlenden LibreOffice-Abhängigkeiten oder vollem Speicher.
Bei Audio-Problemen arbeiten Sie folgenden Diagnosepfad ab:
- Prüfen Sie mittels
sudo bbb-conf --check auf Fehler.- Verifizieren Sie die TURN-Erreichbarkeit mit
turnutils_uclient.- Kontrollieren Sie die CPU- und RAM-Auslastung per
htop.- Werten Sie relevante Logs mit
journalctl -u bbb-web -f aus.
Best Practices für den BBB-Betrieb
Ein stabiler Betrieb von BigBlueButton erfordert konsequente Systemdisziplin. Der Server sollte ausschließlich für BBB genutzt werden. Vor größeren Veranstaltungen sind Lasttests mit dem BBB-Load-Tester essenziell, um Engpässe frühzeitig zu erkennen. Für zuverlässige Verbindungen – insbesondere in restriktiven Netzwerken – sollten mindestens zwei redundante TURN-Server in getrennten Rechenzentren betrieben werden.
Häufige Fehlplanungen betreffen unterdimensionierte oder überbuchte Systeme (etwa mit weniger als 16 GByte RAM), fehlende TURN-Infrastruktur sowie unterschätzte WebRTC-Last. Die Folgen sind meist Audioaussetzer, Video-Freezes und Verbindungsabbrüche. In der Praxis lassen sich laut Angaben der Entwickler rund 80 Prozent aller Probleme auf eine falsche Dimensionierung zurückführen.
Vor dem Produktivstart sollte eine technische Checkliste abgearbeitet werden: fehlerfreier Systemcheck (bbb-conf), funktionierender TURN-Test, gesicherte API-Zugänge, aktivierte Sicherheitsmechanismen (Firewall, Rate-Limiting), Monitoring mit Alerting sowie getestete Backups. Im laufenden Betrieb sind zentrale Metriken entscheidend: CPU-Auslastung über 80 Prozent und RAM über 75 Prozent deuten auf kritische Zustände hin, ebenso wie UDP-Paketverluste über fünf Prozent. Die Anzahl aktiver WebRTC-Verbindungen ist der wichtigste Lastindikator. Typischerweise zeigen sich Überlastungen zuerst durch Audio-Probleme – daher ist proaktives Monitoring unerlässlich.
Fazit
BigBlueButton ist die Enterprise-Klasse der Open-Source-Videokonferenzen. Die Installation ist dank automatisierter Skripte in überschaubarer Zeit machbar. Die eigentliche Arbeit beginnt beim Finetuning.
(dr)
Links
[1] BigBlueButton: https://it-a.eu/q8z11
[2] FreeSWITCH: https://it-a.eu/q8z12
[3] Kurento Media Server: https://it-a.eu/q8z13
[4] mediasoup: https://it-a.eu/q8z14
[5] Redis: https://it-a.eu/q8z15
[6] Akka: https://it-a.eu/q8z16
[7] Coturn: https://it-a.eu/n0pe9
[8] Scalelite: https://it-a.eu/q8z18
[9] BigBlueButton Exporter: https://it-a.eu/q8z19