WebRTC Server: Die besten Open-Source-WebRTC-Medienserver 2026

Einführung

Sobald mehr als eine Handvoll Leute in einem Videocall sitzen, reicht reines Peer-to-Peer nicht mehr. Jeder Browser müsste seinen Stream an jeden anderen schicken, und bei acht Teilnehmern ist der Upload eines normalen Laptops am Ende. Dann braucht es einen WebRTC Server, der die Streams einsammelt und verteilt.

Die gute Nachricht: Die besten Medienserver dafür sind Open Source. Die schlechte: Nicht jedes Projekt, das in älteren Vergleichen auftaucht, wird noch gepflegt. Intels Open WebRTC Toolkit ist seit Oktober 2024 archiviert, und die Kern-Repositories von Medooze sind nicht mehr öffentlich auf GitHub zu finden. Wer heute einen Server auswählt, sollte zuerst auf das Datum des letzten Commits schauen und erst danach auf die Feature-Liste.

Dieser Vergleich ist für Entwickler und IT-Teams, die einen WebRTC-Medienserver selbst betreiben wollen, ob für Videokonferenzen, Live-Streaming oder eine eigene Anwendung. Der Stand der Projekte ist Oktober 2026.

Open Source Media Server: Was macht ein WebRTC-Medienserver?

Ein WebRTC-Medienserver sitzt zwischen den Teilnehmern. Jeder Browser schickt seinen Audio- und Videostream genau einmal an den Server, und der verteilt ihn an alle anderen. Fast alle modernen Server arbeiten dabei als SFU (Selective Forwarding Unit): Sie leiten Pakete nur weiter und entscheiden je nach Bandbreite des Empfängers, welche Qualitätsstufe er bekommt. Das Mischen der Streams zu einem einzigen Bild (MCU) ist teuer und kaum noch üblich.

Ein Open Source Media Server hat zusätzlich einen offenen Quellcode. Sie können ihn prüfen, ändern und auf eigener Hardware betreiben, ohne Lizenzgebühr pro Minute oder pro Teilnehmer. Der Medienserver ist allerdings nur ein Teil der Architektur. Für Verbindungen hinter Firewalls brauchen Sie zusätzlich einen TURN-Server, und für den Verbindungsaufbau einen Signalisierungsserver. Wie STUN, TURN und ICE zusammenspielen, erklärt unser Artikel STUN vs TURN vs ICE (auf Englisch).

Vorteile von Open-Source-Lösungen für WebRTC-Anwendungen

• Keine Lizenzkosten. Sie zahlen für Server und Bandbreite, nicht pro Minute.
• Volle Kontrolle über die Daten, weil die Medienströme Ihre eigene Infrastruktur nie verlassen.
• Anpassbarkeit bis in den Code, von der Oberfläche bis zum Routing der Streams.
• Transparenz: Sicherheitsfunktionen lassen sich prüfen, statt sie einem Anbieter glauben zu müssen.

Der Preis dafür ist Betriebsaufwand. Updates, Monitoring, Skalierung und die nächtliche Störung gehören Ihnen. Für ein Team ohne Linux-Erfahrung ist ein gehosteter Dienst manchmal die ehrlichere Antwort.

Übersicht der wichtigsten Funktionen

• Simulcast und adaptive Qualität: Der Server schickt jedem Empfänger die Qualitätsstufe, die seine Verbindung tragen kann.
• Aufzeichnung: Bei manchen Servern eingebaut, bei anderen eine eigene Komponente (bei Jitsi zum Beispiel Jibri).
• Skalierung über mehrere Server: Ein einzelner Server hat eine Obergrenze. Entscheidend ist, ob sich eine Konferenz auf mehrere Server verteilen lässt.
• Protokoll-Brücken: SIP, RTMP, WHIP/WHEP oder HLS, je nachdem, womit Ihre Anwendung sprechen muss.

Welcher ist der beste WebRTC Media Server?

Die kurze Antwort: Für Videokonferenzen, die einfach funktionieren sollen, Jitsi Meet. Für eine eigene Anwendung mit SDKs LiveKit. Für maximale Kontrolle in Node.js mediasoup. Für Streaming an viele Zuschauer Ant Media Server, wenn das Budget für die Enterprise Edition da ist. Die einzelnen Projekte im Detail:

