Arborescence des pages

Vous regardez une version antérieure (v. /wiki/pages/viewpage.action?pageId=958988294) de cette page.

afficher les différences afficher l'historique de la page

« Afficher la version précédente Vous regardez la version actuelle de cette page. (v. 4) afficher la version suivante »

Cette documentation ne concerne que la future version de Pod v2.8, prévue fin février 2021.

Contexte et solution apportée

Contexte

Suite à la pandémie de COVID-19, il a été mis en place, à l'université de Montpellier, un système de classe virtuelle Open Source reposant sur Big Blue Button (BBB).

Pour informations, BigBlueButton (https://bigbluebutton.org/) est un outil de classe virtuelle ayant les fonctionnalités suivantes :

  • Vidéo/webcam
  • Audio
  • Chat
  • Partage de document + annotation
  • Partage d’écran
  • Sondage
  • Enregistrement
  • Création de groupes
  • Prises de notes partagées
  • Intégration de vidéos externes
  • Intégration Moodle et WordPress

Cependant, l'une des plus grosses contraintes de BigBlueButton concerne la limite de 100 étudiants par session (cf. https://docs.bigbluebutton.org/support/faq.html#how-many-simultaneous-users-can-bigbluebutton-support).

Dans la plupart des cas, cette limite de 100 étudiants par session n'est pas un blocage, mais dans certains cas bien précis - par exemple, des cours magistraux pour des L1 - cette limite devient bloquante à l'utilisation de BigBlueButton.

Solution

Pour résoudre cette problématique, je suis parti d'une solution mise en place à l'Université Polytechnique Hauts-de-France et l'ai modifié pour l'intégrer totalement dans Pod v2.

Cette solution fonctionne pour BigBlueButton mais également pour Scalelite (cf. https://github.com/blindsidenetworks/scalelite), un système de répartition de charge pour BigBlueButton.

L'idée de cette solution est de :

  • Récupérer régulièrement les informations concernant les sessions en cours, ainsi que les usagers, dans BigBlueButton pour les insérer dans la base de données de Pod.
    Cf. le système de publication des présentations Web de BigBlueButton vers Podv2 : https://www.esup-portail.org/wiki/x/AgCBNg

  • Traiter ces données pour permettre aux utilisateurs, connectés dans Pod, de pouvoir réaliser un direct de leur session BigBlueButton en cours,



    Il ne faut pas que l'utilisateur utilise de salles privées dans BigBlueButton. En effet, le système de salles privées de BigBlueButton ouvre des popups, et il pourrait arriver que le direct n'affiche que l'appel de la popup.

    Il faut également que l'utilisateur mette fin à la réunion pour que le direct s'arrête (une déconnexion n'est pas suffisante et le direct continue alors).

  • Pour réaliser ce direct, l'utilisateur devra valider les options possibles en validant un formulaire :



    Ces options sont les suivantes :

    • Accès restreint : Mettre l'accès restreint permet que le direct ne soit accessible qu'aux utilisateurs authentifiés, typiquement via le système d'authentification CAS de l'université. Sans accès restreint, le direct peut être accessible à tous.

    • Affichage du chat public : En cas d'activation, le chat public sera affiche dans la partie gauche du direct.

    • Enregistrer la session dans Mes vidéos : Cette option permet l'enregistrement de la vidéo du direct en même temps. Cela signifie qu'une fois le direct réalisé, le fichier vidéo sera automatiquement publié en mode Brouillon pour cet utilisateur et sera alors mis automatiquement dans la file d'attente pour encodage.

      Cette option peut être désactivée dans le paramétrage de Pod et ne sera alors pas affiché aux utilisateurs (cf. explications techniques ci-dessous).

    • Activer le chat : Via cette option, un tchat sera affiché dans la page de ce direct de Pod, sous la vidéo en direct. Les messages envoyés dans le chat de cette page de direct se retrouveront dans le chat public de BigBlueButton. Ainsi, les étudiants qui consultent la page de direct pourront communiquer avec l'enseignant et autres usagers de BigBlueButton.

      Pour informations, seuls les utilisateurs authentifiés sur la page de direct pourront envoyer des messages, même si le direct est accessible à tous.

      Non authentifié, l'utilisateur obtiendra ce message :

      Une fois authentifié, l'utilisateur pourra envoyer un message :

      Dans BigBlueButton, le nom de l'utilisateur qui a envoyé le message sera bien entendu affiché :

    Une fois le formulaire validé, le direct sera lancé en moins d'une minute.

  • Les étudiants pourront accéder au direct créé automatiquement, via l'onglet des directs de Pod.



    Le système va créer automatiquement un diffuseur (terminologie Pod) dont le nom correspond à une concaténation de (BBB) et du nom de la session dans BigBlueButton.

    Bien entendu, ce diffuseur sera automatiquement supprimé lors de l'arrêt de la session BigBlueButton.

Remarques importantes


Aucun impact sur BigBlueButton

Cette solution repose totalement sur Pod et n'impacte en rien BigBlueButton. Aucune modification n'est à réaliser côté BigBlueButton.

Les utilisateurs dans BigBlueButton

Les informations concernant les modérateurs dans BigBlueButton dépendent du client BBB utilisé : Greenlight ou le plugin mod_bigbluebuttonbn pour Moodle.

Le système réalisé n'a été testé qu'avec le plugin mod_bigbluebuttonbn pour Moodle (CASifié, donc les données proviennent de notre annuaire LDAP); cela signifie que les modérateurs sont définis - dans mon cas - sous la forme "Prenom Nom".

Il est possible de paramétrer ce format, via le paramètre BBB_USERNAME_FORMAT. A l'heure actuelle, les formats "Prenom Nom" ou "Nom Prenom" peuvent être gérés via ce paramétrage.

(avertissement) Ce point est crucial pour que le système fonctionne correctement : une correspondance doit exister sur le "Prenom Nom" ou "Nom Prenom" (selon la configuration BBB_USERNAME_FORMAT) des modérateurs de BigBlueButton et le "Prenom Nom" des utilisateurs dans la base de données de Pod.

(question) A priori, cela devrait pouvoir fonctionner avec Greenlight si celui-ci est configuré pour utiliser l'annuaire LDAP de l'établissement et les champs givenName et sn.

Architecture de la solution

  • Aucune étiquette