{"id":16723,"date":"2018-05-02T14:52:34","date_gmt":"2018-05-02T18:52:34","guid":{"rendered":"https:\/\/www.crim.ca\/?post_type=blogue&p=16723"},"modified":"2023-06-07T16:43:10","modified_gmt":"2023-06-07T20:43:10","slug":"webrtc-et-la-construction-dune-application-web-de-videoconference","status":"publish","type":"blogue","link":"https:\/\/www.crim.ca\/fr\/blogue\/webrtc-et-la-construction-dune-application-web-de-videoconference\/","title":{"rendered":"WebRTC et la construction d\u2019une application Web de vid\u00e9oconf\u00e9rence"},"content":{"rendered":"
\n

Ce billet repr\u00e9sente le fruit d\u2019une veille technologique pr\u00e9alable \u00e0 la construction d\u2019une application Web de vid\u00e9oconf\u00e9rence bas\u00e9e sur une architecture moderne et utilisant les technologies disponibles en ce printemps 2018.<\/p>\n

Nous entendons par \u00abapplications Web\u00bb une application ne n\u00e9cessitant aucune installation suppl\u00e9mentaire et respectant les derniers standards Web recommand\u00e9s par le W3C. Cela exclut donc, par exemple, une technologie n\u00e9cessitant l\u2019installation d\u2019un\u00a0plugin\u00a0<\/em>Flash dans le navigateur.<\/p>\n

Ceci est l\u2019histoire, plut\u00f4t technique mais tout de m\u00eame accessible, d\u2019une petite aventure dans l\u2019univers WebRTC de la vid\u00e9oconf\u00e9rence Web.<\/p>\n

\n
\"\"<\/div>
Source:\u00a0https:\/\/www.pubnub.com\/wp-content\/uploads\/2014\/10\/WebRTCVoice.png<\/a><\/figcaption><\/figure>\n

Les protocoles de diffusion vid\u00e9o<\/h2>\n

Nos premi\u00e8res recherches nous ont rapidement amen\u00e9s vers les protocoles de diffusion vid\u00e9o et la notion de diffusion en direct (live streaming)<\/em>. Apr\u00e8s tout, ne cherchions-nous pas nous aussi \u00e0 partager en direct du contenu audio\/vid\u00e9o dans un lecteur vid\u00e9o HTML5?<\/p>\n

\n

Note<\/strong>. Pour un tour d\u2019horizon de ces technologies, voir ce rapport encore tout \u00e0 fait pertinent:\u00a0\u00c9tat de l\u2019art des technologies et protocoles de diffusion de contenu vid\u00e9o sur Internet<\/a><\/p>\n<\/blockquote>\n

Les protocoles\u00a0HLS\u00a0<\/strong>(pour HTTP Live Streaming),\u00a0MPEG-DASH<\/strong>\u00a0(Dynamic Adaptative Streaming over HTTP) ou encore\u00a0HDS\u00a0<\/strong>(HTTP Dynamic Streaming) existent pour accomplir cette t\u00e2che. Le d\u00e9bat est encore en cours \u00e0 savoir lequel s\u00e9lectionner pour une diffusion en direct de contenu vid\u00e9o.<\/p>\n

En r\u00e9alit\u00e9, bien qu\u2019on parle de diffusion en direct, ces protocoles impliquent une\u00a0latence de niveau interm\u00e9diaire<\/strong>\u00a0puisqu\u2019ils sont tous bas\u00e9s sur HTTP, lui-m\u00eame bas\u00e9 sur TCP\/IP. Avec HLS ou MPEG-DASH, par exemple, on aura un \u00e9cart de l\u2019ordre de 30 \u00e0 45 secondes entre la captation du flux multim\u00e9dia et l\u2019\u00e9coute de celui-ci dans le navigateur! Cet \u00e9cart pourrait \u00eatre \u00e9ventuellement r\u00e9duit sous les 10 secondes en utilisant diff\u00e9rentes techniques d\u2019optimisation (voir\u00a0<\/em>Achieving low latency video streaming<\/a>).<\/p>\n

\n

Note<\/strong>. Il existe aussi d\u2019autres protocoles comme\u00a0RTMP\u00a0<\/strong>qui n\u2019est pas bas\u00e9 sur HTTP et offre une faible latence, mais qui n\u00e9cessite un plugin Flash pour \u00eatre utilis\u00e9 dans un navigateur, ce qui l\u2019exclut d\u2019office.<\/p>\n<\/blockquote>\n

Une latence de plusieurs secondes est, par ailleurs, inimaginable dans un contexte de vid\u00e9oconf\u00e9rence et c\u2019est pour cette raison qu\u2019il faut irr\u00e9m\u00e9diablement se tourner vers des diffusions \u00e0 ultra-faible latence, des\u00a0diffusions en temps r\u00e9el<\/strong>.<\/p>\n

Au-del\u00e0 de la latence, la diffusion en direct est un cas d\u2019utilisation distinct du n\u00f4tre en ce qu\u2019elle est, par nature,\u00a0unidirectionnelle\u00a0<\/strong>et implique souvent la diffusion \u00e0\u00a0une large audience<\/strong>\u2026 Bon, il s\u2019agit certainement d\u2019un mauvais d\u00e9part et vous \u00eates probablement aussi confus que nous\u2026<\/p>\n

\n
\n
\"\"<\/div>\n<\/div>\n<\/figure>\n

Et si on prenait un peu de recul pour mieux comprendre les enjeux?<\/p>\n

Communication temps-r\u00e9el dans le navigateur<\/h2>\n

Dans un monde pas si lointain, toute fonctionnalit\u00e9 interactive ou encore tout traitement intensif c\u00f4t\u00e9 client dans un navigateur passaient par l\u2019interm\u00e9diaire de\u00a0plugins:\u00a0<\/em>Java Applet ou encore Flash (particuli\u00e8rement pour l\u2019affichage de contenu vid\u00e9o). Ces\u00a0plugins\u00a0<\/em>\u00e9taient aussi un mal n\u00e9cessaire pour pouvoir utiliser les diff\u00e9rents protocoles de communication ou autres standards propres au monde de l\u2019Internet.<\/p>\n

Dans le monde plus particulier de la communication temps-r\u00e9el, hier encore, l\u2019installation d\u2019un logiciel propri\u00e9taire (WebEx, Zoom) \u00e9tait n\u00e9cessaire pour initier une communication multim\u00e9dia en temps r\u00e9el. Dans le monde du Web, le\u00a0plugin\u00a0<\/em>Flash permit de rem\u00e9dier temporairement \u00e0 cette situation en offrant l\u2019interop\u00e9rabilit\u00e9 dont tous r\u00eavaient et en \u00e9largissant les possibilit\u00e9s permises dans le navigateur Web. Mais Flash appartenait \u00e0 une seule compagnie, son d\u00e9veloppement n\u2019\u00e9tait ni concert\u00e9 ni ouvert et cette technologie op\u00e9rait dans un navigateur Web, tel un corps \u00e9tranger, par interm\u00e9diaire de l\u2019installation d\u2019un\u00a0plugin.<\/em><\/p>\n

Or, depuis l\u2019av\u00e8nement du standard HTML5, l\u2019id\u00e9e, et la tendance g\u00e9n\u00e9rale, est d\u2019apporter les fonctionnalit\u00e9s directement dans le navigateur et d\u2019instaurer des API r\u00e9ellement\u00a0natives (<\/strong>du point de vue du navigateur)\u00a0<\/strong>et d\u00e9velopp\u00e9es de fa\u00e7on collaborative et\u00a0ouverte\u00a0<\/strong>par les acteurs de l\u2019industrie.<\/p>\n

Ainsi naquit la\u00a0sp\u00e9cification WebRTC<\/a><\/p>\n

La sp\u00e9cification WebRTC<\/h2>\n
\n
\n
\"\"<\/div>\n<\/div>\n<\/figure>\n

WebRTC pour\u00a0Web Real-Time Communication<\/strong>\u00a0entend, comme son nom l\u2019indique, rendre possible les communications multim\u00e9dias en temps r\u00e9el dans un contexte Web en \u00e9vacuant la n\u00e9cessit\u00e9 d\u2019une installation pr\u00e9alable. WebRTC est une collection de standards, de protocoles et d\u2019API JavaScript permettant le partage navigateur \u00e0 navigateur de contenu vid\u00e9o, audio ou encore de donn\u00e9es.<\/p>\n

Ce standard fut d\u00e9fini conjointement par le\u00a0W3C Working Group<\/strong><\/a>,<\/strong>\u00a0qui se chargea de la d\u00e9finition des API dans le navigateur, et l\u2019IETF Working Group<\/strong><\/a>,<\/strong>\u00a0qui s\u2019occupa des aspects plus techniques des protocoles d\u2019\u00e9change, du format des donn\u00e9es, de la s\u00e9curit\u00e9, etc.<\/p>\n

WebRTC se compose de trois API principales \u2014 MediaStream, RTCPeerConnection, DataChannel \u2014 et n\u00e9cessite quelques protocoles de transport que nous verrons dans cette section.<\/p>\n

MediaStream<\/h2>\n

Un crit\u00e8re essentiel pour que le navigateur puisse offrir des fonctionnalit\u00e9s de t\u00e9l\u00e9conf\u00e9rence est \u00e9videmment de pouvoir acc\u00e9der au contenu audio\/vid\u00e9o captur\u00e9 par l\u2019appareil h\u00f4te.<\/p>\n

L\u2019objet MediaStream permet un tel acc\u00e8s simplifi\u00e9 par la m\u00e9thode\u00a0getUserMedia<\/strong>, mais encapsule aussi de puissants moteurs de traitement audio\/vid\u00e9o internes permettant d\u2019en am\u00e9liorer la qualit\u00e9 (encodage, d\u00e9codage, synchronisation, gestion des fluctuations de la bande passante, dissimulation des paquets perdus, r\u00e9duction des bruits dans la bande audio, am\u00e9lioration de l\u2019image dans le flux vid\u00e9o, etc.) Notons que la majorit\u00e9 des navigateurs vont forcer l\u2019utilisation de HTTPS dans la page avant de permettre l\u2019utilisation de getUserMedia.<\/p>\n

WebRTC supporte pr\u00e9sentement diff\u00e9rents codecs de compression, mais principalement\u00a0VP8\u00a0<\/strong>et\u00a0H.264<\/strong>\u00a0pour la vid\u00e9o et\u00a0Opus\u00a0<\/strong>pour l\u2019audio.<\/p>\n

Une fois l\u2019acquisition du flux multim\u00e9dia enclench\u00e9, celui-ci peut \u00eatre utilis\u00e9 \u00e0 diff\u00e9rentes fins dans d\u2019autres API du navigateur:\u00a0Web Audio<\/strong>\u00a0pour lancer la piste audio dans le navigateur,\u00a0Canvas<\/strong>\u00a0pour faire la capture d\u2019une image,\u00a0CSS3<\/strong>\u00a0et\u00a0WebGL<\/strong>\u00a0pour appliquer des effets 2D\/3D sur le flux ou encore\u00a0RTCPeerConnection,<\/strong>\u00a0que nous verrons plus loin, pour envoyer directement ces donn\u00e9es \u00e0 un autre navigateur!<\/p>\n

Transport et protocoles<\/h2>\n

WebRTC se distingue d\u2019abord par le choix du protocole de transport qui le soutient. En effet, WebRTC a d\u00e9termin\u00e9\u00a0UDP\u00a0<\/strong>comme couche de transport (du mod\u00e8le OSI) qui se pr\u00eate particuli\u00e8rement bien au contexte temps-r\u00e9el o\u00f9 la latence devient critique. Si UDP n\u2019offre aucune garantie par rapport \u00e0 TCP (qui garantit l\u2019arriv\u00e9e des paquets, mais aussi l\u2019ordre de ceux-ci), il se pr\u00eate beaucoup mieux aux flux multim\u00e9dias en temps r\u00e9el qui peuvent g\u00e9n\u00e9ralement supporter la perte de certaines donn\u00e9es (codecs audio et vid\u00e9o).<\/p>\n

\n
\"\"<\/div>
Protocoles du Web \u00e0 gauche et WebRTC \u00e0 droite. Source:\u00a0https:\/\/hpbn.co\/assets\/diagrams\/f91164cbbb944d8986c90a1e93afcd82.svg<\/a><\/figcaption><\/figure>\n

Comme le diagramme pr\u00e9c\u00e9dant en t\u00e9moigne, d\u2019autres protocoles sont mis en oeuvre pour permettre notamment le cryptage du contenu, mais aussi le contr\u00f4le du d\u00e9bit, le contr\u00f4le de la congestion, la gestion des erreurs, etc., tous n\u00e9cessaires pour \u00e9viter la submersion du r\u00e9seau et la d\u00e9gradation de la communication:<\/p>\n