Diffuser depuis un réseau d'entreprise

Diffuser depuis le réseau d'une entreprise, c'est le moment où la plupart des animateurs commencent à s'inquiéter. Le pare-feu est strict, l'ordinateur a été configuré par quelqu'un d'autre, le VPN est obligatoire, et rien de tout cela ne se teste avant le jour même. La réponse courte, c'est que dans la plupart des cas vous n'avez rien à faire, parce que la salle se débrouille seule avec un réseau fermé.

Vous trouverez ci-dessous ce qui se passe sans vous, comment savoir que cela a fonctionné, et l'ensemble plus restreint de cas où lancer notre programme vaut la peine.

Ce que le réseau bloque réellement

Les navigateurs portent le son et l'image en direct par WebRTC, qui envoie ses médias en UDP. La sécurité des entreprises n'aime guère l'UDP. Un pare-feu qui ne laisse passer que le TCP sur les ports 80 et 443, un VPN qui tunnelise le TCP et laisse tomber le reste, un équipement qui inspecte les paquets et se méfie de ce qu'il n'arrive pas à classer, chacun d'eux arrêtera un flux WebRTC sans jamais l'annoncer.

Cette contrainte est réelle et parfaitement banale dans la finance, l'administration, la santé et les grands groupes. Elle ne signe pourtant pas la fin de votre webinaire.

Ce qui se passe déjà sans vous

À côté de la route du navigateur tourne notre propre protocole de diffusion adaptatif. Il ne repose pas sur WebRTC, dans la plupart des cas le port TCP 443 lui suffit, et il s'active tout seul pour chaque salle de webinaire permanente et chaque événement programmé. Le port 443 est celui qu'utilise tout site en HTTPS, le trafic emprunte donc le chemin que votre pare-feu garde déjà ouvert.

Retenez l'essentiel, les deux routes aboutissent au même transport. Lancer le programme ne vous fait pas passer sur un protocole plus rapide ni plus lent, il démarre le même à la main. Prérequis techniques décrit le protocole, et la latence de la diffusion expose le décalage à attendre, entre intervenants sur une ligne saine il est de 100 à 600 millisecondes, et pour votre public la même plage plus un petit tampon de lissage.

Ce qu'aucun protocole ne sait faire, c'est inventer de la bande passante. Une ligne vraiment trop lente ou trop instable coûte toujours l'image à votre public, et que faire quand la vidéo se fige ou que les participants décrochent traite cela à part.

Comment vérifier à l'avance

N'attendez pas le jour J. Ouvrez notre test de connexion depuis la machine et le réseau d'où vous diffuserez, de préférence à la même heure de la journée, car une ligne d'entreprise à neuf heures du matin n'est pas celle que vous avez testée à sept heures du soir.

Entrez ensuite une fois dans la salle elle-même. À l'entrée, elle propose une vérification du matériel et de la connexion, et c'est précisément cette vérification qui emprunte le vrai chemin. Si votre caméra apparaît et que votre voix est captée, le réseau ne vous gêne pas.

Ce qu'apporte le lancement du programme

Le programme DTS est le mode manuel de ce même transport. Puisqu'il tourne de toute façon, la question devient ce que change un démarrage à la main, et la réponse tient en une phrase, le flux quitte le navigateur.

Cela compte dans deux situations. La première est le partage d'écran, car un navigateur en perte de paquets rend un texte cassé ou flou, alors que notre logiciel est conçu pour réduire ces pertes au minimum et garder l'image lisible. Le raisonnement complet se trouve dans pourquoi le partage d'écran demande notre logiciel. La seconde est une ligne qui trébuche sans arrêt, où la route du navigateur passe son temps à se rétablir tandis que le programme, lui, tient le flux d'un seul tenant.

Remarquez ce qui ne figure pas sur cette liste. Le programme ne vous achète pas moins de latence et ne sauve pas une connexion qui n'a plus de bande passante.

Ce que coûte le programme