1. Jitsi Meet: Der Open-Source-WebRTC-Medienserver Nr. 1

Hauptfunktionen und Vorteile von Jitsi

• Skalierbarkeit: Eine einzelne Konferenz lässt sich über mehrere Videobridges verteilen (Relays, früher Octo). Mit Autoscaling auf AWS oder Kubernetes trägt das auch große Veranstaltungen.
• Verschlüsselung: Medien sind immer per DTLS-SRTP zwischen Browser und Server verschlüsselt. Echte Ende-zu-Ende-Verschlüsselung ist zusätzlich als Option verfügbar, in Browsern, die Insertable Streams unterstützen.
• Fertige Oberfläche: Sie müssen kein Frontend bauen. Logo, Farben und Texte lassen sich trotzdem anpassen, wie unsere Anleitung zur Jitsi-Frontend-Anpassung zeigt.
• Modularität: Jede Komponente läuft als eigener Dienst und lässt sich einzeln skalieren oder ersetzen.

Funktionen von Jitsi Meet

• Bildschirmfreigabe, Chat, Hand heben und Reaktionen
• Umfragen, Breakout Rooms und Lobby-Modus
• Virtuelle Hintergründe und Rauschunterdrückung im Browser
• Aufzeichnung und Live-Streaming über Jibri
• Transkription und Untertitel über Jigasi
• Simulcast und Anzeige des aktiven Sprechers
• Etherpad für gemeinsame Notizen
• Android- und iOS-Apps sowie Web- und native SDKs
• Eigenes Branding

API-Zugriff und -Steuerung in Jitsi Meet

Für die Einbindung in eigene Anwendungen gibt es zwei Wege. Die IFrame API bettet ein komplettes Meeting in Ihre Webseite ein und steuert es per JavaScript (Stummschalten, Teilnehmer auslesen, Ereignisse abfangen). Wer eine eigene Oberfläche bauen will, nutzt lib-jitsi-meet und spricht direkt mit Jicofo und der Videobridge. Die IFrame API ist für die meisten Projekte der schnellere Weg; unser Artikel zur Jitsi IFrame API (auf Englisch) hat Code-Beispiele.

Kundenspezifische Jitsi-Entwicklung von Meetrix

Meetrix entwickelt und betreibt angepasste Jitsi-Meet-Installationen für Unternehmen, Bildungseinrichtungen und Plattformen, die Video in ihr eigenes Produkt einbauen. Typische Aufträge:

• Eigene Funktionen und Integrationen, etwa in CRM- oder ERP-Systeme, sowie ein eigenes UI-Design.
• Authentifizierung über JWT, LDAP oder SSO und strengere Sicherheitseinstellungen für Finanzwesen, Gesundheitswesen und Behörden.
• Skalierung über mehrere Videobridges und Regionen für große Veranstaltungen.
• DSGVO-konforme Installationen in EU-Rechenzentren, mehr dazu weiter unten.

Jitsi auf AWS und GCP einrichten

Für den schnellen Start gibt es vorkonfigurierte Jitsi-Meet-Images von Meetrix im AWS Marketplace und im Google Cloud Marketplace, in Größen von 50 bis 500 Teilnehmern, mit oder ohne Aufzeichnung. Sie zahlen nutzungsbasiert pro Stunde. Wer lieber selbst installiert, findet in unserer Docker-Compose-Anleitung (auf Englisch) den manuellen Weg.

1. Jitsi auf AWS

Das AMI im AWS Marketplace startet Jitsi Meet auf einer EC2-Instanz in Ihrem eigenen AWS-Konto. Instanz auswählen, Domain eintragen, starten. SSL-Zertifikat und Konfiguration sind vorbereitet.

2. Jitsi auf GCP

Im Google Cloud Marketplace gibt es dieselben Varianten als Compute-Engine-Deployment. Praktisch, wenn Ihre übrige Infrastruktur schon in Google Cloud läuft und Sie eine Region in Frankfurt oder einer anderen EU-Region wählen wollen.

