WebRTC (Web Real-Time Communication, littéralement « communication en temps réel pour le Web ») est une interface de programmation (API) JavaScript développée en mode Free & Open-Source Software au sein du W3C et de l'IETF. C'est aussi un canevas logiciel avec des implémentations précoces dans différents navigateurs web pour permettre une communication en temps réel. Le but du WebRTC est de lier des applications comme la voix sur IP, le partage de fichiers en pair à pair en s'affranchissant des modules d'extensions propriétaires jusqu'alors nécessaires.
L'API repose sur une architecture triangulaire puis pair à pair dans laquelle un serveur central est utilisé pour mettre en relation deux pairs désirant échanger des flux de médias ou de données qui échangent ensuite sans autre relais. Cette architecture et la pile de protocoles utilisée posent des questions de sécurité et d'utilisation en relation avec d'autres technologies (comme les NAT ou les pare-feux) qui sont pour la plupart en cours de résolution par l'IETF et le W3C.
La technologie WebRTC est assez récente, les groupes de travail W3C/IETF ont débuté en 2011. Les navigateurs ont commencé à l'intégrer à partir de 2013-2014..... Son intégration au sein des différents navigateurs est encore inégale en 2019. Pour certains navigateurs, des extensions propriétaires existent comme celle de Temasys pour Internet Explorer et Safari..
Historique
Les échanges directs entre navigateurs ne sont pas une nouveauté introduite par le W3C et l'IETF mais les recherches et implémentations précédentes n'étaient pas standard (à cause de l'utilisation de plugins propriétaires tels qu'Adobe Flash ou Microsoft ActiveX) et souvent mal documentées. Ces protocoles et plugins furent à la source de difficultés d'interopérabilité et de mise à jour pour les sites utilisant ces systèmes. Bien que ces implémentations permettaient une utilisation allant jusqu'à la visioconférence (telle que celle proposée par Adobe avec le Littéralement : Protocole de flux média en temps réel), elles reposaient sur des plugins propriétaires et étaient donc dépourvues de standards.
Les applications internet riches étant perçues comme une évolution des pages web statiques, elles ont rapidement offert la possibilité d’animer les textes et les dessins présentés par le navigateur mais aussi de réaliser des fonctionnalités de glisser-déposer ou encore de flux (audio et vidéo) bidirectionnel. Cependant, si les applications riches sont, en partie au moins, exécutées par le navigateur, elles n'impliquent des communications qu'entre ce dernier et un (ou parfois plusieurs) serveur(s) web.
WebRTC est une technologie permettant les communications directes (i.e. sans passer par un serveur web) et en temps réel entre plusieurs navigateurs. soutenue par Google., Mozilla et au sein des standards du World Wide Web Consortium (W3C), dont les premières ébauches sont apparues en . Afin d'en assurer le développement, une liste dédiée a été créée au sein du W3C dès .. ainsi qu'un groupe de travail au sein de l'IETF en http://tools.ietf.org/wg/rtcweb/charters?item=charter-rtcweb-2011-05-03.txt.
Cependant, à ces initiatives s'opposait Microsoft qui a soumis une proposition concurrente le ..
Le standard qui définit WebRTC n'était pas encore complet en 2012, il pouvait encore subir de fortes modifications. Toute expérimentation était ainsi encouragée afin d'obtenir des retours d'expérience. L'API est basée sur des travaux préliminaires du WHATWG (qui se basaient sur l'API ConnectionPeer et sur les travaux issus des laboratoires d'Ericsson).
Le groupe de travail espérait en 2012 des évolutions http://lists.w3.org/Archives/Public/public-media-capture/2012Dec/att-0159/RecordingProposal.html suffisantes des spécifications à travers : les échanges d'entrées/sorties au sein du groupe RTCWEB d'IETF pour définir les protocoles pouvant permettre les communications en temps-réel au sein des différents navigateurs web ; le respect de la vie privée : des intrusions pouvant se faire en accédant à des parties locales de l'ordinateur (caméra, micro...) ou en espionnant depuis l'extérieur les données échangées ; les discussions techniques sur les canaux d'échange de données (quels qu'ils soient) entre particuliers ; les retours d'expériences venant d'autres groupes et individus.
Description générale de la norme
thumb|upright=1.5|Architecture d'une application WebRTC
L'architecture développée en mode Free & Open-Source Software de l'API WebRTC repose sur une construction triangulaire impliquant un serveur et deux pairs. Les deux navigateurs téléchargent depuis un serveur une application JavaScript vers leur contexte local. Le serveur est utilisé comme point de rendez-vous afin de coordonner les échanges entre navigateurs jusqu'à ce que la connexion directe entre navigateurs soit établie. L'application téléchargée utilise l'API WebRTC pour communiquer avec le contexte local. Le but est d'avoir une application cliente en JavaScript et HTML5 interagissant avec le navigateur au travers de l'API WebRTC.
Les flux d'échange entre navigateurs peuvent rencontrer divers serveurs qui se chargeront de modifier, traduire ou gérer le signal au besoin, permettant par exemple la traversée de pare-feux, proxys ou NAT.
Afin d'établir une connexion utilisant le standard WebRTC, les navigateurs A et B doivent être connectés simultanément à la page du service et télécharger la page HTML ainsi que le code JavaScript permettant de maintenir la connexion ouverte par HTTPS ou socket. Lorsque le navigateur A souhaite établir la connexion avec B, l'API instancie un objet PeerConnection qui, une fois créé, permet d'établir des flux de médias ou de données. Il est aussi nécessaire, pour une vidéoconférence par exemple, que les utilisateurs A et B acceptent le partage de leur caméra et/ou de leur microphone.
thumb|upright=1.5|Établissement d'une connexion entre deux clients utilisant WebRTC
Une fois cet objet PeerConnection créé par A, le navigateur envoie au serveur un paquet contenant les informations sur les médias partagés ainsi qu'une empreinte liant la connexion à A. Le serveur va décoder ce paquet et identifier qu'il s'agit d'une communication à destination de B et enverra donc un signal à B. B est notifié du souhait de A d'établir une connexion et accepte ou non sa requête. Si elle est acceptée, le même processus a lieu entre B et A cette fois afin d'établir la connexion bidirectionnelle. Une fois celle-ci établie, les flux de médias ou de données peuvent être ajoutés à la connexion librement.
Dans le cadre par exemple d'un streaming vidéo en peer-to-peer entre navigateurs, l'utilisateur télécharge depuis un serveur les métadonnées de la vidéo qu'il souhaite regarder ainsi qu'une liste de pairs disponibles et ayant tout ou partie de la vidéo. L'établissement d'une connexion avec les pairs permet, par le flux de données, le téléchargement des morceaux de la vidéo qui sont réassemblés après vérification de leur intégrité puis lancement de la vidéo dans un lecteur HTML5.
L'API webRTC s'appuie sur des standards existants comme STUN., ICE, TURN, DTLS ou encore SRTP, technologies en parties issues du projet libjingle..
PeerConnection
L'API RTCPeerconnection. représente le lien établi avec un navigateur distant, reposant sur le protocole UDPUser Datagram Protocol (habituellement une autre instance de la même application JavaScript s’exécutant sur le client distant). Afin d'établir cette connexion en pair à pair, il est nécessaire de s'appuyer sur un canal de communication établi par un serveur web et utilisant par exemple un objet XMLHttpRequest ou une WebSocket. Mozilla et Google en ont réalisé une démonstration technique en ...
Pour obtenir une connexion, l'un des pairs doit obtenir les informations locales (telles que les protocoles supportés pour l'audio ou la vidéo). Cette étape est permise par l'API via Session Description ProtocolSession Description Protocol. SDP se base sur la de l'IETF définissant une approche requête / réponse. Lors de l'établissement d'une session, un pair crée une requête qui décrit ce qu'il désire faire et l'autre répond en spécifiant les options qui ont été sélectionnées. Néanmoins, l'utilisation de SDP est en cours de remplacement au sein de la norme WebRTC par le protocole JSEPJavaScript Session Establishment Protocol, http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03, notamment à cause des problèmes posés par le format de transmission de SDP, le blob d'information.
Dans le cadre de WebRTC, l'échange de ces requêtes et réponses par SDP se fait par un mécanisme laissé au choix de l'implémentation (typiquement un serveur Web utilisant une socket).
Ce processus utilisant SDP permet la négociation à la fois pour RTP (transport de médias) et pour SCTP (permettant le transport de données).
Afin d'assurer la continuité de la connexion en cas de conversion d'adresse par NAT et éviter le blocage par les pare-feux (notamment en entreprise), l'objet PeerConnection utilise les protocoles UDP, STUN et ICE.
Une fois cette connexion en pair à pair établie, chaque partie peut établir des MediaStreams ou DataStreams l'utilisant.
Data channels
thumb|upright=0.6|Structure de la pile de protocoles utilisée par WebRTC dans un échange de données.
L'API DATA channels offre un moyen d'échange de données génériques bidirectionnel et pair à pair. Cette composante de webRTC permet l'échange de données telles que des images ou du texte. Une première démonstration par Mozilla a eu lieu en ..
Ces canaux de données sont créés entre pairs en utilisant l'objet PeerConnection. Ces données autres que les flux médias sont échangées via le protocole SCTPStream Control Transmission Protocol, lui-même encapsulé dans DTLSDatagram Transport Layer Security. Cette solution permet au flux de données d'être intégré dans le même paquet que les flux de médias et donc de partager le même numéro de port pour les échanges.
SCTP supporte nativement plusieurs flux de données de façon bidirectionnelle (jusqu'à 65536 dans chaque direction) au sein d'une association SCTP et gère les priorités. De cette façon, il est possible de favoriser les messages de haute priorité face aux gros objets à priorité basse. Chaque flux représente une connexion logique unidirectionnelle.
Afin d'assurer la confidentialité et l'authenticité des paquets SCTP échangés, chaque flux repose sur le protocole DTLS.
Au sein d'un canal de données, les applications peuvent transmettre des messages de façon ordonnée ou désordonnée. L'ordre de remise est préservé uniquement dans le cas d'une transmission de paquets ordonnés envoyés sur le même lien de données.
Un flux de données est créé lorsque l'un des pairs appelle une méthode CreateDataChannel() pour la première fois après avoir créé un objet PeerConnection. Chaque appel suivant à CreateDataChannel() créera un nouveau flux de données au sein de la connexion SCTP existante.
Le protocole DTLS n'a pas pour seul rôle d'encapsuler les paquets SCTP. Dans le cadre d'un multiplexage avec des flux médias, le protocole DTLS encapsule la gestion des clés et la négociation des paramètres pour le protocole SRTPSecured Real-Time Transport Protocol, utilisé pour la gestion des flux médias. Il y a donc dépendance du flux média vis-à-vis du flux de données.
Flux Media
thumb|upright=1.1|Structure de la pile de protocoles utilisée par WebRTC dans un échange de médias.
Un MediaStream. est une représentation d'un flux de données spécifique audio ou vidéo. Il permet la prise en charge des actions sur le flux média telles que l'affichage, l'enregistrement et l'envoi à un pair distant. Un MediaStream peut être local ou distant. L'API MediaStream gère les flux audio et vidéo et indique à l'application qu'elle doit donner accès à la caméra, aux haut-parleurs et au microphone ;