Déployer une réelle alternative à Skype dans nos universités en utilisant des outils libres et standardisés

Transcription

1 Déployer une réelle alternative à Skype dans nos universités en utilisant des outils libres et standardisés Emil Ivov Jitsi / BlueJimp emcho@jitsi.org Guillaume Schreiner Université de Strasbourg, Direction informatique schreiner@unistra.fr Philippe Portelli Université de Strasbourg, Direction des usages du numérique philippe.portelli@unistra.fr Résumé Aujourd'hui, l'utilisation de Skype est déconseillée dans nos établissements et laboratoires. Dans la réalité, cette directive du Ministère de l Enseignement et la Recherche est rarement appliquée et nombreux sont les utilisateurs de ce produit pour une raison simple : le manque d'alternatives. Cependant, une réelle solution, basée sur des outils libres et standardisés, est possible et relativement simple à réaliser dans la plupart des universités françaises. Sur cette idée, l'université de Strasbourg (UdS) a lancé un projet ayant pour but de fournir un service de messagerie instantanée et de visioconférence à destination de l ensemble des étudiants, enseignants chercheurs et administratifs. Cet article décrit en détails les différentes améliorations apportées au logiciel de messagerie instantanée Jitsi et son intégration au système d'information de l UdS. Nous aborderons ensuite l infrastructure composant le service qui utilise les serveurs Openfire, TurnServer, JingleNodes, Freeswitch ainsi que leur intégration respectant les contraintes de haute disponibilité. Enfin, nous présenterons les différents services que ce projet propose à nos utilisateurs. Mots clefs VoIP, visio-conférence, messagerie instantanée, SIP, IPv6 1 Introduction Aujourd'hui, l'utilisation de Skype est interdite ou fortement déconseillée dans la plupart des établissements publics en France. Les raisons sont nombreuses et variées, allant des risques de sécurité et d espionnage industriel à la surconsommation de bande passante. Néanmoins, dans la réalité, ces conseils sont rarement appliqués et nous continuons tous à nous servir de Skype pour une raison principale : le manque d'alternatives. En effet, peu d'applications aujourd'hui regroupent les mêmes avantages : gratuit à l'utilisation appels audio et vidéo de bonne qualité conférences support des principaux systèmes d exploitation (Windows, Mac OS X et Linux) 12/10/2011 1/14 JRES 2011

2 sécurité: des appels chiffrés [particulièrement important] une large communauté d'utilisateurs, facilitant son adoption facilité d utilisation Ces caractéristiques ont rendu Skype indispensable pour la plupart des collaborations qui ont lieu dans les universités et les laboratoires ainsi que pour des conversations personnelles. Cependant, une vraie alternative basée sur des outils libres est beaucoup plus réaliste que beaucoup ne l imaginent. Dans le cadre du schéma directeur numérique de l'établissement, l'université de Strasbourg (UdS) a démarré en 2011 un projet ambitieux dont le but est de fournir une alternative concrète pour l ensemble des étudiants, enseignants chercheurs et administratifs. Du côté de l université, l'effort est à l initiative de la Direction des Usages du Numérique avec le soutien de la Direction Informatique. Le projet se fait en étroite collaboration avec la société BlueJimp : principal contributeur au projet open source Jitsi (précédemment nommé SIP Communicator). Le projet de l université est basé principalement sur l'utilisation du protocole XMPP. Cela peut paraître surprenant pour beaucoup des habitués de la voix sur IP car habituellement ce genre de service est fourni par le protocole SIP. Malheureusement, malgré sa fiabilité démontrée dans le domaine de la téléphonie, SIP a échoué en tant que solution viable de présence et de messagerie instantanée. Les raisons sont diverses et nous allons les détailler dans le document complet. Il en résulte que les implémentations actuelles des serveurs et clients SIP manquent de fonctionnalités basiques comme l'utilisation d'avatars, le transfert de fichiers ou simplement la présence et la sauvegarde centralisée des listes de contacts. Conçu en 1999, XMPP intègre ces fonctionnalités depuis ses toutes premières versions. Il ne lui manquait alors que les extensions lui permettant de gérer des appels audio/vidéo. En 2007, peu après la sortie du service GTalk, Google et la XMPP Standards Foundation créent ensemble Jingle qui résout ce problème. Même si sémantiquement Jingle est fortement inspiré de SIP, il a l'avantage d avoir intégré dès sa conception certains points dont SIP ne disposait pas au départ. L'utilisation native de ICE par exemple (expliqué plus bas) rend les déploiements de XMPP beaucoup plus scalables et mieux adaptés à l'internet d'aujourd'hui. Plus important encore, XMPP dispose d'un modèle beaucoup plus sécurisé de fédération. Contrairement à SIP, la plupart des serveurs XMPP sont capables de communiquer les uns avec les autres. Les utilisateurs du déploiement XMPP à l'université de Strasbourg pourront communiquer aussi bien entre eux qu'avec des abonnés de jabber.org et même, et c'est certainement le plus intéressant, avec Gmail, dont la communauté est comparable à celle de Skype. La dernière composante de l'équation est l'existence d'un logiciel qui permettrait des conversations d'une haute qualité avec le protocole XMPP. Il y a encore quelques mois ce problème n avait que peu de solutions. Fin 2010, le projet Jitsi a annoncé le support des appels audio/vidéo avec Jingle sur Microsoft Windows, Linux et Mac OS X, avec également des fonctionnalités avancées telles que l'annulation d écho, les codecs large bande et les conférences. Il ne restait plus qu'à mettre le tout ensemble. Dans cet article, nous allons nous attacher à décrire les développements et les déploiements effectués dans le cadre du projet. Plus particulièrement, nous allons nous arrêter sur les points suivants : Les composantes utilisées dans le déploiement serveur XMPP, STUN/TURN et JingleNodes. Nous allons décrire chacune de ses applications ainsi que les raisons pour lesquelles elles ont été choisies. Le développement de l'interopérabilité des appels entre GTalk et Jitsi. Comme nous l avons déjà précisé, l ouverture de la solution vers une grande communauté d interlocuteurs potentiels a été considérée comme particulièrement importante. Pouvoir discuter avec les abonnés de Gmail était donc crucial. Malgré l utilisation de XMPP et l implication de Google dans la standardisation de Jingle, l extension utilisée par GTalk pour les conversations était assez différente. Nous allons expliquer ces différences et notre solution. 12/10/2011 2/14 JRES 2011

