Compatibilité Jitsi avec infra Teams

Beaucoup d’entreprises utilisent MS-Teams comme solution de visioconf et ont configuré leurs infras (firewall, proxy) en conséquence. Utiliser Jitsi pour communiquer avec le personnel de ces entreprises n’est pas possible car Jitsi n’utilise pas les même ports (TCP/UDP) et demander aux entreprises d’étendre leurs confs à une autre solution comme Jitsi est très compliqué…

L’idéal serait d’avoir une solution Jitsi utilisant les ports Teams déjà ouverts par l’entreprise. Ca tombe bien, Jitsi utilise un seul port UDP (10000) et les entreprises sont censées en avoir ouverts 4 pour Teams (3478…3481).

Dans mon entreprise nous utilisons Talk/Nextcloud pour les visioconfs. Un serveur STUN/TURN a été mis en place, il utilise le port 3478 et les confs avec les entreprises utilisant habituellement Teams fonctionnent et nous avons pu quitter Teams (ouf !!!). Jitsi étant plus sexy que Talk, je suis en train de tester cette solution.
J’ai installé un serveur Jitsi dans mon entreprise et il fonctionne correctement en interne comme en externe, test effectué entre un PC dans l’entreprise et 2 téléphones Android en 4G avec l’application Jitsi.
Par contre ça ne fonctionne pas entre un PC de mon entreprise actuelle (PC-a) et un autre PC dans mon ancienne entreprise (PC-b) (je connais l’infra de ces deux entreprise, ça aide !). Pas de video mais le chat textuel fonctionne.

Dans l’entreprise B, les accès Internet se font via un proxy Squid vieillot. Le port 10000 n’est pas ouvert non plus.
Sur mon installation de Jitsi (sur Debian 10), je constate qu’un serveur coturn tourne et utilse les ports 3478, 3479 et 5349… or Jitsi n’est-il pas censé n’utiliser à présent que les ports 443 (web+TURN) et le port 10000 ?
Comment utiliser ce serveur coturn pour les confs d’entreprise à entreprise ?

Ce que tu exposes est assez généralement observable dès que l’on commence à mixer des usages au sein d’une organisation et des accès individuel. C’est à dire que les règles ingress|egress du réseau de l’organisation sont naturellement très différentes de celle d’un accès «individuel». Du coup, mixer les deux devient problèmatiques.
C’est bien la raison pour laquelle coturn doit être déployé sur un port 443 et doit être accessible à partir d’un fqdn différent. Il y a eu des discussions à ce sujet sur le forum. Le truc étant d’éviter à avoir à déployer coturn sur une autre instance|machine que celle de ton jitsi. C’est faisable mais, ça fonctionne pas toujours très bien en particulier pour les ws.

Une exemple de déploiement chez hadoly
Des bises!

Intéressant Stéphane, merci pour le lien.
Je pense par contre que de chercher à positionner corturn sur le 443 rend Jitsi moins compatible avec les confs d’entreprise. Les entreprises ont QUASIMENT TOUTES ouvert leurs ports 3478 à 3481 pour Teams et donc paramétrer le serveur STUN/TURN sur le 443 plutôt que sur son port standard c’est prendre le risque inutile de buter sur un proxy chatouilleux ou un firewall qui ferait de l’analyse de trames.

Pour info, nous utilisons pour le moment Talk/Nextcloud pour les visioconfs (avec un serveur coturn sur le 3478 standard) et ça fonctionne d’entreprise à entreprise (là où avec Jitsi ça bloque).
Talk/Nextcloud est par contre moins sexy que Jitsi (et une cata en chat textuel car les notifications au travers d’un navigateur c’est pas au point !).

Bonsoir

le turn sur le port 443 peut être bloqué effectivement par des proxy faisant de l’analyse de flux

sinon pour faciliter les utilisateurs tu as aussi le plugin jitsi pour outlook qui permet de faire des comme avec teams

OK, j’avais mal compris ton exposé de problème.

Du coup, j’ai des questions.

  • quel serveur turn|coturn est employé pour votre nextcloud|talk(spreed)?
  • idem -> un serveur de signalement externe?

Par exemple, avez-vous déployé https://github.com/strukturag/nextcloud-spreed-signaling comme sfu?

J’ai viré aussi Outlook et rapatrié la messagerie on-premise. Le but est de se passer des GAFAM et protéger les données de l’entreprise…

Selon moi, JITSI a besoin:

  • Du 443 pour l’interface WEB
  • Du 10000 (par defaut) pour le canal video

Et si les clients sont cachés derrière un NAT, alors un serveur TURN est requis, et tourne par défaut sur 3478. Ce dernier remplace l’usage du 10000.

CFQD:
Cas 1 : 443 + 10000
Cas 2 : 443 + 3478

Dans le cas 2, on le décline en un « Cas 3 » en utilisant 2 IP:
Cas 3 : 443_IP1(interface) + 443_IP2(TURN)

Ainsi, le client derrière un proxy laissant sortir « que » 443 sera bien servi.