8
min. Lesezeit

Was ist Web Real Time Communications?

In diesem Artikel werden wir einige Funktionen der Verwendung von WebRTC vorstellen und die Vor- und Nachteile dieser Technologie betrachten.
Aleksey Andruschenko
Full-Stack-Entwickler
November 13, 2025
[Updated]

Inhaltsverzeichniss

WebRTC (Web-Echtzeitkommunikation) ist ein Standard, der die Übertragung von gestreamten Audio-, Video- und Inhalten zwischen Browsern (ohne Installation von Plugins oder anderen Erweiterungen) oder anderen Anwendungen, die dies unterstützen, in Echtzeit beschreibt. Mit dieser Technologie kann der Browser in ein Videokonferenzterminal umgewandelt werden. Um die Kommunikation einzuleiten, öffnen Sie einfach die Webseite der Konferenz.

So funktioniert WebRTC

Betrachten wir am Beispiel eines Anrufs zwischen zwei Teilnehmern über einen Browser, wie die Technologie funktioniert:

  1. Benutzer öffnet die Seite: Der Benutzer öffnet eine Seite mit WebRTC-Inhalten.
  2. Anfrage zum Gerätezugriff: Der Browser fordert bei Bedarf Zugriff auf die Webcam und das Mikrofon an. Solange der Benutzer nicht Zugriff auf das Gerät gewährt, wird es nicht verwendet. In Fällen, in denen dies optional ist (z. B. beim Ansehen einer Sendung), sind keine zusätzlichen Berechtigungen erforderlich.

Vorteile des WebRTC-Standards

  • Keine Softwareinstallation erforderlich: Benutzer müssen keine zusätzliche Software installieren.
  • Qualitativ hochwertige Kommunikation danke an:
    • Die Verwendung moderner Video- und Audiocodecs.
    • Automatische Anpassung der Datenstromqualität an die Verbindungsbedingungen.
    • Eingebautes Echo- und Geräuschreduzierungssystem.
    • Automatische Verstärkungssteuerung (AGC) für die Mikrofonpegel der Teilnehmer.
  • Hohes Maß an Sicherheit: Alle Verbindungen sind gemäß den DTLS- und SRTP-Protokollen gesichert und verschlüsselt. Darüber hinaus arbeitet WebRTC nur über das HTTPS-Protokoll, und jedes Web, das diese Technologie verwendet, muss mit einem Zertifikat signiert sein.
  • Unterstützung für SVC-Technologie: Mit der Implementierung der VP9- und AV1-Codecs wurde die Unterstützung für die SVC-Technologie (Scalable Video Coding) hinzugefügt. Obwohl es derzeit keine Implementierung in den Browsern selbst gibt, ermöglichen Softwarelösungen wie TrueConf die Verwendung von SVC in Browser-Clients.
  • Eingebauter Mechanismus für die Inhaltserfassung: Dazu gehören Funktionen wie Desktop-Sharing.
  • Flexible Steuerschnittstelle: Die Möglichkeit, jede Steuerschnittstelle auf Basis von HTML5 und JavaScript zu implementieren.
  • Open-Source-Projekt: Sie können es in Ihr Produkt oder Ihre Dienstleistung einbetten.
  • Echte Multiplattform: Dieselbe WebRTC-Anwendung funktioniert in jedem Betriebssystem, auf einem Computer oder Mobilgerät gleich gut, sofern der Browser WebRTC unterstützt. Dies spart erhebliche Ressourcen bei der Softwareentwicklung.

