Une modification récente de l'appel Matrix affecte la découverte des transports MatrixRTC, mais pas les identifiants ni les ports TURN de Coturn. Dans sa mise à jour du 21 août 2026, Matrix.org a indiqué qu'Element Call 0.24 abandonnait la découverte des transports MatrixRTC via le /.well-known/matrix/clientfichier du serveur d'accueil. Les déploiements Element Call autonomes doivent prendre en charge le point de terminaison des transports MatrixRTC ; Element Web/Desktop et Element X conservaient l'ancienne méthode de découverte comme solution de repli pendant la transition des clients. Ceci est distinct de la configuration TURN classique.
Ce guide configure Coturn pour le service TURN de Synapse, qui fournit des identifiants ICE temporaires aux clients utilisant des appels WebRTC classiques. Les appels de groupe Element Call et MatrixRTC actuels utilisent une unité de transfert sélectif (SFU) LiveKit et un service d'autorisation MatrixRTC. Coturn seul ne remplace pas ces composants. Si vous souhaitez héberger Element Call sur votre propre serveur, suivez la procédure LiveKit décrite dans le guide officiel d'Element Call ; n'ajoutez Coturn que si votre architecture média nécessite un service TURN distinct.
| Chemin d'appel | Que configurer | Quand ce guide Coturn s'applique |
|---|---|---|
| Appel WebRTC traditionnel ou hérité | Coturn plus Synapse turn_uriset un secret partagé | Utilisez la configuration ci-dessous lorsque le client demande des informations d'identification TURN au point de terminaison de Synapse /voip/turnServer. |
| MatrixRTC / Appel d'élément | Une unité de service LiveKit (SFU), un service d'autorisation MatrixRTC et une découverte de transport du serveur domestique | Coturn ne remplace pas LiveKit. LiveKit inclut un service TURN intégré optionnel ; veuillez suivre sa propre configuration réseau et TURN. |
Pour MatrixRTC sur Synapse, le guide d'auto-hébergement actuel d'Element Call utilise matrix_rtc.transportset active le registre de transport du serveur d'accueil via l'indicateur de fonctionnalité expérimentale documenté. L'avis de Matrix.org 2026 indique que cette modification concerne principalement les déploiements Element Call autonomes ; les autres administrateurs peuvent préparer le point de terminaison tandis que les clients compatibles conservent une solution de repli. Consultez le guide correspondant aux clients et à la version de Synapse que vous utilisez.
STUN permet à un client WebRTC de découvrir l'adresse réseau publique qu'il peut diffuser. TURN relaie les flux multimédias lorsque deux clients ne peuvent pas établir de connexion directe via leurs routeurs ou pare-feu. Coturn implémente ces deux services. Sans relais accessible, un appel peut sonner mais rester bloqué sur « Connexion en cours » si les participants se trouvent sur des réseaux restrictifs ou non liés.
Un serveur TURN nécessite une adresse IP publique ou une passerelle NAT dotée d'une adresse IP publique et de règles de redirection appropriées. Un serveur privé ne peut pas servir de relais Internet pour les utilisateurs distants de Matrix. Pour un déploiement Synapse de petite taille, vous pouvez installer Coturn sur le serveur principal ou utiliser un hôte public distinct. Un hôte distinct offre une meilleure protection du pare-feu et une mise à l'échelle indépendante ; une installation sur le même hôte est plus simple, mais exige des règles de pare-feu rigoureuses afin que le relais n'expose pas les services privés.
Sur Debian ou Ubuntu, installez le paquet de distribution :
sudo apt update
sudo apt install coturnCe paquet fournit un service systemd et son fichier de configuration principal est généralement situé à l'emplacement indiqué /etc/turnserver.conf. D'autres distributions utilisent leur propre nom de paquet, leur propre système de gestion des services et leur propre chemin de configuration.
Générez un secret bien gardé. Par exemple :
openssl rand -hex 32Utilisez le même secret dans Coturn et Synapse. Traitez-le comme un mot de passe : ne réutilisez pas une valeur d’exemple de la documentation, ne l’intégrez pas à un dépôt public et ne l’incluez pas dans un rapport de bogue public. Si votre version de Synapse le permet turn_shared_secret_path, vous pouvez stocker le secret dans un fichier protégé plutôt que directement dans le YAML. Synapse a ajouté cette option dans la version 1.116.0 ; vérifiez votre version déployée avant de l’utiliser.
Modifiez /etc/turnserver.confet configurez le nom du service et l'authentification par secret partagé. Remplacez les espaces réservés au domaine et au secret :
listening-port=3478
tls-listening-port=5349
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_THE_SAME_RANDOM_SECRET
realm=turn.example.org
min-port=49152
max-port=65535
no-tcp-relay
no-multicast-peers
user-quota=12
total-quota=1200
sysloguse-auth-secretActive le mécanisme d'authentification TURN à durée limitée utilisé par Synapse. Ne configurez pas l'accès anonyme et n'exposez pas de relais ouvert. Les valeurs de quota ci-dessus constituent un point de départ issu des recommandations Coturn de Synapse ; ajustez-les en fonction du nombre d'utilisateurs et de la capacité prévus. no-tcp-relayEmpêche les clients de demander au relais de se connecter à des destinations TCP arbitraires ; cela ne signifie pas que vous devez désactiver TCP comme protocole de transport client-TURN.
Le protocole TURN peut être détourné pour servir de relais vers des adresses réseau internes ou sensibles. Appliquez l'intégralité des plages d'adresses interdites aux pairs dans l'exemple de sécurité Synapse Coturn actuel, y compris les plages pertinentes pour vos réseaux IPv4 et IPv6. Vérifiez les règles avant de les copier si des utilisateurs ont légitimement besoin d'accéder à des pairs du réseau privé. Assurez-vous également que Coturn est à jour et surveillez ses journaux et quotas.
Si l'hôte TURN se trouve derrière un routeur, ajoutez son adresse publique à la configuration afin que Coturn annonce une adresse de relais accessible :
external-ip=YOUR_PUBLIC_IPV4
listening-ip=YOUR_PRIVATE_IPV4Remplacez les valeurs d'exemple par les adresses réelles ; l'adresse d'écoute est facultative si Coturn est déjà lié à l'interface appropriée. Transmettez la plage d'écoute et de relais TURN du routeur vers ce serveur. Une adresse externe incorrecte est une cause fréquente d'échec des appels fonctionnant sur le même réseau local mais échouant entre des réseaux différents.
Autorisez les ports correspondant à votre configuration Coturn à la fois dans le pare-feu hôte et dans tout pare-feu ou routeur cloud :
Pour UFW, un ensemble de règles de base pour l'écouteur UDP/TCP et le relais UDP peut ressembler à ceci :
sudo ufw allow 3478/tcp
sudo ufw allow 3478/udp
sudo ufw allow 49152:65535/udpAjoutez les règles 5349 uniquement si l'écouteur TLS ou DTLS correspondant est configuré et annoncé. Vérifiez également le groupe de sécurité de votre fournisseur ; une règle UFW au niveau de l'hôte ne peut pas remplacer une règle de blocage d'entrée cloud. Ne publiez pas l'interface de contrôle d'administration de Coturn sur Internet.
Ajoutez les paramètres TURN suivants à la configuration Synapse active, généralementhomeserver.yaml : . Le nom d'hôte doit être résolu publiquement vers l'hôte TURN :
turn_uris:
- "turn:turn.example.org:3478?transport=udp"
- "turn:turn.example.org:3478?transport=tcp"
turn_shared_secret: "REPLACE_WITH_THE_SAME_RANDOM_SECRET"
turn_user_lifetime: 1h
turn_allow_guests: trueLes deux premières URI annoncent des transports TURN ordinaires sur le port 3478. Si TLS est configuré et testé, vous pouvez également annoncer une URI telle que `<URI>` turns:turn.example.org:5349?transport=tcp. N'annoncez pas d' URI tant que le certificat, le serveur d'écoute, le pare-feu et la compatibilité client ne sont pas tous en place. Le certificat TLS et la clé privée de Coturn sont définis avec `<URI>` et turns:`<URI>` dans sa configuration.certpkey
Configurez turn_allow_guestscette option selon votre règlement intérieur et les conditions relatives aux invités. L'activation peut permettre à des utilisateurs non authentifiés de demander des identifiants TURN, ce qui peut être nécessaire pour les appels des invités, mais augmente le risque d'abus. La désactivation peut rendre les appels des invités instables. Dans tous les cas, utilisez la surveillance et les quotas.
Redémarrez Coturn et Synapse après avoir modifié leurs fichiers :
sudo systemctl restart coturn
sudo systemctl restart matrix-synapseSi le nom de votre unité systemd Synapse diffère, veuillez l'utiliser. Rechargez ou redémarrez les clients concernés ; les paramètres TURN de Synapse étant actualisés régulièrement, un client peut ne pas constater de changement immédiatement.
Commencez par configurer TURN UDP/TCP sur le port 3478 et vérifiez qu'un relais potentiel fonctionne. N'activez TURN sur TLS que si les réseaux de vos utilisateurs l'exigent, par exemple en présence de pare-feu d'entreprise autorisant le trafic de type TLS mais bloquant le protocole UDP classique. TLS étend la connectivité, mais implique le renouvellement des certificats, un écouteur supplémentaire et des vérifications de compatibilité client.
Il existe une mise en garde spécifique à Matrix : le guide Synapse Coturn actuel indique que le protocole TLS/DTLS avec certificats Let's Encrypt n'est pas compatible avec les clients Matrix utilisant la bibliothèque WebRTC de Chromium, notamment Element pour Android et iOS, comme précisé dans ce guide. Vérifiez la compatibilité de vos versions client avant de publier un URI TLS. Ce même guide recommande de configurer d'abord le service de base, puis d'ajouter TLS/DTLS ultérieurement.
Vérifiez d'abord que Coturn est en cours d'exécution et consultez ses journaux :
sudo systemctl status coturn
sudo journalctl -u coturn -fEnsuite, depuis une session client Matrix authentifiée, examinez la requête adressée au point de terminaison API client-serveur de Synapse /_matrix/client/v3/voip/turnServer. Une réponse positive doit inclure un nom d'utilisateur, un mot de passe, une durée de vie (TTL) et les URI TURN que vous avez configurées. Ne divulguez pas publiquement cette réponse ; ces informations d'identification constituent des jetons d'accès temporaires pour votre relais.
Utilisez l'exemple officiel WebRTC Trickle ICE pour effectuer un test avec un nom d'utilisateur et un mot de passe fournis par Synapse. Ajoutez votre URI TURN et vos identifiants, exécutez le test de collecte ICE et recherchez un candidat de type relay. Un serveur répondant uniquement aux requêtes STUN peut afficher un candidat réflexif, mais ne parvient pas à relayer les flux multimédias. Effectuez le test depuis une connexion mobile ou un réseau externe à votre réseau local, puis établissez un appel réel entre des participants situés sur des réseaux différents.
/voip/turnServer.external-ip, redirection de ports et route de retour. Coturn doit diffuser l'adresse publique accessible aux clients.turns:l’URI annoncée et la compatibilité spécifique au client.Pour les clients navigateurs, les diagnostics WebRTC du navigateur indiquent si le média a sélectionné un relais. Pour MatrixRTC, vérifiez que Synapse publie bien le point de terminaison de transport et que les routes WebSocket et d'autorisation LiveKit sont accessibles. Testez à la fois le point de terminaison actuel et toute solution de repli documentée requise par les clients que vous prenez en charge.
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
