Sélectionner une page

Contexte

Chez Octopuce, nous hébergeons différentes infrastructures de visioconférence, toutes équipées du logiciel libre Bigbluebutton : serveurs dédiées, serveurs mutualisés, clusters de serveurs gérés via Scalelite. Bref, nous avons différentes personnes qui utilisent BBB ( Bigbluebutton ) comme service chez nous. Au fil des remontées d’erreurs, nous avons remarqué que beaucoup venaient de l’utilisation d’outils Apple, donc soit du système IOS, soit de Safari. Nous avons cherché à en savoir plus sur le comportement des outils IOS vis à vis de TURN et des bridages réseau.

Environnement de test

Pour les tests,

Matériel :
iPad en IOS 14.4 (dernière version de MARS 2021), iPad de 8e génération de 2020
serveur BBB dédié au test, en version 2.2.31
serveur TURN d’Octopuce

Outils :
Bridage réseau via iptables sur notre routeur local

Rappel :
Le Partage d’écran depuis l’iPAD : le partage d’écran n’est pas supporté par ce navigateur, donc on ne le teste pas. Par ailleurs, cette limitation est applicable à tout IOS.

Configuration TURN client du serveur BBB :
1er choix : turns:turn.octopuce.fr:443?transport=tcp
2nd choix : turn:turn.octopuce.fr:3478

Tests

Tous flux ouverts

  • Audio : 40 à 64 kbps
  • webcam en émission : 30 à 40 kbps
  • Webcam en réception : 30 à 40 kbps
    Tout marche bien et passe en UDP, avec les paramètres de visio Octopuce ( caméra et partage d’écran paramétrés pour être bas )
  • Partage d’écran en réception 1080p ( ideal_rate: 2 / max: 3 ) 200 à 300 kbps consommé

Ipad sans UDP (via iptables REJECT), flux TCP ouvert

  • Audio : OK, il passe par TURN:HTTPS en TCP/443
    Parcours :
    au début, l’IPAD s’adresse directement à TURN.OCTOPUCE.FR/UDP/3478 pour l’audio
    puisqu’il reçoit un REJECT, il essaye alors immédiatement le TURN/TCP/TLS/443 où on lui répond avec un cert COMODO/Certigo
    le flux audio symétrique sur TURN/TCP/TLS/443 fait plutôt 80 kbps (dû à la surcouche pour le tunneling TURN)
  • Webcam en émission :
    Message « le media ne peut atteindre le serveur (erreur 1020) » après environ 30 secondes
  • Webcam en réception :
    les webcam apparaissent au bout d’environ 60 à 90 secondes et passent en flux TCP direct vers BBB (sur des ports ‘exotiques’ src & dst)
  • Partage d’écran en réception :
    • si on partage l’écran à un ipad ainsi bridé :
    • il tente d’abord UDP direct avec BigBlueButton (rejected)
    • puis via TURN/UDP/3478 (rejected) rapidement
    • puis via TURN/TCP/TLS/443, mais ne tunnelle pas les données dans TURN
    • il finit par négocier un port TCP exotique direct avec BBB au bout de ~30 sec
    • l’image du partage d’écran apparaît au bout de 60 secondes

Ipad sans UDP autorisé (iptables DROP), flux TCP ouvert

Même comportement que via les iptables REJECT

Ipad sans UDP autorisé (iptables REJECT) et sans TCP (iptables REJECT) (TCP uniquement autorisé sur le port 443)

  • Audio : OK, il passe par TURN:HTTPS en TCP/443
  • Webcam en réception :
    les webcam apparaissent au bout d’environ 60 à 90 secondes
    et passent en flux TURN/TCP/TLS/443
  • Webcam en émission :
    Message « le media ne peut atteindre le serveur (erreur 1020) » après environ 30secondes
  • Partage d’écran en réception :
    l’image du partage d’écran apparaît au bout de 60 secondes
    et passe en flux TURN/TCP/TLS/443

Ipad avec TCP/443 autorisé et UDP/3478 vers TURN.octopuce.fr autorisé

  • Audio : OK instantané comme d’habitude
  • Webcam en réception : OK rapidement
  • Webcam en émission : OK rapidement, tout passe dans TURN/UDP/3478
  • Partage d’écran : OK rapidement (aussi rapide que sur un pc openbar), tout passe dans TURN/UDP/3478

Tests v2

Nous avons inversé la configuration TURN pour avoir :
1er choix : turn:turn.octopuce.fr:3478
2nd choix : turns:turn.octopuce.fr:443?transport=tcp
Nous n’avons pas eu de comportement différent

Conclusion et conseils

Via ces divers tests, on peut donc voir que BBB est très résistant aux pare-feu réseaux, et essaye beaucoup de moyens pour faire transiter ses flux vidéos. Cela peut cependant prendre un certain temps à être négocié (jusqu’à 90 secondes dans le pire des cas)

Nous recommandons d’installer et de configurer son propre serveur TURN pour Bigbluebutton, c’est devenu un standard et c’est même géré par le script bbb-install.sh si besoin.
Nous recommandons également de vous assurer que les utilisataires de votre service Bigbluebutton ont un pare-feu ouvert selon les recommandations de Bigbluebutton. Si cela n’est pas possible, ou trop compliqué, nous conseillons d’avoir à minima le flux vers votre
serveur TURN sur le port UDP 3478 d’ouvert.