Nachteile des Standards

  • Inkompatibilität zwischen Lösungen: Alle WebRTC-Lösungen sind nicht kompatibel, da der Standard nur Methoden zur Übertragung von Video und Audio beschreibt. Die Implementierung von Methoden zur Kontaktaufnahme mit Teilnehmern, zur Überwachung ihrer Verfügbarkeit, zum Austausch von Nachrichten und Dateien, zur Terminplanung und zu anderen Funktionen bleibt dem Entwickler überlassen. Mit anderen Worten, es ist nicht möglich, von einer WebRTC-Anwendung zur anderen aufzurufen.
  • Bedenken hinsichtlich des Datenschutzes: Für Benutzer, die sich Sorgen um ihre Privatsphäre machen, ist es beunruhigend, dass WebRTC ihre echten IP-Adressen preisgeben kann. Weder ein Proxyserver noch die Nutzung des Tor-Netzwerks tragen zur Wahrung der Anonymität bei. Sie können Ihre IP-Adresse mithilfe verschiedener VPN-Dienste und auch bei Verwendung eines TURN-Servers verbergen. Bei Bedarf kann die Verwendung von WebRTC deaktiviert werden.
  • Fehlende Unterstützung für die Remotedesktopverwaltung: Ja, Sie können übertragen, was auf dem Bildschirm des Geräts passiert, aber es handelt sich um einen unidirektionalen Videostream wie das von einer Kamera übertragene Bild, ohne dass eine Interaktion mit der Streamquelle möglich ist. Dies geschieht aus Sicherheitsgründen: JavaScript-Code kann nichts außerhalb des aktuellen Browserfensters steuern. Zusätzliche Funktionen, einschließlich der Desktop-Fernsteuerung, können mithilfe speziell entwickelter Client-Anwendungen von Videokonferenzanbietern abgerufen werden.

Codecs in WebRTC

WebRTC-Codecs können in obligatorische (Browser, die diese Technologie implementieren, müssen sie unterstützen) und optionale (nicht Teil des Standards, aber einige Browser fügen sie hinzu) unterteilt werden.

Audiocodecs

Um den Audioverkehr in WebRTC zu komprimieren, werden obligatorische Codecs (Opus und G.711) und ergänzende Codecs (G.722, iLBC, iSAC) verwendet.

  • Opus: Opus ist ein Audiocodec mit niedriger Kodierungslatenz (von 2,5 ms bis 60 ms), Unterstützung für variable Bitraten und hoher Komprimierung, wodurch er sich ideal für die Übertragung von Audio in Netzwerken mit variabler Bandbreite eignet. Es ist der Haupt-Audiocodec für WebRTC. Opus ist eine Hybridlösung, die die besten Funktionen der SILK-Codecs (Sprachkomprimierung, Beseitigung menschlicher Sprachverzerrungen) und CELT-Codecs (Audiodatenkodierung) kombiniert. Der Codec ist frei verfügbar, und Entwickler, die ihn verwenden, müssen den Urheberrechtsinhabern keine Lizenzgebühren zahlen. Im Vergleich zu anderen Audiocodecs gewinnt Opus in vielerlei Hinsicht deutlich. In mehreren Parametern übertrifft es recht beliebte Codecs mit niedriger Bitrate wie MP3, Vorbis, AAC LC. Opus stellt das „Klangbild“ wieder her, das dem Original näher kommt als AMR-WB und Speex.
  • G.711: G.711 ist ein veralteter Sprachcodec mit einer hohen Übertragungsrate (64 kbps), der am häufigsten in herkömmlichen Telefonsystemen verwendet wird. Sein Hauptvorteil ist die minimale Rechenlast aufgrund der Verwendung leichter Komprimierungsalgorithmen. Der Codec hat eine geringe Sprachsignalkomprimierung und verursacht keine zusätzliche Audioverzögerung während der Benutzerkommunikation.
  • G.722: G.722 ist ein ITU-T-Standard, der 1988 verabschiedet wurde und derzeit kostenlos ist. Er kann mit Geschwindigkeiten von 48, 56 und 64 kbps betrieben werden und bietet eine Klangqualität auf G.711-Niveau. Ebenso ist G.711 veraltet. Es wird in den Browsern Chrome, Safari und Firefox unterstützt.
  • iLBC: iLBC (Internet Low Bitrate Codec) ist ein Schmalband-Sprachcodec mit Open Source. Verfügbar in den Browsern Chrome und Safari. Aufgrund der hohen Datenstromkomprimierung erhöht die Verwendung dieses Codecs die CPU-Last.
  • iSAC: iSAC (Internet Speech Audio Codec) ist ein Breitband-Sprachcodec, der zuvor proprietär war und derzeit Teil des WebRTC-Projekts ist, dessen Verwendung jedoch nicht obligatorisch ist. Wird in Chrome- und Safari-Browsern unterstützt. Die WebRTC-Implementierung verwendet eine adaptive Bitrate von 10 bis 52 kbit/s mit einer Abtastrate von 32 kHz.

Videocodecs

