Numéro d'appel & code unique

[klorydryk]

Numéro unique :
générés et conservés par le frontal
Salon supprimé libère le code au bout d'un an
uniques par pool (obligatoire)
codes numériques uniquement
taille recommandée : 9 chiffres
Offrir la possibilité de modifier le code téléphone (comme l'url)
Dans un second temps, créer une récurrence du renouvellement des url et code d'accès téléphone + envoi de mail au propriétaire avec les nouvelles infos

Code envoyé au Scalelite dans le create()
(Affichage dans BBB de la séparation en 3 groupes de 3 chiffres séparés par un espace : à faire par Arawa)

[LoanR]

Pas de numéro d'appel sur les instances mutu

[LoanR]

@klorydryk, sur vos instances, vous avez des numéros de configurés pour qu'ils soient disponibles pour BBB ? Comment vous gérez cette liste ?

[klorydryk]

il y aura un numéro de tel par instance B3Desk, qui doit être stocké dans la configuration de cette instance (pour pouvoir être affiché dans le carton d'invitation). Il peut être envoyé lors du Create via "dialNumber" et le code pin via "voiceBridge"

[LoanR]

Le scalelite devant l'instance BBB de test semble refuser les PIN envoyés par B3Desk.

USE_EXTERNAL_VOICE_BRIDGE: Whether or not to try to use the voiceBridge number passed by the BigBlueButton API client. Defaults to false. If your API client generates numbers compatible with your BigBlueButton configuration, you can change this to true to use them. Note that Scalelite will ignore the voice bridge number provided, and generate a new one, if the number is already in use by a different meeting.

Tu pourrais me confirmer cette conf ?

[LoanR]

@klorydryk Aujourd'hui, le code PIN est généré par BigBlueButton et / ou Scalelite.
Il y a une persistance de ce code entre les utilisations d'un salon, le Scalelite semble garder la valeur.

Le jour ou la responsabilité de la génération de ce code PIN passe à B3Desk, on a le risque d'en générer un qui existe déjà :

• il n'y a pas d'interface prévue pour récupérer les code PIN déjà attribués, on ne peut récupérer cette info seulement si le meeting est en cours
• on peut récupérer cette info et la sauvegarder sur les meeting en question pour pouvoir générer les prochains PIN "libres"
• mais comme il y a persistance de cette info mais de façon "silencieuse", on ne peut pas être sûr d'avoir envoyé un PIN qui n'est utilisé par aucun salon non en cours.

Des questions :

• Est-ce qu'il y a une conf à faire côté Scalelite pour lui retirer la persistance ?
• Si on arrive à ne plus avoir de persistance, est-ce qu'il y a un enjeu à ce qu'un même meeting ait toujours le même PIN ?

[LoanR]

Scalelite semble ne pas nous laisser la possibilité de modifier un PIN de meeting une fois qu'il a été créé :
https://github.com/blindsidenetworks/scalelite/blob/ba4f88e2b648fcfa98271ddc11373c77bec9d9ec/app/models/meeting.rb#L27

    raise ArgumentError, "Voice bridge cannot be updated once set" unless @voice_bridge.nil?

[klorydryk]

B3Desk devient LE générateur de code PIN des salons.

• Scalelite peut les conserver mais doit pouvoir être mis à jour par B3Desk
• Si Scalelite ne peut pas modifier un code PIN il faut
  • corriger ça dans le code BBB
  • vider la base Scalelite des salons de ses codes PIN avant la bascule

[LoanR]

Pour le moment, ce qui semble possible de faire :

• envoyer un PIN à Scalelite pour la création d'un nouveau salon (après déploiement) avec la configuration appropriée (USE_EXTERNAL_VOICE_BRIDGE=True chez Scalelite). Ce PIN ne pourra pas être modifiable ensuite. Si ce PIN est déjà utilisé par un autre meeting, Scalelite se chargera d'en générer un autre, ce qui sera assez déceptif pour le modérateur qui veut diffuser l'information.
• récupérer au compte goutte les PIN déjà utilisés (lorsque le meeting est en cours). Cela réduira au fur et à mesure le risque de générer un PIN déjà utilisé et permettra de prévenir un modérateur que le PIN qu'il a entré est déjà utilisé

Ce qu'on ne peut pas faire dans l'immédiat :

• éditer un PIN pour un salon existant
• être certain à la création d'un salon que le PIN personnalisé qu'on renseigne n'est pas déjà utilisé par un salon qui a été créé avant le déploiement de la feature (et dont on n'a pas encore pu récupérer le PIN)

Piste 1 : suppression manuelle des PIN Scalelite

Supprimer la valeur des PIN directement dans la base Scalelite permettrait :

• de pouvoir laisser à B3Desk la responsabilité de générer et fournir ces PIN
• on n'aurait plus de risque d'avoir un PIN en doublon

Par contre :

• les PIN ne seraient toujours pas éditables
• difficile de passer à l'échelle sur toutes les instances avec une manipulation manuelle à faire sur le Scalelite en même temps que le déploiement de B3Desk

[klorydryk]

Réponse du support

Il est indiqué dans la documentation de Scalelite le paramètre suivant qui doit être mis à "true" afin d'autoriser les codes PIN externes :

USE_EXTERNAL_VOICE_BRIDGE: Whether or not to try to use the voiceBridge number passed by the BigBlueButton API client. Defaults to false. If your API client generates numbers compatible with your BigBlueButton configuration, you can change this to true to use them. Note that Scalelite will ignore the voice bridge number provided, and generate a new one, if the number is already in use by a different meeting.

... par ailleurs il me semble qu'exécuter une commande d'API /end?meetingID=... efface les données contenues dans la base Redis et laisse libre la création de nouveaux codes PIN pour le meeting.

[LoanR]

@BHoury, est-ce que vous pouvez configurer le Scalelite de dev pour passer cette conf USE_EXTERNAL_VOICE_BRIDGE à True ?
On va avoir besoin de faire des tests.

[LoanR]

@klorydryk en l'état, faire une requête /end?meetingID= ne libère pas le voiceBridge, si on relance le meeting après, le voiceBridge est toujours le même alors que cette info n'existe pas dans B3Desk. La procédure suivie :

• Création d'un nouveau meeting directement via l'API Scalelite (sans passer par B3Desk et un éventuel effet de bord de l'appli)
  GET https://[...].arawa.fr/bigbluebutton/api/create?allowStartStopRecording=true&autoStartRecording=false&meetingID=15bd0211-9c5b-4082-9992-cbbc32ec9986&name=free-voiceBridge&record=false&checksum=[...]

<response>
  <returncode>SUCCESS</returncode>
  <meetingID>15bd0211-9c5b-4082-9992-cbbc32ec9986</meetingID>
  <internalMeetingID>
    989ef0c8dcecd94c63ed4a6d1b73f220fc574e05-1742552844248
  </internalMeetingID>
  <parentMeetingID>bbb-none</parentMeetingID>
  <attendeePW>NXWDl8VY</attendeePW>
  <moderatorPW>ORho37ha</moderatorPW>
  <createTime>1742552844248</createTime>
  <voiceBridge>9148230</voiceBridge>
  <dialNumber>[...]</dialNumber>
  <createDate>Fri Mar 21 11:27:24 CET 2025</createDate>
  <hasUserJoined>false</hasUserJoined>
  <duration>0</duration>
  <hasBeenForciblyEnded>false</hasBeenForciblyEnded>
  <messageKey/>
  <message/>
</response>

• Fermeture du meeting
  GET https://[...].arawa.fr/bigbluebutton/api/end?meetingID=15bd0211-9c5b-4082-9992-cbbc32ec9986&checksum=[...]

<response>
  <returncode>SUCCESS</returncode>
  <messageKey>sentEndMeetingRequest</messageKey>
  <message>
    A request to end the meeting was sent. Please wait a few seconds, and then use the getMeetingInfo or isMeetingRunning API calls to verify that it was ended.
  </message>
</response>

• Vérification de la bonne fermeture du meeting
  GET https://[...].arawa.fr/bigbluebutton/api/isMeetingRunning?meetingID=15bd0211-9c5b-4082-9992-cbbc32ec9986&checksum=[...]

<response>
  <returncode>SUCCESS</returncode>
  <running>false</running>
</response>

• Re-création du meeting avec le même id
  GET https://[...].arawa.fr/bigbluebutton/api/create?allowStartStopRecording=true&autoStartRecording=false&meetingID=15bd0211-9c5b-4082-9992-cbbc32ec9986&name=free-voiceBridge&record=false&checksum=[...]

<response>
  <returncode>SUCCESS</returncode>
  <meetingID>15bd0211-9c5b-4082-9992-cbbc32ec9986</meetingID>
  <internalMeetingID>
    989ef0c8dcecd94c63ed4a6d1b73f220fc574e05-1742553228253
  </internalMeetingID>
  <parentMeetingID>bbb-none</parentMeetingID>
  <attendeePW>vKWoq8Ms</attendeePW>
  <moderatorPW>Il6DpkSg</moderatorPW>
  <createTime>1742553228253</createTime>
  <voiceBridge>9148230</voiceBridge>
  <dialNumber>[...]</dialNumber>
  <createDate>Fri Mar 21 11:33:48 CET 2025</createDate>
  <hasUserJoined>false</hasUserJoined>
  <duration>0</duration>
  <hasBeenForciblyEnded>false</hasBeenForciblyEnded>
  <messageKey/>
  <message/>
</response>

Le voiceBridge est à nouveau 9148230 avec un end entre les deux. L'information est persistée quelque part sur le Scalelite. (et probablement que raise ArgumentError, "Voice bridge cannot be updated once set" unless @voice_bridge.nil? nous empêchera de le setter au lancement)
On va voir si la modification de la conf change quelque chose, mais la réponse du support semble fausse.

[pielonet]

Bonjour,

Les codes PIN ne sont pas persistés par Scalelite en base de données, du moins après que le meeting est fini. On peut croire cela car le code PIN généré la deuxième fois (par un nouvel appel d'API "/create?...") est identique.

Or c'est un choix délibéré des développeurs de Scalelite de faire en sorte que les codes PIN générés aléatoirement soient identiques dans la plupart des cas. La valeur "meeting_id" est en effet utilisée pour l'initialisation du générateur de nombres aléatoires : Voir https://github.com/blindsidenetworks/scalelite/blob/d751a842febbf0c3fca23152888db0c2d0399b46/app/models/meeting.rb#L208C1-L212C14

    # In order to make consistent random pin numbers, use the provided meeting as the seed. Ruby's 'Random' PRNG takes a 128bit
    # integer as seed. Create one from a truncated hash of the meeting id.
    seed = Digest::SHA256.digest(meeting_id).unpack('QQ').inject { |val, n| (val << 64) | n }
    prng = Random.new(seed)
    tries = 0

Par ailleurs, le paramètre USE_EXTERNAL_VOICE_BRIDGE est désormais actif sur le serveur Scalelite de test.

Je pense que le code PIN peut désormais être changé sans difficultés après que la session est terminée. (Il est à noter que Scalelite vérifie si un "meeting" dans sa base de données est toujours actif sur le serveur BBB et le supprime de sa base de données s'il est terminé (voir https://github.com/blindsidenetworks/scalelite/blob/d751a842febbf0c3fca23152888db0c2d0399b46/lib/tasks/poll.rake#L140). Si bien qu'il n'est pas nécessaire - et pas conseillé, au risque d'interrompre une session en cours - de faire un appel d'API "/end?meetingID=...")

[LoanR]

Super ! Merci pour les infos @pielonet !

[SbirLobo]

Bonjour @klorydryk ,

J'ai besoin de clarifier certains points.
1 - Salon supprimé libère le code au bout d'un an
Dans quel but ce code devrait être conservé un an après la suppression du salon ?
2 - Offrir la possibilité de modifier le code téléphone (comme l'url)
De quelle url parle-t-on ici ? Est ce que c'est le propriétaire qui peut modifier l'url ?
3 - Dans un second temps, créer une récurrence du renouvellement des url et code d'accès téléphone + envoi de mail au propriétaire avec les nouvelles infos
Qu'entend-on par créer une récurrence du renouvellement ?

Voici ce que nous avons mis en place à ce jour :

• les codes sont gérés par b3desk
• les propriétaires ont la possibilité de personnaliser le code (à la création ou via édition)
• les codes sont uniques par pool
• les codes sont composés de 9 chiffres (la premier ne peut pas être 0 pour répondre à une exigence bbb).