Jitsi - meet petite aide de configuration

#1

Bonjour à toutes,

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 ! :slight_smile:

"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).

J’ai trouvé des informations ici : https://github.com/jitsi/jitsi-meet/issues/4464 et ici https://community.jitsi.org/t/jitsi-videobridge-consuming-200-cpu-utilization-constantly/19482/3 pour le bug lié à l’utilisation CPU.

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 :wink: merci par avance

#2

derrière un fw? à la maison? :stuck_out_tongue:

Pour la conf coturn:

use-auth-secret
keep-address-family
static-auth-secret=
realm=turn2.indie.host
cert=/path/to/certs/fullchain.pem
pkey=/path/to/certs/privkey.pem

#no-tcp
no-cli
listening-port=3478
tls-listening-port=443
external-ip=turn2.indie.host
verbose
syslog
dh2066


proc-user=turnserver
proc-group=turnserver

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.

Ensuite :slight_smile: Et la ça devient marrant :wink:

Il faut que tu mettes ces 2 fichiers:

enleve l’indentation.
La et la :

Je sais que ça doit pas etre clair… désolé… Pose tes auestions, j’essai d’y repondre.

Sinon, tu peux aussi essayer le paquet instable de jitsi debian, il y a le turn dedans :slight_smile:

1 Like
#3

Bonsoir,

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 :slight_smile:

Merci en tous les cas pour toute votre aide.

#4

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.

Ici regarde, un exemple:

https://codimd.indie.host/QxJ2Lp-WQymXxT3Fu1F9Wg

#5

Bonjour Pierre,

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.

#6

Autant pour moi !
Ça à l’air bon sous Firefox aussi.
J’ai bien des connexions dans ‘Candidat local’.

Merci beaucoup pour l’aide apportée.

#7

Hello je m’incruste sur le sujet :

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é ?

Merci

#8

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.

#9

Merci pierre ,

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.

#10

pas 100% non, 99% :slight_smile: J’ai eu le cas.