[Nÿco's blog] open standards & free/libre/opensource
XMPP/Jabber is coming back, and is here to stay!
L’ALDIL, Association Lyonnaise pour le Développement de l’Informatique Libre, LUG de Lyon, a publié les « fiches libres », des pages au format A4, à épingler dans son bureau ou à distribuer lors de toutes sortes de rencontres en tout genre. L’initiateur et leader du projet est Olivier Oriol. C’est très simple :
« Le principe fort est : 1 fiche, 1 sujet, 1 page. ».
Ces fiches éditées sous Scribus sont placées sous licence FDL, avec les illustrations concoctées sous GIMP et placées sous licence LAL de la copyleft_attitude.
Je vous encourage à les télécharger, les imprimer, les distribuer et/ou les afficher. Pour avoir épinglé quelques unes de ces fiches libres dans mon bureau au boulot, je peux dire que ça fonctionne plutôt pas mal : ça attire l’attention, attise la curiosité et ça fait (se) poser des questions.
Sur Jabber, il y a tout plein de sujets qui peuvent faire l’objet d’une fiche libre, j’ai donc brouillonné quelques textes, sur ma page perso. Je vous invite à les améliorer ou à les commenter, plutôt en public, dans les pages de discussion associées ou bien sur le salon xmpp:jabber@chat.jabberfr.org.
Voici donc « Histoire de Jabber » un premier PDF, issu de Scribus. Soyez indulgents, ce sont là mes premiers pas dans la PAO libre. Si d’ailleurs vous avez des remarques également sur les « best practices » en la matière, n’hésitez pas.
Voici le SlideCast de la présentation sur les clients Jabber menée par Walid Nouh et moi-même lors de la session « VoIP et IM » du salon Solutions Linux en février 2007.
Un SlideCast est une présentation sur le web, avec les slides et la voix. Celui-ci est au format Flash, désolé, c’est propriétaire. C’est hébergé sur SlideShare, Peter Saint Andre en a déjà parlé sur son blog.
L’enregistrement de nos voix est assez faible, désolé, on l’a fait rapidement avec les moyens du bord. Le résultat n’est pas très pro, mais il a le mérite d’être en ligne. La durée est de 35 minutes, mais vous pouvez sauter des slides, les plus soporifiques notamment. Le widget en-dessous de la présentation, une sorte de barre de progression avec des marques pour chaque passage de slide, donne beaucoup de renseignements quant au débit et à la répartition du temps passé sur chaque slide, ça ne pardonne pas ! ;-)
Très de clavardage, voici la prez :
Si vous voulez y accéder sur le site SlideShare ou la placer sur votre blog : http://www.slideshare.net/Nyco/clients-xmpp-sl07. Le format Flash ne permettant pas d’indexer le texte contenu, celui-ci est disponible juste en-dessous, en version brute. Sinon, il est toujours possible de télécharger la version PDF originale.
La préparation d’un SlideCast est assez facile : upload de la présentation sur SlideShare, enregistrement de la voix et upload du mp3 quelque part sur le web accessible, et synchronisation des deux à l’aide de l’outil de synchronisation en Flash, lui aussi.
Si vous voulez vous inscrire et partager vos slides sur SlideShare n’hésitez pas, c’est un bon moyen de diffusion d’information. Vous pouvez même rejoindre le groupe XMPP, Jabber, Jingle.
Les demandes de voix sur Jabber sont de plus en plus pressantes, mais on ne sait pas toujours de quoi il en retourne. Voici donc un modeste petit article pour dessiner un petit l’historique de Jingle, ce que c’est, ce que ce n’est pas, ainsi qu’un petit état des lieux.
La volonté de faire de la voix sur Jabber n’est pas nouvelle puisqu’elle date depuis les tout débuts de Jabber, en 1999, soit au moment même où certains systèmes et protocoles de messagerie instantanée propriétaires faisaient leur apparition. Et ce n’est pas à force de répéter et rabâcher sans cesse « on veut la VoIP sur Jabber ! » que ça va arriver tout seul, comme ça, en tombant du ciel, plouf ! Surtout lorsque c’est pour imiter les propriétaires… et sans contributions !
Il faut savoir et bien garder à l’esprit que le processus de fabrication d’un standard ouvert prend énormément de temps. D’une part car un consensus est toujours difficile à atteindre (ah ce genre humain !…), et d’autre part, car ce standard doit répondre à un maximum d’attentes et fonctionner, pas seulement théoriquement, dans des très nombreuses conditions.
Évidemment, il est bien plus aisé d’implémenter rapidement une petite fonction sur un périmètre réduit lorsqu’on détient le contrôle total sur le seul serveur et le seul client « officiel» de son petit réseau propriétaire et fermé. Il en va tout autrement dans un contexte global, celui de l’internet, de la pérennité, de l’ouverture, de l’interopérabilité, de la fiabilité et de l’évolutivité de ce standard.
En l’occurrence, il y a eu plusieurs tentatives par le passé de faire de la voix sur Jabber, dont une notamment, TINS, très proche de SIP, décrit dans la XEP-0111, XEP retirée en 2005… en faveur de Jingle, je ne ferai pas tenir le suspense plus longtemps. Ce protocole fut implémenté dans Jabbin 1.0, un fork de Psi. TINS était tout simplement difficile à intégrer à Jabber/XMPP, à cause de sa sémantique.
Le protocole standard ouvert H.323, puis son « successeur » SIP (approximation volontaire), ont été envisagés. SIP semble enfin le bon protocole qui a arraché le plus grand nombre de suffrages à ce jour, car il est adopté massivement par l’industrie des télécoms et l’informatique. Hélas, son plus grand défaut est quasiment rédhibitoire : il ne passe pas bien les NAT, on y reviendra.
Son extension SIMPLE pour la messagerie instantanée et la présence est hélas très complexe et assez faible au niveau de la présence. Déjà qu’un bon softphone SIP est difficile à implémenter, alors un logiciel à la fois client Jabber ET softphone SIP/SIMPLE, il est évident que c’est excessivement complexe, même si Gizmo Project (propriétaire), SIP Communicator et WengoPhone y réussissent avec plus ou moins de bonheur. Ekiga et Twinkle font très bien l’affaire en tant que softphones SIP.
Donc Jingle a été créé. Plus précisément, Google a créé Jingle pour Google Talk, son service et client de messagerie instantanée et de présence, ET de voix sur IP… de bonne qualité. Ce service, tout le monde le sait, est basé sur le standard ouvert Jabber/XMPP.
Jingle a été créé en secret et a été dévoilé en été 2005. Google s’était tout de suite engagé à ouvrir cette extension de VoIP, et l’a fait dans les mois qui ont suivi en publiant ses spécifications ainsi que la bibliothèque libre libjingle. Des travaux avaient déjà commencé en ce sens, les deux initiatives se sont rejointes, et la spécification de Jingle a tout de suite été prise en charge par la XSF (XMPP Standards Foundation), afin de la disséquer, l’éprouver, la confronter au vrai monde la vie réelle, pour finalement arriver à en faire un standard ouvert généralisé d’initialisation de sessions multimédia.
Il est vrai que tant qu’à faire, pourquoi limiter Jingle à la seule voix, alors qu’avec un protocole de signalisation, on peut avoir la vidéo également, mais aussi au transfert de fichiers, le bureau à distance, les applications collaboratives quasi-temps-réel, les jeux en ligne, et toute application utilisant des flux binaires… le tout se reposant sur l’infrastructure Jabber : identification, authentification, présence, services, chiffrement, décentralisation, instantanéité…
J’avais dit plus haut que j’y reviendrais… Les NAT, c’est la peste d’IPv4 : ils empêchent de nombreuses communications de s’établir tranquillement, de par leur typologie et leurs implémentations. Des techniques pour passer ces NAT existent mais ne résolvent pas tous les problèmes, et surtout apportent diverses solutions complexes, incomplètes et hétérogènes. STUN et TURN sont sans aucun doute les deux exemples les plus populaires, issus du BEHAVE charter de l’IETF, mais nécessitant le déploiement de serveurs spécifiques. Il existe des clients, bibliothèques et serveurs STUN et TURN libres/opensource ou propriétaires.
ICE a donc été créé : il s’agit d’une méthodologie du MMUSIC charter de l’IETF créée pour SIP (et Jingle) afin que ceux-ci puissent traverser les NAT à l’aide de ces techniques précédemment citées. ICE est en cours de finalisation du côté de l’IETF, il devrait être validé ces semaines ou mois prochains, et il est déjà adopté par l’industrie. Ce qu’il faut savoir, c’est que ICE va permettre de passer 90 à 100 % des NAT déployés sur la planète… au prix d’une complexité encore plus grande.
Si vous n’avez pas compris ce passage, ce qu’il faut retenir, c’est que de nombreux problèmes de VoIP dus au réseau vont être très prochainement résolus… mais pas facilement.
Un client Jabber implémentant Jingle procédera donc ainsi pour initier une conversation audio ou plus généralement une session multimédia avec un autre client Jabber/Jingle :
La négociation des paramètres de sessions se fait bien entendu sur XMPP.
Comme c’est déjà le cas sur Jabber/XMPP avec les passerelles, ou plutôt les « transports », mais aussi avec la RFC de mapping bidirectionnel basique entre XMPP et SIMPLE, la XSF a l’habitude de traiter les problématiques d’interopérabilité, ça fait partie intégrante de son coeur de métier. La volonté initiale n’était donc pas de réinventer la poudre, mais bien d’ouvrir XMPP à la téléphonie, de lui offrir un protocole natif de signalisation, d’ajouter les utilisateurs de Jabber aux réseaux standards ouverts de téléphonie.
Voici donc les XEP liées à Jingle en cours de travail et de finalisation, à destination des implémenteurs :
D’autres sont sans aucun doute à venir, et vous pouvez bien évidemment proposer les vôtres.
Diverses implémentations existent à ce jour, mais forcément toutes sont qualifiables d’expérimentales puisque les spécifications de Jingle et de ICE ne sont pas finalisées.
On retrouve Jingle dans les bibliothèques libjingle, Smack et libDingaling, dans les frameworks Telepathy et Tapioca, on a aussi des services comme jabphone et GTalk2VoIP, le serveur Openfire et puis bien entendu les clients comme Coccinella, Psi, Gajim, Jabbin, Kopete, Landell, Spark, le client Jabber de Maemo, et aussi toutes les implémentations qui se font encore discrètes…
Cet article est une traduction de « All About PubSub », écrit Gaston Dombiak et Matt Tucker, publié le 17 avril 2006. avec leur autorisation.
Publish-subscribe (pubsub) est une puissante extension au protocole XMPP. Il peut être vu comme le RSS de la messagerie instantanée ; les utilisateurs souscrivent à un élément et reçoivent les notifications lorsque celui-ci est mis à jour. Le principe général de la notification sur lequel se base le procotole peut être trouvé à sur le web.
Quelques exemples :
Dans cet article, nous couvrirons le protocole pubsub en détail puis discuterons de ses applications possibles.
Collection et noeuds racine (image)
La spécification pubsub est définie par la XEP-0060 et est pleinement implémentée dans Wildfire 2.6 et supérieure. Les objets primaires dans un service pubsub sont appelés « noeuds », auxquels les utilisateurs souscrivent et et sur lesquels ils publient. Les noeuds sont hiérarchiques (structure en arbre) et ont deux types :
Lorsqu’un utilisateur souscrit à un noeud, ce noeud est soit :
Le diagramme de droite montre à la fois des noeuds et des feuille. Il y a toujours un noeud racine. Dans ce cas, nous avons des noeuds enfants « musique » et « films ». Le noeud musique contient les groupes « cure » et « depeche mode ».
Pubsub fournit un cadre riche de permissions. Les noeuds peuvent avoir différents modèles d’accès et de publication. Un modèle d’accès définit qui est autorisé à souscrire et récupérer les éléments tandis qu’un modèle de publication définit qui est autorisé à publier des éléments sur le noeud.
Les options de modèles d’accès sont :
Les options du modèle de publication sont :
Lorsqu’un utilisateur souscrit à un noeud, il spécifie la configuration de la souscription. Les informations de configuration peuvent inclure une date d’expiration, des mots-clefs qui vont être utilisés pour filtrer les notifications ou des préférences sur la date de livraison des notifications. En utilisant l’exemple de modèle pubsub du dessus, un utilisateur pourrait souscrire à tous les évènements de « depeche mode » sur un mois, avec un filtre sur le mot-clef « shows ».
Les utilisateurs peuvent souscrire plusieurs fois à un noeud. Chaque souscription à un noeud peut avoir des informations de configuration différentes telles que le filtrage par mots-clefs et des préférences de notifications. Lorsque l’utilisateur a souscrit plusieurs fois, alors le service pubsub va envoyer une seule notification vers l’utilisateur si plusieurs souscriptions ont été affectées pas le même élément publié. Cette optimisation minimise l’impact de trop nombreux souscripteurs avec plusieurs notifications sur le même élément publié.
Une fois qu’un utilisateur a demandé une souscription à un noeud, la nouvelle souscription est sujette au modèle d’accès mentionné au-dessus. Si le noeud utilise le modèle de permission « autorise », alors les propriétaires du noeud vont recevoir un message demandant d’approuver la nouvelle demande de souscription. Les propriétaires de noeuds peuvent aussi récupérer la liste complète des demandes de souscriptions n’importe quand. Les utilisateurs ne recevront pas les notifications du noeud tant que la souscription n’est pas approuvée. Une fois que l’approbation est donnée, la souscription devient « active » et les utilisateurs vont recevoir les éléments les plus récemment publiés mais aussi les éléments qui seront publiés plus tard.
Propriétaires et souscripteurs (image)
Le diagramme au-dessus montre l’exemple précédent de service pubsub, mais avec un propriétaire et un souscripteur. L’utilisateur Joe détient tous les noeuds musique. Sally a souscrit à Depeche Mode et attend que sa souscription au noeud film soit approuvée.
Publication (image)
Chaque fois qu’un évènement est publié, il contient zéro, un ou plusieurs éléments. Chaque élément peut optionnellement contenir une charge (données). Pour continuer notre exemple, Joe veut publier l’agenda des prochains concerts de Depeche Mode. Chaque représentation pourrait être représentée par un élément individuel, avec les détails de l’information inclus dans la charge de chaque élément.
Les souscripteurs ont aussi la possibilité de demander au service la liste des éléments publiés n’importe quand. En d’autres termes, pubsub prend en charge l’envoi ciblé (« push ») et la demande (« pull ») dans la notification d’évènements.
Nous avons couvert les bases du protocole pubsub et comment il peut être utilisé en tant que service de publication et de souscription. Mais pubsub ne sert pas seulement aux notifications d’évènements ; le framework est assez puissant pour prendre en charge un certain nombre de cas d’usages de collaboration intéressants&nsbp;:
Avez-vous votre propre idée sur la manière dont pubsub pourrait être utilisé ? Nous vous attendons de pied ferme !
[Nÿco's blog] open standards & free/libre/opensource 