Chez le @LeCloudGirofle on nous demande parfois des outils de visio, mais on en fait pas chez nous (pour l’instant). On redirige généralement vers la liste des chatons qui proposent de la visio, sans forcément avoir du recul sur les détails de chaque service en terme de fonctionnalité ou de capacité de montée en charge.
On se demandait notamment s’il y en avait parmi vous qui auraient mis en place un service de pont audio pour rejoindre les salons de visio via téléphones (un Trunk SIP) ?
On voit qu’avec la solution Talk (vu qu’on fait déjà du Nextcloud) ce n’est pas possible sans avoir recours à une Infrastructure Haute Perfomance.
Est-ce que vous en faites avec du Jitsi ou BBB sinon ?
Par ailleurs on a récemment eu une demande d’une entreprise de l’ESS (qu’on connaît bien) avec des volumes assez importants, qui souhaiterait (entre autre) cette fonctionnalité.
Pour illustrer, voici les volumes en questions
~2000h cumulées /mois
~5000 connexions /mois
~850 codes de réunions différents
~85 personnes connectées en simultané au maximum
Et ils prévoient une forte croissance de leurs équipes l’année prochaine.
Est-ce qu’il y a des gros matous dans la salle qui souhaiteraient s’y frotter ?
Personnellement, j’ai installé une instance « Galène » (voir Recherche retour d'expérience sur Galène)
C’est un outil de visio très simple à déployer et à administrer
Par contre, contrairement à BBB, ce n’est pas fait pour du gros volume en visio simultané.
A étudier si dans vos cas, cela peux convenir
À Émancip’Asso, il y avait un sujet sur « designer une offre de service », et de « répondre aux attentes ». Typiquement la, j’ai l’impression qu’il faudra un support dédié et un engagement sur la QoE/QoS (Quality of Experience/Quality of Service). Par la suite, j’explique ce que ce support devrait être capable d’investiguer selon moi, indépendamment du logiciel retenu.
Il faudrait qu’il monitore les différentes métriques d’une telle solution, et qu’il ait une connaissance métier de cette dernière. Il y a plusieurs métriques à connaitre, à observer, et à maintenir sous un certain seuil (mouth to ear delay strictement inférieur à 400ms, idéalement en dessous de 150ms). Tout ça implique plein de composants (jitter buffer, annulation d’écho, codecs, transport, les problèmes de TCP avec le bufferbloat, le scheduling de votre serveur, etc.) qu’il faut connaître et déboguer. Un exemple concret : ça a mis longtemps chez Mumble pour que quelqu’un arrive à mettre le doigt sur le fait que l’annulation d’écho était mal configurée et laissée passer la voix, et si je suis au courant, c’est que ça a été un sujet d’agacement en réunion mensuelle CHATONS[1]. Je vous renvoie à la section 3.1 de ma thèse pour plus d’infos sur le sujet de la VoIP.
De mon côté, je ne connais rien à BBB mais je connais un peu Jitsi pour dire que : 1) je suis très convaincu qu’un déploiement du paquet Debian/Ubuntu fournit ne proposera pas une QoE/QoS satisfaisante, c’est vraiment un packaging « démo » très bridé[2], 2) Je vous conseille de déployer le + possible à la main pour comprendre le fonctionnement interne du système que vous mettez en place et afin de pouvoir l’adapter à votre contexte forcément spécifique 3) le trunk SIP chez Jitsi s’appelle Jigasi, et pour info on peut aussi enregistrer/streamer des sessions - y compris sur Peertube - avec Jitsi grâce à Jibri[3] 4) Deuxfleurs n’a pas de Jigasi/Jibri/Peertube déployé, on ne surveille pas les stats/métriques, et on n’est pas outillé structurellement pour répondre à cette demande pour le moment.
C’est pas pour faire peur/décourager, mais c’est pour donner des clés de compréhension pour maximiser les chances de succès de cette initiative, et des suivantes, qu’on dise pas que « Zoom ça marche mieux quand même », et peut être aussi mettre des mots, qualifier, visibiliser ce travail de maintenance qui fait qu’un outil rend service ou non.
C’est plein de scripts bash qui viennent modifier vos configurations avec des regex d’une mise à jour à l’autre, avec le risque de corrompre votre configuration, particulièrement si vous l’avez modifiée. Les daemon Java sont lancés avec des paramètres hardcodés, comme la RAM, qui fait qu’ils se comportent mal dans des conteneurs, et probablement limite artificiellement leurs performances lors de la montée en charge, etc. ↩︎
J’ai bien noté que l’enregistrement de réunion ne faisait pas parti du cahier des charges ↩︎
Merci @Laurent, oui j’avais oublié de lister Galène dans les outils que l’on considère. J’aime beaucoup l’outil à l’utilisation simple et léger.
Merci @quentin, je vois que t’as bien creusé le sujet
En effet le support et la maintenance ne sont pas à négliger, et nos connaissances en la matière (visio) ne sont pas bien vastes au Cloud Girofle. On aimerait peut-être s’y mettre à terme mais ça nécessite beaucoup de travail comme tu as pu le souligner.
Je viens de faire un tour sur votre forge, je vais aller creuser ça, merci
Par curiosité, comment est-ce que vous gérez (ou géreriez) le monitoring de vos docker (je dévie du sujet donc on peut en parler ailleurs si tu penses que c’est plus judicieux) ?
Merci encore pour ces clefs de lectures qui nous aideront à bien choisir notre solution finale.
On va pas implémenter DONAR tout de suite en tout cas
Je connais un peu mieux bbb ( et pas pour hadoly qui préfère jitsi ). J’ai eu adminstré qq instances avec un loadbalancer en front ainsi qu’une passerelle SIP vers un ITSP. On a utilisé Ovh telecom et Twilio (qui est un pure player telecom). Avec une préférence pour Ovh telecom car oui même si leur offre commerciale est incompréhensible et bien ça fonctionnait médiocrement mais tout le temps en France+Europe. Twilio, c’était plus aléatoire et très dépendant du|des pays d’origine des appelants.
Sur bbb (de mémoire), le composant qui fait cela est freeswitch SignalWire | ☏ FreeSWITCH. Là on touche on brontosaure dont la configuration n’est pas triviale, mais ça marche tout le temps. Donc merci aux dev de bbb qui rendent intelligible cela avec juste un seul script bash.
Dans le cas de bbb, freeswitch n’est employé que pour la passerelle audio vers un l’opérateur. Il suffit donc de renseigner un dialplan+sip.profiles ( login et identifiant fournit par l’opérateur télécom ), et, hop, magie, freeswitch ira s’inscrire vers l’opérateur. Les numéros appelants seront routés de l’opérateur vers le numéro du sip.profiles configuré dans freeswitch. Pour chaque room, un code unique à 5 ou 6 chiffre permet de contrôler l’accés.
Je fais plus ça, mais peut-être que @Martin a eu fait ou souhaiterait faire avec vous? J’aurais dit indiehosters, mais de mémoire, ils sont pas très fan de bbb. ping @unteem
Ensuite, @dino administre des instances pour l’éduc nat et pourrait vous fournir des retex plus complet.
Salut à tous,
merci @stephane pour le ping
Chez Numéricoop nous ne faisons pas trop de visio non plus. Mais c’est clairement un sujet chez nous et il faut nous y mettre.
Je n’ai pas et je pense pas qu’on ai de compétences précises sur ces sujets.
Je suis partant pour monter des équipes sur un sujet et d’autant plus que là cela nous aidera directement chez Numéricoop.
Je suis donc ok pour parler de tout ca.
On se fait une visio sur le sujet visio ?
simple et léger.
?