Les 9 et 10 septembre, une réunion commune intermédiaire des groupes de travail WebRTC et Device API du W3C s’est tenue au siège de Microsoft à Redmond.

Les réunions intermédiaires, également appelées réunions « face-à-face » (quand elles n’ont pas lieu en Chine…), sont des réunions plus petites et plus ciblées qui se déroulent entre les grandes réunions pleinières, avec un programme précis pour faire avancer les choses plus vite. Les réunions IETF (3 par an) sont longues et peuvent être épuisantes. Les réunions du W3C, ou plutôt « la réunion » sans ‘s’ puisque seul le TPAC est technique, sont aussi très longues, mais surtout elles n’ont lieu qu’une seule fois par an. Certains voudraient pouvoir prendre des décisions plus rapidement, notamment quand le programme déborde de nouvelles fonctionnalités demandées par WebRTC 1.0. Ces réunions intermédiaires permettent d’obtenir des retours d’expérience et de prendre des décisions qui sont difficiles voire impossible à prendre par e-mail.

Plus tôt cette année, le groupe de travail WebRTC est arrivé au bout du temps qui lui était alloué et a demandé une extension au W3C. L’extension a été accordée sous la condition que la convergence entre le travail du groupe WebRTC et celui du groupe ORTC devienne plus qu’une réalité. Erik L. (de Hookflash) est devenu un des présidents du nouveau groupe WebRTC et la convergence entre les spécifications a été accélérée.

Cette réunion était dédiée, en particulier, à mettre à jour la liste des fonctionnalités que nous devrions avoir dans la version 1.0 ou à laisser pour plus tard, afin d’avoir une vision claire avant TPAC (fin octobre au Japon), de telle sorte que la réunion du TPAC se résume à la validation des décisions prises et qu’elle s’achève avec une liste stable des fonctionnalités pour la version 1.0.

Beaucoup de nouvelles APIs ont été expérimentées au sein du groupe ORTC (qui était composé de nombreux membres du groupe WebRTC), et Peter T. de Google par exemple est venu avec beaucoup de propositions sur la manière de concevoir ces nouvelles APIs. Celles-ci n’étaient pas trop controversées, étaient relativement petites, et tout s’est bien passé. La plupart des sujets abordés et les présentations correspondantes sont maintenant disponibles ici.

Puis nous avons parlé de simulcast.

La discussion sur simulcast a été…  intéressante. Comment faire pour diffuser sur le fil un même contenu encodé à différentes résolutions et différents débits binaires n’était pas vraiment un problème, quasiment tout le monde est d’accord sur ce qui doit être fait (même si Microsoft et Cisco ont un peu argumenté sur ce sujet). Le but ultime n’a pas non plus été un réel sujet de discussion. tout le monde est d’accord que nous devrions viser  une JS API qui permettrait non seulement le simulcast, mais aussi le codage vidéo scalable (SVC) plus tard, et que cette nouvelle API approuvée un peu plus tôt fasse le boulot. La principale préoccupation était la masse de travail et les efforts devant être mis en œuvre pour l’inclure dans WebRTC 1.0 sans retarder encore plus la version finale.

Il y avait deux aspects à cela. Premièrement, comme le simulcast touche à presque toutes les couches, depuis le fil jusqu’à la signalisation, la masse de travail pour le tester et le débugger sera plus importante qu’à l’habitude et Google était préoccupé sur sa capacité à le finir avant la fin de l’année. Deuxièmement, et en lien avec le premier point, la discussion a porté sur la manière de gérer la signalisation du simulcast.

Ici, nous ne sommes pas en train de parler du Plan B contre le plan Unifié, qui touchent à comment gérer la signalisation de flux multiples dans une seule PeerConnection, mais nous traitons de simulcast, qui est un sous-cas des flux multiples où les flux ne sont pas indépendants les uns des autres mais des variations (différentes résolutions, différents nombres d’images par seconde) de la même source. Le point clé, ici, c’est que vous ne voulez pas que ce soit le navigateur qui traite chacun de ces flux indépendamment. Par exemple, vous ne voulez PAS que le contrôle de congestion de la bande passante du navigateur ou que l’algorithme d’adaptation de la bande passante du codec modifie séparément la résolution du flux. Ce que vous voulez, c’est que, pour s’adapter à une bande passante trop faible, ce soit d’abord la résolution la plus haute qui soit éliminée, voire même que la transmission de la vidéo soit totalement interrompue pour privilégier la transmission du son. Ceci est possible avec des flux multiples indépendants, c’est également possible (conceptuellement) avec simulcast car vous connaissez la dépendance entre les flux.

