Si votre site est hébergé par nos soins, cette configuration est déjà préinstallée. Ce guide s’adresse aux administrateurs qui hébergent eux-mêmes leur instance Discourse.
Discourse Voice utilise WebRTC pour les appels vocaux et vidéo. Il est livré avec des serveurs STUN publics pour aider les participants à établir une connexion directe. Les administrateurs peuvent remplacer ces serveurs et ajouter un serveur TURN pour prendre en charge les réseaux où les connexions directes échouent.
Pour un serveur dédié à votre communauté, nous recommandons l’utilisation de TURN avec une authentification par secret partagé et un paramètre STUN vide. Cela permet la découverte d’adresses publiques et un relais de secours sans avoir à distribuer un mot de passe TURN permanent.
Ce guide s’applique aux appels peer-to-peer de Voice. Les salles utilisant LiveKit utilisent la configuration ICE/TURN propre à LiveKit. En savoir plus sur la configuration LiveKit de Voice.
À quoi servent STUN et TURN ?
- STUN aide un navigateur à découvrir son adresse IP publique et son port afin de tenter une connexion directe.
- TURN relaie les médias lorsqu’une connexion directe ne peut pas être établie.
Une allocation TURN authentifiée retourne également l’adresse publique du navigateur. WebRTC peut utiliser cette adresse comme candidat réflexif serveur, offrant ainsi l’avantage de la découverte d’adresse de STUN sans avoir besoin d’un serveur STUN séparé. Spécification TURN.
Avec un TURN par secret partagé configuré, Voice autorise à la fois les connexions directes et relayées, même si son paramètre STUN est vide. La configuration de serveurs TURN uniquement ne force pas tous les appels à passer par le relais. Configuration ICE de Voice.
1. Préparer un serveur TURN
Vous pouvez utiliser un service TURN managé qui prend en charge l’authentification par secret partagé de l’API REST TURN, ou exécuter coturn vous-même.
Pour une configuration auto-hébergée, préparez :
- Un serveur avec une adresse IP publique et une bande passante suffisante pour les appels relayés.
- Un nom de domaine tel que
turn.example.com, pointant directement vers ce serveur. - Un accès pare-feu pour son écouteur TURN et la plage de ports UDP de relais.
- Un certificat valide si vous proposez TURN via TLS.
Les navigateurs des participants se connectent directement à TURN. Un proxy inverse HTTP ordinaire ou un proxy CDN ne peut pas transporter le trafic TURN.
Exemple de configuration coturn
Générez un secret aléatoire :
openssl rand -hex 32
Gardez ce résultat privé. Vous saisirez la même valeur dans coturn et dans Discourse.
Sur un serveur avec une adresse IP publique directement attribuée, utilisez ce qui suit comme point de départ dans /etc/turnserver.conf :
listening-port=3478
fingerprint
realm=turn.example.com
use-auth-secret
static-auth-secret=REPLACE_WITH_YOUR_RANDOM_SECRET
# Désactiver les requêtes STUN autonomes.
# Les allocations TURN authentifiées retournent toujours l'adresse publique du client.
no-stun
min-port=49152
max-port=65535
no-multicast-peers
# Cet exemple démarre sans TLS.
no-tls
no-dtls
Remplacez le nom de domaine et le secret, protégez le fichier de configuration et redémarrez coturn. Supprimez toute configuration no-auth ou user= statique contradictoire. Le mode secret partagé de Coturn active le mécanisme d’authentification dont il a besoin en interne. Référence de configuration Coturn.
Autorisez le trafic entrant vers :
| Port | Protocole | But |
|---|---|---|
3478 |
UDP et TCP | Connexions des navigateurs à TURN |
49152–65535 |
UDP | Médias relayés |
Autorisez également le trafic sortant correspondant. La plage de ports de relais doit correspondre à min-port et max-port.
Si le serveur se trouve derrière un NAT, configurez le mapping external-ip=IP_PUBLIQUE/IP_PRIVÉE de coturn et transférez les ports de l’écouteur et de relais. Les ports de relais doivent conserver leurs numéros de port à travers le NAT. Options de déploiement Coturn.
Ajouter TLS pour les réseaux restrictifs
TURN via TLS offre une autre option de connexion pour les participants dont les réseaux bloquent l’UDP.
Supprimez no-tls et configurez :
tls-listening-port=5349
cert=/path/to/fullchain.pem
pkey=/path/to/privkey.pem
Ouvrez le port 5349/TCP, assurez-vous que coturn peut lire le certificat et la clé, et redémarrez-le après les renouvellements de certificat.
Vous pouvez utiliser 443/TCP à la place si ce port est disponible sur le serveur TURN. Cela peut aider sur les réseaux restrictifs, bien que certains réseaux inspectent et bloquent également le trafic non-HTTP sur le port 443. La plage de ports UDP de relais est toujours requise lorsque les navigateurs atteignent TURN via TCP ou TLS. Documentation du serveur Coturn.
2. Configurer Discourse
Dans Admin → Settings, recherchez ces paramètres Voice :
| Paramètre | Valeur |
|---|---|
voice_stun_servers |
Vide — supprimez les entrées par défaut |
voice_turn_secret |
La valeur utilisée pour static-auth-secret de coturn |
voice_turn_secret_servers |
Vos URI TURN, séparées par | |
voice_turn_servers |
Vide |
voice_turn_username |
Vide |
voice_turn_credential |
Vide |
Pour la configuration ci-dessus, saisissez ceci dans voice_turn_secret_servers :
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp
Si vous avez activé TLS, ajoutez son point de terminaison :
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp|turns:turn.example.com:5349?transport=tcp
Utilisez des URI turn: et turns:, sans //. N’énumérez que les points de terminaison réellement pris en charge par votre serveur.
La liste voice_turn_secret_servers utilise des identifiants générés à partir du secret partagé. La liste séparée voice_turn_servers utilise un nom d’utilisateur et un mot de passe fixes. Définitions des paramètres Voice.
Enregistrez les paramètres, puis demandez aux participants de quitter et de rejoindre à nouveau les appels pour obtenir la nouvelle configuration.
3. Vérifier la configuration
Testez avec deux participants sur des réseaux différents, tels que la bande passante domestique et les données mobiles. Confirmez que l’audio fonctionne dans les deux sens, puis testez la vidéo et le partage d’écran.
Dans les navigateurs Chromium, ouvrez chrome://webrtc-internals avant de rejoindre :
- Un candidat
srflxreprésente une adresse publique découverte. - Un candidat
relayreprésente un relais TURN disponible. - La paire de candidats sélectionnée montre la connexion qui transporte réellement les médias.
Un appel direct réussi ne prouve pas que le relais fonctionne. Testez également depuis un réseau qui nécessite TURN, ou utilisez un client de test WebRTC avec iceTransportPolicy: "relay" et des identifiants temporaires.
Vérifiez les journaux de coturn pour les allocations authentifiées réussies. Les requêtes sans identifiants valides ne doivent pas obtenir d’allocation de relais. Un défi d’authentification initial 401 est normal ; les échecs d’authentification répétés nécessitent une investigation.
Garder le serveur dédié à votre communauté
Le secret partagé reste sur Discourse et sur le serveur TURN. Les participants reçoivent des identifiants temporaires à la place. Voice génère actuellement des identifiants valides pour la création d’allocations pendant 12 heures ; une allocation établie peut continuer tant qu’elle est renouvelée. Génération des identifiants de Voice.
Cela empêche un relais ouvert anonyme, mais les identifiants TURN ne sont pas liés à une origine de navigateur : un participant peut copier et réutiliser ses identifiants temporaires. Pour limiter les abus :
- Restreignez l’accès à Voice aux groupes prévus.
- Surveillez la bande passante de relais et le nombre d’allocations.
- Définissez des quotas d’allocation et des limites de bande passante coturn appropriés à votre communauté.
- Bloquez l’accès au relais vers les destinations privées, link-local et autres destinations internes accessibles depuis l’hôte TURN.
- Gardez coturn à jour et faites tourner le secret partagé s’il est exposé.
Utilisez un secret dédié pour ce déploiement Discourse. Avec no-stun activé, le serveur cesse également d’offrir le service STUN autonome anonyme. Authentification et contrôles d’accès Coturn.
Alternatives
Remplacer uniquement les serveurs STUN publics
Définissez voice_stun_servers sur vos propres URI STUN, séparées par | :
stun:stun.example.com:3478
Laissez les paramètres TURN vides si vous n’avez pas besoin de relais. STUN seul ne peut pas faire fonctionner les appels sur tous les réseaux. Un serveur coturn configuré avec no-stun ne peut pas servir ce point de terminaison.
Utiliser TURN avec un nom d’utilisateur et un mot de passe fixes
Si votre fournisseur ne prend pas en charge l’authentification par secret partagé, configurez voice_turn_servers, voice_turn_username et voice_turn_credential. Laissez les paramètres de secret partagé vides.
Les participants reçoivent ces identifiants fixes, ce qui les rend plus faciles à réutiliser en dehors de votre site. De plus, Voice force actuellement les connexions relayées lorsque des serveurs TURN statiques sont configurés et que la liste STUN est vide. Préférez l’authentification par secret partagé lorsque votre fournisseur la prend en charge. Configuration ICE de Voice.