Self-hosted Videokonferenzen auf VPS: Bandbreite planen

Self-hosted Videokonferenzen auf einem VPS sind ein Bandbreitenproblem

Self-hosted Videokonferenzen scheitern auf kleinen Servern aus einem Grund, und dieser liegt fast nie an der Installation. Die Server-Komponente, die jedes moderne Werkzeug verwendet, ist eine SFU (Selective Forwarding Unit). Sie empfängt einen Videostream von jedem Teilnehmer und leitet eine Kopie an alle anderen Teilnehmer weiter. Daher wächst der ausgehende Datenverkehr des Servers quadratisch mit der Anzahl der Teilnehmer. Ein 1 GB oder 2 GB VPS mit einer geteilten Uplink-Anbindung führt die Software zwar problemlos aus. Er wird jedoch nicht die von Ihnen angestrebte Vollversammlung bewältigen.

Gehen Sie bei der Arbeit daher in dieser Reihenfolge vor: Zählen Sie die Personen, berechnen Sie die benötigten Megabit und wählen Sie erst dann den Server aus. Die Installation dauert zwanzig Minuten durch Kopieren und Einfügen. Die Uplink-Bandbreite entscheidet darüber, ob man Sie hören kann.

Warum wächst der Bandbreitenbedarf mit dem Quadrat der Teilnehmerzahl?

Beginnen wir mit einem Mesh. Jeder Browser codiert sein Kamerabild und sendet eine Kopie direkt an jeden anderen Browser. Kein Media-Server verarbeitet das Video. Ein Mesh-Anruf mit zwei Personen benötigt einen Signalisierungsserver sowie ein TURN-Relay für Anrufe, bei denen die beiden Browser keine direkte Verbindung herstellen können. Deshalb sind Einzelanrufe beim Hosting fast kostenlos. Mesh funktioniert ab etwa vier oder fünf Personen nicht mehr zuverlässig, weil ein Laptop an einem privaten Internetanschluss gleichzeitig vier oder fünf separate Kopien seines eigenen Videos hochladen muss.

Ein SFU arbeitet anders. Jeder Browser lädt eine Kopie zum Server hoch. Der Server liest die RTP-Header (Real-Time Transport Protocol) und leitet die Pakete an die anderen Teilnehmer weiter, ohne das Video zu decodieren. Das ist der gesamte entscheidende Mechanismus. Deshalb benötigt ein SFU wenig CPU, aber viel Netzwerkbandbreite.

Die ältere Architektur ist ein MCU (Multipoint Control Unit). Es decodiert jeden eingehenden Stream, fügt sie zu einem Bild zusammen und codiert dieses Bild erneut. Die ausgehende Bandbreite ist gering. Die CPU-Kosten sind enorm. Für Video verwendet heute fast niemand mehr ein MCU. Auch in diesem Leitfaden kommt keines zum Einsatz.

Nun zur Berechnung für ein SFU. Angenommen, jede Person sendet Video mit 1.2 Mbps und niemand hat die Kamera ausgeschaltet. Der Server empfängt N mal 1.2 Mbps. Das wächst linear und ist unkritisch. Der Server sendet N mal (N minus 1) mal 1.2 Mbps, weil jede der N Personen die übrigen N minus 1 Streams empfangen muss. Dieser zweite Wert beendet Projekte.

[
  {
    "label": "4 people",
    "sfu_egress_mbps": 14.4,
    "egress_gb_per_hour": 6.5,
    "monthly_volume_tb": 0.13
  },
  {
    "label": "8 people",
    "sfu_egress_mbps": 67.2,
    "egress_gb_per_hour": 30.2,
    "monthly_volume_tb": 0.6
  },
  {
    "label": "15 people",
    "sfu_egress_mbps": 252,
    "egress_gb_per_hour": 113.4,
    "monthly_volume_tb": 2.3
  },
  {
    "label": "30 people",
    "sfu_egress_mbps": "1,044",
    "egress_gb_per_hour": 469.8,
    "monthly_volume_tb": 9.4
  },
  {
    "label": "50 people",
    "sfu_egress_mbps": "2,940",
    "egress_gb_per_hour": "1,323",
    "monthly_volume_tb": 26.5
  }
]

Diese Zeilen sind Berechnungen und keine Messwerte eines bestimmten Servers. Die Monatsspalte setzt zwanzig Stunden Gespräche pro Monat voraus. Lesen Sie zuerst die letzte Zeile. Fünfzig Personen mit eingeschalteter Kamera benötigen 2,940 Mbps dauerhaft ausgehenden Datenverkehr von einer einzelnen Maschine. Dreißig Personen benötigen 1,044 Mbps. Vier Personen benötigen 14.4 Mbps. Das verarbeitet jeder VPS, ohne dass es auffällt. Zwischen der Zeile mit vier Personen und der Zeile mit dreißig Personen wächst die Teilnehmerzahl um das Siebeneinhalbfache, während der ausgehende Datenverkehr um mehr als das Siebzigfache wächst.

