Documentation en cours de rédaction, reposant sur un processus nécessitant des travaux complémentaires. Ne peut être utilisée en l'état en production. Cette documentation ne concerne que la version 3.6.0 et supérieure de Pod. Il ne faut pas confondre ce système avec l'ancien système utilisé pour Pod v2, devenu obsolète. |
Le module des réunions de Pod repose sur l'utilisation de BigBlueButton.
Pour informations, BigBlueButton (https://bigbluebutton.org/) est un outil de classe virtuelle ayant les fonctionnalités suivantes :
Cependant, l'une des plus grosses contraintes de BigBlueButton concerne la limite de 200 é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 200 é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.
Il peut y avoir aussi d'autres cas où vous pouvez souhaiter séparer l'interface des présentateurs de celles des auditeurs, vis-à-vis des droits.
Ainsi, la solution pour résoudre cette problématique est de proposer un mode webinaire pour le module des réunions de Pod.
Ce mode webinaire permet de transmettre des informations à un large public via une diffusion en direct (accessible depuis la page des directs de la plateforme) et une interaction - si l'usager le souhaite - via un chat intégré.
L'idée étant de séparer les présentateurs des auditeurs:
En terme d'interface dans Pod, voici ce que cela donne :
Cette solution repose sur :
En cours de définition. cf. https://www.renater.fr/connecteur-de-salles-la-solution-dinteroperabilite-entre-les-differents-systemes-de-visioconference/
Voici la configuration nécessaire à réaliser dans son settings_local.py :
Paramètre | Valeur par défaut | Description |
---|---|---|
USE_MEETING_WEBINAR | False | Activation du mode Webinaire pour le module des réunions |
MEETING_WEBINAR_SIPMEDIAGW_URL | URL du serveur SIPMediaGW qui gère les webinaires (Ex: https://sipmediagw.univ.fr) | |
MEETING_WEBINAR_SIPMEDIAGW_TOKEN | Jeton bearer du serveur SIPMediaGW qui gère les webinaires | |
MEETING_WEBINAR_FIELDS | ("is_webinar", "enable_chat",) | Permet de définir les champs complémentaires du formulaire de création d’un webinaire. Ces champs complémentaires sont affichés directement dans la page de formulaire d’un webinaire. |
MEETING_WEBINAR_AFFILIATION | "['faculty', 'employee', 'staff']" | Groupes d’accès ou affiliations des personnes autorisées à créer un webinaire |
MEETING_WEBINAR_GROUP_ADMIN | webinar admin | Groupe des personnes autorisées à créer un webinaire |
Typiquement, voici un exemple de settings_local.py permettant d'utiliser ce mode webinaire :
################ # Utilisation du mode Webinaire pour le module des réunions USE_MEETING_WEBINAR = True # URL du serveur SIPMediaGW qui gère les webinaires (Ex: https://sipmediagw.univ.fr) MEETING_WEBINAR_SIPMEDIAGW_URL = "https://sipmediagw.univ.fr" # Jeton bearer du serveur SIPMediaGW qui gère les webinaires MEETING_WEBINAR_SIPMEDIAGW_TOKEN = "token" # Options possibles pour un webinaire MEETING_WEBINAR_FIELDS = ( "is_webinar", "enable_chat", ) # Groupes d’accès ou affiliations des personnes autorisées à créer un webinaire MEETING_WEBINAR_AFFILIATION = ["faculty", "employee", "staff"] # Groupe des admins des webinaires MEETING_WEBINAR_GROUP_ADMIN = "webinar admin" ################ |
Pour utiliser cette fonctionnalité, il est nécessaire de définir les informations liées à la publication RTMP et au streaming HLS.
Pour ce faire, il est nécessaire d'accéder au module d'Administration de Pod et de définir ses informations via le nouvel accès "Passerelles de live".
Ce nouveau système de passerelle de live fait la jointure entre une adresse RTMP et un diffuseur de Pod, déjà existants dans Pod, pour ceux qui utilisent des directs.
Ces informations sont accessible dans la partie Administration / Sessions / Passerelles de live
Pour ajouter une passerelle de live, il suffit de :
Pour plus d'informations sur les directs, veuillez consulter la documentation : https://www.esup-portail.org/wiki/x/BgC8KQ Par exemple, si vous saisissez :
Cette passerelle de live pourra gérer un webinaire; le flux vidéo et audio sera envoyé par SIPMediaGW via le protocole RTMP au serveur live.univ.fr, sur l'application live avec le nom nom. Le direct du webinaire, affiché dans la page des directs de Pod, lira le flux vidéo et audio via le protocole HLS à l'adresse https://live.univ.fr/hls/nom.m3u8. |
Chaque passerelle de live pourra alors être utilisé pour réaliser un webinaire. Cela signifie qu'il est possible d'avoir plusieurs passerelles de live pour pouvoir gérer plusieurs webinaires en parallèle (sur des plages horaires qui se chevauchent). Par exemple, si je défini 2 passerelles de live, il pourra y avoir 2 webinaires en parallèle sur les mêmes périodes. Bien entendu, il faut que le serveur SIPMediaGW (ou les serveurs SIPMediaGW accessibles derrière un proxy) aient les ressources nécessaires pour gérer autant de webinaires. |
Le principe de ce mode webinaire est d'être le plus simple et le plus intuitif possible pour l'usager :
Le fait de créer un webinaire va automatiquement créer un nouvel évènement accessible dans la page des directs (selon le paramétrage du diffuseur utilisé par la passerelle de live). |
Lorsque le présentateur démarre le webinaire :
L'utilisateur streaming, utilisé par SIPMediaGW simule un usager lambda. Il va alors réaliser une connexion au Pod de départ et participer à la réunion BigBlueButton en cours. Côté réseau, cela signifie que Pod doit être accessible par le serveur SIPMediaGW (paramétré via MEETING_WEBINAR_SIPMEDIAGW_URL) sur les ports Web (80, 443). |
Pendant le webinaire, le présentateur peut utiliser l'ensemble des options et actions sur le webinaire, à savoir :
Le fait d'arrêter le direct correspond à envoyer une requête de type Stop au serveur SIPMediaGW; à l'heure actuelle, l'arrêt prends de l'ordre de 10s. Ainsi, il peut y avoir un peu d'attente lors de l'arrêt du direct, redémarrage du direct et lors d'un clic sur Terminer le webinaire. Par contre, le démarrage est quant à lui très rapide. |
Le présentateur peut également modifier à sa convenance la date et la durée du webinaire; l'évènement est modifié en conséquence. Cela peut-être pratique pour tester le système avant le jour J. |
2 nouvelles interfaces sont maintenant disponibles dans l'administration, à savoir :
Il y a aussi le module de gestion des directs, en particulier pour les évènements :
Selon votre configuration (cf. fichier pod_uwsgi.ini), il vous est possible de retrouver les logs de ce mode webinaire dans le fichier de logs applicatif de Pod.
Par exemple, il peut s'agir de /home/pod/django_projects/podv3/uwsgi/uwsgi-pod.log ou /var/log/syslog
Il suffit de rechercher les lignes contenant le mot-clé webinar.
Voici un exemple de ligne en lien avec les webinaires :
[29/Mar/2024 14:50:11] INFO [webinar - webinar.py:225] start_rtmp_gateway for meeting 13 “Webinaire du 29 mars 2024”: {"res": "ok", "app": "streaming", "uri": ""} (EXCEPTION: None)
Il faut savoir que toutes les actions importantes sont loggués, même s'il n'y a pas d'erreurs. |