Navigation

Dans l’idée de proposer un nouveau service hébergé par Picasoft, axé visioconférence, la question du choix du service se pose. Framatalk, basé sur Jitsi, est notre référence a priori : on cherche des fonctionnalités relativement similaires (utilisation anonyme, faible empreinte, simple…). Cette page propose une comparaison minimale des services existants pour servir de base aux futures discussions.

Note : à part cette comparaison des outils de visioconférence, qui ne vise que deux des outils que l’on a retenu, je n’ai pas trouvé de comparatif similaire. C’est donc un travail inédit susceptible de contenir des imprécisions et/ou des erreurs.

On exclut d’office les services de visioconférence sans client web, dans l’esprit des services proposés par Picasoft. On exclut également les outils utilisant uniquement des protocoles et technologies obsolètes, ainsi que les services ne proposant pas de communications chiffrées par défaut.

Ci-dessous un comparatif synthétique des outils retenus, avec plus de détails dans les prochaines sections.

	Apache OpenMeetings	BigBlueButton	Jitsi	Hubl.in	Jangouts	Spreed
Licence	Apache 2.0	LGPL3	Apache 2.0	AGPL3 + clauses de paternité	MIT	AGPL3
Protocole(s)	RTMP (TCP), RTP (UDP)	RTMP, RTP	RTP	RTP	RTP	RTP
Langages	Java, ActionScript, PHP, JS	Java, ActionScript, JS	Java, JS	JS	JS	Go, JS
Base de données	Toutes, autres	MongoDB	Non	MongoDB, Redis	Non	Non
Compatibilité mobile	Partielle	Oui	Oui	Oui	Partielle	Oui
Partage d’écran	Oui	Oui	Oui	Non	Oui	Non
Chat textuel	Oui	Oui	Oui	Non	Oui	Non
Image Docker officielle	Oui	Médiocre	Oui	Oui	Non	Oui
Activité	Forte	Forte	Forte	Faible	Faible	Inexistante
Prérequis hardware	8Go RAM, 2x2GHz	8Go RAM, 4x2GHz	Forte BW	Forte BW	Forte BW	N/A
Utilisateurs anonymes	Non	Non	Oui	Oui	Oui	Oui

On donne quelques détails supplémentaires pour les outils retenus, dépendant de l’abondance de la documentation proposée. Tous les outils n’ont pas pu être testés (absence d’instance de test).

OM est basé sur le serveur Flash libre Red5, qui offre des fonctionnalités de streaming audio et vidéo. Il utilise le protocole RTMP (Real-Time Messaging Protocol), utilisé par les player Flash. Maintenant que Flash est obsolète, un portage NodeJS/HTML5 est en cours, avec l’utilisation de WebRTC et l’abandon de Red5, qui n’offre pas la possibilité d’utiliser WebRTC dans sa version libre. WebRTC est utilisé dans son mode SFU (Selective Forwarding Unit), c’est-à-dire avec un composant de routage des flux de données centralisé.

L’outil, parfois cité comme une alternative aux outils propriétaires comme Skype, est probablement trop complet pour notre utilisation. En particulier, il propose de l’édition de documents collaborative (LibreOffice), un système de tableau blanc et impose l’utilisation d’une base de données ainsi que l’enregistrement des utilisateurs. De plus, les prérequis matériel sont bien trop élevés pour nous.

OM est donc probablement un choix peu pertinent, le service n’est pas assez minimal et pourrait interférer avec d’autres services que Picasoft propose(ra). OM convient sans doute mieux pour les collaborations d’équipes sur le “long terme”.

BBB est très similaire à OM en terme de fonctionalités et d’histoire : basé sur Red5/Flash, passage en HTML5, système de tableau blanc… Cité également comme alternatives à Skype, BBB se présente en fait comme conçu pour le e-learning, et propose à ce titre des ponts avec des outils pédagogiques. Bien que très actif, les réticentes sont les mêmes que pour OM : prérequis matériels très élevés (en ajoutant qu’un serveur baremetal est conseillé, car l’utilisation de FreeSwitch - pour l’audio - fonctionne mieux en environnement non virtualisé), fonctionnalités hors-sujet pour nous, nécessité de gérer des utilisateurs, etc.

