Se sei ospitato da noi, questa opzione è già preconfigurata sul tuo sito. Questa guida è destinata agli amministratori che ospitano Discourse in autonomia.
Discourse Live utilizza WebRTC per le chiamate vocali e video. Viene fornito con server STUN pubblici per aiutare i partecipanti a connettersi direttamente. Gli amministratori possono sostituire tali server e aggiungere TURN per supportare le reti in cui le connessioni dirette non riescono.
Per un server dedicato alla tua community, consigliamo di eseguire coturn come server sia STUN che TURN, con autenticazione a secret condiviso per TURN. Questo fornisce il rilevamento dell’indirizzo pubblico e un fallback di inoltro senza distribuire una password TURN permanente o fare affidamento su server STUN di terze parti.
Questa guida si applica alle chiamate peer-to-peer di Live. Le stanze che utilizzano LiveKit usano invece la propria configurazione ICE/TURN di LiveKit. Scopri la configurazione LiveKit di Live.
Cosa fanno STUN e TURN?
- STUN aiuta il browser a scoprire il proprio indirizzo IP pubblico e la porta, in modo da poter tentare una connessione diretta.
- TURN inoltra i media quando non è possibile stabilire una connessione diretta.
Un browser che conosce il proprio indirizzo pubblico può offrirlo come un candidato srflx (server-reflexive), il che rende possibili le connessioni dirette attraverso i NAT domestici e degli uffici. Senza uno di questi, la maggior parte delle chiamate ripiega sul relay TURN, aggiungendo latenza e larghezza di banda per il relay.
STUN deve rimanere aperto anche quando si esegue TURN. Una risposta di allocazione TURN contiene anche l’indirizzo pubblico del browser, ma solo alcuni browser (come Firefox) lo utilizzano come candidato. I browser basati su Chromium e Safari apprendono il loro indirizzo pubblico solo da una richiesta STUN Binding separata e i browser non allegano mai credenziali alle richieste Binding. Se il server disabilita STUN (no-stun) o richiede l’autenticazione (secure-stun), tali browser non ottengono alcun candidato srflx e ogni chiamata a cui partecipano viene inoltrata tramite relay.
Con TURN configurato con secret condiviso, Live consente sia connessioni dirette che inoltrate tramite relay. Configurare TURN non forza tutte le chiamate a passare attraverso il relay. Configurazione ICE di Live.
1. Preparare un server TURN
Puoi utilizzare un servizio TURN gestito che supporta l’autenticazione a secret condiviso TURN REST API, oppure eseguire tu stesso coturn.
Per una configurazione self-hosted, preparati a:
- Un server con un indirizzo IP pubblico e larghezza di banda sufficiente per le chiamate inoltrate.
- Un hostname come
turn.example.com, puntato direttamente a quel server. - Accesso al firewall per il suo listener TURN e l’intervallo di porte UDP per il relay.
- Un certificato valido se offri TURN su TLS.
I browser dei partecipanti si connettono a TURN direttamente. Un ordinario proxy inverso HTTP o un proxy CDN non può trasportare il traffico TURN.
Esempio di configurazione coturn
Genera un secret casuale:
openssl rand -hex 32
Mantieni il risultato privato. Inserisci lo stesso valore in coturn e Discourse.
Su un server con un IP pubblico direttamente assegnato, usa quanto segue come punto di partenza in /etc/turnserver.conf:
listening-port=3478
fingerprint
realm=turn.example.com
use-auth-secret
static-auth-secret=REPLACE_WITH_YOUR_RANDOM_SECRET
# Non aggiungere no-stun o secure-stun: i browser inviano richieste STUN Binding
# senza credenziali e molti si basano su di esse per scoprire il loro indirizzo pubblico.
min-port=49152
max-port=65535
no-multicast-peers
# Questo esempio inizia senza TLS.
no-tls
no-dtls
Sostituisci l’hostname e il secret, proteggi il file di configurazione e riavvia coturn. Rimuovi qualsiasi configurazione no-auth o user= statica in conflitto. La modalità a secret condiviso di Coturn abilita internamente il meccanismo di autenticazione necessario. Riferimento configurazione Coturn.
STUN anonimo riporta solo l’indirizzo del client stesso; non può inoltrare traffico, quindi non trasforma il tuo server in un relay aperto. Le versioni recenti di coturn mantengono disattivati per impostazione predefinita gli attributi opzionali di risposta RFC 5780 e MAPPED-ADDRESS, il che mantiene le dimensioni delle risposte Binding vicine a quelle della richiesta e limita la loro utilità per gli attacchi di riflessione. Lascia rfc5780 e stun-backward-compatibility disabilitati.
Consenti il traffico in ingresso verso:
| Porta | Protocollo | Scopo |
|---|---|---|
3478 |
UDP | STUN e TURN |
3478 |
TCP | TURN |
49152–65535 |
UDP | Media inoltrati |
Consenti anche il traffico in uscita corrispondente. L’intervallo del relay deve corrispondere a min-port e max-port.
Se il server si trova dietro un NAT, configura la mappatura external-ip=IP_PUBBLICO/IP_PRIVATO di coturn e inoltra le porte del listener e del relay. Le porte del relay devono mantenere i loro numeri di porta attraverso il NAT. Opzioni di distribuzione Coturn.
Aggiungere TLS per reti restrittive
TURN su TLS fornisce un’altra opzione di connessione per i partecipanti le cui reti bloccano UDP.
Rimuovi no-tls e configura:
tls-listening-port=5349
cert=/path/to/fullchain.pem
pkey=/path/to/privkey.pem
Apri 5349/TCP, assicurati che coturn possa leggere il certificato e la chiave e riavvialo dopo i rinnovi del certificato.
Puoi usare 443/TCP invece se quella porta è disponibile sul server TURN. Questo potrebbe aiutare su reti restrittive, sebbene alcune reti ispezionino e blocchino anche il traffico non-HTTP sulla porta 443. L’intervallo di porte del relay UDP è ancora richiesto quando i browser raggiungono TURN su TCP o TLS. Documentazione server Coturn.
2. Configurare Discourse
In Admin → Settings, cerca queste impostazioni di Live:
| Impostazione | Valore |
|---|---|
live_stun_servers |
L’URI STUN del tuo server coturn — sostituisci le voci predefinite |
live_turn_secret |
Il valore utilizzato per il static-auth-secret di coturn |
live_turn_secret_servers |
Le tue URI TURN, separate da | |
live_turn_servers |
Vuoto |
live_turn_username |
Vuoto |
live_turn_credential |
Vuoto |
Per la configurazione sopra, inserisci questo in live_stun_servers:
stun:turn.example.com:3478
E questo in live_turn_secret_servers:
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp
Se hai abilitato TLS, aggiungi il suo endpoint:
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp|turns:turn.example.com:5349?transport=tcp
Usa gli URI stun:, turn: e turns:, senza //. Elenca solo gli endpoint che il tuo server supporta effettivamente.
I browser basati su Chromium inviano anche richieste STUN ai server TURN che elenchi, quindi un live_stun_servers vuoto può funzionare a patto che coturn risponda a STUN anonimo. Elencare esplicitamente l’URI STUN rende la configurazione più chiara, copre altri browser e consente alla diagnostica della connessione di Live di testarlo in modo indipendente.
L’elenco live_turn_secret_servers utilizza credenziali generate dal secret condiviso. L’elenco separato live_turn_servers utilizza un nome utente e una password fissi. Definizioni impostazioni Live.
Salva le impostazioni, poi chiedi ai partecipanti di uscire e rientrare nelle chiamate per ottenere la nuova configurazione.
3. Verificare la configurazione
Esegui test con due partecipanti su reti diverse, come banda larga domestica e dati mobili, e in più di un browser — almeno un browser basato su Chromium e Firefox. Conferma che l’audio funziona in entrambe le direzioni, poi testare video e condivisione dello schermo.
Mentre sei in una stanza peer-to-peer, apri il menu ⋮ della stanza e scegli Diagnostica della connessione:
- Sotto Server STUN/TURN, ogni server dovrebbe mostrare Raggiungibile. I server TURN dovrebbero elencare un Indirizzo di relay e i server UDP dovrebbero elencare un Indirizzo pubblico. “Indirizzo pubblico: Nessuno” significa che le richieste STUN non hanno ricevuto risposta — controlla l’assenza di
no-stun/secure-stune che3478/UDPsia aperto. - Sotto Peer, la rotta mostra come ogni connessione trasporta i media: Diretta (stessa rete), Diretta (attraverso NAT tramite STUN) o Inoltrata tramite TURN. La maggior parte dei partecipanti sulle reti domestiche ordinarie dovrebbe connettersi direttamente.
- Copia report produce un report di testo che puoi condividere con chi sta risolvendo i problemi. Include gli indirizzi IP dei partecipanti, quindi condividilo in modo privato.
Nei browser Chromium, chrome://webrtc-internals mostra gli stessi dettagli a un livello inferiore:
- Un candidato
srflxrappresenta un indirizzo pubblico scoperto. - Un candidato
relayrappresenta un relay TURN disponibile. - La coppia di candidati selezionata mostra la connessione che effettivamente trasporta i media.
Una chiamata diretta riuscita non prova che l’inoltro funzioni. Testa anche da una rete che richiede TURN, oppure usa un client di test WebRTC con iceTransportPolicy: "relay" e credenziali temporanee.
Controlla i log di coturn per allocazioni autenticate corrette. Le richieste senza credenziali valide non devono ottenere un’allocazione di relay. Una sfida iniziale di autenticazione 401 è normale; ripetuti fallimenti di autenticazione richiedono investigazione.
Mantieni il server dedicato alla tua community
Il secret condiviso rimane su Discourse e sul server TURN. I partecipanti ricevono invece credenziali temporanee. Live attualmente genera credenziali valide per creare allocazioni per 12 ore; un’allocazione stabilita può continuare mentre viene aggiornata. Generazione delle credenziali di Live.
Questo impedisce un relay aperto anonimo, ma le credenziali TURN non sono legate all’origine del browser: un partecipante può copiare e riutilizzare le sue credenziali temporanee. Per limitare gli abusi:
- Limita l’accesso a Live ai gruppi previsti.
- Monitora la larghezza di banda del relay e i conteggi delle allocazioni.
- Imposta quote di allocazione e limiti di larghezza di banda di coturn appropriati per la tua community.
- Blocca l’accesso del relay a destinazioni private, link-local e altre destinazioni interne raggiungibili dall’host TURN.
- Mantieni coturn aggiornato e ruota il secret condiviso se viene esposto.
Usa un secret dedicato per questa distribuzione di Discourse. Il tuo server risponderà anche alle richieste STUN anonime da chiunque; questo è atteso, utilizza poca larghezza di banda e non concede accesso al relay. Autenticazione e controlli di accesso Coturn.
Alternative
Sostituire solo i server STUN pubblici
Imposta live_stun_servers sui tuoi URI STUN, separati da |:
stun:stun.example.com:3478
Lascia le impostazioni TURN vuote se non hai bisogno di un relay. STUN da solo non può far funzionare le chiamate su tutte le reti.
Usare TURN con nome utente e password fissi
Se il tuo provider non supporta l’autenticazione a secret condiviso, configura live_turn_servers, live_turn_username e live_turn_credential. Lascia vuote le impostazioni del secret condiviso.
I partecipanti ricevono quelle credenziali fisse, il che le rende più facili da riutilizzare al di fuori del tuo sito. Inoltre, Live attualmente forza le connessioni tramite relay quando vengono configurati server TURN statici e l’elenco STUN è vuoto. Preferisci l’autenticazione a secret condiviso quando il tuo provider la supporta. Configurazione ICE di Live.