Désolé pour le petit message impromptu je me mets en soutien des services infos de mon établissement qui font un super boulot mais qui ont quelques questions sur Jitsi Meet et si quelqu’une avait des bouts de réponse ça serait super !
"Si tu as des contacts qui ont l’habitude de travailler avec JitSi Meet (ça c’est les chatons ;)), je suis preneur.
Que ce soit sur l’ancienne machine virtuelle, ou sur le serveur actuel, il y a toujours le processus JVB (jitsi-video-bridge) qui prend plus de 100 %
J’ai vu sur plusieurs documentations / forums que l’option « org.jitsi.videobrige.DISABLE_TCP_HARVESTER » peut résoudre le problème.
Le seul souci, c’est que les gens qui ont un firewall assez restrictif, ne pourront plus accéder à JitSi Meet.
Il faut donc mettre en place un serveur « Turn / CoTurn ».
Je voulais juste savoir s’il y a un exemple de configuration validée et s’il fallait l’héberger sur une autre machine (à priori, vu que ça va tourner sur le port 443 : c’est obligatoire).
Pour le serveur TURN / CoTurn : il y a des informations ici : [je retire ça comme un lien sinon ça me bloque] community jitsi org /t/one-way-media-only-nat-issues-after-upgrade/15328/13
C’est juste que je n’aime pas trop avoir à tester des paramètres sans être sûr de moi, mais je ferai avec si besoin."
Si vous pouvez l’aider ça serait super gentil on essaye de profiter de l’occasion pour promouvoir les outils libres et les garder après merci par avance
Il faut mettre un secret la: static-auth-secret=
Realm, c’est le nom de ton serveur.
Le cert et le pkey, c’est ton cert et ta clé, valide le cert.
Le proc-user risque de te poser soucis suivant ta config… a toi de voir.
Tout d’abord, merci pour la réponse et les détails donnés.
Je pense avoir bien configuré coturn et le mod_turncredentials.lua.
Y-a-t’il un moyen simple de tester que tout est fonctionnel (à priori avec chromium et chrome://webrtc-internals/ ?
Pour répondre à la question : le serveur est derrière un firewall (shorewall) avec sa propre IP publique et ce n’est pas à la maison
Je préfère firefox et la tab about:webrtc il y a un plugin aussi pour tester webrtc.
Si tout fonctionne, tu devrais voir ton turn dans les candidats locaux.
Merci pour les précisions.
À priori, sous Chromium (80.0.3987.13) , avec ‹ chrome://webrtc-internals › je vois les connexions au serveur CoTurn.
À priori, sous Firefox (firefox ESR 68.6.0 paquet Debian Buster), je ne vois pas les connexions au serveur CoTurn.
Cela pourrait-il être la version de Firefox qui est en cause ?
Je peux mettre des captures d’écran et partager la configuration : je n’exclus pas du tout une erreur de configuration de ma part.
PS : Merci pour le lien, ça aide quand même. Il faut juste penser à enlever le ‹ ?edit › pour voir les captures d’écran.
Merci beaucoup et désolé pour toutes ces questions.
On cherche a rendre notre Jitsi Meet fonctionnel entre N utilisateurs derrière différent proxy http d’entreprise ou autre (test ultime pour un outil de visioconf )
Je ne suis pas sur d’avoir compris si :
JVB peut permettre a a 2 ou plus clients derrière un proxy a envoyer/recevoir leur flux webrtc ?
EDIT : Oui mais sur 4443 en mono serveur et donc 443 si JVB a son domaine/server dédié )
Un serveur TURN n’est alors utile que pour soulager JVB pour les connexions 1a1 mais pas NaN ou JVB sera de toutes façons utilisé ?
Tout le temps, N=2 ou plus, les flus passent par le JVB.
Le TCP harvester de jitsi n’est pas utile. Le udp 10000 suffit.
Il faut configurer TURN sur le 443, TCP avec TLS, le protocole ressemble « presque » à https. Si le proxy ou firewall n’est pas tatillon, il laisse passer.
Enfin quand l’utilisateur arrive sur la visio, le jvb est annoncé comme remote candidate, et le turn est dans les locale candidate.
Le navigateur essaye les paires de candidats dans l’ordre de priorité. Et donc si derrière proxy, il utilise le candidat local turn qui est de type relay. Donc le flux passe par turn 443, puis jvb udp.
après pas mal de lecture , il semble que faire tourner le jvb sur un sous domaine sur port 443 permet de passer pas mal de firewall , mais pour un résultat a 100% un turn est effectivement necessaire.
Bonjour @pierre, @ekimia, Auriez vous un exemple de config a mettre en oeuvre pour faire tourner VideoBridge2 sur le 443 derrière un vhost/sous domaine différent du Front (jitsi-meet) ?
Du coup, la partie web, c’est nginx, le navigateur a besoin de discuter en 10000 avec le jvb (jitsi video bridge) pour le webrtc, la partie vidéo/audio.
Ce dont on discutait plus haut, est le fait que les gens derrière des firewall ont en général le port 10000 bloqué. Et dans ce cas là, il faut ajouter un serveur turn dans le mix. Et donc ce qu’il se passe, c’est quand la visio démarre, « jitsi » va proposer aux navigateurs plusieurs points pour se connecter en visio, les tester et prendre le meilleur. Il faut alors ajouter le turn à la liste.
Il faut configurer le turn sur le port 443 avec du tls, et la plupart des firewall pensent que c’est du https, et ils laissent passer, mais il existe des firewall plus tatillons qui vont voir la supercherie et ne laisseront pas passer, et là, il n’y a rien à faire.
Du coup, tu veux la config du turn? Est-ce que tu utilises docker pour déployer ou non?
Je suis ce beau schéma, mais j’ai, en plus, un reverse proxy nginx devant tout ça, le tout derrière un NAT.
En vous lisant j’avais cru comprendre que vous faisiez fonctionner le JVB sur le port 443 avec une URL specifique, differente de celle du FrontWeb, ce qui m’intéresse pour faire tourner ET le le frontal ET le JVB sur le meme port, le « routage » se faisant avec le reverse proxy en frontal (conf.underworld.fr:443 → Serveur1-FrontalWEBMeet dédié / jvb.underworld.fr:443 → Serveur2-JVB dédié
Pour TURN, j’ai laissé tombé avec une seule IP, le stream NGINX porté par le reverseproxy me faisant perdre toute entête de l’IPsource des requêtes http.
Vu la réponse de damencho, ça ne serait pas un luxe pour mon instance de repartir FromScratch parce que y a eu pas mal de changement depuis 2ans dans de multiple fichier de conf
A un moment ils faisaient ça sur le paquet debian de jitsi si je ne m’abuse, faire tourner le jvb aussi sur le 443 et laisser le nginx discriminer le traffic entre web et jvb.
Je sais pas ce qu’ils font aujourd’hui.
En tout cas, et je sais pas exactement pourquoi, le traffic tls du turn ressemble plus à de l’https que le traffic tls du jvb, je crois que c’est comment le webrtc négocie le tls au départ, cela se voit trop par les firewall qui le dégage plus facileemnt que tu turn, mais je t’avoue que je raconte sûrement des bétises
Mais je pense bien que c’est possible de faire du turn ET du web sur le meme port 443, mais je ne saurais pas te dire comment là tout de suite
Et oui, la conf a pas mal changer, quand j’ai un doute je repars souvent from scratch d’ailleurs )
j’ai réussi a faire ecoute nginx sur le 443, puis en fonction de l’URL (conf.underworld.fr ou turn.underworld.fr) a router vers TURn ou JITSI. Mais je perdais toute information sur la SourceIP pour tout mes services, non soutenable. mais techniquement ça marche (Stream nginx)
merci par avance
