La version web de Skype disponible sans plugin dans Edge

La version web de Skype disponible sans plugin dans Edge

Un fonctionnement parfois capricieux

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

18/04/2016 4 minutes
21

La version web de Skype disponible sans plugin dans Edge

La version web de Skype peut désormais se passer complètement de plugin si elle est utilisée dans Edge. Un premier mouvement de Microsoft vers une version totalement « web » de la solution VoIP.

L’éditeur avait promis il y a un moment que Skype finirait par être disponible sur le web sans devoir installer de plugin. Ce dernier est présent depuis environ trois ans et permet l’utilisation du service dans à peu près tous les navigateurs, y compris Safari sous OS X. Même si cette version peut s’avérer pratique, beaucoup se demandaient l’intérêt de devoir installer un plugin : quitte à vraiment installer un élément, pourquoi ne pas le faire avec le client classique ?

La version web de Skype s’utilise dans une bonne partie des services en ligne de Microsoft. Elle est présente à droite dans Outlook.com par exemple, ou sur le site de OneDrive. La barre latérale présente les derniers contacts à qui l’on a parlé, un clic permettant de rouvrir une conversation. Jusqu’à présent, utiliser la fonction d’appel audio ou vidéo affichait un avertissement invitant à installer le plugin, autorisant après coups ce type de communication, quel que soit le client utilisé par le contact.

En théorie, une expérience très simple

Vendredi soir, dans un billet de blog, Microsoft a annoncé que cette installation n’était désormais plus requise, mais à une seule condition : que l’utilisateur se serve d’Edge, le navigateur exclusif à Windows 10. Il faut simplement que la version 1511 (mise à jour majeure de novembre) au moins soit installée pour commencer à utiliser la fonction, compatible aussi bien avec les appels audio que vidéo.

L’éditeur se sert finalement du moteur ORTC, intégré dans son navigateur il y a plusieurs mois. Les appels tiennent compte de toutes les fonctionnalités qui étaient permises par l’installation du plugin, notamment celles de partage pour afficher, par exemple, des présentations PowerPoint. Globalement, la seule différence avec la situation précédente est que l’utilisateur n’aura pas à passer par une étape supplémentaire.

Les scénarios envisagés couvrent à peu près tous les cas de figure. On retrouve ainsi tous les appels en 1+1 et ceux de groupe avec les utilisateurs de la version web, ou de la dernière mouture du client Skype pour Windows et OS X. Microsoft précise que la révision la plus récente doit être installée, ce qui pourrait être un facteur bloquant dans certains cas, tous les utilisateurs ne mettant pas à jour, même lorsqu’une notification apparaît pour prévenir.

En pratique, des appels capricieux

En théorie, la méthode est donc simple : il suffit d’appeler un contact. En pratique, c’est un peu plus compliqué. Nous avons procédé à plusieurs essais, qui se sont révélés finalement assez peu concluants. Les appels sont bien émis sans que la moindre installation ne soit réclamée, mais si le son du micro est transmis depuis Edge vers le contact (qui possède bien la dernière version de Skype pour Windows), l’inverse ne se fait pas. Le problème s’est manifesté également avec la dernière version de Skype pour OS X. Tout aussi curieux, l’appel d’un contact a provoqué un message d’erreur dans la conversation, Skype signalant qu’une personne cherchait à nous joindre avec une ancienne version, alors qu’elle possédait bien la 7.22 sous Windows.

skype web

Tant qu’à faire, nous avons poussé les tests dans quelques autres directions. Vers des contacts utilisant Skype sur un smartphone ou une tablette, l’appel n’est pas reçu. Ce fut le cas aussi bien vers Windows 10 Mobile, qu’Android et iOS : les applications ne signalent rien. Cela étant, Microsoft indique expressément sur son blog que seuls les clients pour ordinateurs sont pris en compte actuellement. Et d’Edge vers Edge ? C’est le seul scénario qui a fonctionné de notre côté. Notez d’ailleurs que la communication s’est faite sans problème entre deux PC avec la dernière version stable de Windows 10, mais également entre une version stable et la dernière build 14316 du Fast Ring.

Chrome et Firefox plus tard

Signalons enfin que la prise en charge sous Edge n’est qu’une première étape. Microsoft confirme ainsi que les mêmes capacités seront disponibles sous Chrome et Firefox dès que ces derniers seront pleinement compatibles avec le codec vidéo H.264. Par ailleurs, certaines fonctionnalités, comme le partage d’écran, ne sont pas encore disponibles.