3. Weitere Cloud-Plattformen

Darüber hinaus hat Meetrix Jitsi für Kunden auf Azure, Alibaba Cloud, OVH, Oracle Cloud, DigitalOcean und IBM Cloud eingerichtet. Diese Installationen sind Projektarbeit, keine fertigen Marketplace-Images.

2. LiveKit: Der WebRTC Server für eigene Anwendungen

LiveKit fehlte in früheren Versionen dieses Vergleichs, und das war ein Fehler. Mit über 21.000 GitHub-Sternen ist es heute das am meisten beachtete Projekt in dieser Liste. LiveKit ist eine SFU in Go unter Apache 2.0, mit SDKs für Web, iOS, Android, Flutter, React Native und Unity. Die aktuelle Version ist 1.13 (Oktober 2026).

• Für Entwickler gebaut: Es gibt keine fertige Meeting-Oberfläche wie bei Jitsi, dafür saubere SDKs, mit denen Sie Video in Ihr eigenes Produkt einbauen.
• Skalierung: Mehrere LiveKit-Server teilen sich die Last über Redis, ohne dass Sie selbst Routing bauen müssen.
• KI-Sprachagenten: Das Agents-Framework von LiveKit ist derzeit einer der beliebtesten Wege, Echtzeit-KI per Sprache anzubinden.

Wie LiveKit sich im direkten Vergleich schlägt, steht in LiveKit vs Jitsi (auf Englisch).

3. Mediasoup: WebRTC Media Server für Node.js

Kernfunktionen von Mediasoup

• Leistung: Sehr geringer Ressourcenverbrauch pro Stream, weil der C++-Kern pro CPU-Kern einen eigenen Worker startet.
• Simulcast und SVC: Jeder Empfänger bekommt die passende Qualitätsstufe.
• Verschlüsselung: DTLS-SRTP wie bei jedem WebRTC-Server.
• Aktive Entwicklung: Das Repository bekommt laufend Releases, zuletzt im Oktober 2026.

Für Teams mit Node.js-Erfahrung, die eine eigene Plattform bauen und keine fertige Oberfläche mitschleppen wollen, ist mediasoup eine sehr gute Wahl. Für ein Team, das einfach nur Meetings braucht, ist es zu viel Eigenbau.

4. Ant Media Server: Streaming Server mit niedriger Latenz

Community Edition oder Enterprise Edition?

Hier liegt der Haken, den viele Vergleiche verschweigen. Laut Ant Medias eigener Dokumentation hat die kostenlose Community Edition eine Latenz von 8 bis 12 Sekunden, weil sie über HLS ausliefert. Die rund 0,5 Sekunden, für die Ant Media bekannt ist, gibt es nur in der kostenpflichtigen Enterprise Edition. Dasselbe gilt für adaptives Bitrate-Streaming und Clustering.

• Aufzeichnen und Restreaming: Streams lassen sich aufzeichnen und gleichzeitig an YouTube Live oder Facebook Live weiterleiten.
• Viele Protokolle: WebRTC, RTMP, HLS und DASH aus einem Server.

Wenn Sie ohnehin für die Enterprise Edition zahlen, ist Ant Media für Streaming sehr bequem. Wenn nicht, sind LiveKit oder mediasoup die bessere Ant Media Alternative für niedrige Latenz.

5. Janus Server: Das flexible WebRTC Gateway

Hauptmerkmale von Janus

• Plugin-Architektur: Sie aktivieren nur, was Sie brauchen, vom Echo-Test bis zum SIP-Gateway, und können eigene Plugins schreiben.
• Brücke zu SIP und RTP: Janus ist eine der einfachsten Möglichkeiten, WebRTC mit Telefonanlagen oder klassischem RTP zu verbinden.
• Geringe Latenz: Als SFU leitet es Medien ohne Transkodierung weiter.
• Lizenz: GPL-3.0. Für ein geschlossenes Produkt sollten Sie das vorher klären; Meetecho bietet auch kommerzielle Lizenzen an.