In realen Deployments liegen die Werte unter diesen Zahlen. Es ist wichtig zu wissen, warum. Jitsi und LiveKit verwenden beide Simulcast: Ein Sender veröffentlicht gleichzeitig mehrere Qualitätsstufen. Das SFU leitet eine niedrige Qualitätsstufe an Teilnehmer weiter, die nicht auf dem Bildschirm angezeigt werden. Jitsi verfügt außerdem über eine last-N-Einstellung. Sie leitet Video nur von den zuletzt aktiven Sprechern weiter. Beides spart viel Datenverkehr. Die Form der Kurve ändert sich dadurch nicht. Beide Verfahren helfen nicht mehr, sobald alle ihre Kamera einschalten und die Videos der jeweils anderen Teilnehmer anheften.

Was bietet Ihnen ein VPS-Uplink tatsächlich?

Eine Angebotsseite nennt einen "1 Gbps Port". Dies ist die Geschwindigkeit der virtuellen Netzwerkkarte, keine Garantie für den nächsten Netzwerkknoten. Die Anbindung wird mit anderen Mietern auf demselben physischen Host geteilt. Daher ist der dauerhafte Durchsatz während der Stoßzeiten geringer als die Portgeschwindigkeit. Eine Videokonferenz erzeugt genau eine solche dauerhafte Last. Die meisten Tarife beinhalten zudem ein monatliches Transfervolumen, nach dessen Verbrauch die Geschwindigkeit gedrosselt oder eine Gebühr erhoben wird.

Dieses Volumen ist der Punkt, an dem die Kosten auf der Rechnung steigen. Zwanzig Stunden eines Gesprächs mit dreißig Personen bewegen in einem Monat 9.4 TB aus dem Server, bei 469.8 GB pro Stunde. Zwanzig Stunden eines Gesprächs mit fünfzig Personen bewegen 26.5 TB. Prüfen Sie das Transferlimit, bevor Sie auf den Arbeitsspeicher achten. Wenn die Angebotsseite hierzu vage bleibt, ist diese Unschärfe bereits Ihre Antwort. Ein günstiges VPS-Angebot richtig lesen ist für diese Art von Arbeitslast wichtiger als für fast jede andere.

Jitsi Meet: die Standardempfehlung und ihre Voraussetzungen

Jitsi Meet ist für die meisten der beste Ausgangspunkt. Die Installation erfolgt aus dem eigenen Debian-Repository des Projekts. Während der Installation konfiguriert das Paket nginx und ein Zertifikat. Die Videobridge (JVB) verwendet nur einen UDP-Port. Dadurch bleiben die Firewall-Regeln übersichtlich. Seit Oktober 2026 führt das Handbuch Debian 12 (Bookworm) oder neuer sowie Ubuntu 24.04 (Noble Numbat) oder neuer als unterstützte Versionen auf. Außerdem wird OpenJDK 17 vorausgesetzt.

sudo apt update
sudo apt install -y apt-transport-https curl gnupg
sudo add-apt-repository universe
sudo apt update
sudo curl -sL https://prosody.im/files/prosody-debian-packages.key -o /usr/share/keyrings/prosody-debian-packages.key
echo "deb [signed-by=/usr/share/keyrings/prosody-debian-packages.key] http://packages.prosody.im/debian $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/prosody-debian-packages.list
sudo apt install -y lua5.2
curl -sL https://download.jitsi.org/jitsi-key.gpg.key | sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg'
echo "deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/" | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
sudo apt update
sudo apt install -y jitsi-meet

Das Installationsprogramm fragt nach einem Hostnamen und bietet anschließend eine Zertifikatsauswahl an. Wählen Sie die Option Let's Encrypt. Verwenden Sie einen Domainnamen, der bereits auf die öffentliche Adresse dieses Servers aufgelöst wird. Das Zertifikat wird über eine HTTP-Challenge ausgestellt. Ein Name, der auf ein anderes Ziel zeigt, führt an dieser Stelle zu einem Fehler.

Öffnen Sie anschließend die Ports. Das Handbuch dokumentiert die folgenden Ports. SSH steht an erster Stelle, damit ufw enable Sie nicht aussperrt:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp
sudo ufw enable

TCP 80 und 443 stellen die Webanwendung bereit und ermöglichen die Zertifikatserneuerung. UDP 10000 überträgt Audio und Video für jeden Anruf, der über die Bridge läuft. Dieser Port wird häufig vergessen. TCP 5349 gehört zum coturn-Server, den das Jitsi-Paket zusammen mit der Bridge installiert. Er ist der Ausweichpfad für Benutzer, deren Netzwerk UDP blockiert. UDP 3478 ist der STUN-Port von coturn. Das Handbuch kennzeichnet ihn als optional, weil Jitsi ihn erst nach einer Änderung an config.js verwendet.

sudo systemctl status jitsi-videobridge2
sudo ss -ulnp | grep 10000

Der erste Befehl sollte den Dienst als aktiv melden. Der zweite sollte anzeigen, dass die Bridge auf UDP 10000 lauscht. Gibt er nichts aus, wurde die Bridge nicht gestartet. /var/log/jitsi/jvb.log zeigt den Grund.

Für die Dimensionierung veröffentlicht das Jitsi-Handbuch einen eigenen Ausgangswert. BigBlueButton nennt einen deutlich höheren Wert:

[
  {
    "label": "Jitsi Meet",
    "ram_gb": 8,
    "cpu_cores": 4,
    "uplink_mbps": "1,000"
  },
  {
    "label": "BigBlueButton 3.0",
    "ram_gb": 16,
    "cpu_cores": 8,
    "uplink_mbps": 250
  }
]