Das Problem der Auswahl eines Videocodecs für WebRTC dauerte mehrere Jahre, was zur Aufnahme der VP8- und H.264-Codecs in den Standard führte. Es gibt auch Implementierungen optionaler Videocodecs (H.265, VP9, AV1).

  • VP8: VP8 ist ein kostenloser Videocodec mit einer offenen Lizenz, der sich durch eine hohe Decodierungsgeschwindigkeit von Videostreams und eine erhöhte Widerstandsfähigkeit gegen Bildverluste auszeichnet. Der Codec ist vielseitig, leicht in Hardwareplattformen implementierbar und wird daher häufig von Entwicklern von Videokonferenzsystemen in ihren Produkten verwendet. Kompatibel mit den Browsern Chrome, Edge, Firefox und Safari (12.1+).
  • H.264: Der kostenpflichtige H.264-Videocodec wurde viel früher bekannt als sein Gegenstück. Es ist ein Codec mit einem hohen Grad an Videostream-Komprimierung bei gleichbleibender hoher Videoqualität. Seine weit verbreitete Verwendung unter Hardware-Videokonferenzsystemen lässt auf seine Verwendung im WebRTC-Standard schließen. Kompatibel mit den Browsern Chrome (52+), Edge, Firefox (veraltet für Android 68+) und Safari.
  • VP9: VP9 ist ein offener und kostenloser Videokomprimierungsstandard, der 2012 von Google entwickelt wurde. Es ist eine Weiterentwicklung von Ideen, die in den VP8-Standard eingebettet sind und anschließend um den AV1-Standard erweitert wurden. Kompatibel mit Chrome (48+) und Firefox-Browsern.
  • H.265: H.265 ist ein kostenpflichtiger Videocodec, der Nachfolger von H.264, der dieselbe visuelle Qualität bei halber Bitrate bietet. Dies wird durch effizientere Komprimierungsalgorithmen erreicht. Dieser Codec konkurriert derzeit mit dem kostenlosen AV1-Codec.
  • AV1: AV1 ist ein Open-Source-Videokomprimierungscodec, der speziell für die Übertragung von Videos über das Internet entwickelt wurde. Wird in den Browsern Chrome (70+) und Firefox (67+) unterstützt.