Janus ist die richtige Wahl, wenn WebRTC mit anderen Protokollen zusammenarbeiten muss. Für eine reine Meeting-Plattform ist der Aufwand höher als bei Jitsi.

6. Kurento: Medienverarbeitung, aber kaum noch Weiterentwicklung

Kernfunktionen von Kurento

• Medienverarbeitung: Pipelines mit Computer-Vision-Filtern auf Basis von GStreamer und OpenCV.
• Aufzeichnen und Mischen: Direkt auf dem Server.
• Projektstatus: Die letzten Commits im Repository sind Wartungsarbeiten (April 2026), neue Funktionen kommen kaum noch. Das Team hinter Kurento hat sich auf OpenVidu konzentriert.

Für ein bestehendes Kurento-Projekt ist das kein Grund zur Panik, es läuft weiter. Für ein neues Projekt würde ich Kurento nur noch wählen, wenn Sie die serverseitige Medienverarbeitung wirklich brauchen. Wer es trotzdem ausprobieren will: Kurento auf Ubuntu installieren (auf Englisch).

7. Open WebRTC Toolkit (OWT): Eingestellt

Intel hat das Projekt eingestellt. Das owt-server-Repository ist seit dem 23. Oktober 2024 archiviert, und die README warnt vor bekannten Sicherheitslücken, die nicht mehr behoben werden. Für neue Projekte kommt OWT daher nicht in Frage. Wenn Sie es noch betreiben, planen Sie die Migration, am ehesten zu LiveKit oder mediasoup.

8. Medooze: Nur noch mit Vorsicht

Die Kern-Repositories (media-server und media-server-node) sind im Oktober 2026 nicht mehr öffentlich auf GitHub verfügbar. Kleinere Bibliotheken wie semantic-sdp-js und whip-whep-js sind weiterhin online, wurden aber seit Ende 2024 kaum aktualisiert. Ohne öffentlichen Quellcode für den eigentlichen Server ist Medooze für ein neues Open-Source-Projekt keine Empfehlung mehr.

WebRTC Server Open Source: Vergleichstabelle

Server	Typ	Lizenz	Status (Okt. 2026)	Am besten für
Jitsi Meet	Komplette Plattform mit SFU	Apache 2.0	Aktiv	Videokonferenzen ohne Eigenentwicklung
LiveKit	SFU mit SDKs	Apache 2.0	Aktiv	Video in eigenen Apps, KI-Sprachagenten
mediasoup	SFU-Bibliothek (Node.js, Rust)	ISC	Aktiv	Eigene Plattform mit voller Kontrolle
Ant Media Server	Streaming-Server	Community: Open Source, Enterprise: kommerziell	Aktiv	Live-Streaming an viele Zuschauer
Janus	Plugin-basiertes Gateway	GPL-3.0	Aktiv	WebRTC mit SIP, RTP und Streaming verbinden
Kurento	SFU/MCU mit Medienverarbeitung	Apache 2.0	Nur noch Wartung	Bestehende Projekte mit Filtern
OWT	Server und SDK	Apache 2.0	Archiviert (2024)	Nicht für neue Projekte
Medooze	SFU mit Node.js	Kern nicht mehr öffentlich	Unklar	Nicht für neue Projekte

Streaming Server Open Source oder Konferenz-Server?

• Viele sprechen mit vielen (Meetings, Unterricht): Jitsi Meet, oder LiveKit, wenn Sie die Oberfläche selbst bauen.
• Wenige senden an sehr viele (Events, Übertragungen): Ant Media Server, oder LiveKit beziehungsweise Janus mit dem Streaming-Plugin.
• WebRTC trifft Telefonie: Janus mit dem SIP-Plugin, oder Jitsi mit Jigasi.
• Volle Kontrolle im eigenen Code: mediasoup.

DSGVO-konform WebRTC betreiben: Selbst hosten statt Cloud-Dienst

WebRTC verschlüsselt Medien grundsätzlich per DTLS-SRTP. Ob eine Lösung DSGVO-konform ist, hängt deshalb nicht am Protokoll, sondern daran, wo der Server steht und wer Zugriff auf die Daten hat. Ein selbst gehosteter Open-Source-Server ist hier im Vorteil, weil Sie beides selbst bestimmen. Konkret heißt das:

