Videokonferenzen auf dem VPS: Bandbreite berechnen

Self-hosted-Videokonferenzen auf einem VPS sind ein Bandbreitenproblem

Self-hosted-Videokonferenzen scheitern auf kleinen Servern aus einem Grund, der fast nie mit der Installation zusammenhängt. Der Serverbestandteil, den moderne Tools dafür verwenden, ist eine SFU (Selective Forwarding Unit). Sie nimmt von jedem Teilnehmer einen Videostream entgegen und leitet eine Kopie davon an alle anderen Teilnehmer weiter. Dadurch wächst der ausgehende Datenverkehr im Quadrat zur Teilnehmerzahl. Ein VPS mit 1 GB oder 2 GB RAM an einer gemeinsam genutzten Uplink-Verbindung kann die Software problemlos ausführen. Für die von Ihnen geplante Konferenz mit allen Teilnehmern reicht die Verbindung jedoch nicht aus.

Gehen Sie daher in dieser Reihenfolge vor. Zählen Sie die Teilnehmer, berechnen Sie den Bedarf in Megabit und wählen Sie anschließend den Server aus. Die Installation dauert zwanzig Minuten und besteht im Wesentlichen aus Copy-and-paste. Die Uplink-Verbindung entscheidet darüber, ob die anderen Teilnehmer Sie hören können.

Warum wächst die Bandbreite mit dem Quadrat der Teilnehmerzahl?

Beginnen wir mit Mesh. Jeder Browser kodiert sein Kamerabild und sendet eine Kopie direkt an jeden anderen Browser. Kein Medienserver verarbeitet das Video. Für einen Mesh-Anruf mit zwei Personen werden nur ein Signalisierungsserver und keine weiteren Komponenten benötigt. Deshalb sind Einzelgespräche im Hosting nahezu kostenlos. Mesh funktioniert ab etwa vier oder fünf Personen nicht mehr, weil ein Laptop an einem privaten Internetanschluss gleichzeitig vier oder fünf separate Kopien seines eigenen Videos hochladen muss.

Eine SFU funktioniert anders. Jeder Browser lädt eine Kopie auf den 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 dekodieren. Das ist der gesamte Mechanismus. Deshalb benötigt eine SFU wenig CPU-Leistung, aber viel Netzwerkbandbreite.

Die ältere Architektur ist ein MCU (Multipoint Control Unit). Sie dekodiert jeden eingehenden Stream, setzt die Streams zu einem Bild zusammen und kodiert dieses Bild erneut. Die ausgehende Bandbreite ist gering. Der CPU-Aufwand ist enorm. Für Video verwendet heute fast niemand mehr ein MCU. Auch dieser Leitfaden nicht.

Nun zur Berechnung für eine 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 unproblematisch. Der Server sendet N mal (N minus 1) mal 1.2 Mbps, weil jede der N Personen die anderen 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 geht von zwanzig Gesprächsstunden pro Monat aus. 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 erkennbare Belastung. 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.

Reale Installationen bleiben unter diesen Werten. Es ist wichtig zu wissen, warum. Jitsi und LiveKit verwenden beide Simulcast. Dabei veröffentlicht ein Sender mehrere Qualitätsstufen gleichzeitig. Die SFU leitet an Teilnehmer, die nicht auf dem Bildschirm angezeigt werden, eine niedrigere Qualitätsstufe weiter. 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 sich gegenseitig anheften.

Was liefert Ihnen ein VPS-Uplink tatsächlich?

Auf einer Tarifseite steht „1 Gbps port“. Das ist die Geschwindigkeit der virtuellen Netzwerkkarte und keine Zusage für den nächsten Hop. Die Verbindung wird mit den anderen Mandanten auf demselben physischen Host geteilt. Deshalb liegt der dauerhafte Durchsatz während einer stark ausgelasteten Stunde unter der Portgeschwindigkeit. Eine Telefonkonferenz erzeugt genau eine solche dauerhafte Last. Bei den meisten Tarifen gibt es außerdem ein monatliches Transfervolumen. Nach dessen Überschreitung wird die Übertragung gedrosselt oder abgerechnet.