3 Gestion des NATs et interopérabilité IPv4/IPv6. Même si la grande majorité des machines dans les réseaux de l UdS disposent d adresses IPv4 publiques, le service et l application devaient absolument continuer à fonctionner depuis n importe quel réseau. Nous allons expliquer les techniques de traversée des NATs qui ont été déployées à la fois du coté des serveurs mais aussi dans l application. L'intégration dans les infrastructures existantes et la réutilisation des comptes ENT/LDAP. Lors de chaque déploiement d une nouvelle application ou service, la question de l'intégration avec l infrastructure existante se pose. Nous allons présenter les solutions retenues pour pouvoir permettre la réutilisation des comptes et l'accès aux annuaires existants. La gestion de la sécurité et de la confidentialité. Toutes les conversations menées entre les utilisateurs du service sont chiffrées et protégées contre les attaques de type Man In the Middle. Nous allons donc présenter brièvement le mécanisme utilisé pour préserver la confidentialité. L'interconnexion avec les réseaux téléphoniques. Il est possible pour les utilisateurs du nouveau service de passer également des appels vers les postes du réseau téléphonique de l'université. C est d ailleurs le seul endroit où l utilisation de SIP a été nécessaire et souhaitons également aborder la manière dont XMPP et SIP ont été utilisés en parallèle. Note: Dans l édition 2007 des JRES[1], nous avions fait une première présentation du projet SIP Communicator (parent de Jitsi). Cet article représente donc une suite logique ainsi que l'inscription du projet dans un contexte réel d'utilisation. 2 Rappels protocolaires Avant de passer à la description des différentes solutions et les composantes de l'infrastructure, voici un rappel des différents protocoles mis en œuvre. 2.1 XMPP Dans le contexte du projet, XMPP [2] (Extensible Messaging and Presence Protocol) est la pierre angulaire protocolaire. Créé en 1999 sous le nom Jabber, le nom XMPP viendra quelques années plus tard. Initialement, le protocole se focalise sur la présence et la messagerie instantanée. Contrairement aux solutions populaires de l époque, telles que ICQ ou Yahoo! Messenger, Jabber a depuis ses premières versions été conçu pour fonctionner dans un contexte multi-domaine. Comme pour le mail, chaque utilisateur est associé à un domaine administratif sans que cela n empêche les communications avec le reste du monde. Autrement dit, quand Alice est connectée à un serveur du domaine example.com, elle peut communiquer avec Bob même si celui-ci est connecté à un serveur du domaine exemple.fr d'un autre fournisseur. Dans le jargon du milieu, cette connexion inter-domaine est souvent appelée «fédération» et, comme avec la messagerie électronique, elle passe par l utilisation d identifiant type URI comme xmpp:alice@example.com et xmpp:bob@exemple.fr (Figure 1). Figure 1: Topologie XMPP Contrairement à SMTP, la communauté de XMPP a proposé un modèle de sécurité assez robuste dès son déploiement. En effet le protocole impose à chaque serveur, l utilisation de TLS et de certificats SSL, ce qui réduit largement le risque d utilisations abusives telles que le SPAM. Pendant les années 2000, les adoptions industrielles ne cessent de se multiplier. L'exemple le plus connu est celui de Google avec le service GoogleTalk [3]. Peu après le lancement initial du service en 2005, Google y ajoute le support des appels audio/vidéo. Les extensions permettant cette fonctionnalité, appelées Jingle, sont ensuite rendues publiques par Google qui continue de travailler 12/10/2011 3/14 JRES 2011