1. Server in einem EU-Rechenzentrum betreiben, etwa in den AWS-Regionen Frankfurt oder bei einem europäischen Hoster.
2. Einen Auftragsverarbeitungsvertrag (AVV) mit dem Hoster abschließen.
3. Logs und Aufzeichnungen nur so lange speichern, wie es nötig ist, und Aufzeichnungen nur mit Einwilligung starten.
4. Den TURN-Server ebenfalls selbst betreiben, damit auch weitergeleitete Medien Ihre Infrastruktur nicht verlassen.
5. Keine externen Dienste (etwa Analyse-Skripte oder öffentliche STUN-Server von Drittanbietern) ungeprüft einbinden.

Das ist keine Rechtsberatung, aber es ist die technische Grundlage, auf der Ihr Datenschutzbeauftragter aufbauen kann. Mehr zum Thema steht in unserem Artikel über DSGVO-konforme WebRTC-Lösungen (auf Englisch).

So wählen Sie den richtigen WebRTC-Medienserver aus

1. Ist das Projekt noch lebendig?

Schauen Sie zuerst auf GitHub: Wann war der letzte Commit, wann das letzte Release, werden Issues beantwortet? Ein Medienserver hängt an Browser-Änderungen, und ein Projekt ohne Updates bricht irgendwann mit einer neuen Chrome-Version.

2. Fertige Plattform oder Baukasten?

Jitsi liefert Oberfläche, Apps und Moderation mit. LiveKit und mediasoup liefern Bausteine, aus denen Sie Ihr eigenes Produkt bauen. Die falsche Wahl kostet entweder Monate an Eigenentwicklung oder endet in einem Produkt, das wie Jitsi aussieht, obwohl es das nicht sollte.

3. Skalierung und Latenz

Wie viele Teilnehmer pro Konferenz, wie viele Konferenzen gleichzeitig, und wie viel Verzögerung ist akzeptabel? Für Meetings brauchen Sie unter einer halben Sekunde, für Streaming reichen oft ein paar Sekunden über HLS.

4. Sicherheit und Authentifizierung

Alle Server verschlüsseln den Transport. Prüfen Sie zusätzlich, wie Räume geschützt werden (JWT, Passwörter, Lobby) und ob sich der Server an Ihr Identitätsmanagement anbinden lässt.

5. Lizenz

Apache 2.0 und ISC sind unkompliziert. GPL-3.0 (Janus) und Open-Core-Modelle wie bei Ant Media sollten Sie vor der Entscheidung mit Ihrem Produktmodell abgleichen.

Branchen, die WebRTC-Medienserver nutzen

• Gesundheitswesen: Videosprechstunden, bei denen Patientendaten das eigene Rechenzentrum nicht verlassen dürfen. Selbst gehostetes Jitsi ist hier verbreitet.
• Bildung: Virtuelle Klassenzimmer und Prüfungsaufsicht, oft eingebunden in Moodle oder ein anderes LMS.
• Events und Streaming: Webinare und Live-Übertragungen mit tausenden Zuschauern, typischerweise mit Ant Media oder einer SFU plus HLS-Ausgabe.
• Kundenservice und Finanzberatung: Video direkt im Browser oder in der App, ohne dass der Kunde etwas installiert.
• KI-Anwendungen: Sprachagenten, die in Echtzeit zuhören und antworten, ein Bereich, in dem LiveKit gerade stark wächst.

Fazit

Für die meisten Teams, die Videokonferenzen selbst hosten wollen, ist Jitsi Meet 2026 weiterhin der kürzeste Weg zu einem funktionierenden System. Wer Video in die eigene Anwendung einbaut, sollte LiveKit ansehen, und wer jedes Detail kontrollieren will, mediasoup. OWT und Medooze gehören nicht mehr auf die Liste für neue Projekte, und Kurento nur noch, wenn Sie seine Medienverarbeitung wirklich brauchen.

Die englische Originalfassung dieses Vergleichs finden Sie unter Best Open Source WebRTC Media Servers 2026.