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
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ärken | Grenzen |
|---|---|
| Browserbasiert, kein Plugin, einfacher Zugang | Standard-Verschlüsselung ist Transport-, kein E2EE |
| SFU spart Server-CPU, geringe Latenz | optionales 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 Bandbreite | TURN-Server in der Praxis fast immer nötig |
| Skalierung über mehrere Videobridges | Skalierung 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.