4 dessus en collaboration avec la XMPP Standards Foundation (XSF). En 2009, une première version standardisée de Jingle [4] est publiée par la XSF. XMPP dispose désormais d une palette complète d'outils pour les communications temps réel. Malgré la participation très active de Google dans le processus de standardisation de Jingle, les services GoogleTalk continuent d utiliser la version initiale du protocole créé par Google en Cette version est par la suite devenue incompatible avec les nouveaux standards développés dans le cadre de la XSF. Il en est de même pour les fonctionnalités d appels vidéo intégrés à Gmail. L entreprise a récemment communiqué ses intentions de mettre à jour ses implémentations et a déjà même fait quelques pas dans cette direction. En attendant, les utilisateurs du services GTalk restent joignables uniquement par le biais de cette première version du protocole. Pour des raisons de clarté, nous allons appeler Gingle, la version Google des extensions Jingle pendant le reste de cet article. Ce terme non officiel est souvent utilisé lors des discussions techniques sur ce sujet. 2.2 Et SIP alors? Depuis une dizaine d années, SIP [5] (Session Initiation Protocol) connait un énorme succès en téléphonie sur IP et est très souvent choisi pour les nouveaux déploiements. Divers groupes de travail ont défini dans le cadre de l'ietf des RFCs décrivant la manière d'utiliser SIP allant des fonctionnalités standards jusqu'à la structuration d'architectures réseaux de type IMS (IP Multimedia Subsystem). Une partie de ce travail a été aussi orientée vers l'utilisation de SIP pour la présence et la messagerie instantanée. Du point de vue sémantique, SIP dispose en effet des mécanismes nécessaires pour une alternative à Skype. Pourquoi ne pas le choisir alors comme protocole principal? La réponse se situe d'une part dans les implémentations et d'autre part dans le protocole lui-même. Ces dernières années, SIP a surtout été utilisé pour des déploiements dont le but est de remplacer et d'améliorer les installations de téléphonies existantes. Il est donc beaucoup plus important pour un équipementier ou un éditeur de logiciel SIP de concentrer ses efforts sur le support de fonctionnalités classiques (boites vocales, les postes de standardistes ou les passerelles SS7) plutôt que sur des fonctionnalités nouvelles (présence, le transfert de fichiers ou des listes de contacts sauvegardées sur un serveur). De plus, les mécanismes qui implémentent ces nouvelles fonctionnalités pour les applications SIP sont complexes. Pour sauvegarder ou récupérer une liste de contacts, une application SIP devrait supporter un protocole complémentaire appelé XCAP basé sur HTTP. Pour envoyer des messages textes ou échanger des fichiers, l'ietf recommande l'utilisation d'un autre protocole complémentaire appelé MSRP. Bien évidement, aucune de ces raisons ne représentent un problème insurmontable mais elles expliquent en partie l'absence de ces nouvelles fonctionnalités dans les produits SIP actuels. Dans le cadre du projet, SIP ne joue au final qu'un rôle très limité, servant uniquement à relier l'infrastructure XMPP aux passerelles téléphoniques déjà utilisées par l'université de Strasbourg et autorisant ainsi les appels vers les postes classiques pour les utilisateurs du service. Nous détaillerons ce point dans la partie 4 Infrastructures du service. 2.3 La traversée des NATs Les protocoles SIP et XMPP utilisent un modèle trapézoïdal de communication entre deux utilisateurs. Chaque utilisateur est connecté au serveur responsable pour son domaine (voir la Figure 2). Figure 2: Trapèze SIP/XMPP 12/10/2011 4/14 JRES 2011

5 Les messages de signalisation, comme l'initiation, la modification ou la terminaison des appels, traversent ces serveurs. Le gros du trafic par contre, celui transportant les données audio ou vidéo, est sensé circuler directement entre les parties communicantes. Le but est d éviter une infrastructure lourde relayant les communications afin d'obtenir un service peu couteux. Pour y arriver, le protocole SIP demande aux agents utilisateurs (matériels ou logiciels) de s'échanger leurs adresses IPs respectives et de les utiliser ensuite pour l'envoi des flux média. Ce modèle s'est très vite avéré incompatible avec la réalité en raison du déploiement grandissant des boitiers de translation d'adresses : les NATs. Durant les dix dernières années, l'industrie et la recherche ont proposé de multiples mécanismes visant à contourner ce problème Les solutions efficaces mais peu fiables: STUN, UPnP, IPv6 Une première solution de contournement est l'utilisation des protocoles de détection ou de manipulation des NATs comme STUN [6] ou UPnP [7]. Même si ces protocoles peuvent être assez efficaces, c.-à-d. ils permettent l'établissement de flux média directs entre des clients derrière un NAT, ils s'avèrent souvent peu fiables selon les types de NAT ou la localisation topologique des clients. Il en est de même pour le protocole IPv6 qui fournit une IP publique à chaque utilisateur autorisant de facto les communications point à point. Si certains utilisateurs bénéficient déjà d'ipv6, la majorité n'en dispose pas et les tendances montrent que IPv4 va certainement rester la seule option pour de nombreux utilisateurs pendant une période relativement longue Les solutions fiables mais peu efficaces: Latching, TURN, JingleNodes Aujourd'hui, la majorité des déploiements de VoIP gère les traversées des NATs en relayant la totalité des conversations par leurs infrastructures de cœur. Cette solution est aussi fiable qu'on peut l'espérer : les serveurs relais, situés le plus souvent sur l'internet public, vont toujours recevoir les paquets envoyés par les utilisateurs et leur répondre ensuite en utilisant les sessions déjà créées dans les NATs (tout comme un navigateur contactant un serveur web depuis un réseau privé). Différentes sortes de mécanismes existent pour assurer ce relayage. Le plus utilisé, le «latching», est entièrement géré par les serveurs qui se contentent de substituer les adresses IPs envoyées par les clients par des adresses gérées par les serveurs. Des protocoles comme TURN [8] ou JingleNodes [9] permettent essentiellement la même chose avec pour seule différence que le client demande explicitement au serveur d'assurer le relayage. Cette différence qui peut paraitre anodine s'avère essentielle, nous l'expliquerons par la suite. Le rôle de TURN ou JingleNodes est essentiellement de permettre aux clients de demander l'allocation de ports dédiés sur l'interface du serveur relais. Ces ports peuvent ensuite être annoncés par les clients à leurs interlocuteurs. Tout le trafic reçu par le serveur relais sur un port donné est automatiquement redirigé vers le bon client. La différence principale entre les deux protocoles réside dans la demande d'allocation de ports. TURN, extension de STUN, fonctionne indépendamment du protocole de signalisation et peut être utilisé aussi bien avec SIP qu'avec XMPP. Avec JingleNodes, extension du protocole XMPP, le client envoie ses requêtes de réservation de ports vers son serveur XMPP qui se charge lui-même de contacter le relais ( Figure 3). Cette dernière solution de traversée des NATs basée entièrement sur XMPP a été retenue par l Université de Strasbourg. Figure 3: Allocation de port avec TURN et JingleNodes 12/10/2011 5/14 JRES 2011

