Konfiguration von Jitsi Videobridge für eine skalierte Multi-Server-Umgebung

Die Erweiterung der Medienkapazität einer Jitsi Meet-Installation um Jitsi Videobridge (JVB)-Server ist die übliche Methode. Die Web-, Prosody- und Jicofo-Dienste bleiben auf dem bestehenden Meet-Host erhalten. Anschließend werden unabhängige Bridge-Server hinzugefügt, die sich im selben Prosody-Bridge-Discovery-Raum registrieren. Jicofo kann dann neue Konferenzen auf einer verfügbaren Bridge platzieren. In diesem einfachen Design nutzt jeder Konferenzteilnehmer eine ausgewählte Bridge; Octo ist nicht erforderlich, nur weil die Installation mehrere JVB-Server umfasst.

Diese Anleitung orientiert sich an der skalierbaren, paketbasierten Einrichtung gemäß dem Jitsi-Handbuch für Debian/Ubuntu (Stand: 6. Oktober 2026). Die genauen Paketabhängigkeiten und die generierte Konfiguration können je nach Distribution, Jitsi-Paketversion und Installationsmethode (z. B. Docker) variieren. Verwenden Sie die entsprechende offizielle Installationsanleitung für Ihre bestehende Bereitstellung.

Verstehen Sie, was „Multi-Server“ in Jitsi bedeutet.

Bestätigt: Eine einzelne Jitsi Meet-Installation kann mehrere Videobrücken nutzen. Jicofo überwacht die Brücken und weist jeder neuen Konferenz eine Brücke zu. Im vereinfachten Beispiel des Jitsi-Handbuchs befinden sich die Meet-Dienste auf einem Server und drei JVBs auf separaten Servern. Jede Brücke muss für die Meeting-Teilnehmer (Medienübertragung) und für die Meet-Infrastruktur (Signalisierung) erreichbar sein.

Häufiger Irrtum: „Ich brauche einen Load Balancer vor den JVBs.“ Im dokumentierten Multi-Bridge-Design wählt Jicofo eine Bridge aus; Clients senden dann Mediendaten an diese Bridge. Ein generischer HTTP-Load Balancer vor UDP-Mediendaten ersetzt weder die Bridge-Erkennung noch die Konferenzzuordnung. Empfehlung: Fügen Sie jede JVB dem Prosody/Jicofo-Bridge-Pool hinzu und veröffentlichen Sie deren erreichbare Medienadresse. Leiten Sie nicht den gesamten Mediendatenverkehr aller Bridges an eine beliebige UDP-VIP.

Häufiger Irrtum: „Mehr Bridges ermöglichen automatisch, dass sich ein Meeting über alle Server erstreckt.“ In der Basiskonfiguration ordnet Jicofo jeder Konferenz eine Bridge zu. Die Verteilung von Teilnehmern einer Konferenz über verschiedene Regionen oder Bridges hinweg erfolgt über eine separate Relay-Topologie namens Octo (in der aktuellen JVB-Dokumentation als „Secure Relays“ bezeichnet). Empfehlung: Verwenden Sie zunächst das normale Bridge-Pooling, wenn Sie mehr gleichzeitige Meetings wünschen. Octo sollten Sie erst dann in Betracht ziehen, wenn eine Konferenz Bridges an mehreren Standorten nutzen muss oder Sie dieses Relay-Verhalten benötigen.

Planen Sie den Brückenpool vor der Installation

Wählen Sie für jedes JVB einen öffentlichen, stabilen Hostnamen oder eine Adresse. Weisen Sie jeder VM eine eindeutige Betriebssystemidentität und einen eindeutigen JVB-Instanznamen zu, wenn die Konfiguration XMPP MUC Presence verwendet. Alle Bridges müssen denselben Prosody-Dienst und Bridge Brewery Room erreichen können. Achten Sie auf einheitliche Versionen: Jicofo mischt keine Bridges mit unterschiedlichen Versionen in derselben Konferenz, und die aktuelle Relay-Dokumentation wiederholt diese Einschränkung für Octo.

