Arborescence des pages

Vous regardez une version antérieure (v. /wiki/display/ES/Mise+en+place+du+mode+webinaire+pour+les+sessions+BigBlueButton+pour+Pod+v3) 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. 8) afficher la version suivante »


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.

Contexte et solution apportée

Contexte

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 :

  • 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 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.

Solution

Solution : le mode webinaire

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:

  • les présentateurs devront rejoindre la réunion BigBlueButton,
  • les auditeurs devront accéder au direct sur Pod.

Interface dans Pod

En terme d'interface dans Pod, voici ce que cela donne :

  • Édition d'un webinaire, par le présentateur (notion de premier modérateur dans BigBlueButton)


  • Les explications sur le mode webinaire, accessible aux usagers


  • Liste des réunions et webinaires


  • L'interface BigBlueButton, avec le compte streaming


  • La page des évènements en direct


  • Le direct pour les auditeurs


  • Les informations sur un webinaire en cours


Architecture de la solution

Cette solution repose sur :

SIPMediaGW par RENATER

En cours de définition. cf. https://www.renater.fr/connecteur-de-salles-la-solution-dinteroperabilite-entre-les-differents-systemes-de-visioconference/

Configuration et actions complémentaires dans Pod

Configuration dans Pod

Voici la configuration nécessaire à réaliser dans son settings_local.py :

ParamètreValeur par défautDescription
USE_MEETING_WEBINARFalseActivation 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", "show_chat", "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_ADMINwebinar adminGroupe 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",
        "show_chat",
        "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"
################

Actions complémentaires dans Pod

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 "Serveurs d'ingestion".

(info) Ce nouveau système de serveur d'ingestion 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 / Serveurs d'ingestion.


Pour ajouter un serveur d'ingestion, il suffit de :

  • saisir l'adresse URL du flux RTMP, sous la forme rtmp://live.univ.fr/live/nom
  • sélectionner un diffuseur Pod, qui pointe vers un flux HLS. Il est possible de choisir les paramètres de ce diffuseur.


Pour plus d'informations sur les directs, veuillez consulter la documentation : https://www.esup-portail.org/wiki/x/BgC8KQ

Par exemple, si vous saisissez :

  • Flux RTMP : rtmp://live.univ.fr/live/nom
  • Flux HLS (diffuseur) : https://live.univ.fr/hls/nom.m3u8

Ce serveur d'ingestion 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 serveur d'ingestion pourra alors être utilisé pour réaliser un webinaire.

Cela signifie qu'il est possible d'avoir plusieurs serveurs d'ingestion pour pouvoir gérer plusieurs webinaires en parallèle (sur des plages horaires qui se chevauchent).

Par exemple, si je définis 2 serveurs d'ingestion, il pourra y avoir 2 webinaires 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.

Fonctionnement global

Le principe de ce mode webinaire est d'être le plus simple et le plus intuitif possible pour l'usager :

  • le présentateur - s'il a les droits adéquats (cf. paramétrage ci dessus) - créé une réunion en mode webinaire. Il peut choisir ses options concernant :

    • l'affichage du chat public : pour afficher le chat public dans le direct, ce qui n'est pas recommandé par défaut.
    • l'activation du chat : pour donner accès à un chat sur la page en direct pour les auditeurs. Les messages envoyés dans le chat de cette page en direct se retrouveront dans le chat public de BigBlueButton.


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 le serveur d'ingestion).

  • la réunion BigBlueButton est lancée.
  • une requête, de démarrage, sera réalisée sur le serveur configuré SIPMediaGW qui va alors se connecter à Pod avec utilisateur "streaming" sur la réunion définie comme 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).



Exploitation

L'interface d'administration

Les fichiers de logs

  • Aucune étiquette