Journal Petit état de l'art de (quelques aspects de) la messagerie instantanée

Sommaire

• Évènements Fédératifs
• • Skype
  • AOL
• Jingle
• • L'implémentation numéro 1 : Google
  • • Voix et Vidéo
    • Transfert de Fichiers
    • Autres trolls
  • Qu'est-ce qui ne marche pas dans Jingle?
  • • Les codecs
  • La connectivité
  • Conversation audio/vidéo à plus de 2!
• Participez!
• • Participez à du développement logiciel
  • Améliorez les spécifications
  • Améliorez le réseau
  • Reportez les bugs

Salut le monde,

je vois, sur ce site, pas mal d'interrogations sur l'évolution de XMPP, de critiques, et de dénigrement. Je pense donc qu'il peut être utile de donner de temps en temps des petites nouvelles sur ce qu'il se passe en interne.

Évènements Fédératifs

Il y a dernièrement eu deux évènements impliquant de grands noms de la messagerie propriétaire.

Skype

Celui qui a le plus fait parler est le soit-disant support de XMPP dans Skype qui apparaît dans la prochaine bêta Windows. Mais alors que la source originelle (Skype Journal) laisse entendre que le réseau Skype est quasiment prêt à se connecter au réseau standard…

So, now that Skype has XMPP for polling/updating servers, it looks like Skype is almost ready to connect the Skype network to other IM networks.