De plus, l’image Docker proposée fait tourner pas moins de 13 services dans le même conteneur, ce qui n’est pas très rassurant pour la construction d’une image maison.

BBB n’est donc pas un choix pertinent non plus. MConf est un service basé sur BBB que l’on n’évoque pas pour les mêmes raisons.

Jitsi est une collection de projets : les principaux sont Jitsi Meet (visioconférence web), Jitsi Videobridge (routeur de flux) et Jitsi Desktop (client lourd).

Le projet a démarré en 2003, et s’est d’abord concentré sur deux composants :

Jitsi Videobridge, un composant pour serveur XMPP permettant de router les flux audio et vidéo vers les bons participants
Jitsi Desktop, un client lourd XMPP pour proposer de la visioconférence, qui utilise Videobridge.

Avec la démocratisation de WebRTC, Jitsi Meet est né ; il s’agit d’un client web pour organiser des visioconférences.

Pour clarifier un peu le statut de Videobridge, quelques explications : Videobridge s’appuie sur un serveur XMPP (Prosody), qui implémente une extension XMMP permettant de gérer les visioconférences (Colibri). Videobridge est derrière XMPP, ce qui permet de l’utiliser avec n’importe quel client XMPP (et même des clients SIP!). Jitsi Meet, lui, se base sur WebRTC pour envoyer les flux vidéo et audio en utilisant XMPP pour le signaling (i.e. l’initiation de la connexion avec les autres participants, entre autres). Jitsi Meet utilise l’API REST de Prosody.

Une des fonctionnalités intéressantes de Videobridge est que c’est un SFU (Selective Forwarding Unit) et non un MCU (Multi-point Control Unit) ; c’est-à-dire qu’au lieu de mixer les flux vidéos (ce qui est très coûteux en terme de calcul, et rend vite impossible les conférences simultanées et/ou à beaucoup de participants), Videobridge relaie l’ensemble des flux aux participants concernés (d’où la fonctionnalité de routage). Aussi, Videobridge est capable d’adapter les flux à la bande passante des participants et d’envoyer des vidéos de différentes résolutions, voire de ne garder que l’audio. Enfin, le mode Mesh (i.e. pair-à-pair) de WebRTC est utilisé lorsqu’il n’y a que deux participants à la conversation - ce qui représente la majorité des utilisations. Ainsi, le serveur est déchargé de sa responsabilité de relai et on retrouve une utilisation classique de WebRTC.

La compatibilité mobile est assurée grâce à une application, par contre Jitsi fonctionne assez mal sur navigateur mobile.

Aussi, Jitsi s’intègre nativement à Etherpad et propose une sécurisation des conférences par mot de passe.

Notons que Jitsi a été racheté à Atlassian par la société 8×8 en Octobre 2018. Il est difficile de dire ce que le projet deviendra, mais son importante communauté devrait continuer à le faire vivre quoi qu’il arrive.

Jitsi est, à ma connaissance, le seul outil libre permettant de gérer autant de conférences simultanées avec une faible empreinte sur le calcul, tout en s’adaptant au contexte et à la bande passante et en proposant une compatibilité avec les clients XMPP et SIP. Notons que pour le moment, les conférences démarées avec Jitsi Meet semblent s’intégrer seulement partiellement avec les clients XMPP (voire presque pas, en ne conservant que la fonctionnalité de chat textuel dans certains cas - non testé).

Hubl.in est un outil libre, développé par la société Linagora comme composant de son autre outil libre OpenPaas. Il suit globalement le même principe que Jitsi, sans la partie XMPP. On parle donc d’une architecture composée d’un client web, utilisant WebRTC pour transmettre les flux audio et vidéo, et d’un SFU très populaire, Janus. Tout comme Jitsi, les modes Mesh et SFU s’alternent ; Hubl.in utilise le mode Mesh (pair-à-pair) avec EasyRTC pour les visioconférences avec peu de participants (3 à 4, versus 2 pour Jitsi, ce qui nécessite d’uploader N-1 fois les flux) et passe sur le mode SFU avec Janus dès que le nombre de participants augmente.

La majorité des conférences se déroulant à moins de 4 personnes, l’utilisation du mode Mesh est probablement la plus fréquente.

Contrairement à Jitsi, Hubl.in dépend de deux bases de données : MongoDB et Redis. On peut également noter l’absence de chat textuel et de fonctionnalités de partage d’écran.