6 Bien évidement la fiabilité du relayage a un prix et la mise a l échelle devient très difficile pour les déploiements qui desservent un grand nombre d utilisateurs. Ceci est d'autant plus vrai quand on a pour vocation de permettre non seulement des appels audio simples mais aussi des visio-conférences de bonne qualité. Autrement dit, si le trapézoïde de la téléphonique sur IP sépare les données de la signalisation c était bien pour éviter de surcharger le cœur du réseau Un juste milieu : ICE Le protocole ICE [10] (Interactive Connectivity Establishment) propose, comme son nom l'indique, l établissement de connexions de bout en bout et de manière interactive. L idée est assez simple: avant de commencer une session, chaque utilisateur recense toutes les adresses qui pourraient lui permettre de communiquer avec son interlocuteur. Ceci comprend évidement toutes les adresses IPs présentes directement sur la machine (IPv4, IPv6, VPN, Mobile IP ou autre) ainsi que toutes celles qu'il a pu obtenir sur son NAT ou un serveur relais : STUN, UPnP, JingleNodes ou TURN. Toutes ces adresses sont ensuite échangées entre les deux correspondants au lancement de l'appel. Ils effectuent rapidement une série de tests qui permettent de déterminer quels sont les couples d'adresses où la communication est possible et de retenir le couple le plus intéressant. La force d'ice vient justement de la possibilité de trier les adresses par ordre de préférence et de toujours essayer d'utiliser les plus efficaces en premier. De cette manière, les conversations seront relayées, avec TURN ou JingleNodes, uniquement quand une communication directe n'est pas possible 2.4 Sécurité et chiffrement des appels avec ZRTP Il est évident que la confidentialité et la protection de la vie privée sont des sujets qui concernent fortement la communication temps réel. Ces besoins sont encore plus forts dans le monde de la recherche comme l'uds. Pour rappel, c'est justement cette confidentialité, ou plutôt son absence, qui a été jugée inquiétante par le ministère de la Défense et celui de l'enseignement Supérieur et de la Recherche. On constate facilement que la sécurité n'a pas toujours été le point fort de la communication sur IP. Beaucoup de déploiements de VoIP par exemple n'utilisent aucun moyen de protection que ce soit pour les données de signalisation ou les flux audio/vidéo. Encore une fois les raisons sont de nature plutôt pratique que protocolaire. Depuis plusieurs années, le protocole RTP, utilisé pour le transfert média par la quasi totalité des applications de communication, est complété par sa variante sécurisée : SRTP. SRTP définit le transport chiffré des flux RTP. Par contre, SRTP ne gère ni les mécanismes nécessaires au choix de l'algorithme de chiffrement, ni la négociation des clés de chiffrement entre les correspondants. Afin de résoudre ce problème, on distingue trois solutions majeures utilisées aujourd'hui, sans compter les réseaux VPN dédiés à la téléphonie bien peu pratiques pour un déploiement à grande échelle. La première solution, dont la forme la plus populaire est SDES [11], consiste à échanger dans les flux de signalisation une clé symétrique qui sera utilisée par les deux parties pour le chiffrement et le déchiffrement des données média. Pour offrir une protection quelconque, ce mécanisme doit être utilisé uniquement dans des cas où les flux de signalisation sont eux même protégés, par exemple par TLS. Même dans ce cas, un utilisateur n'a aucune garantie que son appel soit protégé de bout en bout. S'il est sûr d'envoyer des données chiffrées, il est tout à fait possible pour l hébergeur du serveur de signalisation d'intercepter ces données, de les utiliser lui-même ou de les retransmettre de manière non sécurisée vers le correspondant. Autrement dit, SDES ne garantit pas à qui on envoie les données. La deuxième solution repose sur l'utilisation de certificats par les participants de l'appel. Le protocole [12] de l'ietf, définit une manière d'y arriver. Avec MIKEY, nous avons effectivement la possibilité de garantir l identité de celui qui reçoit nos données et de nous assurer que personne n'intercepte nos paquets (i.e. Man In The Middle). Cependant, le déploiement de certificats à l échelle de toute l'université risque de s avérer couteux et/ou compliqué, sans parler du fait qu'une telle solution ne serait pas applicable aux conversations avec des personnes non-affiliées à l université. En 2006, l'auteur de PGP [15] Phil Zimmerman, propose un nouveau mécanisme d échange de clés appelé ZRTP [14]. Le protocole repose sur l'utilisation de paires de clés privées et publiques et la création d'un secret partagé à travers un échange Diffie-Hellman. ZRTP se démarque des autres alternatives grâce à l'authentification et la prévention des attaques de type Man In The Middle. Pour 12/10/2011 6/14 JRES 2011

