Software & Collaboration

Jitsi Meet

Jitsi Meet ist eine quelloffene, WebRTC-basierte Videokonferenz-Plattform, die im Browser ohne Plugin läuft und self-hostbar ist; Medienverteilung über eine SFU.

  • WebRTC im Browser, kein Plugin
  • SFU statt MCU
  • DTLS-SRTP, optional E2EE
  • Self-Hosting, Datenhoheit
  • Apache-2.0-Lizenz
Von Andreas Huser, Technische Beratung & Architektur Aktualisiert am 9 Min. Lesezeit

Jitsi Meet ist eine quelloffene Videokonferenz-Plattform, die vollständig im Browser läuft, ohne Plugin oder Client-Installation für die Teilnehmer. Sie lässt sich selbst hosten und gibt damit die volle Kontrolle über die Konferenzdaten ins eigene Haus.

Dieser Artikel erklärt die Komponenten und das SFU-Prinzip, die Bandbreiten-Optimierung über Simulcast und Last-N, die Verschlüsselungslage (Transport-Schutz gegenüber optionalem Ende-zu-Ende), die Zugangskontrolle, die Rolle des TURN-Servers sowie die Skalierung und ihre Grenzen.

1. Komponenten und SFU-Prinzip

Jitsi Meet ist ein Verbund mehrerer Dienste: die Jitsi Videobridge (JVB) als Medienserver, Prosody für die Signalisierung, Jicofo für die Konferenzverwaltung und das Web-Frontend. Optional kommen Jibri (Aufzeichnung/Streaming) und Jigasi (Telefon-Einwahl) hinzu. Die JVB arbeitet als SFU (Selective Forwarding Unit): Sie leitet die Streams der Teilnehmer weiter, statt sie wie eine MCU serverseitig zu einem Bild zu mischen. Das spart erheblich Server-CPU und hält die Latenz niedrig.

2. Bandbreite: Simulcast und Last-N

Damit die Bandbreite nicht explodiert, sendet jeder Teilnehmer sein Video in mehreren Qualitätsstufen gleichzeitig (Simulcast); die Videobridge wählt pro Empfänger die passende Stufe. Zusätzlich begrenzt Last-N die Zahl der gleichzeitig empfangenen Videostreams auf die zuletzt aktiven Sprecher, der Rest läuft als Audio. So bleibt die Downstream-Last auch in größeren Konferenzen beherrschbar.

3. Verschlüsselung: Transport gegenüber Ende-zu-Ende

Hier ist Genauigkeit wichtig. Standardmäßig sind die Verbindungen mit DTLS-SRTP verschlüsselt, aber das ist Transport-Verschlüsselung Hop für Hop: Die Videobridge entschlüsselt die Streams kurzzeitig im Arbeitsspeicher, um sie weiterzuleiten. Das ist kein echtes Ende-zu-Ende-Schutz. Bei Self-Hosting liegt diese Bridge unter eigener Kontrolle. Es gibt zusätzlich ein optionales echtes E2EE über die Insertable-Streams-Technik des Browsers, das aber browserabhängig ist (nicht in iOS-Browsern), manuell aktiviert werden muss, die Teilnehmerzahl auf etwa 20 begrenzt und mit Aufzeichnung und Telefon-Einwahl nicht zusammenarbeitet.

DTLS-SRTP heißt nicht Ende-zu-Ende. Wer echtes E2EE braucht, muss die Browser- und Funktionsgrenzen des optionalen Jitsi-E2EE kennen, sonst verspricht man mehr Schutz, als geliefert wird.

4. Zugang kontrollieren

Standardmäßig kann jeder mit der Raum-URL eine Konferenz betreten oder starten. Für den Produktivbetrieb stehen mehrere Mittel bereit: eine Lobby (Moderator lässt Teilnehmer einzeln ein), ein Raumpasswort und vor allem die JWT-Authentifizierung über ein Prosody-Modul, das eine Anbindung an externe Identitätsquellen erlaubt. Das ältere „Secure Domain“-Verfahren ist offiziell als veraltet markiert und sollte in neuen Installationen nicht mehr eingesetzt werden.

5. TURN und Skalierung

Für Teilnehmer hinter restriktiven Firewalls ist ein TURN-Server (coturn) praktisch Pflicht, weil ein Teil des Verkehrs sonst nicht durchkommt; TURN über Port 443 umgeht die meisten Sperren. Über eine einzelne Videobridge hinaus skaliert Jitsi mit mehreren Bridges (Octo/kaskadierte Bridges), die Jicofo verteilt. Eine einzelne Bridge trägt grob in der Größenordnung von Dutzenden bis etwa hundert Video-Teilnehmern; darüber wird horizontal skaliert.

6. Datenhoheit

Selbst gehostet bleiben alle Medien, Signalisierung und Metadaten auf dem eigenen Server, ohne US-Drittanbieter, was Jitsi für datenschutzsensible Einsätze attraktiv macht. Der öffentliche Dienst meet.jit.si wird dagegen von einem US-Unternehmen betrieben, nutzt Analyse-Werkzeuge und verlangt seit einiger Zeit eine Anmeldung zum Starten von Konferenzen.

7. Stärken und Grenzen

StärkenGrenzen
Browserbasiert, kein Plugin, einfacher ZugangStandard-Verschlüsselung ist Transport-, kein E2EE
SFU spart Server-CPU, geringe Latenzoptionales E2EE browserabhängig, begrenzt, ohne Aufzeichnung
Self-Hosting, volle Datenhoheit (Apache-2.0)Videobridge ist Bandbreiten- und Ressourcen-Engpass
Simulcast/Last-N für effiziente BandbreiteTURN-Server in der Praxis fast immer nötig
Skalierung über mehrere VideobridgesSkalierung und Tuning operativ anspruchsvoll

Häufige Fragen zu Jitsi Meet

Standardmäßig nicht. Die Verbindungen sind mit DTLS-SRTP transportverschlüsselt, aber die Videobridge entschlüsselt die Streams kurzzeitig, um sie weiterzuleiten, das ist Hop-by-Hop-Schutz, kein echtes Ende-zu-Ende. Es gibt ein optionales echtes E2EE über die Insertable-Streams-Technik, das jedoch browserabhängig ist, manuell aktiviert werden muss, die Teilnehmerzahl begrenzt und mit Aufzeichnung oder Telefon-Einwahl nicht funktioniert.

Weil ein Teil der Teilnehmer hinter restriktiven Firewalls oder symmetrischem NAT sitzt, durch die der direkte WebRTC-Medienstrom nicht kommt. Ein TURN-Server (coturn) relayt diesen Verkehr; betreibt man ihn auf Port 443, umgeht er die meisten Firewall-Sperren. Ohne TURN funktionieren Konferenzen für viele Nutzer in Unternehmensnetzen unzuverlässig oder gar nicht.

Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.

Der nächste Schritt

Jitsi Meet im eigenen Haus richtig einsetzen?

Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.

Erstgespräch vereinbaren oder Formular ausfüllen