Das hängt von Ihrer Umgebung ab: Es gibt keine allgemeingültige Anzahl von Teilnehmern pro VM. Jitsis eigene Anforderungsdokumentation legt den Fokus auf Netzwerkkapazität und Auslastung statt auf eine feste Größe. Codec, Auflösung, Simulcast, Paketraten, gleichzeitige Konferenzen und die Bandbreite Ihres Anbieters beeinflussen die Kapazität. Vorgehensweise: Ermitteln Sie zunächst Ihre tatsächliche Auslastung und fügen Sie dann schrittweise weitere Bridges hinzu. Beobachten Sie dabei CPU-Auslastung, Netzwerkdurchsatz, Paketverlust und Konferenzqualität.

Mehrere JVB-Server Schritt für Schritt konfigurieren

1. Stellen Sie sicher, dass der vorhandene Meet-Host betriebsbereit ist.

Bevor Sie Maschinen hinzufügen, überprüfen Sie, ob die bestehende Meet-Seite geladen wird, Prosody und Jicofo ausgeführt werden und ein Testanruf über die aktuelle Bridge erfolgreich ist. Notieren Sie sich die Jitsi-Paketversionen. Eine fehlerhafte Signalisierung oder Zertifikatskonfiguration auf dem Core-Server kann dazu führen, dass eine neue Bridge als falsch konfiguriert erscheint, selbst wenn das Netzwerk einwandfrei funktioniert.

Bei einer Debian/Ubuntu-Paketinstallation sollten Sie die Dienste überprüfen systemctl status prosody jicofo jitsi-videobridge2und die Dienstprotokolle einsehen. Verwenden Sie die in Ihrer Installation vorhandenen Dienstnamen; containerisierte Bereitstellungen verwenden andere Befehle und Protokollspeicherorte.

2. DNS-, Routing- und Firewall-Regeln vorbereiten

Weisen Sie jeder Bridge eine eigene öffentliche Adresse oder eine korrekt konfigurierte 1:1-NAT-Zuordnung zu. Die Anleitung zur skalierbaren Einrichtung beschreibt folgende typische Pfade: Öffentliche Clients erreichen den Webhost über TCP 80/443; JVB-Server erreichen Prosody über TCP 5222; und Clients erreichen jede Videobridge über UDP 10000 für Medienübertragungen. TCP 80 wird im Allgemeinen für Zertifikats- oder Umleitungskonfigurationen verwendet, während eine produktive Meet-Website HTTPS nutzen sollte.

• Erlauben Sie eingehende UDP-Verbindungen über Port 10000 zu jeder Bridge von den Teilnehmernetzwerken, die Ihr Dienst unterstützt.
• Erlauben Sie die Bridge-to-Prosody-TCP-Verbindung 5222 von den JVB-Hosts und beschränken Sie sie auf diese Hosts, wenn Ihre Firewall dies zulässt.
• Halten Sie den Prosody/XMPP-Dienst nach Möglichkeit auf die vorgesehene Infrastruktur beschränkt.
• Private HTTP/Debug-Endpunkte von JVB dürfen nicht öffentlich zugänglich gemacht werden. Wenn Sie einen öffentlichen Colibri-WebSocket-Endpunkt aktivieren oder per Proxy verwenden, befolgen Sie die aktuelle JVB- und Reverse-Proxy-Dokumentation für diese spezifische Bereitstellung.

Dies hängt von Ihrem Netzwerk ab: NAT, Cloud-Sicherheitsgruppen, IPv6, TURN und restriktive Unternehmensnetzwerke erfordern möglicherweise zusätzliche Ports oder Pfade. Die Standard-Portliste ist kein Beweis dafür, dass die Medienübertragung durch Ihre Firewall funktioniert. Empfehlung: Überprüfen Sie den Paketfluss zu jeder öffentlichen Bridge-Adresse von einem externen Client-Netzwerk aus und testen Sie einen tatsächlichen Anruf. Eine erfolgreiche XMPP-Verbindung allein bestätigt nicht die UDP-Medienübertragung.

3. Installieren Sie auf jedem Knoten dasselbe Jitsi Videobridge-Paket.

Verwenden Sie das Jitsi-Repository und die Paketierungsanweisungen, die zur Distribution des Meet-Hosts passen. Installieren Sie auf jedem neuen Debian/Ubuntu-Knoten jitsi-videobridge2das Paket und geben Sie bei der Konfiguration den Meet-Hostnamen gemäß der offiziellen Anleitung für die skalierbare Einrichtung ein. Laut Handbuch benötigt die Bridge für die dokumentierte paketbasierte Einrichtung nach der Installation keine weiteren Änderungen über die Standardeinstellungen hinaus.