An diesem Transfervolumen zeigt sich der entscheidende Kostenpunkt auf der Rechnung. Zwanzig Stunden der Konferenz mit dreißig Teilnehmern übertragen in einem Monat 9.4 TB aus dem Server, bei 469.8 GB pro Stunde. Zwanzig Stunden der Konferenz mit fünfzig Teilnehmern übertragen 26.5 TB. Prüfen Sie das Transfervolumen, bevor Sie den RAM-Wert prüfen. Wenn die Tarifseite dazu keine eindeutigen Angaben macht, ist diese Unklarheit bereits Ihre Antwort. Ein günstiges VPS-Angebot richtig lesen ist für diese Arbeitslast wichtiger als für fast jede andere.

Jitsi Meet: die Standardwahl und ihre Anforderungen

Jitsi Meet ist für die meisten der beste Ausgangspunkt. Die Installation erfolgt aus dem Debian-Repository des Projekts. Dabei konfiguriert der Installer nginx und ein Zertifikat. Die Videobridge (JVB) verwendet nur einen UDP-Port. Dadurch bleiben die Firewall-Regeln kurz. Benötigt werden Debian 11 oder neuer beziehungsweise Ubuntu 22.04 oder neuer.

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

Der Installer fragt nach einem Hostnamen und bietet anschließend eine Zertifikatsauswahl an. Wählen Sie die Option Let's Encrypt. Geben Sie einen Domainnamen an, der bereits auf die öffentliche Adresse dieses Servers auflöst. 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. Dies sind die im Handbuch dokumentierten 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 den gesamten Audio- und Videodatenverkehr. Dieser Port wird häufig vergessen. UDP 3478 und TCP 5349 gehören zum coturn-Server, den das Jitsi-Paket zusammen mit der Bridge installiert. Er dient als Ausweichpfad für Benutzer, deren Netzwerk UDP blockiert.

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. Wenn keine Ausgabe erscheint, wurde die Bridge nicht gestartet. /var/log/jitsi/jvb.log zeigt den Grund an.

Für die Dimensionierung veröffentlicht das Jitsi-Handbuch einen eigenen Ausgangspunkt. 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 für einen produktiv genutzten Server 8 GB RAM und 4 dedizierte Kerne. Häufig reichen 1,000 Mbps Netzwerkbandbreite. Außerdem wird darauf hingewiesen, dass kleinere Installationen mit 4 GB oder 2 GB betrieben werden können. Ein Detail dieser Seite sollten Sie berücksichtigen: Prosody, der XMPP-Server für die Signalisierung, kann nur einen Kern verwenden. Zusätzliche Kerne helfen der Bridge, nicht aber der Signalisierung.

Warum nehmen alle am Anruf teil, aber niemand sieht ein Video?

Das ist der typische Jitsi-Fehler auf einem VPS. Die Teilnehmerliste füllt sich, der Chat funktioniert, und jedes Videofenster bleibt schwarz. Die Videobridge veröffentlicht die Adressen, die sie auf ihren eigenen Schnittstellen findet. Bei einem Anbieter, der der virtuellen Maschine eine private Adresse zuweist und eine öffentliche Adresse darauf abbildet, findet JVB nur die private Adresse. Jeder Client versucht dann, Medien an eine Adresse wie 10.0.0.5 zu senden, aber die Pakete erreichen ihr Ziel nicht.

Teilen Sie der Bridge beide Adressen mit. Fügen Sie eine statische Zuordnung zu /etc/jitsi/videobridge/jvb.conf 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 Anbieters. Ä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 der obige Zuordnungsblock verwendet werden.

