Mit WebRTC [20] können Anwendungen entwickelt werden – die nicht nur auf Kommunikationsfunktionen beschränkt sind. WebRTC ist nicht (nur / hauptsächlich) über das "Aufrufen" innerhalb des Browsers, sondern darüber, wie Webentwickler über JavaScript auf Audio / Video-Eingabegeräte zugreifen und das Problem der Browser-to-Browser-Kommunikation für normale Web-Entwickler abstrahieren können.
Sobald das Browser-to-Browser-Kommunikationsproblem gelöst ist, stellt WebRTC sowohl einen Benutzerdatenkanal für Echtzeitkommunikationsdaten als auch einen Datenkanal bereit, um irgendeine Art von anderen Daten in einer Peer-to-Peer-Weise zu senden.
All dies erfordert meist keine Plug-Ins - sondern wird nativ in den Browsern unterstützt (derzeit Google Chrome, Mozilla Firefox, Opera, Microsoft Edge).
Die einfachste Anwendung für WebRTC ist die Audio / Video-Kommunikation zwischen den Browsern. Die integrierte WebRTC-Fähigkeit bietet Mikrofon (Audio) und Kamera (Video) -Zugriff (der Benutzer kann das Gerät auswählen und Erlaubnis erteilen).
Die wichtigen API-Funktionen für diesen Anwendungsfall sind
Bevor getUserMedia verfügbar war, kannten die Browser bereits "statische" Medienobjekte (<img>, <video>, <audio>). Diese Objekte können angezeigt, aber auch manipuliert werden (z. B. ein <img> -Tag kann man mit dem Attribut width = "400" das Bilds/Video skalieren). Die getUserMedia API erlaubt den Zugriff auf dynamische Quellen wie Mikrofone und Kameras. Die Eigenschaften dieser Quellen können sich an Anwendungsbedürfnisse anpassen. MediaConstraints werden standardmäßig zur Beschränkung von Ressourcen verwendet.
Die PeerConnection ist eine Medientechnologie, die es zwei Benutzern ermöglicht, direkt mit dem Browser zu kommunizieren. Diese Kommunikation wird über einen Signalisierungskanal koordiniert, der durch nicht spezifizierte Mittel bereitgestellt wird, jedoch in der Regel durch ein Skript auf der vom Webserver bereitgestellten Webseite. Viele Websites haben bereits die Möglichkeit, Nachrichten zwischen Web-Client und Server (z. B. über Web-Sockets) auszutauschen.
Beispieldienste sind:
Mit dem RTCDataChannel kann eine Webanwendung generische Anwendungsdaten Peer-to-Peer senden und empfangen.
Die DataChannel-Schnittstelle stellt einen bidirektionalen Datenkanal zwischen zwei Peers dar. Die PeerConnection repräsentiert nur einen Kanal für RTC. Der DataChannel kann jede Art von Daten transportieren.
Ein Beispiel Service ist sharefest.me.
Die getUserMedia API kann nicht nur auf Kamera / Mikrofon als Medienquelle zugreifen, sondern auch auf den gemeinsamen Bildschirm. Aus Sicherheitsgründen erfordert der Zugriff auf den Bildschirm ein Plug-In. Dieses Plug-in ist jedoch nicht die Bereitstellung von Screen-Sharing als solche (dies erfolgt durch die WebRTC Teil des Browsers), sondern gewährt nur den Zugriff auf die Browser-API für bestimmte Domains, die explizit über das Plug-In erlaubt sind.
Die meisten Dienste, die verwendet werden, um mit Audio / Video kommunizieren bieten auch ein Bildschirmfreigabe.
Neben der A / V-Kommunikation und der Bildschirmfreigabe kann der angewendete Datenkanal auch zur Übertragung nicht nur von Dateien, sondern auch von Steuerinformationen verwendet werden. Diese Steuerinformation kann verwendet werden, um den angezeigten Browser-Inhalt zu modifizieren.
Eine Beispielanwendung für dieses kann ein kollaboratives Whiteboard sein. Durch das Senden der Eingaben von einem Whiteboard ("Editor") zu allen anderen Whiteboards unter demselben Link ( "Zuschauer") kann die Browseranwendung als Shared Whiteboard agieren. Unterstützt durch WebRTC-Kommunikationsfunktionen kann eine solche Website z.B. Innerhalb von E-Learning benutzt werden.
Aus dem reinen Browser-Konzept ist WebRTC als Peer-to-Peer-Kommunikation konzipiert, ohne dass zusätzliche Infrastruktur benötigt wird.
Dieser architektonische Ansatz macht schwieriger die Sitzungen mit mehreren Streams, wie Gruppen-Videokonferenzen oder anderen "n-zu-m" Sende-Szenarien zu realisieren.
Dies ist der Punkt, bei dem der Conferencing Baustein ins Spiel kommt. Der Conferencing Building Block kümmert sich um die Verteilung von Medienverkehr zu einer Gruppe von Peers. Diese Verteilung ist auf drei verschiedene Arten möglich, die sich primär in ihren Anforderungen an zusätzliche Server unterscheiden.
Beginnen wir mit dem Peer-to-Peer-Konzept, das zu einem völlig vernetzten Ansatz führt.
Der größte Vorteil dieses Ansatzes ist seine Einfachheit, von einem Entwickler gebaut zu werden, da das keinen Verteilungspunkt im Zentrum des Netzwerks benötigt (vgl. Abbildung 12).
Auf der anderen Seite kommt diese Einfachheit mit einem Preis von einer sehr hohen Nachfrage in Bezug auf die Netzleistung. Je mehr Teilnehmer an einer Konferenz teilnehmen, desto höher wird die erforderliche Netzwerkleistung.
Im Gegensatz zum Peer-to-Peer-Ansatz, der eine selektive Weiterleitungseinheit bzw. eine Mediensteuereinheit beinhaltet, sind zusätzliche Server erforderlich (siehe Abbildung 13). Eine selektive Weiterleitungseinheit wirkt ähnlich wie ein Router oder Proxy, der jeden Medienstrom den er von einem Peer empfängt zu allen anderen Peers sendet.
Einerseits verringert sich dadurch die erforderliche Netzwerkleistung durch das Hochladen von nur einem Medienstrom pro Peer.
Andererseits wird die erforderliche Netzwerkleistung nur auf die selektive Weiterleitungseinheit verschoben.
Bei einer Mediensteuereinheit empfängt die Zentraleinheit, ähnlich wie die selektive Weiterleitungseinheit, alle Medienströme von den Peers. In einem zweiten Schritt wird der Verkehr jedoch von der Zentraleinheit verarbeitet, um für jeden Peer einen einzelnen Stream zu bauen. Die Mediensteuereinheit überträgt nur den einen einzelnen Strom zu jedem einzelnen Peer, was zu einer großen Verbesserung in Bezug auf die erforderliche Netzwerkleistung führt. Zusätzlich ermöglicht dieser Ansatz auch eine Vielzahl von denkbaren Anwendungsfällen, indem unterschiedliche Arten der Medienverarbeitung auf der Zentraleinheit verwendet werden.