N'hésitez pas à nous indiquer dans les commentaires vos retours sur cette fonctionnalité.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

En théorie, une expérience très simple

En pratique, des appels capricieux

Chrome et Firefox plus tard

Commentaires (21)




Microsoft confirme ainsi que les mêmes capacités seront disponibles sous Chrome et Firefox dès que ces derniers seront pleinement compatibles avec le codec vidéo H.264



Euh … Ils se moquent de qui là ? C’est pas Chrome et Firefox qui ne sont pas compatibles, c’est Microsoft qui a fait sa propre tambouille avec le RTC <img data-src=" />








Yseader a écrit :



Euh … Ils se moquent de qui là ? C’est pas Chrome et Firefox qui ne sont pas compatibles, c’est Microsoft qui a fait sa propre tambouille avec le RTC <img data-src=" />





ortc/webrtc, c’est le signalement et la mise en relation des clients entre eux. Mais les clients doivent supporter les mêmes codecs (en fait, ils se mettent d’accord via des messages sip). C’est là que ça bloque… Et non au niveau d’ortc/webrtc (en fait, c’est trois navigateurs sont déjà compatibles entre eux).



Edge ne supporte que le h264, et chrome ne supporte (pour l’instant, ça changera avec Chrome 51) que le VP8. Firefox ne supporte que le h264 en profil “baseline”.



Dès que Chrome 51 sortira, le client Skype web pourra (normalement) être utilisé aussi bien sur Firefox que sur Chrome.



Justement je trouvais ça bizarre, il me semblait que Firefox supportait H264 ?


Oui, firefox supporte le h264. Je suis sûr qu’en changeant le user agent ça passe. J’essaierai ce soir.


Je pense que ça leur prendra masse de temps pour être compatible avec Chrome et FF. IMO, ils voulaient sûrement déjà voir le résultat sur Edge avant de se lancer sur les autres. A la lecture de l’article, ils ont bien fait, ils ont déjà une flanquée de bugs à corriger.


Vous êtes sûr que Firefox et Chrome supportent ORTC ?

J’avais l’impression que ces navigateurs étaient restés au WebRTC 1.0.. Là où Edge supportait le 1.1 (ORTC)


PCi a tout faux sur les raisons pour Firefox et Chrome :



http://iswebrtcreadyyet.com/



C’était déjà difficile de standardiser Webrtc mais non MS a rajouter son ortc , qui deviendra bien sur Webrtc1.1 , a cause de la part de marché de skype et bientot de edge en entreprise.


Oui, il gère le h264 via le codec fourni par Cisco, utilisé pour Hello notamment


C’est plutôt Skype entreprise en Entreprise, Edge pas dispo sur les versions de Windows Entreprise LTSB et le dialogue entre Skype Home et Skype entreprise, ça ne marche pas toujours très bien … et encore moins avec Skype sur les smartphone … très aléatoire … encore perfectible.


Ou alors beaucoup de sites ont lancé des services de visioconf en se basant sur les brouillons du 1.0. Mais le 1.0 avait beau être pas très bien pensé à la base, il a fallu le “finaliser” sans que ça n’aie trop d’impact sur ces sites qui était en production.



Maintenant on a le 1.1 qui est bien plus paramétrable via des API pour javascript sauf qu’aucun site ne veux l’adopter car il faut retravailler le site…



Mais bon c’est plus IN de cracher sur MS que de voir que la version 1.0 n’a pas bien été pensé dès le début..

https://m.nextinpact.com/news/76852-w3c-microsoft-propose-protocole-pour-communi…



https://m.nextinpact.com/news/72953-microsoft-travaille-sur-version-web-skype-ba…



A la base le WebRTC 1.0 était une boîte noire centralisée… C’est Microsoft qui a poussé l’idée d’un fonctionnement Ad-Hoc… Un comble non ? Ah oui mais non Micro$oft c’est caca, Google et Mozilla qui rush de la merde c’est mieux &lt;3








Mithrill a écrit :



Si on peux faire fonctionner Skype sous distribs&nbsp;Linux correctement ça fera plaisir à une amie&nbsp;! Elle n’attendais que ça pour repasser à Linux… merci MS ! &lt;3



(c’est pas trop tôt en fait surtout, vu qu’avant on pouvais utiliser Skype sans soucis avant le rachat)