… si — en suivant les liens — on se réfère à la note de version du produit, il me semble plus comprendre que, simplement, le client Skype est devenu multi-protocole pour suivre la tendance Facebook. Alors, si le client a effectivement intégré du code XMPP (puisque c'est le protocole utilisé par Facebook), ce code n'est que côté client, d'une part (il n'y a donc, d'annoncé officiellement par Microsoft Skype en tous cas, actuellement aucune interconnexion possible avec la Fédération IM), d'autre part, ils l'ont vraisemblablement bridé pour se connecter au serveur Facebook. Notez que je n'ai pas testé, déjà simplement parce que je n'ai pas de Windows. Mais la note de version ne semble vraiment rien dire d'autre que cela. Cela n'a donc simplement aucun intérêt pour moi : c'est du vent (au passage, qui montre la volonté de Microsoft de surfer sur la vague Facebook, donc d'accepter leur assise dans le monde du « réseau sociale »), comme tout ce qui touche ce monstre Facebook.

On note aussi le niveau d'information de ce "journaliste" du Skype Journal qui écrit que XMPP est le protocole utilisé par Yahoo! et Microsoft Live Messenger (pour ceux qui prennent l'information comme une grande nouvelle, je précise : c'est simplement faux) ou que c'est aussi le cas de la plupart des réseaux Jabber (il n'a donc apparemment pas compris que Jabber n'est qu'un synonyme historique de XMPP. Je sens les trolls venir sur le nom, mais sachez que je n'y répondrai plus).

AOL

Et là, si vous êtes perspicace, vous aurez remarqué que ce journaliste citait aussi AIM dans sa liste d'utilisateurs de XMPP mais que je ne l'ai pas relevé avec les deux autres. Car oui, là c'est le second évènement, et personnellement je l'ai trouvé beaucoup plus excitant. Pourtant à l'inverse celui-ci fut plutôt dénigré. Au contraire, je pense qu'il aurait été très intéressant que cet évènement fasse parler de lui car il était important qu'AOL voit que la communauté mondiale accueille leur avancée vers l'ouverture à bras ouverts, pour les y encourager.
Mais j'écris, j'écris… donc : AIM s'est rendu accessible par XMPP!

Bon passé le marketing à moitié vrai-faux, je refroidis les grosses joies.

1. Il ne s'agit que d'un s2s (serveur à serveur), ce qui signifie qu'en "interne" dans le réseau AIM, les communications sont pour l'instant toujours dans leur protocole propriétaire, mais dès qu'on sort du réseau interne, les communications sont converties en XMPP. Personnellement, je n'estime pas cela extrêmement ennuyeux, du moment qu'on peut contacter des utilisateurs AIM (et qu'eux peuvent nous contacter) sans avoir à créer de compte sur leur réseau privé. C'est de la vraie interopérabilité. Je pense aussi qu'avec le temps, ils verront qu'ils ne peuvent tenir sur les deux fronts à la fois, en maintenant constamment un protocole privé et un convertisseur vers le protocole standard. Mais c'est peut-être vœu pieu. On sait que les entreprises ne se rendent pas toujours compte de leur inefficacité rapidement.
2. Mais surtout dans les faits, ce n'est qu'un accord commercial entre Google et AOL (aussi annoncé ici, le jour de l'Open Discussion Day, soit le 19 mai, pas mal comme coïncidence!) pour l'instant. C'est-à-dire que seuls les utilisateurs de gtalk peuvent parler aux utilisateurs AIM.

Et là, vous vous dites "quelle escroquerie!". Mais là où l'espoir reste très bon est qu'il s'agit vraiment d'un serveur XMPP passerelle chez AOL. Gtalk et AIM ne communiquent pas par un protocole propriétaire tiers.

$ telnet xmpp.gxmpp.oscar.aol.com 5269

[j'envoie]

<?xml version='1.0'?>
<stream:stream
from='zemarmot.net'
to='aol.com'
version='1.0'
xml:lang='en'
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'>

[je reçois]

<?xml version='1.0' encoding='UTF-8'?> <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server' from='aol.com' id='4c672fc9' version='1.0'><stream:error><undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error></stream:stream>

Je suis rejeté simplement parce que je ne suis pas Google, mais il y a bien un serveur XMPP chez AOL.
Aussi des enregistrements DNS de service XMPP ont été enregistrés. Si le but était uniquement de se contenter d'un accord Google-AIM, il n'y aurait aucune raison de diffuser des enregistrements DNS publics:

$ ring -t SRV _xmpp-server._tcp.aol.com
aol.com. has a xmpp-server service record on tcp:
    priority  = 0
    weight = 1
    port = 5269
    target = xmpp.gxmpp.oscar.aol.com.

Apparemment les Google Apps ne sont pas encore supportés (d'après la documentation, mais j'ai remarqué que certaines documentations de service Google ne sont pas à jour, donc… à tester) mais ils disent "travailler pour que ce le soit". Et puisque les Google Apps sont n'importe quel nom de domaine, le jour où ce sera fait, ce sera peut-être parce qu'AIM sera totalement ouvert ! En tous cas, pour l'instant, je ne connais aucun autre serveur qui a un tel accord avec AIM, mais AOL a une courte page indiquant que cela peut être possible, et où ils disent surtout que "l'utilisation de la passerelle est actuellement limitée à des partenaires spécifiques" (traduction libre, et emphase de ma part).

Rappelons enfin que Google non plus n'avait pas ouvert ses propres serveurs avant 6 mois en réseau clos, et surtout que AIM a un historique très favorable.
Souvenez-vous, ce début 2008 où fut découvert par hasard un serveur XMPP de test que AOL faisait tourner. Ce serveur permettait aux utilisateurs de AIM de se connecter à leur compte AIM en utilisant des clients Jabber génériques. Ce serveur de test n'existe plus à ma connaissance (en tous cas, plus à la même adresse), mais cela augure un travail en cours dans le sens de l'ouverture (comme l'indique ce message du Lead Architect AOL à l'époque). Et surtout c'est donc la preuve d'une implémentation c2s (client à serveur) existante quelque part chez AOL!

Je vois bien plus de chance de voir AIM devenir la prochaine grosse addition à la fédération (tout est techniquement déjà là, ils n'ont qu'à faire sauter la liste blanche qui limite la connexion avec les serveurs google et c'est bon, ils sont fédérés). Mais forcément, comme certains nous le rappellent, c'est un réseau moribond (qui fut pourtant à une époque le plus gros réseau propriétaire) et donc n'intéresse plus personne. Mais moi — je suis peut-être le seul — je dis: AOL, si vous me lisez dans ce coin perdu de l'Internet francophone, continuez sur cette voie!

Jingle

Passons à tout autre chose. La fonctionnalité la plus attendue par les utilisateurs à l'heure actuelle, c'est Jingle! J'entends par là en particulier la Voix et Vidéo, et ce, fonctionnant presque dans tous les cas. Donc où en est-on ? Je lis de-ci de-là des approximations, donc voici les dernières nouvelles à peu près vraies.

L'implémentation numéro 1 : Google

Voix et Vidéo

Numéro 1 en âge et en utilisation en effet, puisqu'il s'agit de l'implémentation d'origine. J'ai lu beaucoup de bêtises sur Google qui ne voulait pas se mettre à jour, sur l'existence de plusieurs spécifications, etc. Bon pour finir toute polémique, pour ceux ne l'ayant pas lu dernièrement, Google a annoncé officiellement son support aux dernières spécifications Jingle (XEP-166 et XEP-167). Cette mise à jour concerne les appels par Gmail, iGoogle et Orkut, ainsi que la libjingle. Google Talk sur Android n'est pas encore mis à jour mais le sera bientôt, par contre ils ont annoncé qu'ils ne mettront pas à jour Google Talk Windows, poussant ainsi probablement dans le sens de leur politique actuelle "tout web" (en d'autres termes, le logiciel lourd sous Windows est mort).
Dans le même temps, ils conseillent aussi à tous ceux qui avaient intégré du code spécifique GoogleTalk dans leurs clients de le retirer et de passer à du code générique.

Pour le futur proche, leur travail en cours est sur ICE-UDP (XEP-0176) qui a pour but d'améliorer la traversée des NAT. Actuellement, pour dialoguer avec les serveurs Google avec ce transport, il faut se baser sur le brouillon 6 de ICE d'après l'ingénieur Google (Peter Thatcher), bien qu'évidemment je ne le conseille pas. Voyons long terme, Google travaille dessus, on peut donc espérer une mise à jour des clients pas si lointaine. Donc toutes les implémentations XMPP, si vous ne l'avez pas déjà fait, implémentez la version finalisée de ICE (ou utilisez une bibliothèque qui l'implémente) : RFC-5245.

Transfert de Fichiers

Pour les fichiers de transfert, vous serez déçu, Google n'a pas encore leur support aux dernières spécifications dans ses plans. Ils utilisent encore une ancienne version expérimentale (utilisant aussi Jingle, comme la spécification conseillée de nos jours, mais différemment). Mais je ne doute pas que cela arrivera. Simplement ce n'est clairement pas leur priorité devant la voix et vidéo. Ou bien, si leur solution s'avère bien meilleure, certains leur ont proposé de la mettre sur papier pour voir si le fichier de transfert par Jingle peut bénéficier davantage d'expérience Google (toujours pour traverser des NATs, mais cette fois en TCP, ou bien en UDP mais avec une couche de fiabilité).
En fait, il y a actuellement plusieurs solutions possibles dans les implémentations de Google eux-même - d'après l'ingénieur Google - que l'équipe prévoient de rajouter dans la libjingle un jour. Quoiqu'il en soit, on voit que le transfert de fichier a encore beaucoup de marge d'évolution, mais que ce n'est pas pour tout de suite.

Autres trolls

Dans les autres trolls lancés par Google, pour ceux leur disant qu'ils se font concurrence à eux-même avec WebRTC, ils répondent que non. WebRTC est un moyen d'inclure de la vidéo en streaming dans le navigateur et que ça peut tout à fait s'interfacer avec Jingle. C'est donc complémentaire. À vrai dire, Justin Uberti ("Technical Leader" de l'équipe XMPP chez Google) rappelle que c'est déjà ainsi que l'implémentation gmail marche actuellement.

Un autre ingénieur Google, ancien de l'équipe IM, explique son point de vue sur SIP : en quelques mots, c'est complexe, confus, une sécurité en bout de chandelle et une technique de fédération très bancale (qui nécessite plus les avocats des entreprises que les techniciens selon lui). Bon, je n'en dirai pas plus là-dessus, je n'ai aucune connaissance technique de SIP. En tous cas, Google semble faire leur choix. Comme ils le disent dans leur annonce "jingle, c'est le futur!"

Qu'est-ce qui ne marche pas dans Jingle?

Un non-développeur a lancé une autre discussion sur ce qui ne va pas dans Jingle.
De la discussion engendrée, 3 points peuvent en être synthétisés:

1. Des incompatibilités de codec;
2. Les problèmes de connexion (NAT, etc.), et donc la "nouveauté" des standards associés pour les passer (ICE, nodes, etc.), ce qui implique des manques dans les implémentations.
3. Des implémentations incomplètes, bugguées (je sens venir les trolls sur celle-là), ou utilisant des spécifications un peu anciennes car implémentées avant que les spécifications soient finalisées, comme par exemple lorsque Gtalk utilisait une trop vieille version de Jingle.

Les codecs

Le premier point est un énorme troll qui traîne depuis des années: faut-il un codec de référence, et si oui lequel ? Qu'est-ce qu'un bon codec de référence?

1. C'est déjà un codec sans brevet, licence ou autre épée de Damoclès. Cela retire H.264 pour la vidéo évidemment.
2. C'est un codec qui peut se trouver sur le plus (sinon toutes) plateformes possible.

Ce second point en particulier implique de nombreuses restrictions ; déjà, si possible, un codec dont le traitement ne prend pas trop de ressource. C'est en particulier vrai pour l'embarqué en général, et les téléphones ou autre tablettes notamment (surtout de nos jours). Au final, puisque personne ne voulait prendre une vraie décision et pour ne pas refaire les mêmes discussions encore et encore, j'ai pris sur moi de pousser le codec audio dont le consensus me paraissait le plus évident : G.711, existant sous 2 variantes (PCMU et PCMA) car :

1. Extrêmement simple à implémenter : on trouve des implémentations en quelques lignes dans de nombreux projets OpenSource.
2. Extrêmement vieux, et donc tout brevet logiciel qui a pu exister n'est plus.
3. Un point déterminant : il se trouve être le codec historique utilisé dans l'infrastructure téléphonique classique. Cela implique qu'il est implémenté sur toute passerelle de télécommunication (pour lier la VOIP et la téléphonie classique), sous l'une ou l'autre (voire les deux) forme(s) : PCMA (base de l'infrastructure Amérique du Nord-Japon) ou PCMU (reste du monde). Il semblerait que de nombreuses passerelles ne supportent rien d'autre que ces codecs d'ailleurs. En nous assurant que tous les clients supportent ces codecs, nous rendons ainsi tous les clients compatibles pour se brancher directement avec le réseau téléphonique.
4. Usage déjà très courant dans le monde XMPP : l'implémentation majeure Gtalk le supporte, ainsi que de nombreux autres clients.
5. Simple donc finalement est assez bon pour l'utilisation ressource, donc la batterie des machines.

Faisant ainsi le choix du support maximum en prenant le plus petit dénominateur commun, même si la qualité n'est pas extraordinaire (pensez "téléphone") comparé aux codecs récents comme Opus (qui est notre espoir audio du futur dans le domaine, développé notamment avec l'équipe Skype et Jean-Marc Valin, l'auteur de Speex, mais souffre d'incertitudes de brevets qui sont en règlement), il faut toutefois noter qu'une recommandation de codec n'a pas pour but de dire quel est le meilleur codec, mais quel est celui qui nous servira de fallback si un meilleur codec commun n'existe pas. En gros, on veut que toute implémentation ait toujours au moins un codec en commun.

Pour ceux qui se demandent : et Speex ? Il fait bien sûr parti de ceux que l'on a considérés, et a aussi une bonne infiltration dans le milieu. Il ne fut pas choisi, déjà comparé à l'infiltration de G.711 dans l'industrie télécom, ensuite parce qu'il est fait pour de la haute qualité et ne serait pas si efficace que cela au niveau utilisation ressource (ce qui pose problème pour l'embarqué), enfin parce que son propre auteur essaie de l'enterrer au profit du nouveau codec dans lequel il met toute l'expertise qu'il a eue avec Speex : OPUS.

Enfin pour la vidéo, je n'ai pas réussi à pousser de gagnant, déjà parce que la discussion a eu beaucoup plus de mal à se lancer (pour déceler un consensus), ensuite parce qu'il n'y a pas véritablement de vrai codec vidéo aussi parfait que ne l'était G.711. Il y avait bien H.261, vieux codec aussi, sans brevet par âge, et utilisé aussi dans l'industrie du téléphone (visio conf). Néanmoins, il semblerait que la qualité soit vraiment mauvaise et que ce ne soit pas si simple à implémenter, n'en faisant pas un équivalent réel. Notre meilleur espoir est de voir comment VP8 va démarrer dans le web et de s'en emparer ensuite.

En d'autres termes, voici nos deux espoirs dans le monde de l'IM : VP8 et OPUS.

La connectivité

En dehors de ICE-UDP dont je parlais, la technique de nœud de relai (qui peuvent être fournis par des serveurs, ou bien des clients peuvent eux-même se présenter comme des relais, permettant ainsi d'obtenir un système où notre liste de contact peut nous aider à faire passer nos appels quand nous sommes dans un environnement très fermé). L'idée est bonne mais, comme certains l'ont fait remarquer, il existe encore peu de serveur ou de client proposant de tels relais. Dans les faits, cela n'existe pas concrètement, en dehors du papier.

Le service jabber.org prévoit de mettre en place un tel nœud pour créer un précédent (non qu'il n'y en ait aucun, mais s'il y en a, ils sont bien cachés) et aussi montrer l'exemple.

Conversation audio/vidéo à plus de 2!

On n'a pas encore un noyau stable de la VOIP à deux, mais nombreux sont ceux qui poussent la gueulante sur le manque pour la conférence. Eh bien vous avez raison, il faut voir loin !

Malheureusement, il y a concurrence. C'est un sujet en ébullition qui génère de nombreuses discussions enflammées car il y a deux implémentations (basées sur Jingle évidemment) qui se font la guerre :

1. Coin, très récent, reprend des concepts du monde SIP et ne se base pas sur MUC (Multi User Chat, autrement dit les chatrooms^Wsalons). Le but est surtout de promouvoir l'interopérabilité avec les clients SIP pour pouvoir créer des conférences avec à la fois des utilisateurs SIPs et XMPP apparemment. C'est donc intéressant, mais l'architecture basée sur le vieux SIP ne semble pas plaire à tout le monde. Implémenté par le client Jitsi.
2. Muji, beaucoup plus ancien (autrefois appelé mingle), basé sur les MUCs et donc avec une vision probablement plus XMPP-centrée.

Je ne donnerai pas d'avis, je n'ai lu aucun des deux pour l'instant. Mais étant donné le ramdam créé récemment par l'arrivée de Coin (qui a réveillé Muji, plus mis à jour depuis 2009 et n'a jamais connu de moment de gloire ni d'implémentation en masse. Jingle à l'époque étant beaucoup plus bancal cependant, cela se comprend), il ne fait aucun doute que ce sujet va connaître du ménage et des combats mémorables dans les mois à venir.

Surtout que Google nous a annoncé, il y a 4 jours… qu'ils ont eux-même une troisième implémentation différente des 2 autres (utilisée notamment dans Google+), basée sur les MUC, Jingle, ICE et RTP! Badaboum! Peter Thatcher nous dit qu'il est en ce moment même en train d'écrire la documentation. Je pense qu'on aura cette nouvelle spécification devant les yeux très bientôt (avant la fin de l'été pour agrémenter nos longues soirées d'hiver en lecture ?).
Au passage, Peter nous fait son petit commentaire sur Muji, qui ouvre N^2 sessions Jingle (une entre chaque participant), ce qui n'est pas terrible quand le nombre de participants commence à grimper (comme il le dit, à 10 participants, 100 connexions ? Mise à l'échelle impossible).

A priori, ce serait plutôt N*(N+1)/2 (alors que Coin, c'est N-1), mais ça reste du teta(N**2) (on nous dit aussi que c'est la version actuelle mais que le design final de Muji serait bien plus efficace. En même temps, ils le peaufinent depuis 2009 ce design…).

Si je devais faire mon devin, je dirais que l'arrivée de la spécification de Google va mettre tout le monde "d'accord" (mais je peux me tromper, "devin" n'est pas ma profession première), car ils ont un argument de poids : le chiffre. Ils ont des utilisateurs (et pas qu'un peu) donc cela écrase tout, à côté de deux spécifications qui bataillent depuis un mois, dont une existe depuis deux ans sans prise réelle. On retrouve un peu la situation à l'arrivée de Jingle: quelques spécifications éparses pour faire de la vidéo, mais aucune n'arrivait à avoir le dessus et Jingle est arrivée avec sa masse utilisateur. Néanmoins rien n'est fini. Nous sommes un organisme de standard, toutes les spécifications seront lues et les choses qui devront être revues et modifiées le seront. C'est la règle du jeu.

Participez!

Je ne le dirai jamais assez : participez, s'il vous plaît ! Je vois énormément d'énergie gaspillée sur ce site à se plaindre. Alors, oui, la XSF n'est pas si bien organisée, je suis le premier à le dire. Mais aussi c'est parce que nous avons besoin de vous ! Comment participer ?

Participez à du développement logiciel

Les clients et serveurs ont une énorme marge de progression. N'hésitez pas à aider les projets que vous aimez.

Améliorez les spécifications

J'ai lu quantité de plaintes ici sur le fait que nos choix sont mauvais ! Mais sacré nom d'une Marmotte, que ne venez-vous pas nous le dire en face ? Si nous faisons une grossière erreur, c'est pas au mur à côté de vous qu'il faut le dire, mais à nous. Venez nous donner votre sagesse et votre science.
Cela ne s'adresse pas qu'aux plaintifs du coin. Je sais que de nombreux francophones développent du logiciel XMPP, mais nombre d'entre vous ne participez pas du tout au développement des spécifications. Alors, si vraiment vous croyez n'avoir rien à dire et vous trouvez tout parfait, et préférez nous laisser décider, je respecte. Mais est-ce vraiment le cas ? Ne voulez-vous améliorer certains points (il y a nombre de points à améliorer, mais on n'a pas assez de monde pour être sur tous les plans à la fois)? On n'attend que cela. Et ne pensez pas que vous n'avez pas les capacités de discuter spéc. Réfléchir des spécs, cela s'apprend, comme tout (pour la plupart d'entre vous en plus, vous avez déjà la compétence "gestion de troll").

Améliorez le réseau

Vous le voyez, les spécifications sont en mouvement constant. Ce qui importe le plus pour l'intéropérabilité en tant que simple utilisateur, c'est que vous participiez à un réseau stable, et pour cela, mettez à jour vos clients, vos serveurs. Jingle est extrèmement récent et par conséquent commence à peine à vraiment se stabiliser dans les implémentations (comme le montre Google récemment). Si vous ne mettez pas à jour vos clients, c'est évident que si tout le monde a une version plus ou moins expérimentale du protocole, cela marchera moyen.

Et si vous avez un serveur : installez un nœud Jingle dessus pour améliorer la connectivité générale du réseau. Si tous les petits serveurs ont un nœud Jingle, la connectivité fera soudain un bond, les clients implémenteront la gestion des nœuds relais bien plus vite, et la pénétration du standard IM s'accélérera car les utilisateurs diront "ah bah oui, ça marche".

Reportez les bugs

Alors oui y aura des bugs. La plupart de ces spécifications ne sont pas stables. Le but n'est pas d'installer un nouveau logiciel et de dire "ah bah voilà, je l'avais dit, cela ne marche pas", mais de remonter des bugs précis si possible (je ne dis pas de faire un ticket "ça marche pas", mais je sais que bcp ici ont des compétences d'analyse informatique un peu plus élevées que cela).
Aussi pareil Relay Nodes est récent, expérimental et virtuellement totalement inexistant actuellement. Il est un nouveau dans l'environnement IM. Donc si vous installez un serveur de relais, regardez vos logs, et reportez les bugs.

C'est à peu près tout. Désolé, c'est un peu long. J'espère que vous ne vous êtes pas trop ennuyé.