Das Jitsi-Handbuch empfiehlt in der Regel 8 GB RAM. Für einen einfachen Server können demnach 4 dedizierte Kerne ausreichen. Für einen Server für Freunde oder eine kleine Organisation werden häufig 1,000 Mbps Netzwerkbandbreite als ausreichend genannt. Für einen leistungsfähigen Server werden 10 Gbps empfohlen. Kleine Meetings kommen laut Handbuch mit 4 GB aus. Für Testserver reichen 2 GB. Ein Detail dieser Seite sollten Sie beachten: Prosody, der XMPP-Server für die Signalisierung, kann nur einen Kern verwenden. Zusätzliche Kerne unterstützen die Bridge, helfen aber nicht bei der Signalisierung.

Warum treten alle dem Anruf bei, aber niemand sieht ein Videobild?

Das ist der typische Jitsi-Fehler auf einem VPS. Die Teilnehmerliste füllt sich, der Chat funktioniert, und jedes Videobild bleibt schwarz. Die Videobridge veröffentlicht die Adressen, die sie auf ihren eigenen Schnittstellen findet, sowie eine öffentliche Adresse, die sie ermitteln kann. Eine neue Paketinstallation verweist für diese Ermittlung auf einen von Jitsi betriebenen STUN-Server. Im Handbuch steht außerdem, dass sich eine Bridge hinter NAT beim Booten selbst konfigurieren sollte. Wenn die Ermittlung fehlschlägt, zum Beispiel weil ausgehender Datenverkehr zu diesem STUN-Server blockiert wird, veröffentlicht eine Bridge mit privater Adresse nur diese Adresse. Jeder Client versucht dann, Medien an etwas wie 10.0.0.5 zu senden, aber die Pakete erreichen ihr Ziel nicht. Als eigenes Symptom nennt das Handbuch Anrufe, die mit zwei Personen funktionieren und beim Beitritt einer dritten Person fehlschlagen, weil zwei Personen den Peer-to-Peer-Modus verwenden und die Bridge nicht erreichen.

Wenn die Ermittlung nicht ausreicht, teilen Sie der Bridge beide Adressen selbst mit. Fügen Sie in /etc/jitsi/videobridge/jvb.conf eine statische Zuordnung hinzu:

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "10.0.0.5"
          public-address = "203.0.113.10"
        }
      ]
    }
  }
}

Starten Sie den Dienst mit sudo systemctl restart jitsi-videobridge2 neu. Übernehmen Sie die lokale Adresse aus ip -4 addr show und die öffentliche Adresse aus dem Control Panel Ihres Providers. Ältere Anleitungen setzen dasselbe in /etc/jitsi/videobridge/sip-communicator.properties mit den Schlüsseln org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS und org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS. Das funktioniert weiterhin. Bei neuen Installationen sollte jedoch der oben gezeigte Zuordnungsblock verwendet werden.

Eine weitere Ursache ist eine Firewall, die Sie nicht konfiguriert haben. Die meisten Provider betreiben im Control Panel eine Netzwerk-Firewall, die von ufw auf dem Server getrennt ist. UDP 10000 muss in beiden Firewalls geöffnet sein. Um festzustellen, auf welcher Ebene die Pakete verworfen werden, führen Sie sudo tcpdump -ni any udp port 10000 auf dem Server aus, während jemand von außen beitritt. Wenn überhaupt keine Pakete eintreffen, erreicht nichts den Server. Die Sperre liegt dann vor dem Betriebssystem. Wenn Pakete eintreffen, die Videobilder aber schwarz bleiben, antwortet die Bridge mit einer Adresse, die der Client nicht erreichen kann. Dann liegt der Fehler in der Zuordnung. Wenn Sie bei ufw selbst unsicher sind, erklärt die tatsächlich erforderlichen ufw-Regeln für einen VPS die Reihenfolge der Regeln, die häufig zu Problemen führt.

BigBlueButton: umfangreich, festgelegt und auf den ganzen Server ausgelegt

BigBlueButton ist für den Unterricht konzipiert. Es bietet ein Whiteboard, Breakout-Räume, Umfragen und einen Präsentationsbereich. Die Aufzeichnungs-Pipeline ist eine zentrale Funktion und kein nachträglich hinzugefügtes Modul. Im Vergleich zu den anderen Optionen benötigt BigBlueButton mit Abstand die meisten Ressourcen. Außerdem lässt es sich nicht als Paket auf einem bereits eingerichteten Server installieren.

Stand Oktober 2026 ist BigBlueButton 3.0 auf Ubuntu 22.04 der unterstützte Installationsweg. Sie wählen ihn mit dem Versions-Flag jammy-300 aus. BigBlueButton 4.0, das auf Ubuntu 24.04 umstellt, ist bisher nur als Release Candidate verfügbar. Das Projekt empfiehlt für den Produktiveinsatz weiterhin 3.0.x. Laut den veröffentlichten Anforderungen benötigt das System 16 GB Arbeitsspeicher mit aktiviertem Swap, 8 CPU-Kerne mit hoher Single-Thread-Leistung, 250 Mbps symmetrische Bandbreite und 500 GB Speicherplatz, wenn Sie Aufzeichnungen behalten (50 GB, wenn Sie sie deaktivieren). Die benötigten Ports sind TCP 80 und 443 sowie der UDP-Bereich 16384 bis 32768.