Le H264 est supporté par quoi sous nunux ? Cisco a porté son plugin pour FF ? Y a des codecs systèmes ?



Pour la vidéo en stream sous Linux, Firefox repose sur gstreamer alors que le plugin cisco est uniquement pour le webrtc


” A la base le WebRTC 1.0 était une boîte noire centralisée… C’est Microsoft qui a poussé l’idée d’un fonctionnement Ad-Hoc… Un comble non ? Ah oui mais non Micro$oft c’est caca, Google et Mozilla qui rush de la merde c’est mieux &lt;3 “

WebRTC une boîte noir, c’est fort de café!

Technologie en développement ouvert auprès de l’IETF et du W3Chttps://tools.ietf.org/wg/rtcweb/

https://www.w3.org/TR/webrtc/

Le codec audio est super ouvert avec MS/Skype et Mozilla qui ont fait un consensus pour que cela marche partout.



WebRTC n’est pas le must, mais c’est un brouillon et donc il est amené à changer avant la version finale.



Je trouve donc culotté de dire que WEBRtc est une boîte noir. Flash, Silverlight, Windows donc les codes sont fermés, les protocoles plus ou moins documentés. Mais WEBRtc, non. Ou sinon tout le HTML est une boite noire!



Et l’aspect centrale, par rapport à Skype, MSN, ou Facebook Messenger ou Instagram c’est le jour et la nuit. Les premiers sont non interipérable alors que WEBRtc est un canal qui est amené à fonctionner par tout (navigateurs ou client dédiés).


Boîte noire est peut être exagéré, j’aurais du dire une boîte transparente fermé… Tu sais ce qu’il y a dedans mais tu ne peux jouer avec..



Je pense que les gens qui se sont un minimum renseigné sur ORTC seront d’accord pour dire que l’interface SDP du WebRTC 1.0 est bien moins flexible que l’ORTC où le développeur peut choisir bien plus de paramètres..



Vis à vis des codec ça évolue (VP8) :https://blogs.windows.com/msedgedev/2016/04/13/roadmap-update-for-real-time-comm…



Voir VP9 a terme ?https://blogs.windows.com/msedgedev/2016/04/18/webm-vp9-and-opus-support-in-micr…



Et pour la centralisation c’est justement ça qui est drôle… Mozilla et Google ont poussé et même directement commencé à implémenter un brouillon pensé pour être centralisé… N’aurait-il pas été plus intéressant d’avoir des objectifs visant à être moins centralisé dès le début plutôt que commencer à implémenter un brouillon plus que moyen… Tu te rends compte que c’est le méchant Micro$oft qui a poussé à moins de centralisation ?



Et je ne parlerai des sites web qui bâtisse des services pour le grand public sur une norme mal pensé… Et maintenant les apports de l’ORTC ne sont pas prêt à toucher le grand public car les sites web et Mozilla/Google se contentent de cette version au rabais qu’est la 1.0…








arno53 a écrit :



Boîte noire est peut être exagéré, j’aurais du dire une boîte transparente fermé… Tu sais ce qu’il y a dedans mais tu ne peux jouer avec..



Je pense que les gens qui se sont un minimum renseigné sur ORTC seront d’accord pour dire que l’interface SDP du WebRTC 1.0 est bien moins flexible que l’ORTC où le développeur peut choisir bien plus de paramètres..



Vis à vis des codec ça évolue (VP8) :https://blogs.windows.com/msedgedev/2016/04/13/roadmap-update-for-real-time-comm…



Voir VP9 a terme ?https://blogs.windows.com/msedgedev/2016/04/18/webm-vp9-and-opus-support-in-micr…



Et pour la centralisation c’est justement ça qui est drôle… Mozilla et Google ont poussé et même directement commencé à implémenter un brouillon pensé pour être centralisé… N’aurait-il pas été plus intéressant d’avoir des objectifs visant à être moins centralisé dès le début plutôt que commencer à implémenter un brouillon plus que moyen… Tu te rends compte que c’est le méchant Micro$oft qui a poussé à moins de centralisation ?



Et je ne parlerai des sites web qui bâtisse des services pour le grand public sur une norme mal pensé… Et maintenant les apports de l’ORTC ne sont pas prêt à toucher le grand public car les sites web et Mozilla/Google se contentent de cette version au rabais qu’est la 1.0…





Si je ne dis pas de bêtise, avec webrtc un serveur central met en relation les correspondants et ensuite c’est de le connexion directe entre eux. Comment faire moins centralisé, du P2P ?



