1. Introduction (Einführung)
Das Internet wurde von Anfang an als mögliches Vehikel für die Bereitstellung von Echtzeit-Interaktiven Anwendungen betrachtet -- wobei die am leichtesten vorstellbaren Audio-Gespräche (auch "Internet-Telefonie" genannt) und Videokonferenzen sind.
Die ersten Versuche, solche Anwendungen zu erstellen, waren abhängig von speziellen Netzwerken, spezieller Hardware und maßgeschneiderter Software, oft zu sehr hohen Preisen oder von geringer Qualität, und stellten hohe Anforderungen an die Infrastruktur.
Da die verfügbare Bandbreite zugenommen hat und Prozessoren und andere Hardware immer schneller geworden sind, sind die Teilnahmehürden gesunken, und es ist möglich geworden, eine zufriedenstellende Erfahrung auf allgemein verfügbarer Computer-Hardware zu liefern.
Dennoch gibt es noch eine Reihe von Hindernissen für die Fähigkeit zur universellen Kommunikation -- eines davon ist, dass es bisher noch keinen einzigen Satz von Kommunikationsprotokollen gibt, über den sich alle einig sind, dass er für die Kommunikation zur Verfügung gestellt werden sollte; ein anderes ist der schlichte Mangel an universellen Identifikationssystemen (wie sie durch Telefonnummern oder E-Mail-Adressen in anderen Kommunikationssystemen bereitgestellt werden).
Die Entwicklung der "Universellen Lösung" hat sich jedoch als schwierig erwiesen.
Die letzten Jahre haben auch das Aufkommen einer neuen Plattform für die Bereitstellung von Diensten gesehen: die browsereingebettete Anwendung (Browser-Embedded Application) oder "Webanwendung (Web Application)". Es stellt sich heraus, dass es möglich ist, fast jede Art von Dienst darauf bereitzustellen, solange die Browserplattform über die notwendigen Schnittstellen verfügt.
Traditionell wurden diese Schnittstellen durch Plugins bereitgestellt, die separat vom Browser heruntergeladen und installiert werden mussten; bei der Entwicklung von HTML5 [HTML5] sehen Anwendungsentwickler große Versprechungen in der Möglichkeit, diese Schnittstellen auf standardisierte Weise innerhalb des Browsers verfügbar zu machen.
Dieses Memo beschreibt eine Reihe von Bausteinen (Building Blocks), die (1) über eine JavaScript-API in einem Browser zugänglich und steuerbar gemacht werden können und (2) zusammen einen ausreichenden Satz von Funktionen bilden, um die Verwendung von interaktivem Audio und Video in Anwendungen zu ermöglichen, die direkt zwischen Browsern über das Internet kommunizieren. Die resultierende Protokollsuite soll alle Anwendungen ermöglichen, die als erforderliche Szenarien im WebRTC-"Use Cases"-Dokument [RFC7478] beschrieben sind.
Andere Bemühungen -- beispielsweise die W3C Web Real-Time Communications, Web Applications Security und Devices and Sensors Working Groups -- konzentrieren sich darauf, standardisierte APIs und Schnittstellen im Rahmen oder parallel zur HTML5-Bemühung für diese Funktionen verfügbar zu machen. Dieses Memo konzentriert sich auf die Spezifikation der Protokolle und Unterprotokolle, die zur Spezifikation der Interaktionen über das Netzwerk erforderlich sind.
Betreiber sollten beachten, dass die Bereitstellung von WebRTC zu einer Änderung der Art der Signalisierung für Echtzeitmedien im Netzwerk führen wird und zu einer Verschiebung bei den Arten von Geräten führen kann, die zum Erstellen und Konsumieren solcher Medien verwendet werden. Im Fall der Signalisierung wird die WebRTC-Sitzungseinrichtung typischerweise über TLS-gesicherte Webtechnologien unter Verwendung anwendungsspezifischer Protokolle erfolgen. Betriebstechniken, die das Einfügen von Netzwerkelementen zur Interpretation des Session Description Protocol (SDP) beinhalten -- entweder durch (1) den Endpunkt, der das Netzwerk nach einem SIP-Server fragt [RFC3361], oder (2) das transparente Einfügen von SIP Application Layer Gateways (ALGs) -- werden mit solcher Signalisierung nicht funktionieren. Im Fall von Netzwerken, die kooperative Endpunkte verwenden, können die in [RFC8155] definierten Ansätze als geeigneter Ersatz für [RFC3361] dienen. Die Zunahme der browserbasierten Kommunikation kann auch zu einer Abkehr von dedizierter Echtzeit-Kommunikationshardware führen, wie z.B. SIP-Tischtelefone. Dies wird die Wirksamkeit von Betriebstechniken verringern, die dedizierte Echtzeitgeräte in ihrem eigenen Netzwerksegment, Adressbereich oder VLAN platzieren, um Zwecke wie die Anwendung von Verkehrsfilterung und QoS zu erreichen. Die Anwendung der in [RFC8837] beschriebenen Markierungen kann ein angemessener Ersatz für solche Techniken sein.
Obwohl dieses Dokument sich formal auf [RFC8445] stützt, unterstützt zum Zeitpunkt seiner Veröffentlichung die Mehrheit der WebRTC-Implementierungen die Version von Interactive Connectivity Establishment (ICE), die in [RFC5245] beschrieben ist, und verwendet eine Vor-Standard-Version des in [RFC8838] beschriebenen Trickle ICE-Mechanismus. Das in [RFC8445] definierte "ice2"-Attribut kann verwendet werden, um die von einem Remote-Endpunkt verwendete Version zu erkennen und einen reibungslosen Übergang von der älteren Spezifikation zur neueren zu ermöglichen.
Dieses Memo verwendet den Begriff "WebRTC" (beachten Sie die verwendete Groß-/Kleinschreibung), um sich auf die Gesamtanstrengung zu beziehen, die sowohl aus IETF- als auch aus W3C-Bemühungen besteht.