Jingle, la voix et les sessions multimédia sur Jabber

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 voix… depuis longtemps !

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 !

Les standards

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.

Jingle baby !

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.

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é…

NAT

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.

La « procédure » Jingle

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 :

• tentative de connexion directe : elle fonctionnera sur un réseau local
• en cas d’échec, tentative de connexion via NAT : ICE
• en cas de double échec, passage de tout le flux binaire par un proxy, coûteux en bande passante pour le fournisseur de ce service

La négociation des paramètres de sessions se fait bien entendu sur XMPP.

Interopérabilité

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.

XEP : XMPP Extension Protocol

Voici donc les XEP liées à Jingle en cours de travail et de finalisation, à destination des implémenteurs :

• XEP-0166 Jingle
• XEP-0167 Jingle Audio via RTP
• XEP-0176 Jingle ICE Transport
• XEP-0177 Jingle Raw UDP Transport
• XEP-0180 Jingle Video via RTP
• XEP-0181 Jingle DTMF
• XEP-0208 Bootstrapping Implementation of Jingle (Informational)
• XEP-0215 STUN Server Discovery for Jingle

D’autres sont sans aucun doute à venir, et vous pouvez bien évidemment proposer les vôtres.

Implémentations

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…

En guise de synthèse

• Jingle arrive
• Les spécifications Jingle sont en cours de finalisation
• Les spécifications de ICE sont en cours de finalisation
• Les implémentations ont déjà commencé
• Vous pouvez contribuer (code, doc, tests, etc.)