wget -q https://raw.githubusercontent.com/bigbluebutton/bbb-install/v3.0.x-release/bbb-install.sh
less bbb-install.sh
bash bbb-install.sh -v jammy-300 -s bbb.example.com -e info@example.com -g

In den eigenen Beispielen des Projekts wird dieses Skript direkt an bash weitergeleitet. Laden Sie es stattdessen herunter und lesen Sie es zuerst. Das Skript überschreibt Ihre nginx-Konfiguration, installiert einen eigenen Media- und Audio-Stack, fixiert Paketversionen und beansprucht den Hostnamen. Das ist so vorgesehen und kein Fehler: BigBlueButton erwartet, den Server vollständig zu verwalten. Das Skript installiert jetzt standardmäßig eine ufw-Firewall. Übergeben Sie -W, um dies zu deaktivieren. Das alte Flag -w wird weiterhin akzeptiert, hat aber keine Wirkung. -s ist der Hostname. -e ist die Adresse, für die Let's Encrypt ein Zertifikat registriert. -g installiert zusätzlich das Greenlight-Frontend. Wenn derselbe Server auch TLS für andere Dienste terminiert, verschieben Sie BigBlueButton entweder auf einen anderen Server oder machen Sie sich mit der Funktion Ihrer nginx-Reverse-Proxy-Konfiguration vertraut, bevor das Skript sie ändert.

Vergleichen Sie die beiden Zeilen in dieser Tabelle sorgfältig. BigBlueButton verlangt doppelt so viel Arbeitsspeicher und doppelt so viele CPU-Kerne wie in der Empfehlung für Jitsi, benötigt aber nur ein Viertel der Bandbreite. Die beiden Werte wurden nicht nach derselben Methode ermittelt und gehen von unterschiedlich großen Räumen aus. Betrachten Sie daher jeden Wert als Ausgangspunkt des jeweiligen Projekts und nicht als direkten Vergleich. Der Unterschied bei der CPU ist real. Er entsteht durch alle Aufgaben, die BigBlueButton zusätzlich zur Weiterleitung von Video übernimmt.

Galène: die kleine Option

Galène ist eine kompakte SFU, die in Go geschrieben ist. Sie wird zu einer einzelnen statischen Binärdatei kompiliert, bringt ihren eigenen Webclient mit und enthält einen TURN-Server. Daher benötigen Sie keinen XMPP-Server, keine Java-Laufzeitumgebung und keine Rails-Anwendung, die dauerhaft ausgeführt werden muss. Wenn Sie einen zuverlässigen Anruf mit zehn Personen auf einer leistungsschwachen Maschine benötigen, probieren Sie Galène aus, bevor Sie von zusätzlicher Hardware ausgehen.

sudo apt update && sudo apt install -y git golang-go
git clone https://github.com/jech/galene
cd galene
CGO_ENABLED=0 go build -ldflags='-s -w'
mkdir groups

Das golang-go-Paket in Ubuntu 24.04 enthält Go 1.22, während Galènes go.mod inzwischen Go 1.24 voraussetzt. Wenn go build meldet, dass das Modul eine neuere Go-Version benötigt, installieren Sie eine aktuelle Toolchain von go.dev, statt das Distributionspaket anzupassen.

Eine Gruppe ist bei Galène die Bezeichnung für einen Raum. Eine Gruppe ist eine JSON-Datei:

echo '{"users": {"vimes": {"password":"sybil", "permissions":"op"}}}' > groups/night-watch.json
./galene &

Öffnen Sie https://your.server:8443/group/night-watch/ und melden Sie sich als vimes an. Diese Zugangsdaten stammen direkt aus der README des Projekts. Ändern Sie sie, bevor der Port von anderer Stelle erreichbar ist. Für einen produktiven Betrieb verwendet die Installationsanleitung des Projekts einen dedizierten galene-Benutzer. Die Binärdatei sowie die Verzeichnisse static, data und groups liegen dabei in dessen Home-Verzeichnis. Beenden Sie die Testinstanz, die Sie mit ./galene & gestartet haben. Führen Sie anschließend im Verzeichnis, in dem Sie die Binärdatei erstellt haben, Folgendes aus:

sudo useradd --system --create-home --home-dir /home/galene --shell /usr/sbin/nologin galene
mkdir -p data
sudo cp -r galene static data groups /home/galene/
sudo chown -R galene:galene /home/galene

Das Projekt dokumentiert dafür folgende systemd-Unit:

[Unit]
Description=Galene
After=network.target

[Service]
Type=simple
WorkingDirectory=/home/galene
User=galene
Group=galene
ExecStart=/home/galene/galene
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Die Ports sind TCP 8443 für die Weboberfläche, TCP und UDP 1194 für den integrierten TURN-Server sowie ein Bereich hoher UDP-Ports für Medien. Die Installationsanleitung sieht dafür einen großen Bereich mit einigen zehntausend Ports vor. Legen Sie daher einen breiten Bereich fest und erstellen Sie dafür eine einzige Firewall-Regel:

./galene -udp-range 30000-65000