Nuancen bei der Arbeit mit WebRTC

  • Signalisierungsserver: WebRTC bietet Browsern keine Möglichkeit, sich gegenseitig zu entdecken. Wir können zwar alle notwendigen Metadaten über unsere Kollegen generieren, aber wie erfährt ein Browser von der Existenz eines anderen? Wie verbinde ich sie? Der WebRTC-Signalserver verwaltet Verbindungen zwischen Peers. Er hilft bei der Signalisierung, unterstützt einen Peer dabei, einen anderen im Netzwerk zu finden, die Verbindung auszuhandeln, sie bei Bedarf zurückzusetzen und zu beenden. WebRTC spezifiziert kein Signalisierungsprotokoll; eines muss entwickelt oder bestehende Lösungen verwendet werden. Der Transport für das Signalisierungsprotokoll ist ebenfalls nicht spezifiziert. HTTP, WebSocket oder Data Channel können verwendet werden. WebSocket wird häufig verwendet, da es auf einer dauerhaften Verbindung basiert und Daten fast in Echtzeit übertragen kann.
  • Arbeiten mit Hardwaregeräten: Wir können die Namen und Eigenschaften von Kameras erst ermitteln, wenn eine Verbindung hergestellt ist. Wenn mehr als eine Kamera im Client-System installiert ist, wie bei Mobilgeräten, können wir dem Benutzer nur eine Auswahl wie Kamera 1 oder Kamera 2 anbieten, ohne diese Kameras zu benennen (z. B. „Logitech“, „Frontkamera“, „FullHD-Kamera“). Wenn während der Sitzung ein neues Gerät angeschlossen wird, wird die Webanwendung erst informiert, wenn der Benutzer die Seite aktualisiert. Das heißt, wenn Sie die Konferenzseite bereits geöffnet und dann eine neue USB-Kamera angeschlossen haben, weiß die Anwendung nichts davon.
  • Erfassung von Medien: Aus Sicherheitsgründen bietet der Browser keinen direkten Zugriff auf Kameratreiber. Daher können wir nicht auf einer bestimmten Kamera bestehen, Auflösung, Bildrate usw. wählen. Wir können auch keine nachfolgende Videoverarbeitung durchführen, die Helligkeit einstellen, das Video spiegeln und andere Einstellungen, die normalerweise Teil der Einstellungen des Kameratreibers sind, nicht durchführen. Es gibt auch keine einheitliche Standardlösung für Desktop-Sharing. Möglicherweise sind Sie in Videokonferenzanwendungen darauf gestoßen, dass nach dem Initiieren von Desktop-Sharing häufig ein zusätzlicher Konferenzteilnehmer erstellt wird, der das ausgewählte Desktop- oder Anwendungsfenster streamt. Probleme, mit denen wir bei der Arbeit mit Kameras konfrontiert sind (Unfähigkeit, den Namen der Kamera anzugeben und Geräteeigenschaften abzurufen), betreffen auch die Arbeit mit Monitoren während der Desktopübertragung.
  • P2P-Verbindung (Session Description Protocol - SDP): Die API zur Generierung des SDP-Protokolls ist asynchron, sodass Situationen auftreten können, in denen die im eingehenden SDP-Paket beschriebenen Medienstream-Parameter nicht mit dem übereinstimmen, was der Client tatsächlich sendet. Es gibt zwei SDP-Formate: Plan B wird von Chromium-basierten Browsern verwendet, und Unified Plan, der von Firefox verwendet wird. Plan B hat alle Medienstreams im gleichen Format. Wenn wir keinen externen Medienserver verwenden, besteht die Möglichkeit, dass einige Konferenzteilnehmer das Format unseres Medienstreams nicht verstehen und ihn nicht anzeigen können. Unified Plan ermöglicht die Auswahl eines Codecs für jeden Medienstream, z. B. die Codierung von Desktopübertragungen mit einem Codec und die Kameraübertragung mit einem anderen. Sie können dem Signalserver beibringen, ein SDP in ein anderes zu übersetzen, aber das erhöht die Serverlast.
  • RTP- und SRTP (SSL) -Medienstreaming: Wie funktioniert das, wenn es NAT gibt, bei dem Computer unter einer IP-Adresse erscheinen, aber intern verschiedene IP-Adressen kennen? Das ICE-Framework (Interactive Connectivity Establishment) hilft dabei. Es beschreibt, wie man NAT umgeht und eine Verbindung herstellt, wenn wir NAT haben. Dieses Framework verwendet einen STUN-Server, einen speziellen Server, an den Sie sich wenden können, um Ihre externe IP-Adresse herauszufinden. Während des P2P-Verbindungsaufbaus muss jeder Client eine Anfrage an diesen STUN-Server stellen, um seine IP-Adresse zu ermitteln, zusätzliche Informationen zu generieren (IceCandidate) und diesen IceCandidate mithilfe des Signalmechanismus auszutauschen. Die Clients erfahren dann gegenseitig die richtigen IP-Adressen und können eine P2P-Verbindung herstellen. Es gibt jedoch komplexere Fälle, z. B. wenn ein Computer hinter doppeltem NAT versteckt ist. In solchen Fällen schreibt das ICE-Framework die Verwendung eines TURN-Servers vor. Dabei handelt es sich um einen speziellen Server, der die Client-Client- (P2P) -Verbindung in eine Client-Server-Client-Verbindung umwandelt und als Relay fungiert. Die gute Nachricht für Entwickler ist, dass unabhängig davon, in welchem der drei Szenarien die Verbindung hergestellt wurde (lokales Netzwerk, STUN-Server oder TURN-Server), die API-Technologie identisch bleibt. Zu Beginn spezifizieren wir einfach die Konfiguration der ICE- und TURN-Server, geben an, wie auf sie zugegriffen wird, und dann kümmert sich die Technologie um alles unter der Haube. Dies bringt weitere Herausforderungen mit sich, wie z. B. die Notwendigkeit, über STUN- und TURN-Server zu verfügen, und die damit verbundenen Kosten für deren Support und Wartung. Obwohl der TURN-Server ein einfacher Proxy ist und kein Video verarbeitet, muss er über eine schnelle Internetverbindung verfügen, um den Medienstream in Echtzeit an alle Konferenzteilnehmer verteilen zu können.