Die andere Ursache ist eine Firewall, die Sie nicht konfiguriert haben. Die meisten Anbieter 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 sich jemand von außerhalb verbindet. Wenn überhaupt keine Pakete eintreffen, erreicht nichts den Server. Die Sperre liegt dann vor dem Betriebssystem. Wenn Pakete eintreffen, die Videofenster aber schwarz bleiben, antwortet die Bridge mit einer Adresse, die der Client nicht erreichen kann. Dann liegt das Problem bei der Zuordnung. Wenn Sie unsicher sind, ob ufw selbst korrekt konfiguriert ist, beschreibt die tatsächlich erforderlichen ufw-Regeln für einen VPS die Reihenfolge der Regeln, die häufig Probleme verursacht.

BigBlueButton: anspruchsvoll, festgelegt und für den gesamten Server ausgelegt

BigBlueButton ist für den Unterricht konzipiert. Es bietet ein Whiteboard, Gruppenräume, Umfragen und einen Präsentationsbereich. Die Aufzeichnungs-Pipeline ist eine zentrale Funktion und kein nachträglich hinzugefügtes Modul. Gleichzeitig ist es mit deutlichem Abstand die schwergewichtigste Option in diesem Vergleich. Sie können es nicht einfach zu einem bestehenden Server hinzufügen.

Im August 2026 ist BigBlueButton 3.0 auf Ubuntu 22.04 der unterstützte Weg. Wählen Sie diese Kombination mit dem jammy-300-Versions-Flag aus. Laut den veröffentlichten Produktionsanforderungen des Projekts benötigen Sie 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). Erforderlich sind TCP-Port 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 -w -v jammy-300 -s bbb.example.com -e info@example.com -g

Die Beispiele des Projekts leiten dieses Skript direkt an bash weiter. Laden Sie es stattdessen herunter und lesen Sie es zuerst. Das Skript schreibt Ihre nginx-Konfiguration um, installiert einen eigenen Media- und Audio-Stack, legt Paketversionen fest und beansprucht den Hostnamen. Das ist so vorgesehen und kein Fehler: BigBlueButton erwartet, den Rechner vollständig zu verwalten. Das -w-Flag konfiguriert die Firewall, -s ist der Hostname, -e ist die Adresse, für die Let's Encrypt das Zertifikat registriert, und -g fügt das Greenlight-Frontend hinzu. Wenn derselbe Rechner auch TLS für andere Dienste terminiert, verschieben Sie BigBlueButton entweder auf einen anderen Rechner. Alternativ müssen Sie verstehen, was Ihre nginx-Reverse-Proxy-Konfiguration macht, bevor das Skript sie ändert.

Vergleichen Sie die beiden Zeilen in dieser Tabelle sorgfältig. BigBlueButton fordert doppelt so viel Arbeitsspeicher und doppelt so viele CPU-Kerne wie die Jitsi-Empfehlung, benötigt aber nur ein Viertel der Bandbreite. Die beiden Werte wurden nicht auf dieselbe Weise ermittelt und setzen unterschiedliche Raumgrößen voraus. Betrachten Sie daher jeden Wert als Ausgangspunkt des jeweiligen Projekts und nicht als direkten Vergleich. Der Unterschied bei der CPU-Anforderung ist real. Er entsteht durch alle Aufgaben, die BigBlueButton zusätzlich zur Weiterleitung von Video ausführt.

Galène: die kleine Option

Galène ist eine kompakte, in Go geschriebene SFU. Sie wird als einzelnes statisches Binary erstellt, liefert einen eigenen Webclient mit und enthält einen TURN-Server. Dadurch benötigen Sie weder einen XMPP-Server noch eine Java-Laufzeitumgebung oder eine Rails-Anwendung, die dauerhaft ausgeführt werden muss. Wenn Sie einen zuverlässigen Anruf mit zehn Personen auf einer kleinen Maschine benötigen, sollten Sie diese Lösung ausprobieren, 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 ist Go 1.22. Wenn go build meldet, dass das Modul eine neuere Go-Version benötigt, installieren Sie eine aktuelle Toolchain von go.dev, statt mit dem Distributionspaket zu kämpfen.

