WebRTC

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 Real Time Media Flow Protocol (en)), 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 Opera au sein des standards du World Wide Web Consortium (W3C), dont les premières ébauches sont apparues en mai 2011. Afin d'en assurer le développement, une liste dédiée a été créée au sein du W3C dès avril 2011 ainsi qu'un groupe de travail au sein de l'IETF en mai 2011.

Cependant, à ces initiatives s'opposait Microsoft qui a soumis une proposition concurrente CU-RTC-WEB (en) le 8 août 2012.

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 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 ^[Quoi ?] ;
• les retours d'expériences venant d'autres groupes et individus.

Description générale de la norme

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^[Quoi ?] 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.

Établissement d'une connexion entre deux clients utilisant WebRTC

• 1 : A demande au serveur une connexion avec B.
• 2 : Le serveur relaie la demande de A à B.
• 3 : Si B accepte, il envoie une demande de connexion à A.
• 4 : Le serveur relaie la demande à A.
• 5 et 6 : Les PeerConnection bidirectionnelles sont établies.

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 UDP (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 février 2013.

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 Protocol. SDP se base sur la RFC 3264 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 JSEP, 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

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 novembre 2012 .

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 SCTP , lui-même encapsulé dans DTLS. 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 SRTP, 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

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 ;

Afin d'être utilisé, un MediaStream local doit demander l'accès aux ressources multimédia de l'utilisateur via la fonction getUserMedia(). L'application spécifie le type de média (audio ou vidéo) auquel elle souhaite accéder et le navigateur autorise ou refuse l'accès à la ressource demandée. Une fois que le média n'est plus utilisé, l'application peut révoquer son propre accès avec la méthode stop() sur le flux média local.

Les flux médias sont transportés par le biais du protocole RTP, utilisable sur tout protocole de transport implémentant une abstraction de datagram (UDP par exemple). La confidentialité, l'authentification des messages et la protection contre les répétitions sont apportées par l'utilisation sécurisée de RTP, SRTP.

La gestion des clés pour SRTP est assurée par DTLS et donc le flux de données. Il est donc impossible d'avoir un flux média indépendant d'un flux de données là où l'inverse est envisageable.

Il est possible d'associer plusieurs flux médias sur une même connexion SRTP qui utiliseront des ressources médias différentes ou non. Dans ce cas, les sources de chaque flux sont clairement identifiées comme des SSRC.

Multiplexage media / data

L'API WebRTC prévoit le multiplexage de flux données ou média reposant sur une seule connexion de niveau transport. Ce multiplexage fait que les trois protocoles STUN, SRTP et DTLS coexistent au même niveau du modèle et qu'il est nécessaire de démultiplexer les paquets arrivants. Pour cela, le premier octet indiquant la nature du contenu UDP sert à déterminer de quel protocole il s'agit. Une valeur de 0 ou 1 indique un paquet STUN, une valeur entre 20 et 63 indique un paquet DTLS une valeur de 128 à 191 indique un paquet SRTP.

L’intérêt principal de ce multiplexage est qu'en partageant un même paquet de niveau transport, les flux de médias et de données passent plus facilement des NAT ou pare-feux en évitant, par exemple, qu'un paquet portant un flux de média ne soit bloqué alors qu'un paquet de données passe.

Spécifications techniques

À partir de mars 2012, le brouillon de travail de l'IETF WebRTC requiert au minimum les codecs audio suivants :

• PCMA/PCMU (RFC 3551) ;
• Telephone Event (RFC 4733) comme le code DTMF ;
• Opus (RFC 6716) que toutes les applications (côté client) doivent prendre en charge.

Les codecs vidéo ne sont pas encore définis mais doivent répondre à certains critères. Pour être retenu, un codec doit, entre autres, supporter au minimum 10 images par seconde (fps) et jusqu'à 30 ; il doit également supporter une résolution minimale de 320x240 pixels ; en ce qui concerne le codec VP8, il doit être en mesure de supporter l'algorithme bilinéaire du traitement des images et n'appliquer aucun filtre de reconstruction.

Problèmes posés par WebRTC et solutions potentielles

Sécurité des applications

Plusieurs problèmes de sécurité se posent lors de l'utilisation de WebRTC :

• L'application JavaScript (le code utilisant WebRTC) peut être téléchargée depuis n'importe quel site sans consentement de l'utilisateur.
• L'exploitation de ressources média locales (par exemple les caméras et microphones) doit requérir l'approbation de l'utilisateur.
• La confidentialité et l'authentification doivent être garanties dans tout échange pour éviter les attaques telles que l'attaque de l'homme du milieu.
• Les informations privées de l'utilisateur ne doivent pas être dévoilées à des tiers sans le consentement de celui-ci.

Si certains de ces problèmes sont inhérents à toute communication sur Internet, d'autres problèmes ont été résolus par l'implémentation de WebRTC. Ainsi les échanges de médias sont sécurisés par le protocole SRTP.

IP locale privée

WebRTC permet de dévoiler votre adresse IP locale réelle, même en cas d'utilisation d'un VPN.

Gestion de la perte de paquets

Le protocole UDP étant déconnecté et n'utilisant pas de système de vérification de réception des paquets (contrairement au protocole TCP par exemple), la perte de paquets est un problème pouvant se poser lors des transmissions en pair à pair de flux médias. Deux méthodes se présentaient afin de limiter la perte de paquets dus aux problèmes de réseaux :

• NACK qui permet de signaler à l'émetteur une réception échouée ou l'absence de transmission ;
• FEC, un code de contrôle qui permet au récepteur de vérifier que la totalité des paquets est arrivée correctement ;
• RPS (Reference Picture Selection).

Lors de l'envoi d'un flux média, l'émetteur découpe le flux et calcule une somme de contrôle (FEC) qui est envoyée avec ces paquets. À la réception, les FEC sont recalculés pour vérifier l'absence d'erreurs et les données stockées dans une mémoire tampon. Si des paquets manquent, ils sont redemandés.

Dans le cadre de l'API WebRTC, une solution hybride entre NACK et FEC a été implémentée, accompagnée de contrôles temporels afin d'équilibrer la qualité de la vidéo, sa fluidité et le temps de réponse d'une extrémité de la connexion à l'autre.

Ainsi, dans le cadre d'une transmission média, la mémoire tampon servant à la construction des images est de taille variable, dépendant de la longueur des paquets et de la fluidité de rendu optimal calculée par l'application. Du côté de l'émetteur, un optimiseur de flux calcule périodiquement la qualité du trafic sur le réseau et adapte dynamiquement la taille des paquets afin d'éviter au maximum collisions et pertes.

En outre, le calcul de FEC étant la partie la plus longue du processus, l'optimisation de flux permet d'en varier la fréquence, créant ainsi une FEC/NACK adaptative qui répond au mieux aux problèmes rencontrés durant la transmission.

Transiter par des pare-feux ou le NAT

Transiter au travers d'un pare-feu

WebRTC peut être difficile à utiliser en entreprises dans la mesure où celles-ci ont souvent des politiques de sécurité en informatique incompatibles avec les besoins de l'API. En effet, WebRTC est basé sur des flux peer-to-peer entre navigateurs et ces flux sont très sensibles à la latence lorsqu'il s'agit de flux médias. En outre, les serveurs utilisés pour faire transiter les paquets peuvent être éloignés géographiquement des pairs qui communiquent ou avoir une bande passante trop faible pour permettre un transit correct des paquets.

Des approches existent déjà pour franchir un pare-feu :

• Le RTP symétrique est une implémentation de RTP basée sur UDP qui utilise les mêmes ports en entrée et en sortie, afin de simuler un flux bidirectionnel et éviter le blocage arbitraire de paquets;
• Le protocole ICE, qui utilise des paquets de test pour déterminer les règles de filtrage du pare-feu et est aussi utilisé pour traverser un NAT.

Néanmoins les entreprises utilisent de plus en plus des SBC, des pare-feux de niveau application, utilisant un contrôle des flux de signaux et médias (ALG). Ces SBC posent des difficultés pour WebRTC dans la mesure où le flux de signaux n'est pas standardisé par l'API et l'implémentation est laissée libre. De plus, les SBC se placent comme intermédiaires dans la transmission du client vers le serveur, mais le protocole DTLS utilisé par WebRTC ne permet pas l'observation par un tiers de par son chiffrement. Enfin, les SBC utilisent les flux de signaux pour authentifier les flux de données, mais l'API WebRTC ne standardisant pas les flux de signaux, leur utilisation est impossible dans un but d'identification.

L'une des solutions pour venir à bout des difficultés posées par les SBC serait que les entreprises convertissent les flux entrants en sessions SIP, utilisent cette encapsulation pour traverser le SBC puis décapsulent le flux pour le transmettre à l'application. Cependant cette approche reprenant le principe de l'attaque de l'homme du milieu est rendue difficile par la variété des utilisations de WebRTC et par le chiffrement des flux de contrôle et de média de l'API.

Transiter au travers d'un NAT

Afin d'être utilisable si l'un des pairs se situe derrière un NAT, WebRTC utilise le protocole ICE. Deux techniques principales sont utilisées pour traverser ce genre de difficultés.

• La première technique est souvent appelée Hole Punching (en): l'appareil à l'intérieur du NAT envoie un paquet STUN à un serveur en dehors du NAT. Le serveur répond en informant l'émetteur de l'adresse IP et du port apparent avec lequel le paquet a été envoyé, sur lequel les deux communiqueront.

• La seconde technique utilise un relais intermédiaire. Le protocole utilisé pour cela est Traversal Using Relays around NAT (en) : l'entreprise déploie un serveur TURN au sein de la zone démilitarisée (DMZ) avec lequel le pair interne communique et se charge de vérifier qu'il a les droits requis et de surveiller les flux médias qui passent par lui. Le serveur sert ainsi de point de relais aux paquets WebRTC qui transitent entre un pair et l'autre.

Intégration

Navigateurs web

• Opera : une première intégration a été dévoilée en janvier 2012. La version stable comporte cette technologie;
• Google Chrome : une intégration de la technologie est arrivée dans la branche de développement en janvier 2012, et dans la version stable numéro en juin 2012 (toutefois PeerConnection et MediaStream doivent être activés via la page « chrome://flags/ »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)});
• Mozilla Firefox : Mozilla a fait une démonstration en avril 2012. Le 8 janvier 2013, Firefox 18 a fait l'objet d'une implémentation préliminaire. La fondation a fait plusieurs démonstrations de cette fonction au sein de son navigateur. Mozilla a activé, par défaut, WebRTC dans Firefox 22 sorti le 25 juin 2013. La prise en charge de WebRTC dans Firefox mobile sur la plateforme Android est incluse depuis la version 24. Mozilla prévoit de prendre bientôt en charge TURN;
• Internet Explorer: Microsoft a commencé l'intégration d'une API similaire, et Edge propose un support incomplet;
• Ericsson a annoncé en octobre 2012, un premier navigateur compatible WebRTC pour téléphone mobile, appelé Browser et développé pour iOS et Android;
• En avril 2016 Safari (navigateur web) ne supporte pas le WebRTC mais Apple annonce travailler en ce sens.
• En février 2017, Microsoft annonce le support de WebRTC sur les prochaines versions du navigateur Edge, à l'exception cependant des data channels .
• Depuis septembre 2017, le WebRTC est supporté par Safari et Chrome pour IOS 11.

Implémentations et démonstrations

Malgré sa relative nouveauté, la norme webRTC a, dès 2011, été implémentée dans le cadre de plusieurs projets. Ainsi, en mai 2011, les laboratoires Ericsson ont proposé une première implémentation de l'API et en mai 2012, Doubango Telecom a proposé le premier client Sources ouvertes SIP HTML5 utilisant WebRTC. En septembre de la même année, un canvas logiciel à base de JavaScript pour faire tourner le protocole SIP baptisé JsSIP est lancé par Versatica, équipe déjà à l'origine du brouillon de travail sur les WebSockets.

Diverses applications sur l'internet utilisent les outils proposés par WebRTC. C'est le cas par exemple de tawk.com, appear.in, Talky.io, vroom.im ou encore Bistri.com, sites proposant des services de vidéoconférence. Dans la même mouvance, en novembre 2012, ToxBox lance OpenTok qui permet aux développeurs des visioconférences directement au sein de leurs sites Web ou de leurs applications IOS (Apple) et Android. Cette solution s'appuie sur WebRTC quand celui-ci existe au sein du navigateur ou sur Flash. De même, l'échange de données est offert par des sites tels que rtccopy, s'appuyant sur les DataChannel.

Malgré ces premières implémentations, les différents acteurs du web continuaient de travailler sur la technologie. En février 2013, lors du Mobile World Congress Mozilla, Ericsson et AT&T ont fait des démonstrations de WebRTC avec leurs produits. L'ancien service de conversation de Google, Google Talk, devait lui aussi migrer vers WebRTC, le travail était en cours en 2013.

Alternatives

En août 2012, Microsoft a présenté une proposition alternative appelée CU-RTC-WEB (Customizable, Ubiquitous Real Time Communication over the Web) au groupe WebRTC du W3C, une technologie qui aurait débuté en 2010 conjointement avec Skype (que Microsoft a racheté en 2011).

La proposition de Google s'appuie sur le codec VP8 non soumis à des redevances de brevets, tandis que la proposition de Microsoft utilise le standard ISO/CEI H.264, très répandu mais soumis aux redevances de nombreux brevets.

En 2016, Opera et Google Chrome ne supportent que le VP8, firefox et Bowser H.264 et VP8, et Edge partiellement H.264.

Voir aussi

• Extensible Messaging and Presence Protocol
• Jingle (protocole)
• Visiophonie
• Voix sur IP
• WebTorrent, protocole p2p basé sur WebRTC, BitTorrent et le DHT Kademlia

Liens externes

• Site officiel de WebRTC
• W3C Web Real-Time Communications Working Group
• IETF Real-Time Communication in WEB-browsers (rtcweb) Working Group

Bibliographie

• (en) Cullen Jennings, Ted Hardie et Magnus Westerlund, « Real-Time Communications for the Web », Communications Magazine, IEEE, vol. 51,‎ 2013, p. 20-26 (ISSN 0163-6804, DOI 10.1109/MCOM.2013.6495756)

• (en) Salvatore Loreto et Simon Pietro Romano, « Real-time Communications in the Web : Issues, Achievements, and Ongoing Standardization Efforts », Internet Computing, IEEE, vol. 16,‎ 2012, p. 68-73 (ISSN 1089-7801, DOI 10.1109/MIC.2012.115)

• (en) Alan Johnston, John Yoakum et Kundan Singh, « Taking on webRTC in an Enterprise », Communications Magazine, IEEE, vol. 51, n^o 4,‎ avril 2013, p. 48-54 (ISSN 0163-6804, DOI 10.1109/MCOM.2013.6495760)

• (en) Lin Li et Xiping Zhang, « Research On The Integration of RTCWeb Technology with IP Multimedia Subsystem », Image and Signal Processing (CISP), 2012 5th International Congress on,‎ 2012, p. 1158-1161 (ISBN 978-1-4673-0964-6, DOI 10.1109/CISP.2012.6469705)

• (en) Marcin Davies, Joachim Zeiss et Rene Gabner, « Evaluating two approaches for browser-based real-time multimedia communication », Proceedings of the 10th International Conference on Advances in Mobile Computing & Multimedia,‎ 2012, p. 109-117 (ISBN 978-1-4503-1307-0, DOI 10.1145/2428955.2428982)

• (en) Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero et Simon Pietro Romano, « On the Seamless Interaction between WebRTC Browsers and SIP-Based Conferencing Systems », Communications Magazine, IEEE, vol. 51, n^o 4,‎ 2013, p. 42-47 (ISSN 0163-6804, DOI 10.1109/MCOM.2013.6495759)

• (en) Stephan Holmer, Mikhal Shemer et Marco Paniconi, « Handling Packet Loss in WebRTC », International Conference on Image Processing (ICIP 2013),‎ 2013, p. 1860-1864 (lire en ligne)

• (en) Hoanh Huu Tho Le et YoungHan Kim, « Circle-mesh overlay for P2P-based RTCWeb conferencing system », Ubiquitous and Future Networks (ICUFN), 2013 Fifth International Conference on,‎ juillet 2013, p. 489-494 (DOI 10.1109/ICUFN.2013.6614869)

• (en) Kundan Singh et Venkatesh Krishnaswamy, « A case for SIP in JavaScript », Communications Magazine, IEEE, vol. 51, n^o 4,‎ avril 2013, p. 28-33 (DOI 10.1109/MCOM.2013.6495757)

• (en) Christian Vogt, Max Jonas Werner et Thomas Schmidt, « Content-centric User Networks: WebRTC as a Path to Name-based Publishing », 21st IEEE Intern. Conf. on Network Protocols (ICNP 2013), PhD forum, IEEEPress,‎ octobre 2013 (lire en ligne)

• (en) Salvatore Loreto, Vijay Gurbani et Jörg Ott, « Web-Base Communications (guest editorial) », Communications Magazine, IEEE, vol. 51, n^o 4,‎ 2013, p. 18-19 (DOI 10.1109/MCOM.2013.6495755)

• (en) Martin Becke, Erwin Rathgeb, Sebastian Werner, Irene Rüngeler, Michael Tüxen et Randall Stewart, « Data Channel Considerations for RTCWeb », Communications Magazine, IEEE, vol. 51, n^o 4,‎ avril 2013, p. 34-41 (DOI 10.1109/MCOM.2013.6495758)

• (en) Colin Perkins, « Can congestion-controlled interactive multimedia traffic co-exist with TCP? », Proceedings of the 2012 ACM workshop on Capacity sharing,‎ 2012, p. 45-46 (ISBN 978-1-4503-1780-1, DOI 10.1145/2413219.2413232)

• (en) H. Sinnreich et W. Wimmreuter, « Communications on the Web », e & i Elektrotechnik und Informationstechnik, vol. 127, n^o 6,‎ juin 2010 (ISSN 1613-7620, DOI 10.1007/s00502-010-0742-l)

• (en) « WebRTC 1.0: Real-time Communication Between Browsers »

• (en) Arno Baker, Riccardo Pétrocco, Michael Dale, Jan Gerber, Victor Grishchenko, Diego Rabaioli et Johan Pouwelse, « Online video using BitTorrent and HTML5 applied to Wikipedia », Peer-to-Peer Computing (P2P), 2010 IEEE Tenth International Conference on,‎ 2010, p. 1-2 (DOI 10.1109/P2P.2010.5569984)

• (en) Pedro Rodriguez, Javier Cervino, Irena Trajkoska et Joaquin Salvachua, « Advanced videoconferencing services based on WebRTC », Proceedings of the IADIS International Conferences Web Based Communities and Social media,‎ 2012 (ISBN 978-972-8939-72-4)

• (en) Jukka Nurminen, Antony Meyn, Eetu Jalonen, Yrjo Raivio et Raul Garvia Marrero, « P2P media streaming with HTML5 and WebRTC », IEEE International Conference on Computer Communications,‎ 2013

• (en) Tjrek de Greef, Charlie Gullström, Leif Handberg, Peter Parnes et Harold Nefs, « Shared mediated workspaces », Presence Live 2012,‎ octobre 2012 (lire en ligne)

• (en) « Real Time Media Flow Protocol »

• (en) « URCP: Universal Rate Control Protocol »

• (en) « JavaScript Session Establishment Protocol », 2012