ORTC dans Edge – Êtes-vous prêt pour le tsunami ?

This post is also available in: English (Anglais)

[post original : septembre 2015]

Mon twitter est en feu ! C’est une des nouvelles les plus attendues dans l’écosystème, et pour beaucoup, mais pas tous, elle est arrivée bien plus tôt que prévu.

I. Historique et contexte

Plus tôt cette année, en parlant à la conférence WebRTC de NTT à Tokyo, j’ai cité ORTC comme une possibilité pour 2015 (voir transparents numéros #17 et #30). Plus tard, à la réunion WebRTC en juin à San Francisco hébergée par TokBox, j’ai répété cette prédiction qui correspondait à ce que tout le monde pensait (autour de 1:45). La sortie de l’API GetUserMedia, plus tôt, en mai, aurait dû être un indice. Je me trompais.

Pendant les mois d’août et de septembre, de plus et plus d’indices dans l’écosystème nous signalaient une livraison (plus) rapide de ORTC dans Edge. Beaucoup de questions restaient ouvertes : quel codec sera utilisé, à quel point l’API d’ORTC sera proche de l’API de WebRTC-NV, etc. Actuellement, quelques-unes de ces questions sont toujours sans réponse. En septembre, il est devenu clair que tout était fait et prêt, ce qui a ravi quelques développeurs, mais certains membres du comité de standardisation l’étaient moins. Ça doit commencer à donner du sens au fait que j’ai choisi de passer une semaine à Redmond avant la réunion W3C :-).

II. Les faits

Le 18 septembre 2015, Microsoft a annoncé la disponibilité d’ORTC pour les membres du Microsoft Insider Program. Ils l’ont annoncé à beaucoup d’endroits, mais principalement sur les blogs Windows/Edge et Office/Skype. Sur la page officielle de Microsoft, une démo avec Twilio était disponibe. Le même jour, des posts sur le blog webrtchacks et à d’autres endroits très visibles ont commencé à apparaître. Très clairement, certains étaient dans la confidence, comme l’a laissé transparaître leur langage corporel quand le sujet est arrivé sur la table au Kranky geek show.

Quand ce post a été écrit, SimpleRTC (avec sa  démo supportant uniquement l’audio et Chrome pour l’instant) et ortc-adapter de Twilio permettaient déjà l’interopérabilité entre WebRTC et ORTC.

Comme annoncé par Bernard Aboba au Kranky & Geek show, et comme je l’ai signalé sur le fil de discussion correspondant de la mailing list webrtc-discuss, Microsoft prévoit de proposer d’abord sa propre version de 264 SVC, appelée 264UC. Pour les développeurs de média hardcore qui connaissent déjà 264 AVC/SVC et veulent voir la différence avec 264UC, allez ici. Ensuite c’est H.264 standard (AVC) qui sera supporté pour assurer l’interopérabilité avec Firefox et Chrome. Actuellement 264 est déjà supporté par la bibliothèque libwebrtc à travers les API des OS pour WebRTC dans ChromeOS, Android et iOS , il n’y a que Chrome pour ordinateur de bureau qui ne le supporte pas, ce qui fait l’objet d’un bug ouvert et déjà affecté. En bref, ils travaillent dessus au moment où je vous parle et des patchs sont déjà disponibles.

current Skype design – ORTC

Dans l’intervalle, Microsoft prévoit d’utiliser un serveur média pour transcoder entre les différentes variétés de H.264, comme illustré ci-dessus.

III. Conséquences et discussion

A. À court terme

Premièrement et avant toute chose, allez lire l’article du webrtchacks pour avoir une rapide vue d’ensemble de ce dont vous aurez besoin pour réaliser un simple appel 1:1. Prenez une aspirine et revenez ici.

L’API d’ORTC est plus complexe, et comme elle est de plus bas niveau, vous devez définir beaucoup plus de choses que ce que demande l’API WebRTC pour aboutir au même cas d’usage. Les avantages de cette API ne deviennent évident que pour des cas plus complexes comme la manipulation de codecs, les connections avec des serveurs média, les conférences a plusieurs avec une seule peer-connection, le simulcast, les codecs SVC… Pour beaucoup, ça devient juste absurde et superflu. Dans ce cas, utilisez un shim comme ortc-adapter de twillio. Il est très probable, dans une première étape, que la majorité des fournisseurs mettent à jour leur JS SDK dans les semaines à venir pour faire juste ça. Note : ça ne marchera que pour l’audio, donc préparez quelques aspirines pour les développeurs web qui vont devoir gérer tous les navigateurs et tous les média.

Si vous utilisez un plugin pour Internet Explorer, assurez-vous que votre marché en a besoin. Le marché d’entreprise devrait en avoir besoin car il est prisonnier des vieilles versions d’Internet Explorer, mais les sites internet sociaux et classiques peuvent s’en passer. De plus, les deux principaux plugins restent bloqués sur des versions anciennes des spécifications (avant les promesses et d’autres choses qui ont été ajoutées il y a environ 6 mois), et ne montrent aucun signe de préparatifs pour supporter les 30 nouveaux objets créés par l’API ORTC et WebRTC NV .

B. À moyen/long terme

Il y a deux questions principales que vous devez vous poser pour le long terme.

  1. Suis-je limité de quelque manière que ce soit par les API WebRTC ?

Si vous avez déjà tout ce que vous voulez, utilisez juste un shim. Si vous êtes limité en termes de contrôle de réseau (sécurité ou bande passante), codec, nombre de flux, etc, alors ORTC ou WebRTC NV va vous apporter quelque chose. Si vous utilisez un serveur média, il y a aussi de grandes chances que les nouvelles API vous soient bénéfiques.

2. À quel point WebRTC et ORTC sont-elles convergentes ?

C’est la question clé. Si j’attend, ces problèmes d’interopérabilité vont-ils devenir plus simple ou même disparaître ? En tous cas, beaucoup de développeurs JS acceptent un certain degré d’incompatibilité, mais l’incompatibilité sur le fil n’est pas quelque chose que vous pourrez traiter au niveau de JS, donc nous avons ici un réel problème.

Les premiers exemples et démos semblent indiquer que l’interopérabilité est déjà une réalité, du moins en ce qui concerne la signalisation, API et l’audio. Tant que Microsoft ne supportera pas H.264, l’interopérabilité pour la vidéo restera un point d’interrogation.

Finalement, je ne connait personne qui ait consulté les API WebRTC / WebRTC NV / ORTC pour vérifier à quel point elles sont vraiment différentes. Mon sentiment est qu’elles sont suffisamment proches pour que la magie JS les fasse disparaître, mais je ne l’ai pas encore testé.

IV Conclusion

Depuis août, il était évident pour beaucoup que cela allait arriver. Dans ma plus récente présentation (publique), ma dernière diapositive était claire (diapositive #12) : ORTC est une super API, et elle est nécessaire pour beaucoup de cas d’utilisations, mais beaucoup de vendeurs ne sont pas prêts pour le tsunami et la masse de travail nécessaire pour supporter tout ça.

Ma prévision était et reste que l’écosystème WebRTC PaaS va rétrécir de 25% (en nombre de compagnies) car les plus petites sont déjà très très maigres, dans un marché ou la traction reste l’exception et où le financement reste difficile à trouver. Les vendeurs de plugins pour Internet Explorer seront encore plus impactés, du fait que le marché devient plus petit, et ils vont avoir besoin de différentes sources de traction pour espérer récupérer de l’argent. Nous vivons des temps intéressants.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Time limit is exhausted. Please reload CAPTCHA.