Problème de connexion à talk par certains clients

Bonjour,

Je dispose d’un Nextcloud hub 10 (31.0.6) hébergé sur un serveur dédié chez OVH.

La plus part du temps les échanges avec Talk se passent très bien, mais certains de mes clients n’arrivent pas à se connecter. Je vois leur arrivée dans Talk mais ça tourne sans possibilité d’aller plus loin. Je ne vois ni image ni son de mon interlocuteur.

J’ai remarqué que ce phénomène se produit avec des entreprises étant en réseau Microsoft derrière un Windows server.

Je pense qu’un port particulier doit être fermé soit au niveau de leur serveur, soit au niveau de leur box.

En dehors du port 443, Talk utilise t’il d’autres ports pour le support de la vidéo ou du son?

Merci pour vos réponses.

@l.dolle

La réponse n’est pas simple.

Nextcloud Talk utilise WebRTC (WebRTC — Wikipédia WebRTC) pour le son et la vidéo, c’est à dire qu’il s’appuie sur les implémentation des navigateurs pour cela. Les échanges qui passent par le serveur nextcloud en 443 sont le chat et toute la signalisation pour fournir les informations nécessaires à l’établissement des flux WebRTC. Le WebRTC est fondamentalement du pair à pair, donc de client à client.

L’information appliquée à Nexcloud Talk est ici Overview - Nextcloud Talk API documentation ( en anglais ). On la retourve dans le projet GitHub spreed car l’application Talk s’appelle en fait spreed : spreed/docs/TURN.md at main · nextcloud/spreed · GitHub

Que les autres clients soient sous windows n’est pas un problème, ni même qu’ils soient gérés par un ActiveDirectory sur un WindowServer, ce qui importe c’est qu’il y a ait ou non du NAT et des parefeux entre les réseaux.

Il faut effectivement que les flux UDP de chaque participant puissent joindre l’autre soit directement en pair à pair soit via de la magie STUN/TURN.
Le principal problème est que l’adresse ip elle même est utilisée et quand les deux équipements utilisent des adresses privées ( 192.168.x.x ou 10.x.x.x ) et qu’il ne sont pas sur le même réseau local, cela ne marchera qu’avec de l’aide.

Depuis l’invention du NAT dynamique, utilisée massivement dans les box, tous les protocoles pair à pair s’appuient sur des miracles d’ingénierie pour fonctionner. La mise en place des flux est alors très dynamique et très complexe.

Si les deux équipements ont des adresses publiques et qu’aucun parefeu n’intervient il n’y a aucun problème. Mais nous ne sommes pas encore à l’ère du tout ipv6 et les équipements derrière les box en ipv4 ne sont pas joignable.

Si l’un des deux équipement est joignable, avec du STUN on peut s’en sortir, si aucun des deux ne l’est il faut un serveur TURN. Et c’est là que l’on retrouve le TURN de la documentation. Pour que tout marche bien il faut des navigateurs à jour, un serveur STUN/TURN bien configuré et les flux UDP audio vidéo autorisés.

Des spécialistes de WebRTC l’expliqueront mieux que moi, ( https://bloggeek.me/ )

Ma réponse ne contient que mes connaissances personnelles sans IA.

Cordialement

Bonjour @artlog1,

Merci pour les explications. J’ai déjà configuré un serveur turn et stun.

Je vais les contrôler.

J’ai aussi demandé la mise en place d’un serveur de signalisation.

On va bien voir si ça change quelque chose.

Cordialement,