Ce projet est intéressant ; beaucoup plus jeune que Jitsi, ses fonctionnalités correspondent à nos besoins et l’architecture demeure simple et bien réfléchie. La documentation n’est pas très abondante, mais on trouve des articles des développeurs expliquant leurs choix et les futures évolutions. On regrette donc qu’aucun commit n’ait été poussé sur la branche master depuis un an, et l’absence de release claires qui mettent en doute sa perennité. Ces derniers temps, les efforts se sont concentrés sur Hublot, un bot intégrable dans Hubl.in basé sur les mêmes technologies que LinTo, “l’assistant personnel éthique et libre développé par Linagora”.

On dira seulement quelques mots sur Jangouts, car c’est un projet assez spécifique. Niveau fonctionnalités, le projet vise à imiter celles offertes par Google Hangouts (visioconférence et chat textuel, avec partage d’écran).

Il est né en 2016 au sein de hackatons internes au sein de SuSE, et est développé depuis au sein de hackatons publics destinés à la communauté openSuSE. Sa documentation est limitée aux installations sur les dérivés de SuSE, et il semblerait que le projet ne soit pas de proposer une alternative particulièrement performante et/ou innovante par rapport aux autres outils libres, mais bien de proposer une alternative maison et de s’entraîner. Il semble que l’installation sur les systèmes Debian-like ne soit pas toujours aisée, et on ne trouve pas d’image Docker officielle - ce qui n’est pas un obstacle en soi.

Côté architecture, on retrouve comme pour Hubl.in l’utilisation de Janus en mode SFU, garantissant donc une empreinte calculs assez faible. On ne trouve pas de mention de l’utilisation du mode Mesh pour un faible nombre de participants.

Malheureusement, aucun commit n’a été publié la dernière année et le nombre de contributeurs est assez marginal.

Encore moins de mots sur Spreed WebRTC ; c’est un projet libre dont un des buts semble être de promouvoir l’entreprise Spreedbox et son produit hardware éponyme. On retrouve très peu de détails sur l’architecture, sinon que le serveur de média WebRTC est fait maison en Go (donc probablement avec l’utilisation du mode SFU ou MCU). Le dernier commit date d’il y a deux ans, et le repo Git ne compte que 11 contributeurs ; on peut difficilement se baser sur cet outil.

Les seuls outils que l’on peut retenir, à mon sens, sont Jitsi et Hubl.in. D’un côté, OM et BBB sont trop complets pour nous et dépendent encore de technologies obsolètes comme Flash ; de l’autre, Jangouts et Spreed sont des projets plus marginaux et trop peu maintenus pour s’assurer de leur solidité/perennité.

Si Jitsi et Hubl.in semblent plus bullet-proof, on note quelques différences :

Jitsi propose plus de fonctionnalités (chat et partage d’écran).
Hubl.in utilise le serveur WebRTC Janus, à visée très générale, vs Videobridge pour Jitsi, à visée plus spécifique et “fait-maison”.
Hubl.in recquiert des bases de données.
Jitsi s’intègre nativement à Etherpad, que nous hébergeons, et qui permet d’exploiter ensemble le potentiel de l’édition collaborative et de la visioconférence sans outil supplémentaire.
Hubl.in conserve le mode Mesh pour 3 à 4 participants, ce qui peut contribuer à décongestionner le serveur mais recquiert une bonne bande passante sur les terminaux.
Jitsi propose plus de fonctionnalités d’adaptation individuelle, en particulier autour de la bande passante disponible.
Hubl.in propose un bot intelligent pouvant aider à la discussion.
Jitsi nous est familier par notre utilisation de Framatalk.
Jitsi permet de définir un mot de passe par conférence.
Videobridge propose des statistiques que l’on pourrait ajouter au pica-bot.

Au vu de ces éléments, la recommendation irait plutôt vers Jitsi, mais on peut également réfléchir à utiliser Hubl.in pour créer de la diversité au niveau de l’hébergement des services libres de visioconférence - à discuter ensemble.

Comparaison entre les services libres de visioconférence

Vue d'ensemble

Détails

Apache OpenMeetings

BigBlueButton

Jitsi

Hubl.in

Jangouts

Spreed WebRTC

Conclusion

Sources

Picasoft