Posté par jch .
En réponse au journal France Connect Plusse.
Évalué à 2.
Dernière modification le 22 juillet 2024 à 23:06.
le logiciel libre me semble être la base pour (re)établir la confiance […] l'Europe […] doit faire plus pour le Logiciel libre
« À cette fin, les États membres devraient divulguer le code source des composants logiciels de l’application utilisateur des portefeuilles européens d’identité numérique, y compris ceux qui sont liés au traitement des données à caractère personnel et des données des personnes morales. La publication de ce code source sous une licence à code source ouvert (open source) devrait permettre à la société, y compris les utilisateurs et les développeurs, de comprendre le fonctionnement du code, d’en faire l’audit et de l’examiner. […] Toutefois, dans certains cas, la divulgation du code source des bibliothèques utilisées, du canal de communication ou d’autres éléments qui ne sont pas hébergés sur le dispositif de l’utilisateur pourrait être limitée par les États membres, pour des motifs dûment justifiés, en particulier à des fins de sécurité publique.»
Et l'appli mobile n'a pas de niveau de garantie ???
Niveau de garantie élémentaire (le plus bas), c'est indiqué dans le PDF. « Le produit doit résister à un attaquant disposant de compétences techniques basiques et de ressources limitées. »
Ça c'est la décision 119, qui qualifie le service. L'application mobile, par contre, est qualifiée par la décision 120, niveau de garantie élémentaire et niveau de recommandation modéré:
emprunter le smartphone d’un proche, échanger la SIM avec la tienne,
Pas besoin d'échanger la SIM, il est parfaitement possible d'utiliser un téléphone pour recevoir les SMS et un deuxième téléphone pour exécuter l'application. J'exécute l'application sur un téléphone sans SIM, connecté en WiFi, et ça marche une fois sur deux.
Ça dépend des démarches. Tu peux faire une ouverture avec un compte de l'INPI, mais pour un changement d'adresse ou une fermeture d'activité, il te faut FranceConnect Plus.
(Quand j'écris que j'ai passé deux jours au téléphone avec le service clients, ce n'est pas une figure de style.)
Tu le sais parce que tu as réussi, ou tu le supposes parce que c'est écrit sur le site de l'URSSAF ? Ça ne m'étonnerait pas qu'ils te fassent remplir un formulaire avant de finalement te renvoyer sur le Guichet Unique.
Dans ce cas précis, je pense que c'est discutable. L'application a obtenu sa certification, et cela alors même que :
elle accepte de s'installer sur un système Android 6 qui n'est plus supporté depuis des années ;
elle accepte de s'installer sur un système dont la flash n'est pas chiffrée ;
elle est protégée par un code numérique de 4 chiffres, et pas par une passphrase forte.
J'imagine que la certification a été faite sur des principes généraux (protocoles cryptographiques utilisés, procédure de vérification d'identité) et que personne n'a jamais regardé l'application elle-même.
L'identité numérique est aussi nécessaire sur le « Guichet unique » de l'INPI. J'ai passé deux jours au téléphone avec des dames très gentilles (« Je suis d'accord, nous aussi on aimerait bien pouvoir vous dire de passer au guichet avec votre carte d'identité ») avant d'arriver à cette conclusion.
Résultat : j'ai retrouvé un vieux smartphone Android 6 (même pas chiffré!), je l'ai reinitialisé, j'ai ouvert un compte Google, j'ai mis à jour le Play Store, j'ai installé leur application (qui n'est en fait qu'une webview, mais on ne peut pas faire la manip depuis un navigateur), je suis passé à mon bureau de poste avec une pièce d'identité et mon smartphone habituel (qui n'est naturellement pas associé à un compte Google), j'ai attendu 24 heures, j'ai ouvert un compte sur laposte.fr, j'ai activé leur application… et je n'arrive toujours pas à me connecter au « Guichet unique » (« une erreur est survenue »).
Le support pour le multicast est obligatoire dans les hôtes, mais le routage du multicast est optionnel. En pratique, le multicast ne fonctionne donc que localement au lien: il est utile pour localiser les imprimantes localement connectées (Bonjour/Zeroconf/mDNS), mais pas pour communiquer sur l'Internet.
(Le multicast est aussi déployé dans les réseaux des FAI pour la télévision sur IP, mais l'infra n'est pas directement par l'utilisateur pour autre chose que recevoir les flux de télévision.)
Ton idée est sérieusement d'avoir pour un salon de 100 personnes un envoi de 100 flux par chaque machine? Tu te rends comptes de ce que ça représente comme bande passante
Ça fait dans les 50Mbit/s (pour de la basse résolution), donc c'est pas complètement absurde de nos jours. Bien-sûr, il faudrait éviter de recoder la vidéo 100 fois, et l'implémentation de WebRTC dans les navigateurs actuels ne permet pas ça.
Galène c'est sur https://galene.org/ et ça marche bien. En cliquant sur Try it out on peut comme pour Jitsi créer une conférence visio
Et si vous faites un mail amical à l'auteur (moi) en expliquant que c'est pour une bonne cause, il vous fera sûrement un groupe public dont vous êtes l'administrateur.
(Mais l'idéal c'est bien-sûr de s'autohéberger. Comme-ça, vous ne dépendez de la bonne volonté de personne.)
Ils ont fait une interface pour la gestion des salons?
Non, il n'y en a pas pour le moment.
La solution que la plupart des utilisateurs emploient, c'est d'activer la création automatique des groupes dans le serveur : vous faites un groupe, par exemple "/public", avec l'option "allow-subgroups" activée. Lorsqu'un utilisateur se connecte à un groupe "/public/quelquechose", le groupe est créé dynamiquement et reste actif pendant quatre heures.
Pour ce qui est d'une interface de gestion, comme le serveur remarque automatiquement la création d'un nouveau groupe, il suffit d'écrire une interface dans le framework de votre choix qui écrit des fichiers JSON sur disque. Ça devrait prendre une heure pour un programmeur web compétent.
Enfin, la version 0.5 de Galène sera capable de déléguer la gestion des groupes à un serveur tiers. Le code est dans la branche "auth" du dépôt de Galène, et vous trouverez un exemple de serveur d'authentification ici : https://galene.org/galene-auth-server.py
Il me semble que l'architecture est au final assez proche de Jitsi
Oui, et aussi de Janus et de Ion-SFU, que je cite sur galene.org. Ce sont tous des SFU, et ils sont tous bien faits.
Il n'était pas possible d'améliorer [Jitsi] ?
Jitsi est écrit en Java, ce qui complique un peu sont déploiement (il faut installer un JRE sur le serveur), et augmente sensiblement la consommation de mémoire. Par contre, j'avais sérieusement considéré la possibilité de baser Galène sur Janus, qui est économe, propre, et écrit en C; j'ai finalement décidé de faire mon propre serveur, j'ai peut-être eu tort. Quant à Ion-SFU, il n'était pas encore prêt à l'époque.
il y a du code commun entre les deux projets ?
Nous collaborons régulièrement avec les auteurs de Ion-SFU, qui, comme Galène, est basé sur Pion WebRTC. Lorsqu'il y a du code qui peut être utile aux deux projets, nous essayons de le contribuer à Pion: c'est mieux que de faire du copier-coller, et ça profite à tous les projets basés sur Pion.
Dans le cas de conf, le préchargement des PDF dans BBB est pas mal.
[…]
Il faudrait passer d'un mode SFU en MCU selon le nombre de personne ;-)
[…]
pouvoir diffuser simplement vers du webcast youtube ou autre
Il faut faire attention à ne pas ajouter trop de fonctionnalités : le but de Galène est d'être un logiciel simple, efficace et robuste et dont les fonctionnalités sont strictement limitées.
Des irresponsables sans éthique sont-ils les contributeurs avec qui tu souhaites collaborer pour ton projet ?
L'interface de Galène doit fonctionner sur tous les navigateurs: il est important qu'un étudiant qui a un problème d'ordinateur puisse suivre mon cours sur son smartphone. Comme je ne possède de smartphone moi-même, je dois compter sur la bonne volonté des utilisateurs pour me rapporter les problèmes avec Safari pour iOS — et cela alors même que, comme toi, j'ai des doutes sur les aspects éthiques de l'utilisation des systèmes d'Apple.
D'après /proc/cpuinfo, c'est un Haswell à 2.4Ghz, mais c'est une machine virtuelle, et je ne sais pas dans quelle mesure ça réflète le matériel sous-jacent.
Un SFU pousse les paquets sans les interpréter: toute l'intelligence est dans le client. Un MCU décode la vidéo qu'il reçoit, et la recode avant de l'envoyer au client.
Il y a un seul serveur (qu'il faut payer) et de nombreux clients (qui ont déjà été payés). C'est donc a priori une bonne idée que de distribuer les opérations coûteuses en CPU (le codage de la vidéo) sur les clients et d'économiser le CPU du serveur — avantage au SFU. Par contre, si on recode la vidéo, on peut faire plein de choses malines, par exemple combiner plusieurs vidéos en une seule mosaïque à basse résolution, convertir l'audio en un format compatible avec SIP — avantage au MCU.
Il me semble — mais je suis sans doute biaisé — que le modèle SFU est préférable lorsqu'on a assez de CPU et de débit côté client. Comme tu le fais remarquer, si le CPU est généralement disponible, ce n'est pas nécessairement le cas du débit. Galène contourne le problème en permettant au client de choisir quels flots il décide recevoir, par exemple uniquement l'audio, ou uniquement l'audio et la présentation.
En pratique, nous avons deux serveurs: un serveur à un seul cœur (galene.org), utilisé pour l'enseignement, pour les réunions d'une association, et pour les apéritifs confinés, et un serveur à quatre cœurs, payé par le CNRS, et réservé aux activités de recherche. Le petit serveur commence à s'essouffler autour de 400 flots, mais Galène ne se plante pas: les vidéos commencent à freezer, puis reprennent lorsque les gens éteignent leurs caméras. Le gros serveur sert pour les réunions du laboratoire et pour les exposés scientifiques; il a aussi servi lors d'une conférence internationale (SOCS'2020). On ne l'a pas encore chargé suffisamment pour savoir comment il se comporte en situation de crise.
Je suppose que c'est scénario d'usage du type 1 personne diffusant vers 70 autres,
Oui.
qu'il y ait 20 personnes […] dans une seule salle ou dans 10, c'est la même charge côté serveur ?
Pas du tout.
Avec 20 personnes dans un groupe, le serveur reçoit 20 flots, qu'il reémet chacun à 19 personnes. On a donc un total de 20+20*19 = 400 flots.
Avec 10 groupes de deux personnes chacun, le serveur reçoit 20 flots qu'il reémet à une seule personne chacun, pour un total de 20+20=40 flots.
Galène est capable, selon mes tests, de pousser de l'ordre de 400 flots par cœur. Sur un serveur à 4 cœurs, on devrait être capables de pousser 1600 flots, soit une réunion à 40 ou un amphi de 1600 personnes.
Je suis d'accord avec toi : c'est un compromis, voire une compromission.
Dans une vie antérieure, j'ai essayé d'éviter GitHub. Le résultat, c'est que les gens ne contribuaient pas: ils ne me soumettaient pas de rapports de bugs (flemme de s'authentifier sur un autre site), ils se plaignaient qu'il fallait apprendre de nouvelles manières de soumettre un patch, ou, carrément, ils trollaient les forums en disant que le code n'est pas libre puisqu'il n'est pas sur GitHub.
J'ai donc adopté un compromis: le code et le bug tracker sont sur GitHub, mais la liste de diffusion et la page web restent indépendantes. Comme tout compromis, il se fait critiquer des deux côtés : il y a des gens comme toi qui me critiquent pour mon utilisation de GitHub, et des gens qui se plaignent que je maintienne une page web au lieu d'utiliser un WiKi GitHub (regarde les archives de la liste de diffusion de Galène du 23 décembre).
Le protocole WebRTC (utilisé pour communiquer avec les navigateurs) chiffre et authentifie obligatoirement le traffic. On n'a donc pas le choix, il faut tout chiffrer.
Par curiosité — pourquoi as-tu besoin de communication en clair ? Est-ce pour des raisons légales ?
Est-ce que Galène est prévu pour fonctionner derrière un reverse proxy ou un load-balancer ?
Galène utilise trois protocoles :
HTTPS pour le serveur web intégré ;
WSS (WebSocket au dessus de TLS) pour le chat et la signalisation ;
SRTP pour le traffic audio et vidéo.
Pour le traffic HTTPS et WSS, tu fais comme d'habitude. Pour le traffic SRTP, il te faudra un serveur TURN, qui est essentiellement un proxy UDP. Le README inclus avec Galène donne quelques indications sur la mise en place.
Galène va essayer d'établier un flot SRTP direct avant de se rabattre sur TURN après quelques centaines de millisecondes. Je vais ajouter une option qui indique que seul TURN doit être utilisé.
Le site mentionne que Galène a fonctionné avec succès sur de l'ARM64. Quelles sont les cartes ARM64 qui ont été utilisées pour le faire fonctionner ?
[^] # Re: question existentielle
Posté par jch . En réponse au journal France Connect Plusse. Évalué à 2. Dernière modification le 22 juillet 2024 à 23:06.
« À cette fin, les États membres devraient divulguer le code source des composants logiciels de l’application utilisateur des portefeuilles européens d’identité numérique, y compris ceux qui sont liés au traitement des données à caractère personnel et des données des personnes morales. La publication de ce code source sous une licence à code source ouvert (open source) devrait permettre à la société, y compris les utilisateurs et les développeurs, de comprendre le fonctionnement du code, d’en faire l’audit et de l’examiner. […] Toutefois, dans certains cas, la divulgation du code source des bibliothèques utilisées, du canal de communication ou d’autres éléments qui ne sont pas hébergés sur le dispositif de l’utilisateur pourrait être limitée par les États membres, pour des motifs dûment justifiés, en particulier à des fins de sécurité publique.»
— Règlement (UE) 2024/1183, paragraphe 33. C'est moi qui souligne.
[^] # Re: Niveau de garantie != niveau de recommandation
Posté par jch . En réponse au journal L'Identité Numérique de la Poste, mal sécurisée mais au moins elle ne marche pas. Évalué à 2.
Niveau de garantie élémentaire (le plus bas), c'est indiqué dans le PDF. « Le produit doit résister à un attaquant disposant de compétences techniques basiques et de ressources limitées. »
[^] # Re: Niveau de garantie != niveau de recommandation
Posté par jch . En réponse au journal L'Identité Numérique de la Poste, mal sécurisée mais au moins elle ne marche pas. Évalué à 2.
Ça c'est la décision 119, qui qualifie le service. L'application mobile, par contre, est qualifiée par la décision 120, niveau de garantie élémentaire et niveau de recommandation modéré:
https://cyber.gouv.fr/produits-services-qualifies/application-mobile-identite-numerique-la-poste
[^] # Re: Suggestions pragmatiques
Posté par jch . En réponse au journal France Connect Plusse. Évalué à 6.
C'est pour mieux facturer, mon enfant.
Développeur web, ça se facture dans les 40€ de l'heure. Développeur Android, ça peut aller jusqu'à 100€.
[^] # Re: Suggestions pragmatiques
Posté par jch . En réponse au journal France Connect Plusse. Évalué à 3.
Pas besoin d'échanger la SIM, il est parfaitement possible d'utiliser un téléphone pour recevoir les SMS et un deuxième téléphone pour exécuter l'application. J'exécute l'application sur un téléphone sans SIM, connecté en WiFi, et ça marche une fois sur deux.
[^] # Re: Guichet unique de l'INPI
Posté par jch . En réponse au journal L'Identité Numérique de la Poste, mal sécurisée mais au moins elle ne marche pas. Évalué à 4.
Ça dépend des démarches. Tu peux faire une ouverture avec un compte de l'INPI, mais pour un changement d'adresse ou une fermeture d'activité, il te faut FranceConnect Plus.
(Quand j'écris que j'ai passé deux jours au téléphone avec le service clients, ce n'est pas une figure de style.)
[^] # Re: Urssaf
Posté par jch . En réponse au journal France Connect Plusse. Évalué à 3.
Tu le sais parce que tu as réussi, ou tu le supposes parce que c'est écrit sur le site de l'URSSAF ? Ça ne m'étonnerait pas qu'ils te fassent remplir un formulaire avant de finalement te renvoyer sur le Guichet Unique.
# Signature eIDAS privée
Posté par jch . En réponse au journal France Connect Plusse. Évalué à 8.
D'autres ont échoué avant toi.
[^] # L'ANSSI est réaliste ?
Posté par jch . En réponse au journal L'Identité Numérique de la Poste, mal sécurisée mais au moins elle ne marche pas. Évalué à 3.
Dans ce cas précis, je pense que c'est discutable. L'application a obtenu sa certification, et cela alors même que :
J'imagine que la certification a été faite sur des principes généraux (protocoles cryptographiques utilisés, procédure de vérification d'identité) et que personne n'a jamais regardé l'application elle-même.
# Identité numérique et guichet unique INPI
Posté par jch . En réponse au journal La poste, fer de lance de l'identité numérique, l'impose à ses nouveaux comptes courriels. Évalué à 2.
L'identité numérique est aussi nécessaire sur le « Guichet unique » de l'INPI. J'ai passé deux jours au téléphone avec des dames très gentilles (« Je suis d'accord, nous aussi on aimerait bien pouvoir vous dire de passer au guichet avec votre carte d'identité ») avant d'arriver à cette conclusion.
Résultat : j'ai retrouvé un vieux smartphone Android 6 (même pas chiffré!), je l'ai reinitialisé, j'ai ouvert un compte Google, j'ai mis à jour le Play Store, j'ai installé leur application (qui n'est en fait qu'une webview, mais on ne peut pas faire la manip depuis un navigateur), je suis passé à mon bureau de poste avec une pièce d'identité et mon smartphone habituel (qui n'est naturellement pas associé à un compte Google), j'ai attendu 24 heures, j'ai ouvert un compte sur laposte.fr, j'ai activé leur application… et je n'arrive toujours pas à me connecter au « Guichet unique » (« une erreur est survenue »).
Le web est plein de témoignages semblables, tenez:
https://www.plus.transformation.gouv.fr/experiences/4531155_impossible-de-signer-une-demarche-sur-linpi-sans-smartphone
[^] # Re: Vive IPv6
Posté par jch . En réponse au journal meet.jit.si se ferme … un peu. Évalué à 3.
Le support pour le multicast est obligatoire dans les hôtes, mais le routage du multicast est optionnel. En pratique, le multicast ne fonctionne donc que localement au lien: il est utile pour localiser les imprimantes localement connectées (Bonjour/Zeroconf/mDNS), mais pas pour communiquer sur l'Internet.
(Le multicast est aussi déployé dans les réseaux des FAI pour la télévision sur IP, mais l'infra n'est pas directement par l'utilisateur pour autre chose que recevoir les flux de télévision.)
[^] # Re: Vive IPv6
Posté par jch . En réponse au journal meet.jit.si se ferme … un peu. Évalué à 3.
Ça fait dans les 50Mbit/s (pour de la basse résolution), donc c'est pas complètement absurde de nos jours. Bien-sûr, il faudrait éviter de recoder la vidéo 100 fois, et l'implémentation de WebRTC dans les navigateurs actuels ne permet pas ça.
[^] # Re: alternatives qui utilisent jitsi
Posté par jch . En réponse au journal meet.jit.si se ferme … un peu. Évalué à 5.
Et si vous faites un mail amical à l'auteur (moi) en expliquant que c'est pour une bonne cause, il vous fera sûrement un groupe public dont vous êtes l'administrateur.
(Mais l'idéal c'est bien-sûr de s'autohéberger. Comme-ça, vous ne dépendez de la bonne volonté de personne.)
[^] # Re: Et sinon Galène
Posté par jch . En réponse au lien Quel logiciel de visioconférence utiliser ?. Évalué à 4. Dernière modification le 26 janvier 2022 à 15:51.
Non, il n'y en a pas pour le moment.
La solution que la plupart des utilisateurs emploient, c'est d'activer la création automatique des groupes dans le serveur : vous faites un groupe, par exemple "/public", avec l'option "allow-subgroups" activée. Lorsqu'un utilisateur se connecte à un groupe "/public/quelquechose", le groupe est créé dynamiquement et reste actif pendant quatre heures.
Pour ce qui est d'une interface de gestion, comme le serveur remarque automatiquement la création d'un nouveau groupe, il suffit d'écrire une interface dans le framework de votre choix qui écrit des fichiers JSON sur disque. Ça devrait prendre une heure pour un programmeur web compétent.
Enfin, la version 0.5 de Galène sera capable de déléguer la gestion des groupes à un serveur tiers. Le code est dans la branche "auth" du dépôt de Galène, et vous trouverez un exemple de serveur d'authentification ici : https://galene.org/galene-auth-server.py
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 2.
N'hésite pas à envoyer une annonce à galene@lists.galene.org.
[^] # Re: Jitsi
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 8.
Oui, et aussi de Janus et de Ion-SFU, que je cite sur galene.org. Ce sont tous des SFU, et ils sont tous bien faits.
Jitsi est écrit en Java, ce qui complique un peu sont déploiement (il faut installer un JRE sur le serveur), et augmente sensiblement la consommation de mémoire. Par contre, j'avais sérieusement considéré la possibilité de baser Galène sur Janus, qui est économe, propre, et écrit en C; j'ai finalement décidé de faire mon propre serveur, j'ai peut-être eu tort. Quant à Ion-SFU, il n'était pas encore prêt à l'époque.
Nous collaborons régulièrement avec les auteurs de Ion-SFU, qui, comme Galène, est basé sur Pion WebRTC. Lorsqu'il y a du code qui peut être utile aux deux projets, nous essayons de le contribuer à Pion: c'est mieux que de faire du copier-coller, et ça profite à tous les projets basés sur Pion.
Il faut faire attention à ne pas ajouter trop de fonctionnalités : le but de Galène est d'être un logiciel simple, efficace et robuste et dont les fonctionnalités sont strictement limitées.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 4.
Sur un Raspberry Pi 4 — probablement, l'Ethernet est connecté en RGMII, et la librairie standard de Go implémente AES en assembleur NEON.
Sur un Raspberry Pi 1 — probablement pas, l'Ethernet est connecté en USB, le coût des entrées-sorties risque d'être prohibitif.
Si tu décides d'essayer, je serai reconnaissant si tu postes tes conclusions sur la liste de diffusion de Galène.
[^] # Re: Pourquoi le choix GAFAM ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 7.
L'interface de Galène doit fonctionner sur tous les navigateurs: il est important qu'un étudiant qui a un problème d'ordinateur puisse suivre mon cours sur son smartphone. Comme je ne possède de smartphone moi-même, je dois compter sur la bonne volonté des utilisateurs pour me rapporter les problèmes avec Safari pour iOS — et cela alors même que, comme toi, j'ai des doutes sur les aspects éthiques de l'utilisation des systèmes d'Apple.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 2.
Le VPS bas de gamme "Value" d'OVH: https://www.ovhcloud.com/fr/vps/compare/
D'après /proc/cpuinfo, c'est un Haswell à 2.4Ghz, mais c'est une machine virtuelle, et je ne sais pas dans quelle mesure ça réflète le matériel sous-jacent.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 10.
Un SFU pousse les paquets sans les interpréter: toute l'intelligence est dans le client. Un MCU décode la vidéo qu'il reçoit, et la recode avant de l'envoyer au client.
Il y a un seul serveur (qu'il faut payer) et de nombreux clients (qui ont déjà été payés). C'est donc a priori une bonne idée que de distribuer les opérations coûteuses en CPU (le codage de la vidéo) sur les clients et d'économiser le CPU du serveur — avantage au SFU. Par contre, si on recode la vidéo, on peut faire plein de choses malines, par exemple combiner plusieurs vidéos en une seule mosaïque à basse résolution, convertir l'audio en un format compatible avec SIP — avantage au MCU.
Il me semble — mais je suis sans doute biaisé — que le modèle SFU est préférable lorsqu'on a assez de CPU et de débit côté client. Comme tu le fais remarquer, si le CPU est généralement disponible, ce n'est pas nécessairement le cas du débit. Galène contourne le problème en permettant au client de choisir quels flots il décide recevoir, par exemple uniquement l'audio, ou uniquement l'audio et la présentation.
En pratique, nous avons deux serveurs: un serveur à un seul cœur (galene.org), utilisé pour l'enseignement, pour les réunions d'une association, et pour les apéritifs confinés, et un serveur à quatre cœurs, payé par le CNRS, et réservé aux activités de recherche. Le petit serveur commence à s'essouffler autour de 400 flots, mais Galène ne se plante pas: les vidéos commencent à freezer, puis reprennent lorsque les gens éteignent leurs caméras. Le gros serveur sert pour les réunions du laboratoire et pour les exposés scientifiques; il a aussi servi lors d'une conférence internationale (SOCS'2020). On ne l'a pas encore chargé suffisamment pour savoir comment il se comporte en situation de crise.
[^] # Re: Moins gourmand que BigBlueButton ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 9.
Oui.
Pas du tout.
Avec 20 personnes dans un groupe, le serveur reçoit 20 flots, qu'il reémet chacun à 19 personnes. On a donc un total de 20+20*19 = 400 flots.
Avec 10 groupes de deux personnes chacun, le serveur reçoit 20 flots qu'il reémet à une seule personne chacun, pour un total de 20+20=40 flots.
Galène est capable, selon mes tests, de pousser de l'ordre de 400 flots par cœur. Sur un serveur à 4 cœurs, on devrait être capables de pousser 1600 flots, soit une réunion à 40 ou un amphi de 1600 personnes.
[^] # Re: Reverse proxy et matériel ARM64
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 4.
Apparemment pas : https://www.raspberrypi.org/forums/viewtopic.php?t=243410
[^] # Re: Pourquoi le choix GAFAM ?
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 10.
Je suis d'accord avec toi : c'est un compromis, voire une compromission.
Dans une vie antérieure, j'ai essayé d'éviter GitHub. Le résultat, c'est que les gens ne contribuaient pas: ils ne me soumettaient pas de rapports de bugs (flemme de s'authentifier sur un autre site), ils se plaignaient qu'il fallait apprendre de nouvelles manières de soumettre un patch, ou, carrément, ils trollaient les forums en disant que le code n'est pas libre puisqu'il n'est pas sur GitHub.
J'ai donc adopté un compromis: le code et le bug tracker sont sur GitHub, mais la liste de diffusion et la page web restent indépendantes. Comme tout compromis, il se fait critiquer des deux côtés : il y a des gens comme toi qui me critiquent pour mon utilisation de GitHub, et des gens qui se plaignent que je maintienne une page web au lieu d'utiliser un WiKi GitHub (regarde les archives de la liste de diffusion de Galène du 23 décembre).
[^] # Re: Reverse proxy et matériel ARM64
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 4.
Le protocole WebRTC (utilisé pour communiquer avec les navigateurs) chiffre et authentifie obligatoirement le traffic. On n'a donc pas le choix, il faut tout chiffrer.
Par curiosité — pourquoi as-tu besoin de communication en clair ? Est-ce pour des raisons légales ?
[^] # Re: Reverse proxy et matériel ARM64
Posté par jch . En réponse à la dépêche Galène, un serveur de vidéoconférence libre. Évalué à 10. Dernière modification le 23 décembre 2020 à 13:19.
Galène utilise trois protocoles :
Pour le traffic HTTPS et WSS, tu fais comme d'habitude. Pour le traffic SRTP, il te faudra un serveur TURN, qui est essentiellement un proxy UDP. Le README inclus avec Galène donne quelques indications sur la mise en place.
Galène va essayer d'établier un flot SRTP direct avant de se rabattre sur TURN après quelques centaines de millisecondes. Je vais ajouter une option qui indique que seul TURN doit être utilisé.
J'utilise des Olinuxino-A64 d'Olimex; la caractéristique importante pour Galène, c'est la crypto matérielle. J'ai décrit mes expériences ici : https://www.irif.fr/~jch/software/olimex-a64.html