7 assurer les participants que leurs données sont envoyées et reçues uniquement par eux-mêmes, ZRTP affiche un checksum dérivé du secret partagé aussi connu sous le nom SAS (Short Authentication String). Ce checksum apparaît le plus souvent en tant que quatre lettres dans l'interface de l'agent. Les utilisateurs sont tout simplement sensés vérifier que chaque participant voit les mêmes quatre lettres, en les prononçant pendant leur premier appel. Pour continuer son écoute, un attaquant MITM, devrait donc à ce moment arriver à remplacer les paroles des utilisateurs par d'autres, tout en imitant leurs voix. Cette vérification est nécessaire uniquement lors de la première conversation avec un utilisateur donné et ne sera plus demandée lors des futurs conversations. Bien évidement, l'utilisation de ZRTP implique une certaine prise en main de la part des utilisateurs qui pourrait être rébarbative. Or, vu le haut niveau de sécurité garanti par ZRTP et l'absence totale de coût de déploiement, on peut affirmer que la solution est parmi les plus raisonnables existantes aujourd'hui. Ceci conclut l'introduction théorique que nous souhaitons faire concernant les différents protocoles nécessaires pour une véritable alternative à Skype. La suite de l'article présente les implémentations réalisées et déployées dans le cadre du projet. 3 Le projet libre Jitsi Le projet libre Jitsi représente une des principales composantes de la solution décrite dans ce document. Il s'agit d'une application cliente, permettant les appels vidéo, le partage de bureau, la messagerie instantanée, le transfert de fichiers et plusieurs autres fonctionnalités que nous allons évoquer un peu plus en détail ci-dessous. Certains des lecteurs connaissent peut-être l'application sous son ancien nom: SIP Communicator. Une des premières versions du logiciel a d'ailleurs déjà été présentée lors des JRES 2007 [1]. Dans cette section, nous allons surtout nous concentrer sur les nouvelles fonctionnalités que nous trouvons essentielles pour le déploiement à l'université de Strasbourg. 3.1 Historique Jitsi, appelé SIP Communicator à ses débuts, démarre en 2003 comme projet étudiant à l'université de Strasbourg. Le logiciel reste dans un état expérimental pendant quelques années. En 2007, Emil Ivov, fondateur de Jitsi (et l'un des auteurs de cet article), lance avec quelques collaborateurs un projet d'entreprise innovante ayant pour idée de proposer de la maintenance et des intégrations professionnelles du logiciel. La nouvelle start-up BlueJimp collabore avec plusieurs partenaires et donateurs, tels que la NLnet Foundation (Pays-Bas), l'université de Strasbourg, le programme Google Summer of Code et d'autres. De fil en aiguille, Jitsi devient ce qu'il est aujourd'hui: l'un des logiciels communicants libres les plus aboutis et des plus riches en fonctionnalités. 3.2 Fonctionnalités Avant le démarrage du projet à l'uds, Jitsi comptait déjà un nombre important de fonctionnalités. Il y en a cependant beaucoup qui ont été ajoutées explicitement dans ce contexte et dont le financement a été assuré par l'uds. Aujourd'hui, elles sont toutes disponibles librement pour ceux qui souhaitent tenter l expérience. Voici ci-dessous les plus innovantes. 12/10/2011 7/14 JRES 2011

8 3.2.1 Appels audio/vidéo de haute qualité Les appels vidéo sont certainement l'une des fonctionnalités phares de Jitsi. Les appels sont par défaut établis avec une résolution VGA (640x480 pixels) et il est possible pour l'utilisateur de les modifier ce qui peut s avérer pratique dans le cas d'un débit réseau insuffisant. Le codec utilisé par défaut est H.264 et Jitsi supporte également H.263. En ce qui concerne l'audio, les équipes de BlueJimp ont rajouté dans le contexte du projet UdS le support pour plusieurs codecs de haute qualité tels que Silk, G.722, capable de fonctionner sur une fréquence de 16 khz, 24 khz et 32 khz. Il est important de noter que le codec Silk est celui qui est également utilisé par Skype. On obtient donc exactement la même qualité audio en utilisant Jitsi que lors des fameux appels HD de Skype Support de SIP, XMPP et d'autres protocoles Jitsi propose un support complet des fonctionnalités de présence et de messagerie instantanée pour un grand nombre de protocoles et de réseaux comme: Windows Live (MSN), Figure 4: Appel vidéo avec Jitsi Facebook, Google Talk, Yahoo! Messenger, ICQ, AIM et bien entendu SIP et XMPP. Les fonctionnalités de téléphonie et d'appels vidéo sont actuellement proposées pour SIP, XMPP et GoogleTalk sur les systèmes d'exploitation Windows, Linux et Mac OS X. Le support de la variante Google de Jingle a été développé dans le contexte du projet actuel dans le but de l'ouvrir à une grande communauté d'utilisateurs. Les utilisateurs qui ne sont pas enregistrés sur le domaine de l'uds sont joignables avec leur compte Gmail. Il est important de noter que même si la visio conférence avec SIP est relativement bien supportée par les différents logiciels de communication, les implémentation avec XMPP est beaucoup plus rare. Il s'agit d'une des particularités qui rend Jitsi bien adapté pour être une alternative à Skype Traversée des NATs La communauté de Jitsi ainsi que les équipes de BlueJimp ont fourni un grand effort pour l implémentation des protocoles STUN, TURN, et JingleNodes dans une implémentation complète de ICE dans le cadre du projet ice4j.org [15]. Cette pile intègre également l'utilisation d'autres mécanismes de traversée des NATs comme UPnP, et les relais TCP. Jitsi se sert d'ice4j.org pour assurer la traversée des NATs avec XMPP. En ce qui concerne SIP, Jitsi dépend des serveurs SIP pour assurer le relayage. L intégration de ICE pour SIP est prévu pour la fin de l année. 12/10/2011 8/14 JRES 2011

9 3.2.4 Appels de conférence Le plus souvent, pour participer à des appels de conférences il est nécessaire pour les utilisateurs de joindre un numéro spécial (un pont de conférence). Une fois la connexion établie, les différents participants sont mis en relation de manières transparentes mais même s'ils arrivent tous à s'entendre, le logiciel ou l équipement qui a effectué l'appel pour l'utilisateur le perçoit comme un simple appel point à point ce qui rend impossible la présentation visuelle des autres participants ainsi que leur activité dans l'appel. Bien que Jitsi puisse participer à ce genre d'appels, il est également capable de gérer les informations envoyées par le serveur pour afficher aux utilisateurs une représentation plus complète de l'appel (voir l'image ci jointe Error: Reference source not found). Plus important encore, Jitsi est capable d héberger lui-même des appels de conférences de manière entièrement indépendante du serveur et sans limite pour le nombre maximal de participants Sécurité et confidentialité Pour ses appels audio aussi bien que vidéo, Jitsi supporte la sécurisation avec SRTP et les échanges des clés avec SDES pour SIP et ZRTP pour SIP et XMPP. Cette combinaison est assez rare en ce qui concerne ZRTP, Jitsi est le seul logiciel, à notre connaissance, qui propose son support pour les conversations effectuées avec XMPP Divers En plus des points énumérés ci-dessus, il y en a d'autres qui se sont avérés assez importants dans le contexte du projet UdS. Jitsi a la particularité d être multi-plateforme. La communauté supporte actuellement des versions pour Windows, Linux et Mac OS X. De part son parc informatique très hétérogène, le support des différents systèmes d'exploitation était indispensable pour l'université. Enfin, le logiciel propose également l'affichage à distance ou le partage du bureau, les consultations d'un annuaire LDAP et la configuration à distance (online provisioning). 4 Infrastructures du service 4.1 Service XMPP avec Openfire Figure 5: Appel de conférence Comme nous l'avons déjà dit, le protocole XMPP, avec sa sécurité, extensibilité et sa richesse en fonctionnalités, a été choisi comme la base du service. Il existe plusieurs serveurs XMPP libres et de très bonne qualité comme par exemple Openfire [16], ejabberd [17] et Prosody [18]. Dans le cadre du projet à l'uds, nous nous sommes arrêtés sur Openfire, proposé par JiveSoftware et la communauté IgniteRealtime. Les raisons principales de ce choix sont surtout la facilité de manipulation du produit ainsi que le fait qu'il soit entièrement écrit dans le langage Java. Ceci est important car certaines des perspectives d'évolution du projet, comme le support des visio-conférences à plusieurs, nécessiteront peut être le développement d'extensions du serveur. Dans ce cas, la possibilité d'utiliser Java permettra sans doute une réutilisation du code du projet Jitsi. Openfire dispose également d une forte communauté ainsi que de nombreuses extensions, en particulier l extension JingleNodes, plugin qui permet de mettre en relation les clients Jitsi pour des conversations multimédia où les communications directes ne sont pas possibles. L authentification des utilisateurs se fait entre le serveur XMPP Openfire et l annuaire LDAP. A chaque connexion d'un client, Openfire interroge l'annuaire et vérifie les droits d'accès. De cette manière, il n est pas nécessaire de dupliquer la base utilisateurs. Si un nouvel arrivant est ajouté au système d'information, alors il est automatiquement ajouté au serveur LDAP et peut directement se connecter au service sans aucune autre manipulation. 12/10/2011 9/14 JRES 2011