Installieren Sie nicht auf jeder Bridge einen vollständigen zweiten Jitsi Meet-Stack, es sei denn, Sie wünschen bewusst unabhängige Meet-Bereitstellungen. Bei einem Bridge-Pool sollten Web-, Prosody- und Jicofo-Rollen auf dem Core-Host verbleiben und JVB-Dienste auf den anderen Maschinen hinzugefügt werden. Verwenden Sie im gesamten Pool dieselbe unterstützte JVB-Version; führen Sie Upgrades gestaffelt durch, um einen Pool mit gemischten Versionen nicht länger als nötig zu belassen.

4. Brückenregistrierung und Identität überprüfen.

Bei der paketbasierten Einrichtung lassen Sie zunächst die offizielle Paketkonfiguration die erwarteten Einstellungen generieren. Die JVBs müssen sich mit Prosody verbinden und ihre Bridge-Präsenz an denselben Brewery-MUC melden, den Jicofo überwacht. Wenn Sie den aktuellen XMPP-Client-Konfigurationspfad verwenden, finden Sie die relevanten Informationen in der JVB-Dokumentation unter `<JVB-Konfigurationspfad>` videobridge.statsund videobridge.apis.xmpp-client.configs`<JVB-Konfigurationspfad>`. Jicofo muss sich über `<JVB-Konfigurationspfad>` mit der entsprechenden Brewery verbinden jicofo.bridge.brewery-jid.

Eine typische moderne Konfiguration hat diese Form; ersetzen Sie alle Beispielwerte durch die Werte Ihrer Installation und schützen Sie das gemeinsame Geheimnis:

videobridge {
  stats {
    enabled = true
    transports = [{ type = "muc" }]
  }
  apis {
    xmpp-client {
      configs {
        xmpp-server-1 {
          hostname = "meet.example.com"
          domain = "auth.meet.example.com"
          username = "jvb"
          password = "REPLACE_WITH_SECRET"
          muc_jids = "JvbBrewery@internal.auth.meet.example.com"
          muc_nickname = "bridge-01"
        }
      }
    }
  }
}

Verwenden Sie für jede Bridge einen anderen Nicknamen muc_nickname(z. B. `<bridge1>` bridge-02und ` bridge-03<bridge2>`). Das JVB-Projekt weist darauf hin, dass Nicknamen instanzübergreifend eindeutig sein müssen. Der genaue Name der Konfigurationsdatei und ob dieser explizite Block erforderlich ist, hängen von Ihrem Paket und Ihrer bestehenden Konfiguration ab. Vermeiden Sie es, eine manuell erstellte, moderne Konfiguration über die generierten Einstellungen eines älteren Pakets zu legen, ohne vorher die Dokumentation der installierten Version zu prüfen.

5. Starten Sie den Dienst und überprüfen Sie die Protokolle.

Starten Sie JVB auf jedem neuen Host neu oder starten Sie es, und prüfen Sie anschließend, ob es aktiv bleibt und eine Verbindung zu Prosody herstellt. Die Anleitung zur skalierbaren Einrichtung empfiehlt, die Prosody- und Jicofo-Protokolle zu überprüfen, um die Bridge-Verbindungen zu bestätigen und sicherzustellen, dass Jicofo die Bridges erkennt. Falls eine Bridge nicht angezeigt wird, prüfen Sie in dieser Reihenfolge: DNS-Auflösung und Erreichbarkeit von TCP-Port 5222; XMPP-Zugangsdaten und Domain; korrekte Schreibweise des Brauerei-MUC; doppelte Nicknames; und schließlich die JVB/Jicofo-Versionskompatibilität.

6. Führen Sie auf jeder Brücke einen externen Medientest durch.

Starten Sie mehrere neue Testkonferenzen und prüfen Sie, ob Jicofo diese im Laufe der Zeit auf die verfügbaren Konferenzen verteilt. Dass eine Konferenz auf einer Brücke landet, ist normal und deutet nicht auf einen Fehler beim Lastausgleich hin. Nutzen Sie die Debug-Schnittstelle von Jicofo (sofern aktiviert und zugriffsbeschränkt), um verfügbare Brücken und aktive Konferenzen zu überprüfen. Die JVB-Dokumentation enthält curl http://localhost:8888/debugein Beispiel für lokales Debugging; schützen Sie die Diagnoseschnittstellen durch Bindung oder Firewall, damit diese privat bleiben.