Die Option -turn ist auf einem VPS entscheidend. -turn ':1194' lauscht an allen öffentlichen IPv4-Adressen. -turn '203.0.113.1:1194' teilt Galène die Adresse mit, die Clients tatsächlich sehen. Das ist erforderlich, wenn die eigene Adresse des Computers privat ist. -turn '' deaktiviert den integrierten Server, sodass Sie über data/ice-servers.json auf einen externen Server verweisen können. Der Standardwert ist auto. Wenn kein ice-servers.json vorhanden ist, verhält er sich wie :1194.

Sie können nginx vor die Weboberfläche setzen, indem Sie proxyURL in data/config.json festlegen und den Standort /ws mit den Headern für das WebSocket-Upgrade als Proxy weiterleiten. Beachten Sie den Umfang dieser Konfiguration: Clients stellen weiterhin direkte UDP-Datenströme und direkte TCP-Verbindungen zum TURN-Port her. Der Reverse Proxy verarbeitet daher nur die Seite und die Signalisierung. Die Medienübertragung läuft nicht über ihn.

Laut der README von Galène benötigt die Software nur sehr moderate Serverressourcen. Auf der Projekt-Website werden dazu grobe Richtwerte genannt: etwa 20 Teilnehmer pro Kern in einer einzelnen Besprechung gegenüber etwa 300 Teilnehmern pro Kern bei einer Vorlesung. Der Grund ist, dass die Last einer Besprechung quadratisch mit der Teilnehmerzahl wächst. Die oben dargestellte Bandbreitenberechnung gilt weiterhin vollständig. Sie sparen Speicher und vermeiden die zusätzlichen Komponenten aller Dienste, die nicht zur SFU gehören.

Owncast: Eins-zu-viele, während die Bandbreite linear bleibt

Viele Anforderungen an „Videokonferenzen“ bestehen eigentlich darin, dass eine Person einem Publikum etwas präsentiert, das im Chat schreibt. Wenn das auf Ihren Anwendungsfall zutrifft, ist ein SFU das falsche Werkzeug, und die Kostenstruktur ändert sich vollständig. Owncast nimmt einen RTMP-Stream von OBS oder einem ähnlichen Encoder entgegen und stellt HLS über gewöhnliches HTTPS bereit. Die Bandbreite pro Zuschauer steigt linear statt quadratisch. Da die Ausgabe aus gewöhnlichen HTTP-Segmenten besteht, können Sie sie hinter Object Storage oder einem CDN bereitstellen und die Kosten dafür am Origin vermeiden.

curl -sL https://owncast.online/install.sh -o install-owncast.sh
less install-owncast.sh
bash install-owncast.sh

In der Dokumentation des Projekts wird empfohlen, den Dienst nicht als root auszuführen und jedes Remote-Skript vor der Ausführung zu prüfen. Deshalb ist der Download oben ein separater Schritt. Das Installationsprogramm lädt das aktuelle Release und eine ffmpeg-Binärdatei herunter, falls noch keine vorhanden ist. Führen Sie ./owncast aus dem Installationsverzeichnis aus und öffnen Sie das Admin-Panel unter /admin auf Port 8080. Die Standardanmeldung verwendet den Benutzer admin und das Passwort abc123. Der Standard-Stream-Key lautet ebenfalls abc123. Er ist jedoch eine separate Einstellung. Ändern Sie beide Werte, bevor Sie eine Domain auf den Server zeigen lassen.

Aus dem HLS-Design ergeben sich zwei Folgen. Zuschauer sehen die Übertragung mit einigen Sekunden oder Minuten Verzögerung, weil HLS vollständige Segmente ausliefert. Eine Unterhaltung in beide Richtungen ist daher nicht möglich. Außerdem kommen auf dem gesamten Pfad weder UDP noch TURN zum Einsatz. Dadurch erreicht Owncast Netzwerke, in denen eine WebRTC-Verbindung überhaupt nicht aufgebaut werden kann.

Owncast ist außerdem das einzige Tool in diesem Abschnitt, das absichtlich transcodiert. Jede aktivierte Ausgabequalität erfordert eine weitere ffmpeg-Codierung des eingehenden Streams, die während der gesamten Übertragung läuft. Bieten Sie auf einem kleinen VPS eine oder zwei Qualitätsstufen an. Bei fünf Qualitätsstufen ist die CPU ausgelastet, während das Netzwerk ungenutzt bleibt.

Element Call auf einem bereits betriebenen Matrix-Server

Wenn Sie bereits Matrix betreiben, ist Video eine Erweiterung und kein zweites zu verwaltendes Produkt. Dafür ist jedoch mehr als ein Paket erforderlich. Element Call benötigt zwei Komponenten hinter Ihrem Homeserver. Die erste ist eine LiveKit-SFU, die die Medien weiterleitet. Die zweite ist der MatrixRTC-Autorisierungsdienst, element-hq/lk-jwt-service. Er stellt das signierte JWT (JSON Web Token) aus, das ein Matrix-Benutzer der LiveKit-SFU vorlegt. Aktuelle Versionen sind für den Betrieb als Application Service auf Ihrem Homeserver vorgesehen. Dieser proxy stellt die LiveKit-Endpunkte sowohl über die Client-API als auch über die Federation-API bereit. Der ältere Standalone-Modus, bei dem Clients direkt mit dem Dienst kommunizieren, wird weiterhin unterstützt, ist aber veraltet. In beiden Fällen empfiehlt das Projekt einen TLS-Reverse-Proxy davor. Ihr .well-known/matrix/client muss Clients auf diesen Proxy verweisen.