10 Finalement, pour simplifier la mise en place du service, le client Jitsi a été modifié pour proposer une première configuration simplifiée. Pour qu'un utilisateur commence à utiliser le nouveau service il lui suffira de télécharger le logiciel et de rentrer le nom et le mot de passe de son compte habituel. Ceci le connectera au service XMPP et configurera les propriétés nécessaires pour l'utilisation de l'annuaire LDAP et le serveur STUN de l'université. 4.2 Traversée des NATs et des Firewall-s Le service de communication décrit ici a pour but de permettre aux étudiants et personnels de l'université de Strasbourg de communiquer entre eux et avec leurs contacts à n'importe quel moment et n'importe quel endroit. Autrement dit, même s'il est vrai que l'université de Strasbourg dispose d'un nombre confortable d'adresses IPv4 publiques, comme la plupart des universités françaises desservies par RENATER, les utilisateurs du service XMPP ou leurs interlocuteurs peuvent se retrouver dans des topologies diverses et dont la traversée des NATs doit être assurée de manière fiable. De plus, lors des premiers tests d'appels, il s'est avéré que les communications directes sont interdites entre les utilisateurs connectés aux réseaux sans fils de l'uds (c.-à-d. osiris, osiris-sec et eduroam). A l'origine, la mesure avait été mise en place dans le but d'éviter les dysfonctionnements ou les attaques basées sur DHCP ou IPv6 RA. L'absence de moyens plus fins pour la configuration de l'infrastructure sans fil avait donc obligé les équipes de la direction informatique d'interdire toutes communications entre des nœuds voisins. Évidement, la proscription ne pose pas de problème pour les échanges web ou mail mais produit un effet de bord gênant dans le cas des appels IP. Elle rend donc indispensable le déploiement de serveurs relai. La solution prévue initialement pour ces relais était l'utilisation du protocole TURN et du serveur libre TurnServer.org car c'est la solution de relayage recommandée par l'ietf pour l'utilisation avec ICE. Malheureusement il est vite devenu clair que cette solution ne serait pas applicable dans l'environnement de l'uds. En effet, l'une des particularités du protocole TURN est qu'il nécessite, comme pour HTTP et SIP, que l'authentification soit accomplie à l'aide d'un mécanisme de challenge et il est donc nécessaire pour le serveur de connaître le mot de passe utilisateur. Or, dans l environnement actuel de l'université, les véritables mots de passe ne sont pas sauvegardés par l'infrastructure qui dispose uniquement de leur hash SHA-1 Autrement dit, l'utilisation de TURN aurait nécessité une réinitialisation de tous les comptes utilisateur et leur mise à jour avec les mots de passe complets. C'est justement ici que la solution JingleNodes, décrite plus haut, montre toute son utilité. Comme expliqué dans la section 2.3.2, la réservation des canaux avec JingleNodes se fait par le chemin de la signalisation contrairement à TURN où un client est censé contacter le serveur directement (Figure 3). De ce fait un serveur JingleNodes n'a pas besoin d'authentifier ses clients car il reçoit toutes les demandes de relayage depuis les serveurs de signalisation. Il suffit donc de lui indiquer quels sont les serveurs qui ont le droit de l'utiliser. 4.3 Appels vers des fixes Un des objectifs du projet d'alternative Skype est de pouvoir initier des communications audio depuis le logiciel client Jitsi vers tous les postes de téléphone hardware classique gérés par l université. L avantage étant de pouvoir joindre des utilisateurs n ayant pas d ordinateur ou n ayant pas le client Jitsi installé ou démarré. L infrastructure téléphonique de l Université de Strasbourg est composée d un parc téléphonique hétérogène où cohabitent plusieurs technologies de génération différente. La majorité du parc téléphonique est composée de lignes analogiques et numériques reliées à des PABX Alcatel. Une des premières solutions envisagée était donc de raccorder un serveur SIP au réseau téléphonique classique en utilisant une carte Zaptel [19] et de l'utiliser en tant que passerelle vers les utilisateurs de Jitsi. Cette solution a été écartée pour 3 raisons. Tout d abord, la politique universitaire de virtualisation des serveurs se base sur un modèle de serveurs physiques standards dans le but de déplacer les machines virtuelles de manière transparente. Une carte matérielle supplémentaire compliquerait fortement cette souplesse d administration. Deuxièmement, une solution analogique nécessite également de raccorder le serveur physique au PABX via des câbles téléphoniques dédiés. Dans un futur proche, un déplacement géographique des machines vers un site dépourvu de PABX rendrait donc cette solution obsolète. Enfin, cette solution n est pas pérenne car l'université souhaite à moyen terme migrer entièrement vers de la téléphonie sur IP. 12/10/ /14 JRES 2011