La principale question à propos de simulcast a porté sur l’intérêt pour WebRTC de réutiliser le travail fait dans le groupe de travail IETF MMUSIC. Ce groupe est en charge du format SDP et il travaille actuellement sur une proposition spécialement conçue pour le simulcast. Pour certains, cela semblerait étrange de ne pas l’utiliser et de refaire leur travail. Mozilla, qui aurait déjà mis cela en œuvre dans Firefox, était un fervent supporter de son utilisation. Pour d’autres, étant donnée l’histoire du groupe MMUSIC, cette proposition risquerait de prendre trop de temps pour arriver à maturité et devenir une spécification. Google était tout particulièrement réticent à ajouter une dépendance normative supplémentaire à la spécification WebRTC sans avoir ni un contrôle ni même une visibilité sur le délai potentiel qui pourrait en résulter. Mettre l’accent sur la date limite pour aboutir à la version 1.0 et ne pas la repousser, surtout d’un délai indéfini. Comme la prochaine réunion IETF doit avoir lieu APRÈS le W3C TPAC, la probabilité que cette question soit traitée à temps pour la version 1.0 est ramenée à 0.

Comme tout le monde était d’accord sur ce qui est la bonne chose à faire, et que la seule inconnue était la capacité du groupe de l’IETF à rendre sa proposition à temps, deux membres du groupe de travail W3C qui sont également présidents du groupe IETF Rtcweb, nommés J. Cullen de CISCO et H. Peter de Google , ont contacté leurs homologues à MMUSIC pour voir si MMUSIC était intéressé pour organiser une réunion intermédiaire suffisamment tôt pour permettre à cette spécification d’aboutir et de la sortir de la liste des préoccupations actives. La réponse de MMUSIC est positive et ils se sont engagés à accélérer le processus sur la spécification SDP de simulcast.

Le chemin restant à parcourir pour avoir simulcast dans webrtc 1.0 reste semé d’embûches. D’abord MMUSIC doit converger sur les spécifications sdp-multicast, avec, espérons-le, un retour d’espérience de la part du groupe WebRTC. Ensuite, le groupe WebRTC du W3C avait accepté d’avoir une réunion virtuelle avant TPAC (dernière semaine d’octobre), avec un retour d’expérience de MMUSIC en main pour décider si on donne le feu vert pour inclure simulcast dans la version 1.0. Finalement, c’est au TPAC que seront présentés les retours d’expérience des premières mises en œuvre de simulcast et que sera prise la décision finale à propos de l’incorporation de simulcast dans WebRTC 1.0. Tout cela dans 5 semaines 😉

La semaine dernière, j’ai donné une formation à CISCO suivie par un hackaton sur OpenWebRTC. Mon ami et collègue au W3C et à l’IETF, Dan Burnett, gérait la partie standards et specifications de la formation (et Dieu sait qu’il est bon pour ça), pendant que je m’occupais de la partie technique : implémentations, stacks, debugging, navigateurs… C’était une session excellente, la dualité entre la théorie et la pratique (toujours différents dans la vrai vie) était excitante, et l’auditoire s’y connaissait en WebRTC, chacun sur une partie du puzzle que représente une solution de communication basée sur WebRTC. Super expérience.

À la fin de la formation, on m’a posé une question à laquelle je n’étais pas préparé : « quelles sont les solutions et applications WebRTC les plus incroyables ? » Hum, question difficile. Tout d’abord, mais ça dépend des goûts, certaines personnes peuvent être impressionnées par une superbe interface utilisateur (et elles adoreront appear.in de Telenor Digital par exemple), alors que d’autres seront emballées par une entreprise qui a fourni une solution à un problème technique qu’elles-même ont été incapables de résoudre (le navigateur bowser d’Ericson ou le plugin Cordova de eFace2Face, chacun des deux pallie l’absence de support WebRTC sur iOS, alors que le projet webrtcinwebkit essaie de régler le même problème à la source).