Eine Gruppe ist bei Galène die Bezeichnung für einen Raum. Sie wird als JSON-Datei gespeichert:

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 daher, bevor der Port von anderen Stellen aus erreichbar ist. Für einen produktiven Betrieb dokumentiert das Projekt eine 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. Legen Sie diesen Bereich fest, damit Sie dafür eine einzelne Firewall-Regel schreiben können:

./galene -udp-range 40000-40100

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 benötigen Sie, wenn die eigene Adresse der Maschine 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. Ohne ice-servers.json 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 per Proxy weiterleiten. Beachten Sie den Umfang dieser Konfiguration: Clients bauen weiterhin direkte UDP-Datenströme und direkte TCP-Verbindungen zum TURN-Port auf. Der Reverse Proxy verarbeitet daher nur die Seite und die Signalisierung. Die Medien werden nicht über ihn übertragen.

Die Dokumentation von Galène gibt an, dass nur sehr moderate Serverressourcen benötigt werden, nennt aber keinen konkreten Wert. Erwarten Sie daher keine bestimmte Zahl. Die Berechnung der Bandbreite weiter oben gilt weiterhin vollständig. Sie sparen Arbeitsspeicher und vermeiden die zusätzlichen Komponenten aller Dienste, die nicht zur SFU gehören.

Owncast: One-to-many, während die Bandbreite linear bleibt

Viele Anforderungen an „Videokonferenzen“ bestehen tatsächlich 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 normalen HTTP-Segmenten besteht, können Sie sie hinter Object Storage oder einem CDN betreiben 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 davon abgeraten, diesen Dienst als root auszuführen. Außerdem soll jedes entfernte Skript vor der Ausführung geprüft werden. Deshalb ist der Download oben ein separater Schritt. Das Installationsprogramm lädt das aktuelle Release sowie 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 den standardmäßigen Stream-Key abc123 als Passwort. Ändern Sie ihn, bevor Sie eine Domain auf den Server zeigen lassen.

Aus dem HLS-Design ergeben sich zwei Konsequenzen. Zuschauer liegen einige Sekunden oder Minuten hinter dem Livebild zurück, weil HLS vollständige Segmente ausliefert. Eine Unterhaltung in beide Richtungen ist daher nicht möglich. Außerdem gibt es auf dem gesamten Übertragungsweg weder UDP noch TURN. Dadurch erreicht Owncast auch Netzwerke, in denen eine WebRTC-Verbindung überhaupt nicht hergestellt werden kann.

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

Element Call auf einem bereits betriebenen Matrix-Server

Wenn Sie Matrix bereits betreiben, ist Video eine Erweiterung und kein zweites zu verwaltendes Produkt. Es handelt sich dennoch um mehr als ein Paket. Element Call benötigt hinter Ihrem Homeserver zwei Komponenten. Die erste ist eine LiveKit-SFU, die die Medien weiterleitet. Die zweite ist der MatrixRTC-Autorisierungsdienst element-hq/lk-jwt-service. Er übergibt dem Client die LiveKit-WebSocket-URL und ein signiertes JWT (JSON Web Token), mit dem der Client die Verbindung herstellt. Dieser Dienst verwendet die Matrix-Föderations-API. Daher benötigt er einen vorgeschalteten TLS-Reverse-Proxy und einen Namen, der aus der Föderation erreichbar ist.

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 Verbindung über UDP nach außen herstellen kann
• UDP 50000 bis 60000 für Medien; jeder Teilnehmer eines Raums verwendet zwei Ports
• UDP 3478 und TCP 5349, wenn Sie den eingebetteten TURN-Server aktivieren; 5349 muss auf 443 verschoben werden, sofern kein Load Balancer vorgeschaltet ist

Zwei Ports pro Teilnehmer klingt problematisch, ist es aber nicht. Ein Portbereich von 10,000 Ports reicht für Tausende von Teilnehmern aus. Ihre Uplink-Bandbreite ist lange vorher ausgelastet. Öffnen Sie trotzdem den gesamten Bereich. Ein teilweise geöffneter Bereich führt dazu, dass es bei einigen Personen funktioniert und bei anderen fehlschlägt. Das ist die ungünstigste Art von Fehler für die Fehlersuche. Die Konfiguration auf der Homeserver-Seite ist eine eigene Aufgabe. Sie wird in einen Synapse-Homeserver auf einem VPS betreiben behandelt.

