3. Architecture and Functionality Groups (Architektur und Funktionsgruppen)
Das Modell für Echtzeitunterstützung für browserbasierte Anwendungen geht nicht davon aus, dass der Browser alle Funktionen enthält, die von Anwendungen wie Telefonie oder Videokonferenzen benötigt werden. Die Vision ist, dass der Browser die Funktionen haben wird, die für die Webanwendung erforderlich sind, und in Zusammenarbeit mit seinen Backend-Servern arbeitet, um diese Funktionen zu implementieren.
Dies bedeutet, dass zwei wichtige Schnittstellen spezifiziert werden müssen: die Protokolle, die der Browser verwendet, um miteinander ohne zwischengeschaltete Server zu kommunizieren, und die API, die JavaScript-Anwendungen zur Verfügung gestellt wird, um die Fähigkeiten des Browsers zu nutzen.
+------------------------+ On-the-wire
| | Protocols
| Servers |--------->
| |
| |
+------------------------+
^
|
|
| HTTPS/
| WebSockets
|
|
+----------------------------+
| JavaScript/HTML/CSS |
+----------------------------+
Other ^ ^ RTC
APIs | | APIs
+---|-----------------|------+
| | | |
| +---------+|
| | Browser || On-the-wire
| Browser | RTC || Protocols
| | Function|----------->
| | ||
| | ||
| +---------+|
+---------------------|------+
|
V
Native OS Services
Abbildung 1: Browsermodell
Beachten Sie, dass HTTPS und WebSockets auch JavaScript-Anwendungen über Browser-APIs zur Verfügung gestellt werden.
Wie bei allen Protokoll- und API-Spezifikationen sind die Protokolle nicht darauf beschränkt, nur für die Kommunikation mit einem anderen Browser verwendet zu werden; da sie vollständig spezifiziert sind, sollte jeder Endpunkt, der die Protokolle getreu implementiert, in der Lage sein, mit Anwendungen zu interoperieren, die im Browser laufen.
Abbildung 2 beschreibt ein gängiges Bereitstellungsmodell. ("JS" steht für JavaScript.)
+-----------+ +-----------+
| Web | | Web |
| | | |
| |------------------| |
| Server | Signaling Path | Server |
| | | |
+-----------+ +-----------+
/ \
/ \ Application-defined
/ \ over
/ \ HTTPS/WebSockets
/ Application-defined over \
/ HTTPS/WebSockets \
/ \
+-----------+ +-----------+
|JS/HTML/CSS| |JS/HTML/CSS|
+-----------+ +-----------+
+-----------+ +-----------+
| | | |
| | | |
| Browser |--------------------------------| Browser |
| | Media Path | |
| | | |
+-----------+ +-----------+
Abbildung 2: Browser-RTC-Trapezoid
In diesem Diagramm sind die wichtigen Teile zu beachten, dass der Medienpfad (der "untere Pfad") direkt zwischen Browsern verläuft, daher muss er den Spezifikationen der WebRTC-Protokollsuite entsprechen; der Signalisierungspfad (der "obere Pfad") verläuft über Server, die die Signale nach Bedarf ändern, übersetzen oder manipulieren können.
Wenn die beiden Webserver von verschiedenen Entitäten betrieben werden, ist eine Vereinbarung über den Inter-Server-Signalisierungsmechanismus durch Standardisierung oder andere Protokollmittel erforderlich. Bestehende Protokolle (z. B. SIP [RFC3261] oder Extensible Messaging and Presence Protocol (XMPP) [RFC6120]) können zwischen Servern verwendet werden, und standardbasierte oder proprietäre Protokolle können zwischen dem Browser und dem Webserver verwendet werden.
Wenn beispielsweise die Server beider Betreiber SIP implementieren, kann SIP für die Kommunikation zwischen den Servern verwendet werden, während ein standardisierter Signalisierungsmechanismus (z. B. SIP over WebSockets) oder proprietärer Mechanismus zwischen der im Browser laufenden Anwendung und dem Webserver verwendet wird. Ebenso, wenn die Server beider Betreiber XMPP implementieren, kann XMPP zwischen XMPP-Servern verwendet werden, während ein standardisierter Signalisierungsmechanismus (z. B. XMPP over WebSockets oder Bidirectional-streams Over Synchronous HTTP (BOSH) [XEP-0124]) oder proprietärer Mechanismus zwischen der im Browser laufenden Anwendung und dem Webserver verwendet wird.
Die Wahl der Protokolle für Client-Server- und Inter-Server-Signalisierung sowie die Definition der Übersetzungen zwischen ihnen liegen außerhalb des Umfangs der in diesem Dokument beschriebenen WebRTC-Protokollsuite.
Die im Browser benötigten Funktionsgruppen können mehr oder weniger von unten nach oben wie folgt spezifiziert werden:
Data transport (Datentransport): Zum Beispiel TCP und UDP sowie Mittel zum sicheren Aufbau von Verbindungen zwischen Entitäten und Funktionen zur Entscheidung, wann Daten gesendet werden sollen: Staumanagement (Congestion Management), Bandbreitenschätzung (Bandwidth Estimation) usw.
Data framing (Datenrahmung): RTP, Stream Control Transmission Protocol (SCTP), DTLS und andere Datenformate, die als Container verwendet werden, sowie deren Funktionen für Datenvertraulichkeit und -integrität.
Data formats (Datenformate): Codec-Spezifikationen (Codec Specifications), Format-Spezifikationen (Format Specifications) und Funktions-Spezifikationen für zwischen Systemen übertragene Daten. Audio- und Video-Codecs sowie Formate für Daten- und Dokumentfreigabe fallen alle in diese Kategorie. Um ein Datenformat zu verwenden, ist eine Möglichkeit erforderlich, sie zu beschreiben (z. B. Sitzungsbeschreibung (Session Description)).
Connection management (Verbindungsmanagement): Zum Beispiel Aufbau von Verbindungen, Vereinbarung über Datenformate, Änderung von Datenformaten während eines Anrufs. SDP, SIP und Jingle/XMPP fallen in diese Kategorie.
Presentation and control (Präsentation und Steuerung): Was passieren muss, um sicherzustellen, dass Interaktionen auf nicht überraschende Weise ablaufen. Dies kann Floor Control, Bildschirmlayout (Screen Layout), sprachaktivierte Bildumschaltung (Voice-Activated Image Switching) und andere solche Funktionen umfassen, bei denen ein Teil des Systems Zusammenarbeit zwischen den Parteien benötigt. Centralized Conferencing (XCON) [RFC6501] und Cisco/Tandbergs Telepresence Interoperability Protocol (TIP) sind einige Versuche, solche Funktionen zu spezifizieren; viele Anwendungen werden ohne standardisierte Schnittstellen für diese Funktionen erstellt.
Local system support functions (Lokale Systemunterstützungsfunktionen): Funktionen, die nicht einheitlich spezifiziert werden müssen, weil jeder Teilnehmer sie nach eigener Wahl implementieren kann, ohne die Bits auf dem Draht auf eine Weise zu beeinflussen, die andere beachten müssen. Beispiele in dieser Kategorie umfassen Echokompensation (Echo Cancellation) (einige Formen davon), lokale Authentifizierungs- und Autorisierungsmechanismen (Local Authentication and Authorization Mechanisms), OS-Zugriffskontrolle (OS Access Control) und die Fähigkeit zur lokalen Aufzeichnung einer Konversation.
In jeder Funktionsgruppe ist es wichtig, sowohl Innovationsfreiheit als auch globale Kommunikationsfähigkeit zu bewahren. Innovationsfreiheit wird durch Spezifikation in Bezug auf Schnittstellen statt Implementierungen unterstützt; jede Implementierung, die gemäß den Schnittstellen kommunizieren kann, ist eine gültige Implementierung. Globale Kommunikationsfähigkeit wird unterstützt durch: (1) Kernspezifikationen, die nicht durch Probleme mit geistigem Eigentum (IPR) behindert werden, und (2) Spezifikationen von Formaten und Protokollen, die vollständig genug sind, um unabhängige Implementierungen zu ermöglichen.
Man kann die ersten drei Gruppen als bildend für die "Medientransport-Infrastruktur (Media Transport Infrastructure)" betrachten und die letzten drei Gruppen als bildend für den "Mediendienst (Media Service)". In vielen Fällen ist es sinnvoll, gemeinsame Spezifikationen für die Medientransport-Infrastruktur zu verwenden, die in den Browser eingebettet und über Standardschnittstellen zugänglich gemacht werden können, und "tausend Blumen blühen zu lassen" in der "Mediendienst"-Schicht; um jedoch einen interoperablen Dienst zu realisieren, ist es notwendig, mindestens die ersten fünf der sechs Gruppen zu spezifizieren.