WebRTC

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

WebRTC (Web Real-Time Communication, littéralement communication web en temps réel) est une interface de programmation (API) JavaScript actuellement au stade de brouillon (Draft) développée 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 plugins 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 étant récente, son intégration au sein des différents navigateurs Internet est encore inégale ; bien que cela soit partiellement résolu par l'utilisation d'extension propriétaire comme celle de Temasys[1].

Historique[modifier | modifier le code]

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 standards (à cause de l'utilisation de plugins propriétaires tels qu'Adobe Flash ou Microsoft ActiveX) et souvent mal documentées[2]. 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 vidéoconférence (telle que celle proposée par Adobe avec le Real Time Media Flow Protocol (en)[3]) , elles reposaient sur des plugins propriétaires et étaient donc dépourvues de standards[4].

Les applications internet riches étant perçues comme une évolution des pages web statiques, ces applications 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 du streaming (audio et vidéo) bidirectionnel[5]. 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[6] soutenue par Google[7], Mozilla et Opera[8] 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[9],[10] ainsi qu'un groupe de travail au sein de l'IETF en mai 2011[11].

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

Le standard qui établira le WebRTC n'étant pas encore complet, il peut encore subir de fortes modifications. Toute expérimentation est ainsi encouragée afin d'obtenir des retours d'expérience. L'API est basée sur des travaux préliminaires du WHATWG[13] (qui se basaient sur l'API ConnectionPeer et sur les travaux issues des laboratoires d'Ericsson[14]).

Le groupe de travail espère une évolution[15] suffisante des spécifications à travers :

  • les échanges d'entrées/sorties au sein du groupe RTCWEB d'IETF[16] 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'échanges de données (quels qu'ils soient) entre particuliers[17] [Quoi ?] ;
  • les retours d'expériences venant d'autres groupes et individus.

Description générale de la norme[modifier | modifier le code]

Architecture d'une application WebRTC

L'architecture de l'API WebRTC repose sur une construction triangulaire impliquant un serveur et deux pairs[4]. 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[4].

Les flux d'échanges 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 Firewalls, proxys ou NAT[18].

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 webcam et/ou de leur microphone.

Etablissement 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.
  • 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[19].

L'API webRTC s'appuie sur des standards existants comme STUN[20], ICE, TURN, DTLS ou encore SRTP[21], technologies en parties issues du projet libjingle[22].

PeerConnection[modifier | modifier le code]

L'API RTCPeerconnection[23] représente le lien établi avec un navigateur distant, reposant sur le protocole UDP[24] (habituellement une autre instance de la même application JavaScript s’exécutant sur le client distant). Afin d'établir cette connexion 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[25]. Mozilla et Google en ont réalisé une démonstration technique en février 2013[26],[27].

Pour obtenir une connexion, l'un des pair 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 (en)[28]. 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[29]. Néanmoins, l'utilisation de SDP est en cours de remplacement au sein de la norme WebRTC par le protocole JSEP [30], notamment à cause des problèmes posés par le format de transmission de SDP, le blob d'information[31].

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)[32],[33].

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 translation d'adresse par NAT et éviter le blocage par les parefeux (notamment en entreprise), l'objet PeerConnection utilise les protocoles UDP, STUN et ICE[32].

Une fois cette connexion pair à pair établie, chaque partie peut établir des MediaStreams ou DataStreams l'utilisant.

