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.