1. Introduction
L'Internet a été, dès le début de son existence, considéré comme un vecteur possible pour le déploiement d'applications interactives en temps réel -- les plus facilement imaginables étant les conversations audio (alias "téléphonie Internet") et la vidéoconférence.
Les premières tentatives de construction de telles applications dépendaient de réseaux spéciaux, de matériel spécial et de logiciels personnalisés, souvent à des prix très élevés ou de faible qualité, imposant de grandes exigences à l'infrastructure.
Au fur et à mesure que la bande passante disponible a augmenté et que les processeurs et autres matériels sont devenus de plus en plus rapides, les barrières à la participation ont diminué, et il est devenu possible de fournir une expérience satisfaisante sur du matériel informatique couramment disponible.
Néanmoins, il existe encore un certain nombre d'obstacles à la capacité de communiquer universellement -- l'un d'entre eux est qu'il n'existe pas encore d'ensemble unique de protocoles de communication sur lequel tous s'accordent pour qu'il soit mis à disposition pour la communication ; un autre est le manque pur et simple de systèmes d'identification universels (tels que ceux fournis par les numéros de téléphone ou les adresses électroniques dans d'autres systèmes de communication).
Le développement de "La Solution Universelle" s'est toutefois avéré difficile.
Les dernières années ont également vu l'émergence d'une nouvelle plateforme pour le déploiement de services : l'application intégrée au navigateur (Browser-Embedded Application), ou "application web (Web Application)". Il s'avère que tant que la plateforme du navigateur dispose des interfaces nécessaires, il est possible d'y fournir presque n'importe quel type de service.
Traditionnellement, ces interfaces ont été fournies par des plugins (Plugins), qui devaient être téléchargés et installés séparément du navigateur ; dans le développement de HTML5 [HTML5], les développeurs d'applications voient beaucoup de promesses dans la possibilité de rendre ces interfaces disponibles de manière standardisée dans le navigateur.
Ce mémo décrit un ensemble de blocs de construction (Building Blocks) qui (1) peuvent être rendus accessibles et contrôlables via une API JavaScript dans un navigateur et (2) forment ensemble un ensemble suffisant de fonctions pour permettre l'utilisation d'audio et de vidéo interactifs dans des applications qui communiquent directement entre navigateurs via Internet. La suite de protocoles résultante vise à permettre toutes les applications décrites comme scénarios requis dans le document "cas d'utilisation" WebRTC [RFC7478].
D'autres efforts -- par exemple, les groupes de travail W3C Web Real-Time Communications, Web Applications Security et Devices and Sensors -- se concentrent sur la mise à disposition d'API et d'interfaces standardisées, dans le cadre ou en parallèle de l'effort HTML5, pour ces fonctions. Ce mémo se concentre sur la spécification des protocoles et sous-protocoles nécessaires pour spécifier les interactions sur le réseau.
Les opérateurs doivent noter que le déploiement de WebRTC entraînera un changement dans la nature de la signalisation pour les médias en temps réel sur le réseau et peut entraîner un changement dans les types de dispositifs utilisés pour créer et consommer de tels médias. En ce qui concerne la signalisation, la configuration de session WebRTC se fera généralement via des technologies web sécurisées par TLS utilisant des protocoles spécifiques à l'application. Les techniques opérationnelles impliquant l'insertion d'éléments de réseau pour interpréter le protocole de description de session (Session Description Protocol, SDP) -- soit par (1) l'endpoint demandant au réseau un serveur SIP [RFC3361], soit par (2) l'insertion transparente de passerelles de couche application (Application Layer Gateways, ALGs) SIP -- ne fonctionneront pas avec une telle signalisation. Dans le cas de réseaux utilisant des endpoints coopératifs, les approches définies dans [RFC8155] peuvent servir de remplacement approprié pour [RFC3361]. L'augmentation des communications basées sur navigateur peut également conduire à un éloignement du matériel de communications en temps réel dédié, tel que les téléphones de bureau SIP. Cela diminuera l'efficacité des techniques opérationnelles qui placent des dispositifs en temps réel dédiés sur leur propre segment de réseau, plage d'adresses ou VLAN à des fins telles que l'application du filtrage du trafic et de la QoS. L'application des marquages décrits dans [RFC8837] peut être un remplacement approprié pour de telles techniques.
Bien que ce document s'appuie formellement sur [RFC8445], au moment de sa publication, la majorité des implémentations WebRTC prennent en charge la version d'Interactive Connectivity Establishment (ICE) décrite dans [RFC5245] et utilisent une version pré-standard du mécanisme Trickle ICE décrit dans [RFC8838]. L'attribut "ice2" défini dans [RFC8445] peut être utilisé pour détecter la version utilisée par un endpoint distant et pour fournir une transition en douceur de l'ancienne spécification vers la nouvelle.
Ce mémo utilise le terme "WebRTC" (notez la casse utilisée) pour faire référence à l'effort global composé à la fois des efforts de l'IETF et du W3C.