Data channels[modifier | modifier le code]

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[25]. 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 [34].

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 [35], lui-même encapsulé dans DTLS[36]. 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 bidirectionnel (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 à la priorité basse. Chaque flux représente une connexion logique unidirectionnelle[29].

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 foi 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[25].

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égotiation des paramètres pour le protocole SRTP[37], 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[38].

Media streams[modifier | modifier le code]

Structure de la pile de protocoles utilisée par WebRTC dans un échange de médias.

Un MediaStream[39] 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 webcam, 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[25].

Les flux médias sont transportés par le biais du protocole RTP[40], utilisable sur tout protocole de transport implémentant une abstraction de datagram (UDP par exemple). La confidentialité, authentification des messages et la protection contre les répétitions est apportée 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[29].

Multiplexage media / data[modifier | modifier le code]

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 arrivant. Pour cela, le premier octet indiquant la nature du contenu UDP sert à déterminer de quel protocole il s'agit[41]. 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[41].

Spécifications techniques[modifier | modifier le code]

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

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 jusque 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[43].

Problèmes posés par WebRTC et solutions potentielles[modifier | modifier le code]

Sécurité des applications[modifier | modifier le code]

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

  • JavaScript peut être téléchargé depuis n'importe quel site sans consentement de l'utilisateur.
  • Les utilisateurs doivent pouvoir être capables de donner leur agrément à l'utilisation de ressources médias locales comme les caméras et microphones.
  • La confidentialité et l'authentification doivent être garantis 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 l'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[29].

Gestion de la perte de paquets[modifier | modifier le code]

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 de 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éseau:

  • NACK (en)[44] qui permet de signaler à l'émetteur une réception échouée ou l'absence de transmission ;
  • FEC[45], 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. A 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[46].

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 optimale calculée par l'application. Du coté de l'émetteur, un optimisateur 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[47].

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 firewalls ou le NAT[modifier | modifier le code]

Transiter au travers d'un firewall[modifier | modifier le code]

WebRTC peut être difficile à utiliser en entreprise 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 lors qu'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 parefeu :

  • 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 tests pour déterminer les règles de filtrage du parefeu et est aussi utilisé pour traverser un NAT.

Néanmoins les entreprises utilisent de plus en plus des SBC, des parefeux 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 laissé libre de choix à l'implémentation. 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[48].

L'une des solutions pour venir à bout des difficultés posées par les SBC serait que les entreprises convertissent les flux entrant 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[48].

Transiter au travers d'un NAT[modifier | modifier le code]

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'envoyeur 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 que ce pair 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[49].

Intégration[modifier | modifier le code]

Navigateurs web[modifier | modifier le code]

  • Opera : une première intégration a été dévoilée en janvier 2012. La version stable comporte cette technologie[50];
  • 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[51],[52] (toutefois PeerConnection et MediaStream doivent être activés via la page chrome://flags);
  • Mozilla Firefox : Mozilla a fait une démonstration en avril 2012[53]. Le 8 janvier 2013, Firefox 18 a fait l'objet d'une implémentation préliminaire[54]. La fondation a fait plusieurs démonstrations de cette fonction au sein de son navigateur[55],[56],[57]. Mozilla a activé, par défaut, WebRTC dans Firefox 22 sorti le 25 juin 2013[58],[59]. La prise en charge de WebRTC dans Firefox mobile sur la plateforme Android est incluse depuis la version 24[60]. Mozilla prévoit de prendre bientôt en charge TURN[61];
  • Internet Explorer: Microsoft a commencé le travail sur l'intégration d'une API similaire[62];
  • Ericsson a annoncé, en octobre 2012, un premier navigateur compatible WebRTC pour téléphone mobile, appelé Bowser et développé pour iOS et Android[63],[64];

Implémentations et démonstrations[modifier | modifier le code]

Malgré sa relative nouveauté, la norme webRTC a déjà été implémentée dans le cadre de plusieurs projets dès 2011. Ainsi, en mai 2011, les laboratoires Ericson ont proposé une première implémentation de l'API[65],[66] et en mai 2012, Doubango Telecom a proposé le premier client Open Source SIP HTML5 utilisant WebRTC[67],[68]. 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 Websocket[69].

Diverses applications sur internet utilisent les outils proposés par WebRTC. C'est le cas par exemple de tawk.com, appear.in[70], Talky.io[71] ou encore Bistri.com[72], 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 leur sites web ou de leur applications IOS (Apple) et Android. Cette solution s'appuie sur WebRTC[73] 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[74].

Malgré ces implémentations, les différents acteurs du web continuent 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 leur produits[75]. Le service de conversation de Google, Google Talk, pourrait lui aussi migrer vers WebRTC, le travail étant en cours[76].

Alternatives[modifier | modifier le code]

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[77],[78], une technologie qui aurait débuté en 2010 conjointement avec Skype (que Microsoft a racheté en 2011)[79].

La proposition de Google s'appuie sur le codec VP8[80],[81],[82],[83] non soumis à des redevances de brevets, tandis que la proposition de Micrososft utilise le standard ISO/IEC H.264[84],[85],[86],[87], très répandu mais soumis à la redevance de nombreux brevets.

Voir aussi[modifier | modifier le code]

Liens externes[modifier | modifier le code]

Bibliographie[modifier | modifier le code]

  • (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 (ISSN 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 (ISSN 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, no 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, no 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, no 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, no 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 (ISSN 978-1-4503-1780-1, DOI 10.1145/2413219.2413232)
  • (en) Arno Baker, Riccardo Pétrocco, Michael Dale, Jan Gerber, 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)

Références[modifier | modifier le code]

  1. Temasys
  2. S. Loreto 2012, p. 68
  3. Littéralement : Protocole de flux média en temps réel
  4. a, b et c C. Jennings 2013, p. 20
  5. P. Rodriguez 2012, p. 1
  6. (en) « Google release of WebRTC source code from Harald Alvestrand on 2011-05-31 (public-webrtc@w3.org from May 2011) », Lists.w3.org (consulté le 2012-09-12)
  7. http://www.journaldugeek.com/2011/06/15/google-webrtc-chat-video-audio-navigateur/
  8. (en) « Introducing WebRTC - an open real-time communications project - WebRTC », Sites.google.com (consulté le 2012-09-12)
  9. (en) « WebRTC 1.0: Real-time Communication Between Browsers », W3.org (consulté le 2012-09-12)
  10. (en) « Welcome to the list! from Harald Alvestrand on 2011-04-27 (public-webrtc@w3.org from April 2011) », Lists.w3.org,‎ 2011-04-27 (consulté le 2012-09-12)
  11. http://tools.ietf.org/wg/rtcweb/charters?item=charter-rtcweb-2011-05-03.txt
  12. (en) « Customizable, Ubiquitous Real Time Communication over the Web (CU-RTC-Web) », Html5labs.com (consulté le 2012-09-12)
  13. (en) href, « 1 Introduction — HTML Standard », Whatwg.org (consulté le 2012-09-12)
  14. (en) « Beyond HTML5: Peer-to-Peer Conversational Video | Ericsson Labs », Labs.ericsson.com (consulté le 2012-09-12)
  15. (en) http://lists.w3.org/Archives/Public/public-media-capture/2012Dec/att-0159/RecordingProposal.html
  16. (en) « Rtcweb Status Pages », Tools.ietf.org (consulté le 2012-09-12)
  17. (en) « draft-jesup-rtcweb-data-protocol-00 - WebRTC Data Channel Protocol », Tools.ietf.org (consulté le 2012-09-12)
  18. S. Loreto 2012, p. 69
  19. J. Nurminen 2013, p. 2
  20. http://www.webrtc.org/reference/architecture#TOC-Transport-Session
  21. http://www.webrtc.org/reference/architecture
  22. http://www.webrtc.org/faq#TOC-Network
  23. http://dev.w3.org/2011/webrtc/editor/webrtc.html#peer-to-peer-connections
  24. User Datagram Protocol
  25. a, b, c et d S. Loreto 2012, p. 71
  26. https://hacks.mozilla.org/2013/02/hello-chrome-its-firefox-calling/
  27. http://blog.chromium.org/2013/02/hello-firefox-this-is-chrome-calling.html
  28. Session Description Protocol
  29. a, b, c et d C. Jennings 2013, p. 21
  30. JavaScript Session Establishment Protocol, http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03
  31. 2012
  32. a et b S. Loreto 2012, p. 70
  33. P. Rodriguez 2012, p. 2
  34. https://blog.mozilla.org/futurereleases/2012/11/30/webrtc-makes-social-api-even-more-social/
  35. Stream Control Transmission Protocol
  36. Datagram Transport Layer Security
  37. Secured Real-Time Transport Protocol
  38. C. Jennings 2013, p. 23
  39. http://dev.w3.org/2011/webrtc/editor/getusermedia.html#widl-NavigatorUserMedia-getUserMedia-void-MediaStreamConstraints-constraints-NavigatorUserMediaSuccessCallback-successCallback-NavigatorUserMediaErrorCallback-errorCallback
  40. Real-Time Transport Protocol
  41. a et b C. Jennings 2013, p. 22
  42. (en) « draft-cbran-rtcweb-codec-02 - WebRTC Codec and Media Processing Requirements », Tools.ietf.org,‎ 2012-03-12 (consulté le 2012-09-12)
  43. (en) « If VP8 is supported, then it MUST support the bilinear and none reconstruction filters », Tools.ietf.org,‎ 2012-03-12 (consulté le 2012-11-12)
  44. Negative-Acknowledgment
  45. Forward Error Correction
  46. S. Holmer 2013, p. 1860
  47. S. Holmer 2013, p. 1861
  48. a et b A. Johnston 2013, p. 49
  49. A. Johnston 2013, p. 51
  50. http://www.opera.com/docs/specs/presto2.10/
  51. http://www.developpez.com/actu/32809/WebRTC-Google-libere-un-framework-de-communication-audio-et-video-en-temps-reel-depuis-le-navigateur-et-oeuvre-pour-le-standardiser/
  52. (en) « Chromium Blog: Real-time Communications in Chrome », Blog.chromium.org,‎ 2012-01-18 (consulté le 2012-09-12)
  53. http://www.generation-nt.com/mozilla-firefox-technologie-webrtc-demonstration-video-actualite-1565881.html
  54. (en)https://www.mozilla.org/en-US/firefox/18.0/releasenotes/
  55. (en)http://www.youtube.com/watch?v=S6-rAv6bU8Q
  56. (en)https://hacks.mozilla.org/2012/11/progress-update-on-webrtc-for-firefox-on-desktop/
  57. (en)https://hacks.mozilla.org/2012/09/full-webrtc-support-is-soon-coming-to-a-web-browser-near-you/
  58. (en)http://www.mozilla.org/en-US/firefox/22.0/releasenotes/
  59. (en)https://hacks.mozilla.org/2013/02/webrtc-enabled-h-264mp3-support-in-win-7-on-by-default-metro-ui-for-windows-8-more-firefox-development-highlights/
  60. (en)https://blog.mozilla.org/blog/2013/09/17/webrtc-now-available-across-mobile-and-desktop-with-new-firefox-for-android-compatibility/
  61. (en)http://www.webrtc.org/firefox#TOC-Firefox-implementation-details
  62. http://www.generation-nt.com/webrtc-microsoft-skype-actualite-1611002.html
  63. (en) « Experimental WebRTC mobile browser released by Ericsson »,‎ 2012-10-19 (consulté le 2012-10-20)
  64. http://www.blog-ericssonfrance.com/2012/10/lancement-par-ericsson-dun-navigateur-experimental-webrtc-pour-mobile/
  65. (en) « A Web RTC Tutorial | Ericsson Labs », Labs.ericsson.com (consulté le 2012-09-12)
  66. http://www.youtube.com/watch?v=cx4rZH7fLpM
  67. http://sipml5.org/
  68. https://code.google.com/p/sipml5/
  69. http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket
  70. https://appear.in/
  71. https://talky.io/
  72. http://www.webrtcworld.com/topics/webrtc-world/articles/307673-carriers-may-find-new-opportunities-with-webrtc.htm
  73. http://tokbox.com/opentok/api/tools/js/documentation/overview/WebRTC.html
  74. https://rtccopy.com/
  75. (en) https://blog.mozilla.org/blog/2013/02/24/webrtc-ringing-a-mobile-phone-near-you/
  76. https://sites.google.com/site/webrtc/faq#TOC-Do-Google-products-use-WebRTC-and-iSAC-
  77. http://blogs.msdn.com/b/interoperability/archive/2012/08/06/customizable-ubiquitous-real-time-communication-over-the-web-cu-rtc-web.aspx
  78. http://www.developpez.com/actu/46378/Microsoft-soumet-ses-propositions-pour-WebRTC-au-W3C-vers-une-version-Web-de-Skype-sans-recours-aux-plug-ins/
  79. http://www.pcinpact.com/news/72953-microsoft-travaille-sur-version-web-skype-basee-sur-webrtc.htm
  80. (en)https://www.ietf.org/mail-archive/web/rtcweb/current/msg04953.html
  81. (en)http://tools.ietf.org/html/draft-cbran-rtcweb-codec-02#section-3.2
  82. (en)http://www.webrtc.org/blog/webrtcimprovementbetterrealtimevp8andnewrtpprofileadopted
  83. (en)http://tools.ietf.org/html/draft-ietf-payload-vp8-10#page-3
  84. http://www.macg.co/2012/08/microsoft-vers-une-version-web-de-skype-56787
  85. (en)http://html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm#attributes-2
  86. (en)http://webrtchacks.com/ietf-finally-made-decision-mandatory-implement-mti-video-codec-webrtc/
  87. (en)http://html5labs.interoperabilitybridges.com/prototypes/cu-rtc-web-video/cu-rtc-web-video/info