11 Bien entendu toutes ces raisons étant spécifiques à l'uds, cette solution reste techniquement viable et peut être envisagés dans d'autres circonstances. Revenons au cas de l'université de Strasbourg. Il s'est avéré que parmi les PABX téléphoniques, certains (Alcatel OmniExpress OXE plus précisément) disposent d'interfaces SIP. Une connexion physique n'est donc plus nécessaire et peut se faire par le réseau IP. Il est donc possible pour un serveur SIP de les utiliser comme point d entré vers le réseau téléphonique et d'y acheminer des appels provenant du réseau IP. Dernier point à résoudre: comment établir la connexion entre les utilisateurs Jitsi et ces serveurs SIP. Une des idées relativement simple serait de connecter les clients Jitsi, supportant eux même le protocole SIP, directement au serveur. Malheureusement ceci présenterait plusieurs difficultés. Tout d'abord une telle connexion signifierait l'existence de plusieurs comptes et la maintenance de multiples connexions simultanées au niveau du client. Elle serait relativement complexe à mettre en place et éloignerait la solution, des standards. La présentation à l'utilisateur, de comptes distincts SIP et XMPP dans l'interface graphique pourrait être incomprise et devenir perturbante pour l'utilisateur qui a lui fait le choix d'utiliser un seul service. Plus important encore, étant donné que SIP utilise le même modèle d'authentification que le protocole TURN, l'authentification au niveau du serveur aurait présenté exactement les mêmes difficultés que l'utilisation d'un serveur TURN: Les mots de passe utilisateur stockés dans le LDAP sont au format SHA1 et ne sont donc pas exploitables par les serveurs SIP ou TURN. Nous avons donc cherché une autre solution qui permettrait aux clients Jitsi de garder une seule connexion de signalisation: celle avec le serveur XMPP et qui ne demanderait pas d'authentification au niveau du serveur SIP. Là encore le protocole XMPP et son modèle sécuritaire se sont avérés très utiles. Le serveur SIP FreeSWITCH [20] bénéficie d'une fonctionnalité qui lui permet de s'enregistrer en tant que composante dans un serveur XMPP et de gérer les sessions Jingle. Autrement dit, si le serveur XMPP dessert le domaine unistra.fr et que le serveur FreeSWITCH s'enregistre comme composante sous le nom freeswitch, toute demande d'appel Jingle vers des adresses comme exemple@freeswitch.unistra.fr sera transmise au serveur FreeSWITCH. Il est important de noter que même si la signalisation traverse toujours le serveur XMPP, le trafic RTP lui est échangé directement entre les clients Jitsi et le serveur FreeSWITCH. Figure 6: Appels vers des fixes La Figure 6 résume les différentes interactions entre le client Jitsi et les briques logiciels du service. 4.4 Virtualisation, redondance et montée en charge Dans la mouvance actuelle, chaque serveur de la Direction Informatique à l'uds est virtualisé si les applications le permettent. Les avantages de la virtualisation en terme d administration sont les suivants : mutualisation de serveurs physiques déplacement de machines virtuelles à chaud reprise sur panne matérielle plus rapide adaptation des ressources à la demande (CPU RAM) 12/10/ /14 JRES 2011

12 Les serveurs de virtualisation à l'uds sont des machines de 8 à 24 cœurs avec des CPU de type Intel Xeon 2.67GHz. La mémoire vive disponible va de 24Go à 64Go. Les images des disques des machines virtuelles sont stockées sur des disques durs locaux montés en RAID 6 avec un contrôleur matériel. Le système standard de virtualisation est KVM déployé sur le système GNU/Linux Ubuntu LTS. Dans le cadre du projet Jitsi, la solution logicielle retenue est suffisamment souple pour se prêter à la virtualisation. Deux machines virtuelles assurent une redondance active/passive à l aide du logiciel Pacemaker [21]. Le serveur maître possède l IP virtuelle du service Jitsi et lance automatiquement l ensemble des démons nécessaires (Openfire, TurnServer, FreeSWITCH, MySQL). En cas d une défaillance du serveur maître (panne, maintenance), le serveur esclave se réveille, récupère l IP virtuelle Figure 7: Virtualisation, redondance et montée en charge et relance les services. La base de données MySQL est un point particulier car elle tourne en local sur le serveur maitre. Cette base est couplée à un volume réseau DRBD [22] qui est répliqué en temps réel entre les deux serveurs. Ce fonctionnement peut être assimilé à un montage RAID 1 en réseau. Ainsi, en relançant MySQL sur le serveur esclave, les dernière données écrites sur le serveur maître sont disponibles. La Figure 7 résume l architecture et la redondance du service déployé. Concernant la montée en charge, si les ressources de la machine commencent à devenir limitées, la virtualisation permet de redimensionner facilement la puissance CPU et la taille de la RAM. Si l'augmentation des ressources matérielles ne suffit pas à faire face à la montée en charge, d'autres pistes sont envisageables comme une architecture basée sur un cluster de serveurs Openfire grâce à l'extension de clustering. 5 Conclusion et perspectives d évolution Comme déjà précisé dans l'introduction de cet article, en commençant le projet de communication temps réel à l'uds nous avions identifié sept points qui donnent à Skype sa popularité actuelle et qui devront être présents dans toute solution cherchant à le remplacer. Aujourd'hui, une fois le projet terminé il est intéressant de revenir sur cette liste et de voir comment l'alternative déployée répond aux différents critères: gratuit à l'utilisation il est évident qu'avec les solutions utilisées: Jitsi, Openfire, FreeSWITCH, TurnServer et JingleNodes, nous avons un service qui va plus loin que la simple gratuité. Toute composante du projet est distribuée sous une licence libre et peut être reprise, déployée ou modifiée par tout le monde et sans aucune contrainte commerciale. appels audio et vidéo de bonne qualité avec le support des codecs audio de haute qualité tels que G.722, Speex et même SILK utilisé par Skype, ainsi que les appels vidéo en résolution 640x480, les appels avec Jitsi et le nouveau service sont tout à fait comparables et souvent meilleurs que ceux effectués avec Skype. 12/10/ /14 JRES 2011