Die dokumentierten Ports von LiveKit:

• TCP 7880 für die API und den Client-WebSocket, hinter einem Proxy, der TLS terminiert
• TCP 7881 für ICE über TCP, wenn ein Client keine ausgehenden Verbindungen über UDP herstellen kann
• UDP 50000 bis 60000 für Medien; jeder Teilnehmer eines Raums verwendet zwei Ports
• UDP 3478 und TCP 5349, wenn Sie den integrierten TURN-Server aktivieren; 5349 muss auf 443 verschoben werden, sofern kein Load Balancer davor sitzt

Zwei Ports pro Teilnehmer klingen problematisch, sind es aber nicht. Ein Portbereich mit 10,000 Ports reicht für Tausende von Teilnehmern aus. Ihr Uplink ist lange vor dem Ende dieses Bereichs ausgelastet. Öffnen Sie trotzdem den gesamten Bereich. Ein teilweise geöffneter Bereich führt dazu, dass es bei einigen Benutzern funktioniert und bei anderen fehlschlägt. Das ist die ungünstigste Art von Fehler für die Fehlersuche. Die Einrichtung auf der Homeserver-Seite ist eine eigene Aufgabe. Sie wird in einen Synapse-Homeserver auf einem VPS betreiben beschrieben.

Warum kann eine Person keine Verbindung herstellen? TURN und Netzwerke, die UDP blockieren

Zuerst ein wenig Vokabular, das jeweils einmal verwendet wird. ICE (Interactive Connectivity Establishment) ist der Prozess, den zwei WebRTC-Endpunkte nutzen, um einen funktionierenden Pfad zwischen sich zu finden. STUN (Session Traversal Utilities for NAT) ist ein kleiner Dienst, der einem Client mitteilt, wie seine eigene öffentliche Adresse von außen aussieht. TURN (Traversal Using Relays around NAT) ist ein Relay: Wenn kein direkter Pfad existiert, senden beide Seiten ihre Medien an den TURN-Server, der diese weiterleitet.

Sie benötigen TURN für Teilnehmer, deren Netzwerke Sie nicht erreichen können. Einer von ihnen befindet sich möglicherweise in einem Firmen- oder Campusnetzwerk, in dem ausgehendes UDP vollständig blockiert ist. Ein anderer befindet sich hinter einem Carrier-Grade NAT, das für jedes Ziel einen anderen Quellport vergibt; dies wird als symmetrisches NAT bezeichnet und macht die von STUN gemeldete Adresse unbrauchbar.

Das Symptom ist spezifisch. Die meisten Personen treten bei und alles funktioniert. Eine Person sieht die Teilnehmerliste, sieht den Chat, erhält aber nur ein schwarzes Feld und einen Ladekreis. Ihr Browser hat Kandidaten gesammelt, aber keines der Paare hat funktioniert, und ICE endete in einem Fehlerzustand. In Chrome zeigt chrome://webrtc-internals während des Versuchs die Kandidatenpaare und diesen Fehler an. Bitten Sie die Person, es erneut über ein Mobilfunknetz zu versuchen. Wenn es dort funktioniert, ist das Netzwerk die Ursache und TURN die Lösung.

TURN über TCP auf 443 oder 5349 ist der Fallback, der fast überall funktioniert, da ein Netzwerk, das TLS auf 443 blockiert, das Web bereits vollständig gesperrt hätte. Das Paket von Jitsi installiert und konfiguriert coturn automatisch für Sie; genau deshalb beinhalten die dokumentierten Firewall-Regeln UDP 3478 und TCP 5349. Galène hat TURN auf 1194 integriert. LiveKit verfügt über einen eingebetteten TURN-Server, den Sie in der Konfiguration aktivieren. Wenn Sie coturn selbst betreiben:

sudo apt install -y coturn
sudo systemctl enable --now coturn

listening-port=3478
tls-listening-port=5349
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_A_LONG_RANDOM_STRING
realm=turn.example.com
cert=/etc/letsencrypt/live/turn.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.com/privkey.pem
min-port=49152
max-port=65535
no-multicast-peers

Diese Einstellungen gehören in /etc/turnserver.conf. Unter Debian und Ubuntu startet das Paket coturn sofort nach der Installation mit der Standardversion dieser Datei, weshalb enable --now oben feststellt, dass es bereits läuft, und keine Änderungen vornimmt. Ihre Einstellungen werden wirksam, wenn Sie sudo systemctl restart coturn ausführen; jede spätere Änderung an der Datei erfordert denselben Neustart. Ältere Anleitungen weisen zudem an, TURNSERVER_ENABLED=1 in /etc/default/coturn zu setzen. Nur das alte Init-Skript liest diesen Schalter. Die systemd-Unit, die aktuelle Pakete verwenden, tut dies nicht; diese Zeile bewirkt also nichts, und ein coturn, das Sie nicht neu gestartet haben, verwendet weiterhin die Standardkonfiguration.

