Les problèmes d'appels Nextcloud Talk sont souvent décrits comme une « mauvaise qualité vidéo », mais leurs causes sous-jacentes varient. Un utilisateur peut disposer d'une bande passante suffisante et pourtant ne pas parvenir à se connecter car un pare-feu bloque le trafic WebRTC peer-to-peer. Un autre appel peut réussir à se connecter via TURN, mais paraître plus lent car tous les flux multimédias sont relayés. Une réunion importante peut rencontrer des difficultés même avec un serveur TURN parfaitement fonctionnel, car le déploiement utilise toujours la topologie peer-to-peer intégrée au lieu du backend haute performance.
La méthode de dépannage la plus efficace consiste donc à séparer la connectivité , le chemin média et la scalabilité . Au 6 octobre 2026, la documentation Nextcloud Talk indique toujours que TURN est la solution de repli lorsque la connectivité WebRTC directe est impossible et recommande le port 443 pour une compatibilité maximale. Elle précise également qu'un serveur TURN peut être nécessaire même avec le backend haute performance. Consultez la documentation officielle Nextcloud Talk relative à TURN et le guide d'installation officiel de coturn pour Talk .
Utilisez le schéma des symptômes pour choisir la prochaine action au lieu de modifier plusieurs paramètres à la fois.
| Symptôme | Zone la plus probable | Première action | Compromis |
|---|---|---|---|
| L'appel fonctionne sur un réseau mais échoue depuis un réseau d'entreprise ou d'hôtel. | Pare-feu, NAT ou TURN manquant | Vérifiez que le protocole TURN est activé sur UDP/TCP et, le cas échéant, TLS sur le port 443. | Le relais améliore la connectivité mais consomme de la bande passante TURN et peut ajouter de la latence. |
| Les appels à deux personnes fonctionnent bien, les appels à plus de trois deviennent instables. | Topologie des appels et charge du processeur/chargement du client | Évaluer le backend haute performance de Nextcloud Talk | Plus d'infrastructures, mais une meilleure évolutivité pour les appels multipartites |
| La vidéo se connecte mais elle est pixélisée ou se fige. | Perte de paquets, latence, Wi-Fi, capacité de liaison montante ou points de terminaison surchargés | Effectuez un test sur un réseau câblé ou un réseau fonctionnel avant de modifier TURN. | TURN ne peut pas créer de bande passante non disponible. |
| Le test TURN échoue malgré l'exécution de coturn. | Incompatibilité de secret, pare-feu, mappage NAT, DNS ou ports relais | Vérifiez les identifiants, le mappage IP public et la plage de relais. | Ouvrir une large plage de relais est plus simple ; la réduire diminue le nombre de ports exposés, mais nécessite une planification de capacité délibérée. |
Commencez par deux tests rapides. Tout d'abord, établissez un appel entre deux clients sur des réseaux simples, comme deux connexions haut débit classiques. Répétez ensuite l'opération depuis un réseau restreint tel qu'un réseau Wi-Fi d'entreprise, un VPN ou un point d'accès mobile. Si seul le réseau restreint pose problème, TURN est un suspect sérieux. Si les deux appels aboutissent mais que la qualité vidéo est médiocre, collectez des données réseau et matérielles avant de modifier l'architecture de relais.
La procédure de connexion documentée de Nextcloud privilégie la connectivité directe peer-to-peer, utilise STUN pour identifier les adresses accessibles et s'appuie sur TURN lorsqu'une connexion directe est impossible. TURN sert donc principalement de solution de repli , et non d'amplificateur universel de qualité vidéo. Un chemin relayé peut être plus fiable, mais il est aussi plus long et sollicite la bande passante du flux multimédia sur le serveur TURN.
Pour les déploiements auto-hébergés, coturn est l'implémentation TURN la plus courante documentée par Nextcloud. Nextcloud recommande l'authentification par secret partagé pour cette intégration. Générez un secret aléatoire robuste et utilisez la même valeur dans coturn et dans les paramètres d'administration de Talk.
openssl rand -hex 32Une configuration minimale comprend généralement un port d'écoute, l'authentification par empreinte numérique, l'authentification par secret partagé, un domaine et des restrictions d'accès entre pairs. L'emplacement exact du fichier dépend de votre système d'exploitation et de son package. Voici un exemple de configuration :
listening-port=443
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_RANDOM_SECRET
realm=turn.example.com
total-quota=0
bps-capacity=0
stale-nonce
no-multicast-peersLes anciennes versions de coturn peuvent nécessiter des options devenues inutiles dans les versions plus récentes. Il est donc déconseillé de copier une ancienne configuration sans discernement. La documentation Nextcloud coturn, régulièrement mise à jour, indique clairement les directives dépendantes de la version. Vérifiez que votre version de coturn installée est conforme aux instructions Nextcloud coturn actuelles .
Si Coturn est derrière un NAT, configurez correctement la correspondance entre ses adresses publiques et privées. La documentation de configuration de Coturn explique cette external-ipcorrespondance et exige que les ports de relais soient correctement mappés à travers le NAT. Consultez l' exemple de configuration de Coturn en amont .
Pour les médias en temps réel, le protocole UDP est généralement privilégié car il évite les retransmissions TCP et le blocage en tête de file. Cependant, certains réseaux d'entreprise et réseaux invités bloquent complètement l'UDP. TCP ou TURN sur TLS peuvent constituer une solution de repli acceptable sur les réseaux autorisant uniquement le trafic web.
Pour une accessibilité optimale, Nextcloud recommande l'écoute sur le port 443 et prend en charge TURN/TLS. L'utilisation simultanée de ces deux protocoles turn:améliore turns:la compatibilité, mais implique la gestion des certificats et de chemins de transport supplémentaires. Si tous les utilisateurs se trouvent sur des réseaux contrôlés où le protocole UDP est fonctionnel, une architecture privilégiant UDP peut s'avérer plus simple à gérer. En revanche, si les utilisateurs se connectent régulièrement depuis des hôtels, des sites clients, des bureaux sécurisés ou des VPN, le basculement TCP/TLS justifie généralement la configuration supplémentaire.
Une erreur fréquente consiste à n'ouvrir que le port d'écoute TURN. Le client contacte d'abord coturn sur son écouteur, mais coturn alloue également des points de relais pour le flux média. Par défaut, coturn utilise des ports UDP 49152-65535pour l'allocation des relais. Si cette plage est bloquée par le pare-feu de l'hôte, le groupe de sécurité du cloud, le routeur en amont ou le périphérique NAT, l'authentification peut réussir, mais le flux média peut échouer.
Vous pouvez conserver la plage de relais par défaut ou la réduire volontairement min-port. max-portLe compromis est simple : une plage étendue est facile à gérer et offre une grande capacité d'allocation ; une plage réduite est plus facile à définir dans la politique de pare-feu, mais peut devenir un goulot d'étranglement si trop de relais simultanés nécessitent des ports. Dimensionnez une plage réduite en fonction de la concurrence prévue plutôt que de choisir une valeur arbitrairement petite.
Si l'hôte TURN possède une adresse privée derrière un routeur, conservez la correspondance de port un-à-un pour la plage de relais sélectionnée et configurez la correspondance d'adresse publique dans coturn. Si l'hôte possède une adresse IP publique directement sur son interface, l'étape de correspondance NAT est inutile.
Ouvrez l'interface d'administration de Nextcloud et accédez aux paramètres Talk. Ajoutez le serveur TURN en utilisant uniquement l'hôte et le port, et non une http://URL https://. La documentation Talk de Nextcloud indique que le schéma TURN est sélectionné séparément ; le champ serveur doit donc être au format suivant : [adresse_hôte]/[port] turn.example.com:443.
Saisissez le même secret partagé que celui configuré dans coturn et activez les protocoles acceptés par votre serveur. Si vous utilisez TLS, sélectionnez le schéma TURN correspondant et assurez-vous que le certificat corresponde au nom d'hôte TURN. Vous pouvez également utiliser votre propre service TURN comme serveur STUN, ce qui simplifie la gestion des hôtes. Toutefois, il peut être utile de séparer STUN et TURN pour disposer de domaines de défaillance indépendants ou de relais géographiquement distribués.
Ne divulguez pas le secret partagé dans des captures d'écran, des tickets ou des exemples de configuration publics. Nextcloud l'utilise pour générer des identifiants TURN temporaires pour ses clients.
Après avoir enregistré la configuration Talk, effectuez une vérification d'administration afin de déterminer si le serveur TURN renvoie des candidats ICE utilisables. Un résultat positif indique que le navigateur a pu obtenir des candidats fonctionnels auprès du service TURN configuré. Toutefois, cela ne garantit pas le bon fonctionnement de chaque réseau utilisateur, de chaque chemin de relais et de chaque appel important.
Effectuez un nouvel appel depuis au moins un réseau restrictif. Ceci est important car une vérification côté serveur peut réussir alors qu'un réseau utilisateur bloque toujours UDP, la résolution DNS ou un protocole de transport spécifique. Si UDP échoue mais que TCP/TLS sur le port 443 réussit, conservez le chemin de secours. Si tous les chemins échouent, examinez les journaux du pare-feu, les journaux coturn, le DNS, la validité du certificat, le secret partagé et la configuration NAT.
TURN et le backend haute performance résolvent des problèmes différents. TURN relaie le trafic lorsque les clients ne peuvent pas établir le chemin WebRTC requis. Le backend haute performance modifie la gestion des flux multimédias multipartites afin que chaque participant n'ait pas à envoyer un flux distinct à tous les autres.
L'interface Talk de Nextcloud indique que son fonctionnement sans le backend haute performance est uniquement prévu pour les appels de très petite taille, généralement définis dans le projet comme impliquant deux ou trois participants. Si votre problème n'apparaît que lorsque le nombre de participants augmente, l'ajout de TURN permettra peut-être de joindre davantage de clients, mais ne supprimera pas le transfert de données entre pairs ni la charge du processeur. Consultez la configuration système requise pour Nextcloud Talk et les recommandations du projet concernant le backend haute performance avant d'augmenter le nombre d'appels de groupe.
Même avec un serveur backend haute performance, il est recommandé de maintenir TURN disponible lorsque les utilisateurs se connectent depuis des réseaux à accès restreint. Nextcloud indique une plage de ports WebRTC par défaut 20000-40000pour le backend et précise qu'un client limité au port 443 peut nécessiter TURN pour relayer les paquets vers cette plage de ports.
| Option | Avantages | Coûts et limites | Meilleure adaptation |
|---|---|---|---|
| Cotour auto-hébergé | Contrôle total, flux de données sous votre administration, configuration prévisible | Vous gérez les certificats, les mises à jour, la surveillance, la bande passante, la politique de pare-feu et la capacité géographique. | Les organisations possédant des compétences en infrastructure ou des exigences de contrôle strictes |
| TURN géré | Efforts opérationnels réduits et couverture géographique potentiellement plus facile | Les coûts et les supports de diffusion peuvent transiter par un fournisseur de relais tiers. | Les équipes qui privilégient la simplicité opérationnelle et la portée multirégionale |
| Interdit de tourner | Coût serveur minimal et chemin le plus court lorsque WebRTC direct fonctionne toujours. | Les appels peuvent échouer sur les NAT symétriques et les pare-feu restrictifs. | Environnements contrôlés où les réseaux clients sont connus et testés |
min-portréelle .max-portSi Nextcloud Talk fonctionne sur certains réseaux mais pas sur d'autres, configurez un service TURN accessible et vérifiez le serveur d'écoute, le secret partagé, le mappage NAT et les ports de relais. Si les appels sont établis mais de mauvaise qualité, commencez par mesurer la charge du réseau client et du terminal, car TURN peut ajouter de la latence au lieu de la réduire. Si le problème s'aggrave avec le nombre de participants, la solution architecturale la plus appropriée consiste généralement à utiliser un backend haute performance, en conservant TURN comme solution de compatibilité pour les réseaux à accès restreint.
Comparez sept outils qui prennent en charge ou complètent WSUS, allant de la console et des diagnostics natifs de Microsoft à la publication de correctifs tiers et au déploiement à distance.
Comparez six outils de surveillance système Windows pour l'état du serveur, la visibilité des applications et les alertes, avec des informations actualisées sur le déploiement et les licences.
Comparez sept outils Wake-on-LAN en fonction de leurs fonctionnalités et de leur disponibilité, y compris les utilitaires gratuits, les suites d'administration réseau et les outils sélectionnés en 2021 qui ont depuis été retirés du marché.
Comparez neuf outils de ping pour des vérifications rapides d'accessibilité, la découverte de sous-réseaux, les tests TCP et la surveillance de la latence, avec des conseils pour choisir celui qui convient le mieux à votre tâche réseau.
Comparez les meilleurs serveurs TFTP pour Windows, Linux et macOS, notamment SolarWinds, Tftpd64, tftpd-hpa, atftpd, haneWIN et dnsmasq.
Comparez cinq alternatives à Microsoft Access pour le travail sur bases de données de bureau, SQLite, sans code et basées sur navigateur, avec leurs points forts, leurs limites et leurs cas d'utilisation les plus adaptés.
Comparez les outils de surveillance open source et propriétaires en fonction du coût, du support, de la personnalisation, de la sécurité et des options actuelles, notamment Zabbix, Nagios, PRTG et plus encore.
Comprendre comment les termes « entrée » et « sortie » décrivent le trafic entrant et sortant, pourquoi la direction dépend des limites du réseau et comment surveiller la bande passante et repérer les transferts de données à risque.
Comparez six serveurs et collecteurs syslog gratuits pour Windows et Linux, incluant des outils GUI, des options open source, la recherche, les alertes et le transport sécurisé.
Découvrez ce que fait Microsoft IIS, comment fonctionnent son pipeline de requêtes et ses pools d'applications, et quand Apache, NGINX ou Caddy peuvent mieux répondre à vos besoins en matière de serveur Web.