13 conférences avec Jitsi, qui peut fonctionner en tant que mixer audio et agent de focus, il est aujourd'hui possible pour les utilisateurs du service d'organiser ou de participer à des appels de conférence avec, encore une fois, une très bonne qualité audio. support des principaux systèmes d exploitation (Windows, Mac OS X et Linux) vérifié avec Jitsi, qui sera également bientôt disponible en version Android. De plus, vu l'utilisation exclusive de solutions standards, les utilisateurs sont libres d'utiliser n'importe quel autre client supportant les mêmes protocoles. sécurité: appels chiffrés l'utilisation de SSL dans XMPP et le support de ZRTP dans Jitsi garantissent une sécurité qui est nettement meilleure que celle de Skype ou l intimité des utilisateurs est soumise à la bonne volonté du fournisseur du service. [particulièrement important] une large communauté d'utilisateurs, facilitant son adoption avec le support des variantes Google de Jingle, il est possible aujourd'hui pour les utilisateurs UdS d'effectuer des appels vers tous les abonnés XMPP ou Gmail/GTalk qui, dans leur ensemble, représentent une communauté comparable à celle des utilisateurs Skype. facilité d utilisation cette caractéristique étant relativement subjective, nous invitons les lecteurs à l évaluer par eux même en se rendant sur Bien évidemment, nous ne comptons pas en rester là. Dans le mois à venir, le service devrait être étendu pour permettre les appels vidéo à plusieurs participants (fonctionnalité payante avec Skype). Des solutions de facturation plus avancées sont également à l étude et devrait permettre au personnel de l'uds d'effectuer des appels vers tous les postes téléphoniques ou mobiles et non plus seulement vers ceux appartenant à l'université. Nous espérons que cet exemple de déploiement d'alternative Skype encouragera d'autres universités à franchir le pas, créant ainsi une fédération de réseaux interopérables pour les utilisateurs. 6 Remerciements Les auteurs aimeraient remercier Yana Stamcheva (Jitsi/BlueJimp) pour avoir fourni les diagrammes ainsi que Véronique Dupont (Alcatel-Lucent), Guillaume Lacroix (ippi.fr) et Eric Laemmer (Université de Strasbourg) pour leur relecture et commentaires. 7 Bibliographie [1] Emil Ivov et Jean-Marc Muller, SIP Communicator Un outil open source de communication sur IP adapté à nos laboratoires et à nos universités. Journées Réseaux, Novembre [2] Peter Saint-Andre, RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core. Ineternet Engineering Task Force, March [3] Google Talk, [4] Scott Ludwig, Joe Beda, Peter Saint-Andre, Robert McQueen, Sean Egan, Joe Hildebrand, XEP-0166: Jingle. XMPP Standards Foundation, Décembre [5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, RFC 3261: Session Initiation Protocol. Ineternet Engineering Task Force, June [6] J. Rosenberg, R. Mahy, P. Matthews, D. Wing, RFC 5389: Session Traversal Utilities for NAT (STUN). Internet Engineering Task Force, Octobre [7] UPnP: Universal Plug and Play, 12/10/ /14 JRES 2011

14 [8] Rohan Mahy, Philippe Matthews, et Jonathan Rosenberg, RFC 5766: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). Internet Engineering Task Force, Avril [9] Thiago Camargo, XEP-0278: Jingle Relay Nodes. XMPP Standards Foundation, Juin [10] Jonathan Rosenberg, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. Internet Engineering Task Force, Avril [11] F. Andreasen, M. Baugher, D. Wing, RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams. Internet Engineering Task Force, July [12] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, RFC 3830: MIKEY: Multimedia Internet KEYing. Internet Engineering Task Force, August [13] Phil Zimmermann, PGP: Pretty Good Privacy, [14] P. Zimmermann, A. Johnston, J. Callas, RFC 6189: ZRTP: Media Path Key Agreement for Unicast Secure RTP. Internet Engineering Task Force, April [15] Communauté Jitsi, Implémentation Java du protocole ICE, [16] Openfire is a real time collaboration server, [17] A Jabber/XMPP instant messaging server. [18] Communications server for Jabber/XMPP, [19] ZapTel Calling Cards, [20] FreeSWITCH, open source cross-platform telephony platform, [21] Pacemaker, Open Source, High Availability resource manager, [22] DRBD, block devices designed as a building block, 12/10/ /14 JRES 2011