Nun zu den Kosten, die selten dokumentiert werden. Ein Relay überträgt die vollständigen Medien jedes weitergeleiteten Teilnehmers in beide Richtungen. Wenn coturn sich einen Server mit der SFU teilt, läuft der Großteil dieses Datenverkehrs über das Loopback-Interface und belastet die CPU statt der Uplink-Bandbreite. Zudem verschlüsselt der TLS-Listener jedes Paket ein zweites Mal zusätzlich zum DTLS, das die Medien bereits enthalten. Wenn Sie TURN auf eine eigene Maschine auslagern, benötigt diese Maschine einen eigenen Bandbreitenplan, der genauso dimensioniert ist wie der der SFU. TURN über TCP macht aus Echtzeitmedien zudem einen zuverlässigen Datenstrom: Ein verlorenes Paket wird erneut übertragen, anstatt übersprungen zu werden. Ein weitergeleiteter Teilnehmer an einer instabilen Verbindung sammelt daher Verzögerungen an, anstatt nur einen kurzen Aussetzer zu erleben. Das Relay ist ein Fallback, der eine Verbindung herstellt, jedoch mit einer Qualität, die der direkte Pfad übertroffen hätte.

Wann transkodiert die SFU und welche Kosten entstehen dabei?

Eine SFU leitet Pakete lediglich weiter und dekodiert niemals Videos. Deshalb können vier CPU-Kerne einen Raum bedienen, der auf dem Papier unmöglich erscheint. Zwei Funktionen heben diese Eigenschaft auf, und beide überraschen Anwender, die sie per Checkbox aktiviert haben.

Die Aufzeichnung ist der erste Fall. Jitsi zeichnet mit Jibri auf, und die Dokumentation von Jibri beschreibt genau, was dabei geschieht: Es startet eine Chrome-Instanz, die in einem virtuellen Framebuffer gerendert wird, und erfasst sowie kodiert die Ausgabe mit ffmpeg. Das ist ein vollständiger Browser, der das gesamte Meeting rendert, zuzüglich eines Video-Encoders, der während der gesamten Dauer des Anrufs kontinuierlich läuft. Dieselbe Dokumentation besagt, dass nur eine Aufzeichnung gleichzeitig auf einem einzelnen Jibri unterstützt wird und dass Jibri auf einer separaten Maschine oder virtuellen Maschine laufen soll, auf der keine anderen Anwendungen die Anzeige- oder Audiogeräte nutzen. Die Aufzeichnung ist ein zweiter Server, keine bloße Checkbox.

Die telefonische Einwahl ist der zweite Fall. Die Überbrückung einer Telefonleitung in eine Konferenz bedeutet, dass Opus mit 48 kHz in das umgewandelt werden muss, was das Telefonnetz akzeptiert, in der Regel G.711 mit 8 kHz. Dies geschieht in beide Richtungen und kontinuierlich während des gesamten Anrufs. Audio-Transkodierung ist weitaus kostengünstiger als Video-Transkodierung, läuft jedoch pro Anrufverbindung und pausiert nie, sodass die Kosten mit der Anzahl der Anrufer skalieren. Wenn Sie eine Einwahlnummer wünschen, ist ein selbst gehosteter VoIP-Server die Komponente, die diese Arbeit erledigt, und sie gehört aus demselben Grund wie Jibri auf eine eigene Maschine.

Wie groß muss der Server tatsächlich sein?

Für zwei Personen fast gar nicht. Jitsi aktiviert standardmäßig den Peer-to-Peer-Modus, wenn genau zwei Teilnehmer vorhanden sind. In diesem Modus sendet die Konferenz die Daten nicht über die Videobridge, sondern verwendet die direkte Verbindung oder einen TURN-Relay, wenn kein direkter Pfad vorhanden ist. Wenn eine dritte Person beitritt, wechselt Jitsi wieder zur Videobridge. Ein VPS mit 1 GB, auf dem Jitsi läuft, eignet sich daher gut für Einzelgespräche, aber schlecht für Gespräche mit vier Personen. Deshalb wird so häufig berichtet: „Beim Test hat es funktioniert.“

Für bis zu etwa zehn Personen mit aktivierten Kameras liegen 67.2 Mbps bei acht Teilnehmern innerhalb dessen, was der Uplink eines gewöhnlichen VPS dauerhaft unterstützt. Zwei virtuelle CPUs und 4 GB reichen für Jitsi oder Galène bei dieser Größe aus, solange Sie nicht aufzeichnen. Beobachten Sie eher den Transferzähler als die CPU-Auslastung.

Für dreißig Personen beträgt der ungünstigste Fall dauerhaft 1,044 Mbps. Zwanzig Stunden davon entsprechen 9.4 TB. Ab dieser Größe sollten Sie die Bandbreite kalkulieren, bevor Sie den Server kalkulieren. Aktivieren Sie last-N, damit die Bridge nur die zuletzt aktiven Sprecher weiterleitet. Legen Sie für Teilnehmer standardmäßig deaktivierte Kameras fest. Betreiben Sie die SFU an einem Standort, dessen Transferlimit diese Datenmenge abdeckt.

Oberhalb dieser Größe ist ein einzelner VPS die falsche Architektur. Entweder handelt es sich tatsächlich um eine Übertragung. Dann kostet Owncast zusammen mit einem CDN nur einen Bruchteil davon. Oder Sie benötigen mehrere Videobridges hinter einer gemeinsamen Signalisierungsschicht. Das ist ein anderes Projekt als das ursprünglich geplante.

