Accueil
» Comment faire
»
Réussir les appels Nextcloud Talk même en cas de défaillance de Direct Media
Réussir les appels Nextcloud Talk même en cas de défaillance de Direct Media
Pour résoudre un problème de connexion lors d'un appel Nextcloud Talk ou en cas de flux média unidirectionnel, configurez un relais TURN accessible, saisissez son nom d'hôte, son port et son secret partagé dans les paramètres Talk, puis autorisez le trafic à la fois sur le serveur TURN et sur ses ports de relais. TURN fournit à WebRTC une route relayée en cas d'échec de la connexion directe ; il ne résout pas les problèmes de connexion Wi-Fi faible, de perte de paquets ou de surcharge du réseau.
Exemple illustratif : Imaginez une petite organisation dont les employés peuvent participer à un appel Talk depuis le bureau, mais ne peuvent pas envoyer de vidéo de manière fiable depuis le réseau d’un hôtel. Le pare-feu de l’hôtel peut bloquer l’accès direct au flux vidéo. L’exemple ci-dessous décrit les étapes suivies par l’administrateur lors de la vérification de la route, de la configuration de coTURN et du test de la modification ; il ne s’agit pas d’un compte rendu de déploiement ou de test réel.
1. Confirmez qu'un relais est la solution appropriée.
Nextcloud Talk tente d'abord de connecter directement les participants. STUN permet aux appareils de découvrir l'adresse IP publique et le port configurés par le routeur. Si un pare-feu ou une configuration NAT restrictive empêche toujours une connexion directe, TURN prend le relais. Un serveur STUN seul ne peut pas assurer ce relais.
Comparez un appel sur le réseau de l'entreprise avec un appel provenant d'un réseau distinct, comme un point d'accès Wi-Fi. Si l'appel s'établit à un endroit mais échoue systématiquement à établir l'audio ou la vidéo dans la zone où la connexion est restreinte, l'utilisation de TURN est une piste à explorer. Si l'appel s'établit mais que l'image reste floue ou saccadée sur tous les réseaux, mesurez d'abord la bande passante, la perte de paquets, la qualité du Wi-Fi et la charge du processeur ; acheminer davantage de flux multimédias via un relais peut augmenter la charge sans pour autant augmenter la capacité du processeur.
Illustration : une page d’administration avec des champs de configuration et une identification masquée, représentant les paramètres à vérifier avant un appel test.
Notez la version de Talk, le nom d'hôte et le port TURN, si l'hôte TURN se trouve derrière un NAT et si un serveur de traitement haute performance (HPB) est installé. Ces informations doivent rester confidentielles. Les commandes ci-dessous supposent l'utilisation de Linux avec systemd ; les chemins d'accès aux paquets peuvent varier.
2. Configurez coTURN avec l'authentification par secret partagé
La documentation de Nextcloud Talk recommande coTURN 4.5.0.8 ou une version ultérieure, car les versions plus anciennes présentent un problème avec les sockets UDP IPv6. Installez-le depuis le dépôt de votre distribution et localisez son fichier de configuration actif (souvent ` /etc/turnserver.confcoTURN.config.css`). Générez un secret aléatoire sur l'hôte TURN :
openssl rand -hex 32
Stockez cette valeur dans un gestionnaire de mots de passe ou un espace de configuration sécurisé. Dans la configuration coTURN active, définissez l'écouteur, l'authentification par secret partagé et le domaine. Remplacez le nom d'hôte et le secret d'exemple par les valeurs réelles.
La documentation Talk ne concerne lt-cred-mechque les versions de coTURN antérieures à la 4.5.0.8 ; il est recommandé de mettre à jour les installations plus anciennes plutôt que de copier aveuglément les paramètres existants. Si coTURN est installé derrière un NAT, configurez ses adresses publique et de relais conformément au guide de déploiement et assurez-vous que le nom DNS pointe vers une adresse accessible aux participants.
Illustration : un éditeur de configuration représentant l’écouteur coTURN et les paramètres d’authentification ; utilisez les noms de paramètres documentés dans le texte, et non les valeurs déduites de l’image.
3. Ouvrez le chemin d'écoute et de relais.
Autorisez le port d'écoute TURN (3478 dans cet exemple) à travers les pare-feu de l'hôte et des serveurs en amont pour les protocoles UDP et TCP. Pour TLS, coTURN requiert également un certificat et une clé privée valides, et Talk doit utiliser le protocole turns:TLS. Le port 443 permet d'accéder à des réseaux plus restrictifs, mais vérifiez l'absence de conflits : un serveur HPB peut également avoir besoin de ce port, ce qui nécessiterait des adresses IP ou des hôtes distincts.
Les médias utilisent également des ports relais. Autorisez la plage UDP du relais coTURN dans le pare-feu hôte, le groupe de sécurité cloud et le routeur. Si vous configurez `coTURN_listen_password` min-portet max-port`coTURN_relay_password`, ouvrez précisément cette plage ; autoriser uniquement le récepteur est insuffisant. Pour un hôte TURN derrière un NAT, transmettez à la fois le récepteur et la plage de relais et configurez ses adresses publiques/de relais. Conservez les restrictions d'accès aux pairs coTURN pour empêcher l'accès aux services internes non liés.
Illustration : les entrées du pare-feu représentent le trafic d’écoute et de relais qui doit être autorisé ; la plage de ports exacte dépend de la configuration coTURN.
Redémarrez coTURN après modification et vérifiez que le service est actif. Par exemple, sur un hôte systemd :
sudo systemctl restart coturn
sudo systemctl status coturn --no-pager
L'état du service confirme que le processus a démarré ; il ne prouve pas qu'un navigateur distant puisse atteindre le relais. Vérifiez séparément les pare-feu de l'hôte et du fournisseur, et consultez les journaux coTURN pour détecter les erreurs de liaison, les échecs d'authentification ou les messages relatifs aux quotas d'allocation.
4. Ajoutez le serveur dans Talk et vérifiez qu'il s'agit d'un appel réel.
En tant qu'administrateur, ouvrez les paramètres d'administration > Talk . Saisissez le nom d'hôte et le port TURN, par exemple `/var/ login` turn.example.org:3478, ainsi que le même secret que `/ var/login` static-auth-secret. N'incluez pas `/ var/login` https://, turn:`/var/login` ou turns:`/var/login` dans le champ du nom d'hôte ; choisissez le protocole dans les options de Talk. Gardez les protocoles UDP et TCP activés lorsque cela est possible. Utilisez cette fonction turns:uniquement après avoir configuré TLS dans coTURN.
Enregistrez et exécutez la vérification TURN intégrée de Talk si elle est disponible. Appelez ensuite depuis le réseau restreint vers un autre réseau et vérifiez la connexion audio et vidéo bidirectionnelle. Consultez les journaux coTURN pendant l'appel pour détecter d'éventuels problèmes d'attribution ou d'authentification. Dans cet exemple, l'administrateur compare la connexion (de type hôtel) avec l'appel passé depuis le bureau.
Illustration : une fenêtre d’appel à deux personnes représente la vérification de bout en bout après l’enregistrement des paramètres TURN ; confirmez que chaque participant peut envoyer et recevoir des médias.
Si la vérification échoue, comparez le nom d'hôte, le port et le secret, puis vérifiez le DNS, les règles de pare-feu, la plage UDP de relais, la redirection NAT et les journaux de service. Une vérification de base peut ne pas détecter un problème de chemin de relais ; effectuez donc un test depuis un réseau externe. Pour un diagnostic TURN uniquement, suivez la procédure spécifique au navigateur de Talk ; sa méthode en console est temporaire et le comportement du navigateur diffère.
TURN ne prend pas en charge les appels de groupe à grande échelle. Pour les groupes plus importants, Nextcloud recommande l'utilisation d'un HPB (High Power Block) pour les appels de plus de 5 à 10 participants. Si la connexion TURN s'établit mais que la qualité vidéo reste médiocre, vérifiez la bande passante, la perte de paquets, les interférences Wi-Fi et la charge du serveur avant de modifier les quotas de relais.
Vérification
La solution est confirmée par trois signes observables : Talk accepte la configuration TURN, les journaux coTURN indiquent des attributions de relais pendant un appel et les participants sur des réseaux différents peuvent échanger de l'audio et de la vidéo dans les deux sens. Si seul l'appel au bureau fonctionne ou si les journaux n'affichent aucune requête entrante, la route publique est toujours bloquée ou l'hôte et le port configurés ne correspondent pas. Si le flux multimédia est actif mais que la qualité reste médiocre, la connectivité TURN est fonctionnelle et le problème persistant se situe probablement ailleurs sur le réseau ou dans l'infrastructure d'appel.