Te fatigue pas a argumenter, certaines choses sont des fois si évidentes qu’on les ignore facilement.



Avec edge a 2% et personne qui implemente ORTC, il n’est pas prêt de rentrer dans la danse.


&nbsp;Mais arrête.

ORTC finalisé ou pas vient juste d’arriver laisse le temps aux earlier adopter de WebRTC d’évolur vers ORTC (si ils trouvent un intérêt). Laisse le temps à Mozilla et à Google de faire leur propre implémentation.



Il faudrait que tu me donnes ta définition de centraliser. WebRTC est un canal de communication comme l’est http ou STMP. Tu peux pas dire à un canal qu’il est centralisé!!



&nbsp;Rien n’interdit de mettre du WebRTC pour donner une interface WebRTC à XMPP ou à IRC.



Merci pour les liens vers le blog de MS, il y a vraiment un changement de mentalité chez eux <img data-src=" />

&nbsp;

“Je pense que les gens qui se sont un minimum renseigné sur ORTC seront

d’accord pour dire que l’interface SDP du WebRTC 1.0 est bien moins

flexible que l’ORTC où le développeur peut choisir bien plus de

paramètres..&nbsp; ”

Source? Si possible de développeurs ne venant pas de MS ?


Les liens que j’ai posté comm’ N°10 (lui et lui) date de janvier 2013. A cette époque Chrome et Firefox avait déjà implémenter les prémices du WebRTC enfin le brouillon de l’époque.



Et à cette époque le WebRTC c’était ca :







NextINpact a écrit :



En effet, si WebRTC permet bien une vidéoconférence, c’est uniquement de manière centralisée, c’est-à-dire entre un navigateur et un serveur. En clair, si deux utilisateurs veulent communiquer, leurs deux serveurs doivent impérativement passer par un serveur central.





Ce qui me dérange là dedans, c’est qu’on avait déjà commencer à coder un truc qui marchait comme ca dans le brouillon plutôt que réfléchir à un meilleur brouillon des le début… Mais bon c’est pas la première foisqu’on se rend compte que mettre la charrue avant les bœufs n’était pas l’idée du siècle…



Alors je comprends bien que le W3C avance de cette manière en adaptant le brouillon aux réalités des implémentation mais je pense qu’on aurait clairement pu avoir un meilleur cahier des charges dès le début pour le WebRTC. D’ailleurs au final le WebRTC 1.0 a évolué dans ce sens.



Enfin pour la SDP du WebRTC 1.0 et l’intérêt de l’ORTC (aka WebRTC 1.1) ce lien est pas mal :





programmableweb.com a écrit :



The key difference between the ORTC API and the WebRTC 1.0 API is that the ORTC API is a lower-level JavaScript API that provides the same components as the WebRTC 1.0 API while allowing greater flexibility than what is currently available in the WebRTC 1.0 SDP interface. Developers can use the ORTC API to implement advanced capabilities such as layered video coding, simulcast, scalable video coding (SVC), and more. These capabilities can also be implemented using SDP in WebRTC 1.0. However, WebRTC 1.0 communication capabilities can be more difficult for developers to implement. A JavaScript API like the ORTC API, provides greater access to more controls. In WebRTC 1.0, modifying the same controls would require browser source code changes. ORTC is also taking the approach of JavaScript shim libraries; for example, ORTC allows a JavaScript-based shim (“upshim”) to be built on top of ORTC.js which would provide the same functionality of WebRTC 1.0 APIs, including the RTCPeerConnection API. It should also be noted that ORTC APIs do not replace WebRTC 1.0 APIs, but rather augment the existing SDP APIs in WebRTC 1.0 which have been integrated into millions upon millions of devices.





Celui-ci aussi est intéressant ou encore celui-là.



Mais tu as raison laissons le temps au temps … Mais je serais prêts a parier que Edge supportera le WebRTC 1.0 avant que Mozilla ne supporte l’ORTC/WebRTC 1.1



Ah et à propos, contrairement à ce que peut croire freechelmi c’est pas MS qui a proposé l’ORTC … Et aujourd’hui Google est derrière l’ORTC aussi









arno53 a écrit :



Ce qui me dérange là dedans, c’est qu’on avait déjà commencer à coder un truc qui marchait comme ca dans le brouillon plutôt que réfléchir à un meilleur brouillon des le début… Mais bon c’est pas la première foisqu’on se rend compte que mettre la charrue avant les bœufs n’était pas l’idée du siècle…