Warum kann sich eine einzelne Person nie verbinden? TURN und Netzwerke, die UDP blockieren

Zunächst einige Begriffe, die jeweils nur einmal verwendet werden. ICE (interactive connectivity establishment) bezeichnet das Verfahren, mit dem zwei WebRTC-Endpunkte einen funktionierenden Übertragungsweg zwischen sich ermitteln. STUN (session traversal utilities for NAT) ist ein kleiner Dienst, der einem Client mitteilt, wie seine eigene öffentliche Adresse von außerhalb aussieht. TURN (traversal using relays around NAT) ist ein Relay: Wenn kein direkter Übertragungsweg möglich ist, senden beide Seiten ihre Medien an den TURN-Server, der sie weiterleitet.

Sie benötigen TURN für Teilnehmer, deren Netzwerke Sie nicht kontrollieren können. Einer dieser Teilnehmer befindet sich möglicherweise in einem Unternehmens- oder Campusnetzwerk, in dem ausgehendes UDP vollständig blockiert wird. Ein anderer befindet sich möglicherweise 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 eindeutig. Die meisten Personen treten bei und alles funktioniert. Eine Person sieht die Teilnehmerliste und den Chat, erhält aber eine schwarze Kachel mit einem Ladeindikator. Der Browser dieser Person hat Kandidaten gesammelt, aber kein Kandidatenpaar hat funktioniert, und ICE ist in einem fehlgeschlagenen Zustand beendet worden. In Chrome zeigt chrome://webrtc-internals während des Verbindungsversuchs die Kandidatenpaare und diesen Fehler an. Bitten Sie die betreffende Person, es über ein Smartphone im Mobilfunknetz erneut zu versuchen. Wenn es dort funktioniert, ist ihr Netzwerk die Ursache und TURN die Lösung.

TURN über TCP auf Port 443 oder 5349 ist der Fallback, der fast überall funktioniert, weil ein Netzwerk, das TLS auf Port 443 blockiert, auch das Web blockiert. Das Jitsi-Paket installiert und konfiguriert coturn automatisch. Deshalb enthalten die dokumentierten Firewall-Regeln UDP 3478 und TCP 5349. Galène enthält TURN auf Port 1194. Bei LiveKit aktivieren Sie den integrierten TURN-Server in der Konfiguration. 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

Unter Debian und Ubuntu startet der paketierte Dienst erst, wenn Sie TURNSERVER_ENABLED=1 in /etc/default/coturn setzen. Ein installiertes, aber nie aktiviertes coturn sieht von außen genauso aus wie ein System ohne TURN. Deshalb kostet diese eine Zeile viele Menschen einen ganzen Abend.

Nun zu den Kosten, die niemand dokumentiert. Ein Relay überträgt die vollständigen Medien jedes weitergeleiteten Teilnehmers in beide Richtungen. Wenn coturn auf demselben System wie der SFU läuft, durchquert ein großer Teil dieses Datenverkehrs das Loopback-Interface und verursacht eher CPU-Last als zusätzlichen Uplink-Verkehr. Außerdem verschlüsselt der TLS-Listener jedes Paket ein zweites Mal zusätzlich zur DTLS-Verschlüsselung, die die Medien bereits verwenden. Wenn Sie TURN auf einen eigenen Rechner verschieben, benötigt dieser Rechner einen eigenen Bandbreitenplan, der nach demselben Verfahren wie der des SFU dimensioniert wird. TURN über TCP macht Echtzeitmedien außerdem zu einem zuverlässigen Datenstrom. Ein verlorenes Paket wird erneut übertragen, statt übersprungen zu werden. Bei einem weitergeleiteten Teilnehmer mit einer verlustbehafteten Verbindung steigt dadurch die Verzögerung an, statt dass nur kurz eine Störung auftritt. Ein Relay ist ein Fallback, der eine Verbindung herstellt, aber mit einer Qualität, die der direkte Übertragungsweg übertroffen hätte.

