Si vous êtes hébergé par nos soins, cette configuration est déjà prête sur votre site. Ce guide s’adresse aux administrateurs qui auto-hébergent Discourse.
Discourse Live utilise WebRTC pour les appels vocaux et vidéo. Il est livré avec des serveurs STUN publics pour aider les participants à établir des connexions directes. Les administrateurs peuvent remplacer ces serveurs et ajouter TURN pour prendre en charge les réseaux où les connexions directes échouent.
Pour un serveur dédié à votre communauté, nous recommandons d’exécuter coturn comme serveur STUN et TURN, avec une authentification par secret partagé pour TURN. Cela permet la découverte de l’adresse publique et un repli de relais sans diffuser un mot de passe TURN permanent ni dépendre de serveurs STUN tiers.
Ce guide s’applique aux appels peer-to-peer de Live. Les salles utilisant LiveKit utilisent la propre configuration ICE/TURN de LiveKit. En savoir plus sur la configuration LiveKit de Live.
À quoi servent STUN et TURN ?
- STUN aide le 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.
Un navigateur qui a appris son adresse publique peut la proposer comme candidat srflx (server-reflexive), ce qui rend possibles les connexions directes à travers les NAT des domiciles et des bureaux. Sans cela, la plupart des appels se rabattent sur le relais TURN, ce qui ajoute de la latence et une charge de bande passante pour le relais.
STUN doit rester ouvert même lorsque vous exécutez TURN. Une réponse d’allocation TURN contient également l’adresse publique du navigateur, mais seuls certains navigateurs (comme Firefox) l’utilisent comme candidat. Les navigateurs basés sur Chromium et Safari ne découvrent leur adresse publique que via une requête STUN Binding séparée, et les navigateurs n’attachent jamais d’identifiants aux requêtes Binding. Si le serveur désactive STUN (no-stun) ou exige une authentification pour celui-ci (secure-stun), ces navigateurs n’obtiennent aucun candidat srflx et tous les appels auxquels ils se joignent sont relayés.
Avec TURN configuré en mode secret partagé, Live autorise à la fois les connexions directes et relayées. La configuration de TURN ne force pas tous les appels à passer par le relais. Configuration ICE de Live.
1. Préparer un serveur TURN
Vous pouvez utiliser un service TURN géré qui prend en charge l’authentification par secret partagé de l’API REST TURN, ou exécuter vous-même coturn.
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 d’hôte tel que
turn.example.com, pointant directement vers ce serveur. - Un accès pare-feu pour son écouteur TURN et sa plage de ports de relais UDP.
- Un certificat valide si vous proposez TURN via TLS.
Les navigateurs des participants se connectent directement à TURN. Un simple proxy inverse HTTP 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 confidentiel. Vous saisirez la même valeur dans coturn et Discourse.
Sur un serveur avec une IP publique assignée directement, 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=REMPLACEZ_PAR_VOTRE_SECRET_ALEATOIRE
# N'ajoutez pas no-stun ni secure-stun : les navigateurs envoient des requêtes STUN Binding
# sans identifiants, et beaucoup s'appuient dessus pour découvrir leur adresse publique.
min-port=49152
max-port=65535
no-multicast-peers
# Cet exemple démarre sans TLS.
no-tls
no-dtls
Remplacez le nom d’hôte et le secret, protégez le fichier de configuration, et redémarrez coturn. Supprimez toute configuration no-auth conflicting ou d’user= statique. Le mode secret partagé de Coturn active en interne le mécanisme d’authentification nécessaire. Référence de configuration Coturn.
STUN anonyme ne signale qu’à un client sa propre adresse ; il ne peut pas relayer le trafic, ce qui signifie qu’il ne transforme pas votre serveur en relais ouvert. Les versions récentes de coturn désactivent par défaut les attributs de réponse MAPPED-ADDRESS et les options RFC 5780, ce qui maintient les réponses Binding proches de la taille des requêtes et limite leur utilité pour les attaques par réflexion. Laissez rfc5780 et stun-backward-compatibility désactivés.
Autorisez le trafic entrant vers :
| Port | Protocole | Usage |
|---|---|---|
3478 |
UDP | STUN et TURN |
3478 |
TCP | 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 mappage external-ip=IP_PUBLIQUE/IP_PRIVÉE de coturn et transférez les ports d’écoute et de relais. Les ports de relais doivent conserver leurs numéros de port à travers le NAT. Options de déploiement de Coturn.
Ajouter TLS pour les réseaux restrictifs
TURN via TLS fournit une autre option de connexion pour les participants dont les réseaux bloquent UDP.
Supprimez no-tls et configurez :
tls-listening-port=5349
cert=/chemin/vers/fullchain.pem
pkey=/chemin/vers/privkey.pem
Ouvrez le port 5349/TCP, assurez-vous que coturn peut lire le certificat et la clé, et redémarrez-le après le renouvellement des certificats.
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 de relais UDP reste requise lorsque les navigateurs atteignent TURN via TCP ou TLS. Documentation du serveur Coturn.
2. Configurer Discourse
Dans Admin → Paramètres, recherchez ces paramètres Live :
| Paramètre | Valeur |
|---|---|
live_stun_servers |
L’URI STUN de votre serveur coturn — remplacez les entrées par défaut |
live_turn_secret |
La valeur utilisée pour static-auth-secret de coturn |
live_turn_secret_servers |
Vos URI TURN, séparés par | |
live_turn_servers |
Vide |
live_turn_username |
Vide |
live_turn_credential |
Vide |
Pour la configuration ci-dessus, entrez ceci dans live_stun_servers :
stun:turn.example.com:3478
Et ceci dans live_turn_secret_servers :
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp
Si vous avez activé TLS, ajoutez son endpoint :
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp|turns:turn.example.com:5349?transport=tcp
Utilisez les URI stun:, turn: et turns: sans //. Ne listez que les endpoints que votre serveur prend réellement en charge.
Les navigateurs basés sur Chromium envoient également des requêtes STUN aux serveurs TURN que vous listez, de sorte qu’un live_stun_servers vide peut fonctionner tant que coturn répond au STUN anonyme. Lister l’URI STUN explicitement rend la configuration plus claire, couvre d’autres navigateurs et permet aux diagnostics de connexion de Live de le tester séparément.
La liste live_turn_secret_servers utilise des identifiants générés à partir du secret partagé. La liste séparée live_turn_servers utilise un nom d’utilisateur et un mot de passe fixes. Définitions des paramètres Live.
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 qu’une connexion Internet résidentielle et des données mobiles, et dans plusieurs navigateurs — au moins un navigateur basé sur Chromium et Firefox. Confirmez que l’audio fonctionne dans les deux sens, puis testez la vidéo et le partage d’écran.
Pendant que vous êtes dans une salle peer-to-peer, ouvrez le menu ⋮ de la salle et choisissez Diagnostics de connexion :
- Sous Serveurs STUN/TURN, chaque serveur doit indiquer Accessible. Les serveurs TURN doivent lister une Adresse de relais, et les serveurs UDP doivent lister une Adresse publique. « Adresse publique : Aucun » signifie que les requêtes STUN n’ont reçu aucune réponse — vérifiez
no-stun/secure-stunet que3478/UDPest ouvert. - Sous Pairs, la route indique comment chaque connexion transporte les médias : Direct (même réseau), Direct (via NAT grâce à STUN), ou Relayé via TURN. La plupart des participants sur les réseaux domestiques ordinaires devraient se connecter directement.
- Copier le rapport génère un rapport texte que vous pouvez partager avec la personne en charge du dépannage. Il contient les adresses IP des participants, donc partagez-le de manière privée.
Dans les navigateurs Chromium, chrome://webrtc-internals affiche les mêmes détails à un niveau plus bas :
- Un candidat
srflxreprésente une adresse publique découverte. - Un candidat
relayreprésente un relais TURN disponible. - La paire de candidats sélectionnée indique la connexion transportant 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.
Maintenir le serveur dédié à votre communauté
Le secret partagé reste sur Discourse et le serveur TURN. Les participants reçoivent des identifiants temporaires à la place. Live génère actuellement des identifiants valides pour la création d’allocations pendant 12 heures ; une allocation établie peut continuer pendant qu’elle est renouvelée. Génération des identifiants de Live.
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 à Live aux groupes prévus.
- Surveillez la bande passante du relais et le nombre d’allocations.
- Définissez des quotas d’allocation et des limites de bande passante coturn adapté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. Votre serveur répondra également aux requêtes STUN anonymes de n’importe qui ; c’est attendu, utilise peu de bande passante et n’accorde pas d’accès au relais. Authentification et contrôles d’accès de Coturn.
Alternatives
Remplacer uniquement les serveurs STUN publics
Définissez live_stun_servers sur vos propres URI STUN, séparés 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.
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 live_turn_servers, live_turn_username et live_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, Live 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 Live.