&nbsp;

Enfin, il faut toujours un serveur pour savoir où joindre le client. Pour le web c’est le DNS, pour pour XMPP tu dois te connecter à ton serveur pour qu’il demande aux autres serveurs où est ton correspondant, dans IRC tu te connectes un serveur. Même SMTP utilise le DNS.&nbsp; Il n’y a bien que bittorent avec le DHT qui arrive à contourner un centre. Bref, je ne vois pas en quoi tu trouves WebRTC centralisé, alors que Skype, Facebook et Twitter le sont beaucoup plus (sans compter que leur code est fermé).



Les websocket c’était une version là encore brouillon, logique que l’on découvre une faille. Sinon tu vas dire que TLS est pourri car on a trouvé des failles (majoritairement du à la volonté des USA dans les années 90 d’affaiblir la techno)?

Bizarre maintenant, tous les navigateurs ont intégré cette technologie alors qu’elle n’est toujours pas finalisée:http://caniuse.com/#feat=websockets C’est juste de la responsabilité des développeurs web de ne pas mettre une technologie trop jeune dans leur site sans suivre son évolution.



Dans ton lien, je retrouve beaucoup des éléments de langage qu’utilise MS pour critiquer WebRTC. Peut-être que ces critiques sont pertinentes, peut-être pas (pas assez de connaissance pour y répondre). Je note juste que beaucoup critiquent la volonté de WebRTC de rester compatible avec l’héritage de SIP (sûrement l’influence de Cisco). Je serais mauvaise langue, je dirais que MS n’a rien à perdre de caser cette compatibilité et de mettre en avant une technologie qui pourra s’interphasé avec Skype dont le nom est mondialement connu. Bref, cela sent parfois un le FUD.



Pour finir sur Google, ils ont toujours été bizarre sur la communication vidéo. Ils ont appuyé XMPP et lancé Jingle puis retiré +/- XMPP (après avoir utilisé un vielle version d’XMPP et lancé WebRTC. Chez Google l’ouverture d’un protocole de communication vidéo/audio c’est un pas en avant, un pas en arrière.



Tu ne lis pas ce que j’écris :







Arno53 a écrit :



En janvier 2013. A cette époque Chrome et Firefox avait déjà implémenter les prémices du WebRTC enfin le brouillon de l’époque.



Et à cette époque le WebRTC c’était ca :



En effet, si WebRTC permet bien une vidéoconférence, c’est uniquement de manière centralisée, c’est-à-dire entre un navigateur et un serveur. En clair, si deux utilisateurs veulent communiquer, leurs deux serveurs doivent impérativement passer par un serveur central.







Il a fallu attendre février 2013(juste 1 mois après que MS pointe les faiblesses du brouillon de l’époque), pour qu’enfin on aie une communication direct de navigateur à navigateur (avec certes une initialisation avec un serveur tiers au début).



Donc je réitère on a commencer a coder un truc pas terrible alors qu’il a fallu juste 2 semaines de réflexion en plus sur le brouillon pour améliorer sensiblement la norme.



Donc là ca va car on a juste perdu 1 mois, mais coté SDP on est en train de perdre des années pour avoir voulu garder cette compatibilité avec cette héritage vieillissant….



L’ORTC c’est du low-level c’est le DirectX12 de la communication temps réel sur le web, le développeur à la main sur tout, c’est donc très flexible et on peut toujours créer un wrapper pour ceux qui veulent un truc plus simple (high-level)











programmableweb.com a écrit :



Developers can use the ORTC API to implement advanced capabilities such as layered video coding, simulcast, scalable video coding (SVC), and more. These capabilities can also be implemented using SDP in WebRTC 1.0. However, WebRTC 1.0 communication capabilities can be more difficult for developers to implement. A JavaScript API like the ORTC API, provides greater access to more controls. In WebRTC 1.0, modifying the same controls would require browser source code changes. ORTC is also taking the approach of JavaScript shim libraries; for example, ORTC allows a JavaScript-based shim (“upshim”) to be built on top of ORTC.js which would provide the same functionality of WebRTC 1.0 APIs, including the RTCPeerConnection API.







Fin bref si tu penses que l’ORTC est appelé le WebRTC 1.1 car c’est une régression vis-à-vis du WebRTC 1.0, libre à toi …