Testen Sie mit Clients außerhalb des Servernetzwerks. Stellen Sie sicher, dass Audio und Video funktionieren, und überprüfen Sie anschließend die ausgewählte Bridge-Adresse und den UDP-Flow. Falls eine Bridge in Jicofo angezeigt wird, Anrufe aber nur bei Auswahl dieser Bridge fehlschlagen, untersuchen Sie deren öffentliche Adresse, NAT-Mapping, UDP-Firewall und die angekündigten Kandidaten. Halten Sie während Wartungsarbeiten eine Bridge ausschließlich über ein unterstütztes Deaktivierungs- oder Bereitstellungsverfahren für Ihre installierte Version außer Betrieb; der Neustart einer aktiven Bridge kann die ihr zugewiesenen Meetings unterbrechen.

Wann sollte man Octo aktivieren?

Octo ist das richtige Thema, wenn eine Konferenz mehrere Bridges nutzen soll, häufig weil die Teilnehmer über verschiedene Regionen verteilt sind. Es ist keine Voraussetzung für die Hinzufügung von JVBs für normale Kapazitäten. Die aktuelle JVB-Relay-Dokumentation erfordert eine Relay-Konfiguration auf jeder beteiligten Bridge, Colibri WebSockets für Bridge-zu-Bridge-Verbindungen und eine geeignete Jicofo-Bridge-Auswahlstrategie. Regionsabhängiges Verhalten hängt außerdem davon ab, dass der bereitgestellten Meet-Konfiguration genaue Client-Regionsinformationen zur Verfügung gestellt werden.

Eine Relay-Konfiguration umfasst eine eindeutige relay-idRegion für jede Bridge, während Jicofo Octo aktiviert und eine Strategie auswählt RegionBasedBridgeSelectionStrategy. Relay-WebSocket-Endpunkte müssen zudem korrekt über jeden Proxy geleitet werden. Diese Einstellungen variieren je nach Version und Topologie. Befolgen Sie daher die aktuelle Relay-Anleitung und überprüfen Sie die genauen Proxy-Pfade vor der Implementierung.

Empfehlung: Lassen Sie Octo für einen einfachen Bridge-Pool mit einer Region deaktiviert. Falls Sie mehrere Regionen benötigen, testen Sie die dokumentierte Aufteilungsstrategie in einer Testumgebung, prüfen Sie den Bridge-Selektor und den Konferenzstatus von Jicofo und konfigurieren Sie anschließend die Client-Regionen und die regionsbasierte Auswahl. Legen Sie keine Regionsbezeichnungen fest, bevor Sie wissen, wie die Clients die entsprechenden Regionsmetadaten erhalten.

Was Sie bei der Skalierung überwachen sollten

• Netzwerk: Ausgehender und eingehender Durchsatz, Paketverluste, Jitter und ob UDP 10000 von realen Client-Netzwerken aus erreichbar ist.
• Host-Auslastung: CPU, Arbeitsspeicher, JVM-Status und anhaltende Paketrate. Die Größe basiert auf repräsentativen Meetings und nicht auf einer angenommenen universellen Anrufanzahl.
• Pool-Mitgliedschaft: Brückenpräsenz in Jicofo, Versionskonsistenz und die Möglichkeit, neu erstellte Konferenzen auf jedem Knoten zu platzieren.
• Teilnehmererfahrung: Audiokontinuität, Videoaussetzer, Verbindungsabbrüche und Qualität unter der erwarteten Spitzenlast.

Melden Benutzer Probleme nur bei einem JVB, vergleichen Sie dessen Netzwerkpfad und Konfiguration mit einem funktionierenden Peer, bevor Sie den gesamten Cluster erweitern. Wenn alle Bridges gleichzeitig beeinträchtigt sind, liegt der Engpass möglicherweise in der gemeinsam genutzten Bandbreite, den Kernsignalisierungsdiensten oder dem Teilnehmernetzwerk. Die Skalierung funktioniert, wenn neue Bridges unabhängig erreichbar und korrekt registriert sind und die Last in realistischen Tests messbar reduzieren.

Offizielle Referenzen

• Jitsi-Handbuch: DevOps-Leitfaden (skalierbare Einrichtung)
• Jitsi-Handbuch: Anforderungen
• Jitsi Videobridge: MUC-Konfiguration
• Jitsi Videobridge: Relay (Octo)-Setup
• Jitsi Videobridge: HTTP- und REST-Schnittstellen