Was ist WebRTC (Web Real Time Communications)?

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.
Betrachten Sie den Betrieb der Technologie am Beispiel eines Anrufs zwischen zwei Teilnehmern über einen Browser:
WebRTC-Codecs können in obligatorische (Browser, die diese Technologie implementieren, müssen sie unterstützen) und optionale (nicht im Standard enthalten, aber von einigen Browsern hinzugefügt) unterteilt werden.
Um den Audioverkehr in WebRTC zu komprimieren, werden obligatorische Codecs (Opus und G.711) und zusätzliche (G.722, iLBC, iSAC) verwendet.
Opus
Opus ist ein Audiocodec mit niedriger Kodierungslatenz (von 2,5 ms bis 60 ms), Unterstützung variabler Bitraten und hoher Komprimierung, der sich ideal für Audio-Streaming über Netzwerke 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 (Audio Data Encoding) kombiniert. Der Codec ist frei verfügbar. Entwickler, die ihn verwenden, müssen den Urheberrechtsinhabern keine Lizenzgebühren zahlen. Im Vergleich zu anderen Audiocodecs gewinnt Opus sicherlich in vielerlei Hinsicht. In einer Reihe von 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 hoher Bitrate (64 Kbit/s), der am häufigsten in herkömmlichen Telefonsystemen verwendet wird. Der Hauptvorteil ist die minimale Rechenlast aufgrund der Verwendung leichter Komprimierungsalgorithmen. Der Codec hat eine geringe Komprimierung von Sprachsignalen und verursacht keine zusätzliche Audioverzögerung bei der Kommunikation zwischen Benutzern.
G.711 wird von einer Vielzahl von Geräten unterstützt. Systeme, die diesen Codec verwenden, sind einfacher zu verwenden als Systeme, die auf anderen Audiocodecs basieren (G.723, G.726, G.728 usw.). In Bezug auf die Qualität erhielt G.711 beim MOS-Test eine Punktzahl von 4,2 (ein Wert von 4-5 ist der höchste Wert und bedeutet gute Qualität, ähnlich der Qualität des Sprachverkehrs in ISDN und sogar höher).
G.722
G.722 ist ein ITU-T-Standard, der 1988 verabschiedet wurde und derzeit kostenlos ist. Es kann mit 48, 56 und 64 kbps betrieben werden und bietet eine Klangqualität auf dem Niveau von G.711. Und ebenso ist G.711 veraltet. Wird in Chrome, Safari und Firefox unterstützt.
iLBC
iLBC (Internet Low Bitrate Codec) ist ein Open-Source-Schmalband-Sprachcodec. Verfügbar in Chrome und Safari. Aufgrund der hohen Komprimierung des Streams erhöht sich bei Verwendung dieses Codecs die Belastung des Prozessors.
iSAC
iSAC (Internet Speech Audio Codec) ist ein Breitband-Sprachaudiocodec, der früher proprietär war und derzeit Teil des WebRTC-Projekts ist, aber nicht verwendet werden muss. Wird in Chrome und Safari unterstützt. Die Implementierung für WebRTC verwendet eine adaptive Bitrate von 10 bis 52 kbit/s mit einer Abtastrate von 32 kHz.
Die Probleme bei der Auswahl eines Videocodecs für WebRTC dauerten die Entwickler mehrere Jahre. Infolgedessen wurden VP8 und H.264 in den Standard aufgenommen. 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 für Videostreams und eine erhöhte Widerstandsfähigkeit gegen Bildverluste auszeichnet. Der Codec ist universell und lässt sich leicht in Hardwareplattformen implementieren, sodass Entwickler von Videokonferenzsystemen ihn häufig in ihren Produkten verwenden. Kompatibel mit den Browsern Chrome, Edge, Firefox und Safari (12.1+).
Der kostenpflichtige H.264-Videocodec wurde viel früher bekannt als sein Gegenstück. Dies ist ein Codec mit einem hohen Komprimierungsgrad des Videostreams bei gleichbleibender hoher Videoqualität. Die weit verbreitete Verwendung dieses Codecs in Hardware-Videokonferenzsystemen deutet auf seine Verwendung im WebRTC-Standard hin. Kompatibel mit 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 der in VP8 enthaltenen Ideen und wurde anschließend im Rahmen von AV1 erweitert. Kompatibel mit Chrome (48+) und Firefox-Browsern.
H.265
H.265 ist ein kostenpflichtiger Videocodec, der der Nachfolger von H.264 ist und dieselbe visuelle Qualität bei halber Bitrate bietet. Dies wird durch effizientere Komprimierungsalgorithmen erreicht. Dieser Codec konkurriert derzeit mit dem kostenlosen AV1.
AV1
AV1 ist ein Open-Source-Videokomprimierungscodec, der speziell für die Übertragung von Videos über das Internet entwickelt wurde. Wird in Chrome (70+) und Firefox (67+) unterstützt.
WebRTC bietet Browsern keine Möglichkeit, einander zu finden. Wir können alle notwendigen Metainformationen über unsere Lieben generieren, aber woher weiß ein Browser von der Existenz eines anderen? Wie verbinde ich sie?
Ein WebRTC-Signalserver ist ein Server, der die Verbindungen zwischen Peers verwaltet. Es wird nur zur Signalisierung verwendet. Es hilft dabei, einem Peer zu ermöglichen, einen anderen im Netzwerk zu finden, die Verbindung selbst auszuhandeln, die Verbindung bei Bedarf zurückzusetzen und zu schließen.
WebRTC spezifiziert kein Signalisierungsprotokoll, Sie müssen es selbst entwickeln oder vorgefertigte Lösungen verwenden. Außerdem ist der Transport für das Signalisierungsprotokoll nicht spezifiziert. Sie können HTTP, WebSocket oder Datachanal verwenden. Wird häufig als WebSocket verwendet, falls es auf einer dauerhaften Verbindung basiert und Daten nahezu in Echtzeit übertragen kann.
Wir können die Namen und Eigenschaften der Kameras erst ermitteln, wenn die Verbindung hergestellt ist. Wenn mehr als eine Kamera auf dem Client-System installiert ist. Zum Beispiel mobile Geräte. Wir können dem Benutzer nur die Wahl zwischen Kamera 1 und Kamera 2 anbieten, nennen diese Kameras aber nicht (zum Beispiel „Logitech“, „Frontkamera“, „FullHD-Kamera“)
Wenn der Client während der Sitzung ein neues Gerät anschließt, wird die Webanwendung erst darüber 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.
Aus Sicherheitsgründen bietet der Browser keinen direkten Zugriff auf Kameratreiber.
Daher können wir nicht auf der Kamera bestehen, die Auflösung, Bildrate usw. wählen.
Außerdem können wir keine Video-Nachbearbeitung durchführen, die Helligkeit anpassen, das Video spiegeln und andere Dinge, die normalerweise in den Kameratreibereinstellungen enthalten sind.
Es gibt auch keine einheitliche Standardlösung für Desktop-Sharing. Möglicherweise haben Sie in Videokonferenzanwendungen festgestellt, dass, wenn Sie beginnen, einen Desktop gemeinsam zu nutzen, häufig ein zusätzlicher Konferenzteilnehmer erstellt wird, der das von Ihnen gewählte Desktop- oder Anwendungsfenster streamt. Die Probleme, mit denen wir bei der Arbeit mit Kameras konfrontiert sind (die Unfähigkeit, den Kameranamen anzugeben und die Eigenschaften des Geräts nicht zu ermitteln), gelten auch für die Arbeit mit Monitoren bei der Übertragung des Desktops.
Die API zum Generieren von SDP ist asynchron, daher kann es Situationen geben, in denen die im eingehenden SDP-Paket beschriebenen Parameter des Medienstreams nicht dem entsprechen, was der Client tatsächlich sendet.
Es gibt zwei SDP-Formate: Plan B, der von Chromium-basierten Browsern verwendet wird, 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.
Mit dem Unified Plan können Sie für jeden Medienstream einen Codec auswählen.
Codieren Sie beispielsweise die Desktopübertragung 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.
Wie lebt man, wenn es NAT gibt, wenn Computer unter einer IP-Adresse herausragen, aber innerlich voneinander erfahren? Das ICE-Framework hilft dabei: Internet Connectivity Establishment. Es beschreibt, wie man NAT umgeht und wie man eine Verbindung herstellt, wenn wir NAT haben.
Dieses Framework verwendet den STUN-Server. Dies ist so ein spezieller Server, anhand dessen Sie Ihre externe IP-Adresse herausfinden können. Daher muss jeder Client beim Aufbau einer P2P-Verbindung eine Anfrage an diesen STUN-Server stellen, um seine IP-Adresse herauszufinden, zusätzliche Informationen (IceCandidate) zu generieren und diesen IceCandidate mithilfe des Signalmechanismus auszutauschen. Dann wissen die Clients mit den richtigen IP-Adressen voneinander und können eine P2P-Verbindung herstellen. Es gibt jedoch komplexere Fälle. Zum Beispiel, wenn der Computer hinter Double-NAT versteckt ist. In diesem Fall schreibt das ICE-Framework die Verwendung eines TURN-Servers vor.
Dies ist ein so spezieller Server, der die Client-Client-Verbindung, P2P, in eine Client-Server-Client-Verbindung umwandelt, das heißt, er fungiert als Relay. Die gute Nachricht für Entwickler ist, dass unabhängig davon, in welchem der drei Szenarien die Verbindung hergestellt wurde, ob wir uns im lokalen Netzwerk befinden oder ob wir den STUN- oder TURN-Server kontaktieren müssen, die API-Technologie für uns identisch sein wird. Wir geben einfach zu Beginn die Konfiguration der ICE- und TURN-Server an, geben an, wie auf sie zugegriffen werden kann, und danach erledigt die Technologie alles für uns unter der Haube.
Hier stehen wir vor weiteren Schwierigkeiten. Die erste ist die Notwendigkeit, über STUN- bzw. TURN-Server zu verfügen, was die Kosten für deren Support und Wartung angeht. Obwohl der TURN-Server ein einfacher Proxyserver ist und kein Video verarbeitet, muss er über eine Hochgeschwindigkeits-Internetverbindung verfügen, um einen Medienstream in Echtzeit an alle Konferenzteilnehmer verteilen zu können.
Bis heute ist WebRTC nach dem proprietären Zoom-Protokoll das zweitbeliebteste Videokommunikationsprotokoll und liegt vor allen anderen Standards (H.323 und SIP) und proprietären (Microsoft Teams und Cisco Webex) Protokollen.
Die WebRTC-Technologie hatte 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 auf der ganzen Welt sofort um 1 Milliarde Geräte. Tatsächlich ist jeder Browser zu einem Videokonferenzterminal mit grundlegenden Funktionen für die Teilnahme an Videokonferenzen geworden.
Einsatz in Speziallösungen
Die Verwendung verschiedener JavaScript-Bibliotheken und Cloud-Service-APIs mit WebRTC-Unterstützung erleichtert das Hinzufügen von Videounterstützung zu beliebigen Webprojekten. In der Vergangenheit mussten Entwickler für die Datenübertragung in Echtzeit lernen, wie die Protokolle funktionieren, und die Arbeit anderer Unternehmen nutzen, wofür in den meisten Fällen zusätzliche Lizenzen erforderlich waren, was die Kosten erhöhte. WebRTC wird bereits aktiv für die Organisation von Video-Kontaktzentren, die Durchführung von Webinaren usw. genutzt.
WebRTC und HTML5 waren ein Todesstoß für die Flash-Technologie, die bereits ihre bei weitem nicht besten Jahre hinter sich hatte. Seit 2017 unterstützen die führenden Browser Flash offiziell nicht mehr und die Technologie ist endgültig vom Markt verschwunden.
Google Meet ist ein Instant-Messaging-Dienst sowie Video- und Audioanrufe, der 2017 von Google veröffentlicht wurde. Chromium-basierte Browser (Google Chrome usw.) verwenden viele versteckte WebRTC-Funktionen, die nicht dokumentiert sind und in regelmäßigen Abständen an erster Stelle in den Meet-Lösungen erscheinen (wie beim Hangouts-Vorgänger). So war es auch bei der Bildschirmaufnahme, der Hintergrundunschärfe und der Unterstützung der Hardwarecodierung auf einigen Plattformen.
Jitsi Meet ist eine Open-Source-App, die von 8x8 veröffentlicht wurde. Die Jitsi-Technologie basiert auf der Simulcast-Architektur, was einen instabilen Betrieb auf schwachen Kommunikationskanälen und hohe Anforderungen an die Verbindungsgeschwindigkeit auf der Serverseite bedeutet. Ermöglicht die Durchführung von Webkonferenzen nur in einem Browser und verfügt nicht über vollwertige Client-Anwendungen für die Zusammenarbeit. Konferenzen mit maximal 75 Teilnehmern werden unterstützt (bis zu 35 mit hoher Anrufqualität). Um Jitsi in einer Unternehmensumgebung vollständig nutzen zu können, müssen Sie selbstständig zusätzliche Software entwickeln und installieren.
BigBlueButton ist eine kostenlose Videokonferenzsoftware. Die Entwickler legen besonderen Wert auf Fernunterricht (es gibt Funktionen wie ein interaktives Whiteboard, das Anzeigen von Inhalten, die Unterstützung von Umfragen usw.). Unterstützt Webkonferenzen mit bis zu 100 Teilnehmern.
Entgegen der landläufigen Meinung verwendet Zoom keine WebRTC-Technologie, um Mediendaten zu übertragen und zu dekodieren. Dies wurde getan, um Serverressourcen zu sparen. Auf der Browserseite sind andere Webtechnologien beteiligt - Low-Level-WebAssembly und WebSocket. Bei der Verwendung solcher nicht standardmäßiger Verfahren zur Übertragung eines Videostreams können bei einigen Teilnehmern Probleme mit der Bildqualität auftreten.
WebRTC revolutioniert die Echtzeitkommunikation, indem es den direkten Austausch von Sprache, Video und Daten in Browsern ermöglicht, ohne dass Plugins erforderlich sind. Aufgrund seiner einfachen Integration und umfassenden Kompatibilität eignet es sich ideal für moderne Kommunikationslösungen. Sind Sie bereit, WebRTC in Ihrem Projekt zu implementieren? Kontaktieren Sie Moravio noch heute, um herauszufinden, wie unser Team eine vollständig maßgeschneiderte Kommunikationsplattform bereitstellen kann, die Ihren Geschäftsanforderungen entspricht.
Empfohlene Lektüre für Sie
Neue Blogbeiträge, die Sie interessieren könnten
Jakub Bílý
Leiter/in Geschäftsentwicklung