Il tourne sous Windows et macOS, un intervenant sous Linux reste donc sur la route du navigateur. La salle est basculée par le propriétaire du compte depuis le tableau de bord, et à partir de là toute personne qui prend la parole dans cette salle a besoin du programme, tandis que les participants n'installent rien et rejoignent comme d'habitude.

Vous l'installez une fois, puis vous le lancez avant chaque diffusion, car il ne démarre pas seul. Sur cette route, la salle gagne en plus deux réglages de son que le navigateur n'a pas, et perd «Arrière-plan flou» ("Blur background"), qui n'existe pas encore ici. Le guide complet d'installation est la technologie de diffusion alternative (le programme DTS), et la qualité du son sur les webinaires parle des réglages de son.

Cette perte ne concerne en réalité que Windows. Sur un Mac, macOS applique lui-même le flou "Portrait" et le remplacement de fond "Background", et cela avant que l'image n'atteigne la moindre application. Le programme reçoit une image qui porte déjà l'effet, et les deux continuent de fonctionner entièrement. Les arrière-plans virtuels sur macOS montre comment les activer et comment savoir si ce Mac propose "Background".

Travailler à travers un VPN

Un VPN d'entreprise obligatoire n'est pas un obstacle. Les services d'entreprise connus font passer la salle, et ce qui le permet est justement le transport automatique décrit plus haut. Avec les VPN gratuits, l'histoire est autre, leur bande passante suffit rarement à un son et une image réguliers, tenez-les donc à l'écart de tout ce que vous diffusez.

Deux produits réclament une règle à eux avant de laisser passer la salle. Le contournement exact est donné par la diffusion depuis Opera avec le VPN intégré, et le second cas est traité par problèmes de connexion WebSocket avec BitDefender VPN.

Si la plateforme elle-même est bloquée

Certains réseaux vont plus loin qu'un blocage de protocole et ferment notre adresse entièrement. Cela se voit autrement, car la salle ne se charge pas du tout au lieu de se charger sans votre caméra. Le contournement est l'accès par un miroir quand la plateforme est bloquée, et mieux vaut le connaître avant d'en avoir besoin.

Questions fréquentes

Mon entreprise bloque l'UDP. Dois-je installer quelque chose ?

En général non. Le protocole adaptatif s'active tout seul pour chaque salle permanente et chaque événement programmé, et dans la plupart des cas le port TCP 443 lui suffit, celui que votre pare-feu ouvre déjà pour le web ordinaire. Installez le programme quand le partage d'écran doit rester net, ou quand la route du navigateur trébuche sur une ligne faible.

Le programme réduit-il la latence ?

Non. Il démarre le transport que la salle utilise déjà, la latence reste donc dans la même plage dans les deux cas, soit 100 à 600 millisecondes entre intervenants sur une ligne saine. Le programme change la stabilité et non la vitesse, car un flux qui n'a pas à se rétablir ne prend pas non plus de retard.

Mes participants sur le réseau d'entreprise ont-ils besoin de quelque chose ?

Non. Les participants n'installent rien et rejoignent par le lien habituel. Le programme ne va que sur les machines de ceux qui prennent la parole, et c'est ce même transport automatique qui porte le flux jusqu'à un public assis derrière un pare-feu.

Puis-je tester le réseau à l'avance sans créer de salle ?

Oui. Notre test de connexion s'exécute depuis la machine et le réseau d'où vous comptez diffuser, et il vaut la peine de le lancer à l'heure prévue pour l'événement, car une ligne d'entreprise se comporte différemment au fil de la journée.

La sécurité demande quels ports ouvrir. Que leur répondre ?

Le port TCP 443, celui qu'utilise HTTPS. Le protocole adaptatif ne repose pas sur WebRTC et n'a besoin de rien d'autre dans la plupart des cas. Envoyez-leur prérequis techniques, et la sécurité de la plateforme décrit comment le flux est protégé en chemin.

Si votre réseau se révèle plus strict que tout cela, ouvrez le chat en ligne et dites-nous ce que fait la salle quand vous appuyez sur «Microphone». Nous le reprendrons avec vous.