Wann transkodiert die SFU, und welche Kosten entstehen dabei?

Eine SFU leitet Pakete weiter und dekodiert niemals Videodaten. Deshalb können vier Kerne einen Raum versorgen, dessen Betrieb auf dem Papier unmöglich erscheint. Zwei Funktionen durchbrechen diese Eigenschaft. Beide überraschen Benutzer, die sie per Kontrollkästchen aktiviert haben.

Die erste Funktion ist die Aufzeichnung. Jitsi zeichnet mit Jibri auf. Die Dokumentation von Jibri beschreibt genau, was dabei geschieht: Jibri startet eine Chrome-Instanz, die in einem virtuellen Framebuffer gerendert wird, und erfasst und kodiert die Ausgabe mit ffmpeg. Dabei rendert ein vollständiger Browser Ihre gesamte Besprechung. Zusätzlich läuft ein Videokodierer während der gesamten Gesprächsdauer kontinuierlich. In derselben Dokumentation steht, dass auf einem einzelnen Jibri nur eine Aufzeichnung gleichzeitig unterstützt wird. Außerdem ist Jibri für den Betrieb auf einem separaten Rechner oder einer separaten virtuellen Maschine vorgesehen, auf der keine anderen Anwendungen die Anzeige- oder Audiogeräte verwenden. Die Aufzeichnung erfordert einen zweiten Server und lässt sich nicht einfach per Kontrollkästchen aktivieren.

Der zweite Anwendungsfall ist die Einwahl per Telefon. Eine Telefonleitung in eine Konferenz einzubinden bedeutet, Opus mit 48 kHz in beide Richtungen kontinuierlich für die gesamte Gesprächsdauer in das vom Telefonnetz akzeptierte Format umzuwandeln, üblicherweise G.711 mit 8 kHz. Audiotranskodierung ist wesentlich günstiger als Videotranskodierung. Sie läuft jedoch für jeden Gesprächsabschnitt und wird nie pausiert. Die Kosten steigen daher mit der Anzahl der Anrufer. Wenn Sie eine Einwahlnummer benötigen, ist ein selbst gehosteter VoIP-Server die Komponente, die diese Aufgabe übernimmt. Aus demselben Grund wie Jibri sollte er auf einem eigenen Server betrieben werden.

Wie groß muss der Server tatsächlich sein?

Für zwei Personen benötigen Sie fast keine Ressourcen. 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 stattdessen die direkte Verbindung. Wenn eine dritte Person hinzukommt, wechselt Jitsi wieder zur Videobridge. Ein VPS mit 1 GB RAM, auf dem Jitsi läuft, eignet sich daher gut für Einzelgespräche, aber schlecht für Gespräche mit vier Personen. Deshalb hört man so häufig: „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 die Anbindung eines gewöhnlichen VPS dauerhaft verkraftet. Zwei virtuelle CPUs und 4 GB RAM reichen bei dieser Größe für Jitsi oder Galène aus, solange Sie nicht aufzeichnen. Überwachen Sie den Transferzähler statt der CPU-Auslastung.

Bei dreißig Personen beträgt der ungünstigste Fall dauerhaft 1,044 Mbps. Zwanzig Stunden davon entsprechen 9.4 TB. Bei dieser Größe sollten Sie zuerst die Bandbreitenkosten berechnen und erst danach die Kosten für den Server. Aktivieren Sie last-N, damit die Videobridge nur die zuletzt aktiven Sprecher weiterleitet. Legen Sie für Teilnehmer standardmäßig deaktivierte Kameras fest. Platzieren Sie die SFU bei einem Anbieter, dessen Transferlimit diese Berechnung abdeckt.

