3. Architecture and Functionality Groups (Architecture et groupes de fonctionnalités)
Le modèle de support temps réel pour les applications basées sur navigateur ne suppose pas que le navigateur contiendra toutes les fonctions requises par des applications telles que la téléphonie ou la vidéoconférence. La vision est que le navigateur aura les fonctions nécessaires pour l'application web, travaillant en coopération avec ses serveurs backend pour mettre en œuvre ces fonctions.
Cela signifie qu'il est nécessaire de spécifier deux interfaces importantes : les protocoles que le navigateur utilise pour communiquer entre eux sans aucun serveur intermédiaire, et l'API fournie aux applications JavaScript pour tirer parti des capacités du navigateur.
+------------------------+ 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
Figure 1 : Modèle de navigateur
Notez que HTTPS et WebSockets sont également mis à disposition des applications JavaScript via des API de navigateur.
Comme avec toutes les spécifications de protocole et d'API, les protocoles ne sont pas limités à être utilisés uniquement pour communiquer avec un autre navigateur ; étant donné qu'ils sont entièrement spécifiés, tout endpoint implémentant fidèlement les protocoles devrait être capable d'interopérer avec des applications s'exécutant dans le navigateur.
La Figure 2 décrit un modèle de déploiement courant. ("JS" signifie 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 | |
| | | |
+-----------+ +-----------+
Figure 2 : Trapézoïde RTC du navigateur
Dans ce diagramme, les parties essentielles à noter sont que le chemin média (le "chemin inférieur") va directement entre les navigateurs, donc il doit être conforme aux spécifications de la suite de protocoles WebRTC ; le chemin de signalisation (le "chemin supérieur") passe par des serveurs, qui peuvent modifier, traduire ou manipuler les signaux selon les besoins.
Si les deux serveurs web sont exploités par des entités différentes, un accord sur le mécanisme de signalisation inter-serveurs est nécessaire par des moyens de standardisation ou d'autres moyens de protocole. Les protocoles existants (par exemple, SIP [RFC3261] ou Extensible Messaging and Presence Protocol (XMPP) [RFC6120]) peuvent être utilisés entre les serveurs, et des protocoles basés sur des normes ou propriétaires peuvent être utilisés entre le navigateur et le serveur web.
Par exemple, si les serveurs des deux opérateurs implémentent SIP, alors SIP peut être utilisé pour la communication entre les serveurs, tandis qu'un mécanisme de signalisation standardisé (par exemple, SIP over WebSockets) ou propriétaire est utilisé entre l'application s'exécutant dans le navigateur et le serveur web. De même, si les serveurs des deux opérateurs implémentent XMPP, alors XMPP peut être utilisé entre les serveurs XMPP, tandis qu'un mécanisme de signalisation standardisé (par exemple, XMPP over WebSockets ou Bidirectional-streams Over Synchronous HTTP (BOSH) [XEP-0124]) ou propriétaire est utilisé entre l'application s'exécutant dans le navigateur et le serveur web.
Le choix des protocoles pour la signalisation client-serveur et inter-serveurs, et la définition des traductions entre eux, sont hors de la portée de la suite de protocoles WebRTC décrite dans ce document.
Les groupes de fonctionnalités nécessaires dans le navigateur peuvent être, plus ou moins, spécifiés de bas en haut comme suit :
Data transport (Transport de données) : Par exemple, TCP et UDP, ainsi que les moyens d'établir des connexions de manière sécurisée entre les entités, et les fonctionnalités pour décider quand envoyer des données : gestion de la congestion (Congestion Management), estimation de la bande passante (Bandwidth Estimation), etc.
Data framing (Encadrement des données) : RTP, Stream Control Transmission Protocol (SCTP), DTLS, et d'autres formats de données utilisés comme conteneurs, et leurs fonctionnalités pour la confidentialité et l'intégrité des données.
Data formats (Formats de données) : Spécifications de codec (Codec Specifications), spécifications de format (Format Specifications) et spécifications de fonctionnalités pour les données transmises entre les systèmes. Les codecs audio et vidéo, ainsi que les formats pour le partage de données et de documents, relèvent tous de cette catégorie. Pour utiliser un format de données, un moyen de les décrire est nécessaire (par exemple, description de session (Session Description)).
Connection management (Gestion de connexion) : Par exemple, établissement de connexions, accord sur les formats de données, modification des formats de données pendant un appel. SDP, SIP et Jingle/XMPP relèvent de cette catégorie.
Presentation and control (Présentation et contrôle) : Ce qui doit se produire pour s'assurer que les interactions se déroulent de manière non surprenante. Cela peut inclure le contrôle de la parole (Floor Control), la disposition de l'écran (Screen Layout), la commutation d'image activée par la voix (Voice-Activated Image Switching) et d'autres fonctionnalités de ce type, où une partie du système doit coopérer entre les parties. Centralized Conferencing (XCON) [RFC6501] et le Telepresence Interoperability Protocol (TIP) de Cisco/Tandberg sont quelques tentatives de spécifier de telles fonctionnalités ; de nombreuses applications sont construites sans interfaces standardisées pour ces fonctions.
Local system support functions (Fonctions de support système local) : Fonctions qui n'ont pas besoin d'être spécifiées de manière uniforme parce que chaque participant peut les implémenter selon son propre choix sans affecter les bits sur le fil d'une manière dont d'autres doivent se préoccuper. Les exemples de cette catégorie incluent l'annulation d'écho (Echo Cancellation) (certaines formes de celle-ci), les mécanismes d'authentification et d'autorisation locaux (Local Authentication and Authorization Mechanisms), le contrôle d'accès au système d'exploitation (OS Access Control) et la capacité d'enregistrement local d'une conversation.
Dans chaque groupe de fonctionnalités, il est important de préserver à la fois la liberté d'innovation et la capacité de communication globale. La liberté d'innovation est aidée en spécifiant en termes d'interfaces plutôt qu'en termes d'implémentations ; toute implémentation capable de communiquer selon les interfaces est une implémentation valide. La capacité de communication globale est aidée en ayant : (1) les spécifications de base non entravées par des problèmes de propriété intellectuelle (IPR), et (2) les spécifications de formats et de protocoles suffisamment complètes pour permettre des implémentations indépendantes.
On peut considérer les trois premiers groupes comme formant "l'infrastructure de transport média (Media Transport Infrastructure)" et les trois derniers groupes comme formant le "service média (Media Service)". Dans de nombreux cas, il est logique d'utiliser des spécifications communes pour l'infrastructure de transport média qui peuvent être intégrées dans le navigateur et accessibles à l'aide d'interfaces standard, et de "laisser mille fleurs s'épanouir" dans la couche "service média" ; cependant, pour réaliser un service interopérable, il est nécessaire de spécifier au moins les cinq premiers des six groupes.