Le chercheur en moi est toujours impressionné par les gens qui ont une vision et qui non seulement sont capables de voir au-delà de ce qu’il est possible de faire aujourd’hui, mais en plus transforment cette vision en réalité.

Pour cette raison j’aime les présentations de Feross. Ce mec est un passionné, il a une vision, il la met en œuvre, et il a cette capacité rare à transmettre sa passion à son auditoire. Sur un (oui, seulement un, pour plus, vous pouvez le suivre sur twitter) de ses multiples projets supplémentaires, il essaie de développer un bit torrent sur le web supporté directement par les navigateurs internet. J’ai eu la chance de travailler avec lui pendant une demi-journée à Singapour quand il est venu faire une présentation à la JSconf.asia, et de l’écouter de nouveau au « WebRTC meet up » de San Francisco. C’était vraiment des expériences agréables. J’ai hâte de l’entendre de nouveau au « Kranky and geek event » (#webrtclive) plus tard ce mois-ci.

Quand j’étais employé chez Temasys, j’ai eu la chance de travailler avec Thomas Gorissen qui est le meilleur développeur JS de ce côté du globe, organisateur de la « JSconf.asia » et expert en interface utilisateur (UI) / expérience utilisateur (UX) pour Sequoia Capitals parmi (tant) d’autres choses. Je n’ai donc pas eu trop à me soucier de mon code JS, ce qui est bien car les développeurs C++ ne sont, au mieux, que de pauvres développeurs JS 🙂 Ma seule satisfaction est d’avoir réussi à titiller suffisamment sa curiosité sur le WebRTC pour qu’il envisage de travailler dessus. Il ferait partie de mon équipe JS de rêve, avec Feross et Iñaki (voir plus loin).

Il y a certains ingénieurs qui sortent du lot à la fois dans l’écosystème et comme membres de petites équipes tout en continuant à faire la différence. J’ai beaucoup de respect pour le travail de Philipp Hancke et Iñaki Baz Castillo par exemple, et je suis rempli d’humilité devant les connaissance de Victor Pascual Ávila ou Dan Burnett sur les différentes APIs et technologies utilisées. Je vous conseille donc, si ce n’est pas déjà le cas, de les suivre. Je pense qu’Iñaki l’a bien exprimé pour nous tous : « On m’a dit que c’était impossible, donc je l’ai fait ». C’est exactement ma philosophie.

L’avantage de WebRTC c’est que c’est si rapide de s’améliorer, et si facile de commencer à l’utiliser, que je découvre chaque jour des trucs cools. Le projet qui m’excite cette semaine c’est un projet de réseau global p2p par David Dias qui exploite WebRTC. Oui, c’est assez proche de ce que fait Feross et je vois les deux projets comme étant complémentaires, mais ce qui est sympa à propos du projet de David c’est que ses posts de blog sont quasiment des articles de recherche complets. Cela signifie que vous avez toutes les informations du début à la fin avec un aperçu de l’ensemble du domaine des communications p2p (depuis Kazaa), avec des citations, des schémas et ainsi de suite. C’est rafraîchissant de voir quelque chose de bien expliqué et de reproductible. Cela permet aussi à quelqu’un de nouveau dans le domaine (comme moi), mais avec assez de connaissances scientifiques et technologiques, d’emmagasiner assez de connaissances sur les technologies p2p, les signatures électroniques et la sécurité des tables de hachage distribuées utilisées dans les crypto-monnaies comme le Bitcoin par exemple. Je pense qu’il est sur quelque chose et je ne serais pas surpris qu’une entreprise basée aux USA aille le débaucher du Portugal.

Si vous êtes au courant de projets fous qui essaient d’utiliser WebRTC sur des voies non explorées, s’il vous plait faites-le moi savoir, j’ai besoin de ma dose hebdomadaire.

Une version mise-à-jour de ce post est disponible ici.

Lire la suite →