Oberhalb dieser Größe ist ein einzelner VPS nicht die richtige 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 Routing noch ein letzter Punkt: Die meisten Teams benötigen Chat wesentlich mehr Stunden am Tag als Video. Chat ist kostengünstig zu hosten und lässt sich einfach dauerhaft betreiben. Eine selbst gehostete Slack-Alternative für den alltäglichen Austausch und ein Konferenzserver ausschließlich für geplante Gespräche sind die Lösung, die auch mit dem begrenzten Budget eines kleinen VPS zuverlässig funktioniert.

FAQ

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

Chat und Teilnehmerliste werden über den Signalisierungskanal übertragen. Dieser verwendet TCP auf Port 443. Audio und Video verwenden dagegen UDP 10000 zur Videobridge. Wenn die Teilnehmerliste vollständig ist, aber alle Videokacheln 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 Netzwerkfirewall im Control Panel Ihres Providers. Prüfen Sie anschließend, ob die Bridge ihre öffentliche Adresse kennt. Bei einer virtuellen Maschine mit privater Adresse und zugeordneter öffentlicher Adresse fügen Sie unter ice4j.harvest.mapping in /etc/jitsi/videobridge/jvb.conf eine statische Zuordnung hinzu und starten jitsi-videobridge2 neu. Wenn Sie während des Beitritts einer Person sudo tcpdump -ni any udp port 10000 ausführen, erkennen Sie, an welcher Stelle das Problem liegt. Wenn überhaupt keine Pakete eintreffen, liegt die Sperre außerhalb des Betriebssystems.

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

Im ungünstigsten Fall hat jeder die Kamera aktiviert, und die SFU leitet jedem eine Ebene in voller Qualität weiter. Dann verlassen ungefähr 1,044 Mbps den Server. Das entspricht 469.8 GB pro Stunde. Diese Zahl ergibt sich aus 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 nicht jederzeit auf dem Bildschirm angezeigt werden. Planen Sie trotzdem ungefähr für den ungünstigsten Fall, da dieser bei einer Besprechung mit allen Beteiligten eintritt, wenn alle gleichzeitig ihre Kamera aktivieren.

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

Die Installation funktioniert. Auch ein Anruf mit zwei Personen funktioniert, unter anderem weil Jitsi bei genau zwei Teilnehmern den Peer-to-Peer-Modus verwendet und die Videobridge vollständig überspringt. Als Server für Gruppenanrufe ist diese Größe jedoch nicht geeignet. Prosody, die Videobridge und die Java-Laufzeit benötigen Speicher. Die eigene Dokumentation empfiehlt 8 GB RAM für einen produktiven Betrieb. Außerdem wird die Bandbreite vor dem Speicher zum begrenzenden Faktor. 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, liegt am anderen Ende des Anrufs. Ein Teilnehmer in einem Unternehmensnetzwerk, das ausgehendes UDP blockiert, oder hinter einem Carrier-Grade-NAT, das pro Ziel einen anderen Quellport zuweist, kann keinen direkten Medienpfad aufbauen. Das gilt unabhängig davon, ob die Adresse Ihres Servers öffentlich ist. TURN über TCP auf Port 443 oder 5349 stellt einen Relay bereit, dessen Datenverkehr 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 deutlich mehr macht, als Videodaten weiterzuleiten. Die veröffentlichte Produktionsanforderung beträgt 16 GB RAM und 8 CPU-Kerne. Im Handbuch von Jitsi werden dagegen 8 GB und 4 CPU-Kerne genannt. BigBlueButton führt eine vollständige Audiokonferenzlösung, ein gemeinsames Whiteboard, eine Präsentationsschicht, eine Pipeline für Aufzeichnungen und deren Nachbearbeitung sowie ein Web-Frontend mit Benutzerkonten auf demselben Rechner aus. Außerdem ist BigBlueButton bei der Plattformwahl festgelegt: Im August 2026 ist Version 3.0 auf Ubuntu 22.04 die unterstützte Installationsvariante. Beide Zahlen stammen aus der Dokumentation des jeweiligen Projekts. Sie sind Ausgangswerte und keine Messungen Ihrer Arbeitslast.