Zum Schluss noch ein Aspekt der Aufteilung. Die meisten Teams benötigen Chat deutlich mehr Stunden am Tag als Video. Chat lässt sich kostengünstig hosten und einfach dauerhaft betreiben. Eine selbst gehostete Slack-Alternative für den täglichen Austausch und einen Konferenzserver ausschließlich für geplante Gespräche zu betreiben, ist die Aufteilung, die auch bei einem kleinen VPS-Budget funktioniert.

FAQ

Warum können Personen meinem Jitsi-Meeting beitreten, sich aber weder sehen noch hören?

Chat und Teilnehmerliste laufen über den Signalisierungskanal, der TCP auf 443 verwendet. Audio und Video verwenden dagegen UDP 10000 zur Videobridge. Wenn sich die Teilnehmerliste füllt, aber alle Kacheln schwarz bleiben, ist der Medienpfad unterbrochen, während der Signalisierungspfad funktioniert. Prüfen Sie UDP 10000 in beiden Firewalls: in der Firewall des Servers und in der separaten Netzwerk-Firewall im Control Panel Ihres Providers. Prüfen Sie anschließend, ob die Bridge ihre öffentliche Adresse kennt: Wenn die automatische Erkennung sie auf einer virtuellen Maschine mit privater Adresse und zugeordneter öffentlicher Adresse nicht gefunden hat, tragen Sie unter ice4j.harvest.mapping in /etc/jitsi/videobridge/jvb.conf eine statische Zuordnung ein und starten Sie jitsi-videobridge2 neu. Wenn Sie während des Beitritts einer Person sudo tcpdump -ni any udp port 10000 ausführen, sehen Sie, welcher Fall vorliegt. Wenn überhaupt keine Pakete eintreffen, liegt die Sperre vor dem Betriebssystem.

Wie viel Bandbreite benötigt ein Videoanruf mit 30 Personen?

Im ungünstigsten Fall, wenn alle ihre Kamera eingeschaltet haben und die SFU allen eine Ebene in voller Qualität weiterleitet, verlassen ungefähr 1,044 Mbps den Server. Das entspricht 469.8 GB pro Stunde. Diese Zahl ergibt sich aus der Berechnung von N mal (N minus 1) Streams mit jeweils 1.2 Mbps. Sie ist keine Messung Ihrer Umgebung. Simulcast und eine last-N-Einstellung reduzieren den Bedarf im normalen Betrieb deutlich, weil die meisten Teilnehmer zu einem bestimmten Zeitpunkt nicht angezeigt werden. Planen Sie trotzdem nahe am ungünstigsten Fall. Dieser tritt bei einer Besprechung mit allen Teilnehmern auf, wenn alle gleichzeitig ihre Kamera einschalten.

Kann ich Jitsi Meet auf einem VPS mit 1 GB ausführen?

Die Installation funktioniert, und ein Gespräch mit zwei Personen ist möglich. Das liegt teilweise daran, dass Jitsi bei genau zwei Teilnehmern den Peer-to-Peer-Modus verwendet und die Videobridge vollständig umgeht. Als Gruppenanrufserver ist diese Größe nicht sinnvoll. Prosody, die Videobridge und die Java-Laufzeit benötigen sämtlich Arbeitsspeicher. Das Handbuch empfiehlt üblicherweise 8 GB. Die Bandbreitenberechnung wird außerdem vor dem Arbeitsspeicher zum Problem. Wenn Ihnen nur ein Server mit 1 GB zur Verfügung steht, passt Galène in dieser Größe besser als Jitsi.

Benötige ich weiterhin einen TURN-Server, wenn mein VPS eine öffentliche IP-Adresse hat?

Ja. Das Problem, das TURN löst, befindet sich am anderen Ende des Gesprächs. Ein Teilnehmer in einem Unternehmensnetzwerk, das ausgehendes UDP blockiert, oder hinter Carrier-Grade NAT, das für jedes Ziel einen anderen Quellport vergibt, kann keinen direkten Medienpfad aufbauen. Das gilt unabhängig davon, ob die Adresse Ihres Servers öffentlich ist. TURN über TCP auf 443 oder 5349 stellt einen Relay bereit, der für die Firewall wie gewöhnlicher Webverkehr aussieht. Die Paketinstallation von Jitsi richtet coturn standardmäßig dafür ein. Deshalb öffnen die dokumentierten Firewall-Regeln UDP 3478 und TCP 5349.

Warum benötigt BigBlueButton deutlich mehr Hardware als Jitsi Meet?

Weil BigBlueButton wesentlich mehr tut, als Video weiterzuleiten. Die veröffentlichte Produktionsanforderung beträgt 16 GB RAM und 8 Kerne. Im Handbuch von Jitsi werden dagegen 8 GB und 4 Kerne genannt. BigBlueButton betreibt auf demselben Server eine vollständige Audiokonferenzplattform, ein gemeinsames Whiteboard, eine Präsentationsschicht, eine Pipeline für Aufzeichnung und Nachbearbeitung sowie ein Web-Frontend mit Benutzerkonten. Außerdem ist BigBlueButton bei der Plattformwahl festgelegt: Im Oktober 2026 wird für die unterstützte Installation Version 3.0 auf Ubuntu 22.04 verwendet. Beide Zahlen stammen aus der Dokumentation des jeweiligen Projekts. Sie sind Ausgangswerte und keine Messungen Ihrer Arbeitslast.