Le proxy DHT est utile surtout pour les appareils mobiles (Android, iOS). Il sert à s’enregistrer sur la table distribuée (DHT) “au nom de l’appareil” (d’où l’appellation de “proxy”) pendant que l’appareil mobile est en veille / en mode d’économie d’énergie et à essayer de “réveiller” le téléphone avec des notifications “push” lorsque de nouveaux messages arrivent sur la DHT à destination de cet appareil en utilisant le logiciel gorush. Sinon, la synchronisation DHT doit être active en tout temps sur l’appareil ce qui réduit grandement l’autonomie de l’appareil mobile alimenté par une batterie. Plus de détails techniques sur les proxies DHT sont disponibles ici FAQ — Jami documentation
Lorsque Jami ne peut pas acheminer la voix et la vidéo directement de A vers B (pair à pair) il essaie de faire passer ces flux audio et vidéo via des serveurs TURN. Ces derniers écoutent par défaut sur le port UDP 3478 mais utilisent l’intervalle de ports UDP 10000 à 30000 pour faire acheminer les flux audio et vidéo entre les utilisateurs en communication. Ces ports UDP 10000 à 30000 n’écoutent pas en permanence sur le serveur TURN (aucun de ces ports n’est connecté sur le serveur TURN lorsqu’il n’y a aucun appel qui transite par ce serveur).
Zoom (pour reprendre votre exemple de logiciel utilisé au travail) utilise un nombre limité de ports TCP (443, 8801 et 8802) avec un nombre limité de serveurs car les conférences passent à travers leurs serveurs. Zoom a été conçu à la base pour fonctionner sur des réseaux corporatifs, scolaires et universitaires très restrictifs. En contrepartie on doit faire confiance à Zoom et à leurs serveurs pour préserver le caractère privé de nos conférences.
Jami est au contraire un logiciel de communication distribué, donc par définition il ne peut pas fonctionner dans un environnement réseau très restreint. A minima il faut que les ports suivants soient ouverts: FAQ — Jami documentation
Si ce n’est pas possible, la seule façon d’utiliser Jami sur un réseau très restreint sera alors de déployer des serveurs DHT proxy et TURN à l’intérieur du réseau organisationnel (ou sur un DMZ). Si on veut que les gens dans l’organisation puissent quand même communiquer avec le réseau extérieur il faut que:
1- les utilisateurs du réseau local puissent accéder sans encombre aux serveurs dhtproxy et turn (et peut-être nameserver jami) locaux. On parle bien des serveurs déployés par l’organisation et non des serveurs fournis par le projet Jami pour le grand public. Même là on risque d’avoir des difficultés avec les notifications push d’Android et d’iOS à moins d’héberger son propre service de notifications push.
2- ces serveurs dhtproxy et turn internes doivent pouvoir communiquer librement avec Internet (donc tous les ports TCP et UDP dans le lien que j’ai cité ci-dessus doivent fonctionner).
Comme vous le voyez, il ne s’agit pas de quelque chose que l’équipe de développeurs Jami ou un simple utilisateur du réseau organisationnel restrictif peut faire. Il s’agit d’un projet d’architecture infra/réseau que les responsables TI de l’organisation doivent réaliser s’ils décident d’utiliser Jami.
Il y a un guide ici Use Jami on a LAN — Jami documentation pour déployer Jami sur un réseau local (LAN) déconnecté d’Internet. Ce guide peut servir de base à un tel projet.