WebRTC auf dem Videokonferenzmarkt

  • Beliebtheit der Technologie: Bis heute ist WebRTC nach dem proprietären Zoom-Protokoll das zweitbeliebteste Videokommunikationsprotokoll und übertrifft damit alle anderen Standards (H.323 und SIP) und proprietären Protokolle (Microsoft Teams und Cisco Webex).
  • Anstieg der Kundenzahlen: Die WebRTC-Technologie hat einen starken Einfluss auf die Entwicklung des Videokonferenzmarktes. Nach der Veröffentlichung der ersten Browser mit WebRTC-Unterstützung im Jahr 2013 stieg die potenzielle Anzahl von Videokonferenzterminals weltweit sofort um 1 Milliarde Geräte. Im Wesentlichen wurde jeder Browser zu einem Videokonferenzterminal mit grundlegenden Funktionen für die Teilnahme an einer Videokonferenz.
  • Einsatz in Speziallösungen: Die Verwendung verschiedener JavaScript-Bibliotheken und Cloud-Service-APIs, die WebRTC unterstützen, ermöglicht das einfache Hinzufügen von Videounterstützung zu beliebigen Webprojekten. In der Vergangenheit mussten Entwickler für die Datenübertragung in Echtzeit verstehen, wie Protokolle funktionieren, und die Arbeit anderer Unternehmen nutzen. Oft waren zusätzliche Lizenzen erforderlich, was die Kosten erhöhte. Derzeit wird WebRTC aktiv für die Organisation von Video-Kontaktzentren, die Durchführung von Webinaren usw. verwendet.
  • Konkurrenz mit Flash: WebRTC und HTML5 haben der Flash-Technologie, die bereits ihre schlechteren Jahre hinter sich hatte, einen fatalen Schlag versetzt. Seit 2017 unterstützen führende Browser Flash offiziell nicht mehr, und diese Technologie ist vom Markt verschwunden.

Beispiele für Dienste, die WebRTC verwenden

  • Google Meet: Google Meet ist ein Messaging-Dienst sowie eine Plattform für Video- und Audioanrufe, die 2017 von Google eingeführt wurden. Chromium-basierte Browser (Google Chrome usw.) nutzen viele versteckte WebRTC-Funktionen, die nicht dokumentiert sind und regelmäßig zum ersten Mal in der Meet-Lösung (sowie im Vorgänger Hangouts) auftauchen. Dies war bei der Bildschirmaufnahme, der Hintergrundunschärfe und der Unterstützung der Hardwarecodierung auf bestimmten Plattformen der Fall.
  • Jitsi Treffen: Jitsi Meet ist eine Open-Source-Anwendung, die von 8x8 veröffentlicht wurde. Die Jitsi-Technologie basiert auf einer Simulcast-Architektur, was einen instabilen Betrieb auf schwachen Kommunikationskanälen und hohe Anforderungen an die Verbindungsgeschwindigkeit auf der Serverseite bedeutet. Sie ermöglicht Webkonferenzen nur im Browser und verfügt nicht über vollwertige Anwendungen für die Zusammenarbeit mit Kunden. Konferenzen mit bis zu 75 Teilnehmern werden unterstützt (bis zu 35 mit hoher Anrufqualität). Für den vollwertigen Einsatz von Jitsi in einer Unternehmensumgebung muss zusätzliche Software separat entwickelt und installiert werden.
  • Großer blauer Knopf: BigBlueButton ist eine kostenlose Software für Videokonferenzen. Entwickler legen besonderen Wert auf Fernunterricht (Funktionen wie interaktive Whiteboards, Inhaltsanzeige, Unterstützung für Umfragen usw. sind verfügbar). Es unterstützt Webkonferenzen für bis zu 100 Teilnehmer.
  • Was ist mit Zoom?: Entgegen der landläufigen Meinung verwendet Zoom keine WebRTC-Technologie für die Übertragung und Dekodierung von Mediendaten. Diese Entscheidung wurde getroffen, um Serverressourcen zu sparen. Auf der Browserseite sind andere Webtechnologien involviert — Low-Level-WebAssembly und WebSocket. Die Verwendung dieser nicht standardmäßigen Verfahren zur Übertragung von Videostreams kann dazu führen, dass bei einigen Teilnehmern Probleme mit der Videoqualität auftreten.

Jakub Bílý

Leiter/in Geschäftsentwicklung

Gemeinsam zu erfolgreichen Ergebnissen!
Füllen Sie das Formular aus, und wir antworten Ihnen innerhalb von 8 Geschäftsstunden.
Wir beantworten gerne all Ihre Fragen!
Wir analysieren Ihr Projekt und besprechen die Details.

Kontakt aufnehmen

Uploading...
fileuploaded.jpg
Upload failed. Max size for files is 10 MB.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
KI-übersetzt