Fix Nextcloud Talk Video Call Quality and TURN Server Connection

Nextcloud Talk call problems are often described as “bad video quality,” but the underlying causes are not all the same. A user may have enough bandwidth and still fail to connect because a firewall blocks peer-to-peer WebRTC traffic. Another call may connect successfully through TURN but feel slower because all media is being relayed. A larger meeting may struggle even with a perfectly working TURN server because the deployment is still using the built-in peer-to-peer topology instead of the High Performance Backend.

The most useful troubleshooting approach is therefore to separate connectivity, media path, and scalability. As of October 6, 2026, Nextcloud's upstream Talk documentation still describes TURN as the fallback when direct WebRTC connectivity is not possible and recommends port 443 for maximum compatibility. It also notes that a TURN server can still be required when the High Performance Backend is in use. See the official Nextcloud Talk TURN documentation and official coturn setup guidance for Talk.

What should you fix first: bandwidth, TURN, or the High Performance Backend?

Use the symptom pattern to choose the next action instead of changing several settings at once.

Step 1: identify whether the failure is connectivity or media quality

Iniziate con due brevi test. Innanzitutto, effettuate una chiamata tra due client su reti semplici, come due normali connessioni a banda larga. Quindi ripetete il test da una rete più restrittiva, come il Wi-Fi aziendale, una VPN o un hotspot mobile. Se il problema si verifica solo con la rete più restrittiva, TURN è un forte sospettato. Se entrambe le chiamate vanno a buon fine ma la qualità video è scarsa, raccogliete dati di rete e del dispositivo prima di modificare l'architettura di inoltro.

La sequenza di connessione documentata di Nextcloud tenta prima una connessione peer-to-peer diretta, utilizza STUN per individuare gli indirizzi raggiungibili e si affida a TURN quando non è possibile stabilire un percorso diretto. Ciò significa che TURN è principalmente una soluzione di ripiego per la connettività , non un sistema universale per migliorare la qualità video. Un percorso instradato può essere più affidabile, ma è anche più lungo e sposta la larghezza di banda multimediale sul server TURN.

Passaggio 2: configurare coturn per Nextcloud Talk

Per le implementazioni self-hosted, coturn è l'implementazione TURN più comune documentata da Nextcloud. Nextcloud consiglia l'autenticazione con chiave segreta condivisa per questa integrazione. Genera una chiave segreta casuale robusta e utilizza lo stesso valore sia in coturn che nelle impostazioni di amministrazione di Talk.

openssl rand -hex 32

Una configurazione minima include in genere una porta di ascolto, il fingerprinting, l'autenticazione tramite chiave condivisa, un realm e le restrizioni peer. La posizione esatta del file dipende dal sistema operativo e dal pacchetto utilizzato. Una configurazione rappresentativa è la seguente:

listening-port=443
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_RANDOM_SECRET
realm=turn.example.com
total-quota=0
bps-capacity=0
stale-nonce
no-multicast-peers

Le versioni precedenti di coturn potrebbero richiedere opzioni non più necessarie nelle versioni più recenti, quindi non copiare ciecamente una vecchia configurazione. La documentazione di Nextcloud relativa a coturn etichetta esplicitamente le direttive dipendenti dalla versione. Verifica la versione di coturn installata confrontandola con le istruzioni di Nextcloud relative a coturn attualmente in uso .

Se coturn si trova dietro un NAT, configura correttamente la mappatura degli indirizzi pubblici e privati. La documentazione di configurazione di coturn spiega la external-ipmappatura e richiede che le porte di inoltro vengano mappate in modo coerente attraverso il NAT. Consulta l' esempio di configurazione di coturn a monte .

UDP, TCP o TLS: quale dovresti abilitare?

Per i contenuti multimediali in tempo reale, UDP è solitamente il protocollo di trasporto preferito perché evita la ritrasmissione di TCP e il blocco in testa alla coda. Tuttavia, alcune reti aziendali e per ospiti bloccano completamente UDP. TCP o TURN su TLS possono fornire una valida alternativa attraverso reti che consentono solo traffico di tipo web.

Per garantire la massima raggiungibilità, Nextcloud consiglia di rimanere in ascolto sulla porta 443 e supporta TURN/TLS. L'utilizzo di entrambi turn:i protocolli turns:migliora la compatibilità, ma implica anche la gestione di certificati e percorsi di trasporto aggiuntivi. Se tutti gli utenti si trovano su reti controllate in cui è noto che UDP funziona, una configurazione più semplice basata su UDP potrebbe essere più facile da gestire. Se gli utenti si connettono regolarmente da hotel, sedi di clienti, uffici con restrizioni di accesso o VPN, il fallback a TCP/TLS è generalmente una soluzione valida, nonostante la configurazione aggiuntiva.

Passaggio 3: aprire correttamente le porte listener e relay.

Un errore comune è quello di aprire solo la porta di ascolto di TURN. Il client contatta prima coturn sul suo listener, ma coturn alloca anche endpoint di inoltro per i contenuti multimediali. Le impostazioni predefinite di coturn 49152-65535per l'inoltro dei contenuti multimediali utilizzano porte UDP. Se tale intervallo è bloccato dal firewall dell'host, dal gruppo di sicurezza cloud, dal router a monte o dal dispositivo NAT, l'autenticazione potrebbe avere successo ma il trasferimento dei contenuti multimediali potrebbe comunque fallire.

È possibile mantenere l'intervallo di inoltro predefinito o ridurlo intenzionalmente con min-porte max-port. Il compromesso è semplice: un intervallo ampio è semplice da gestire e offre un'ampia capacità di allocazione; un intervallo ristretto è più facile da descrivere nelle policy del firewall, ma può diventare un collo di bottiglia in termini di capacità se troppi inoltri simultanei richiedono porte. Dimensionare un intervallo ridotto in base alla concorrenza prevista, anziché scegliere un numero piccolo arbitrario.

Se l'host TURN ha un indirizzo privato dietro un router, mantieni la mappatura delle porte uno a uno per l'intervallo di inoltro selezionato e imposta la mappatura dell'indirizzo pubblico in coturn. Se l'host ha un IP pubblico direttamente sulla sua interfaccia, il passaggio di mappatura NAT non è necessario.

Passaggio 4: aggiungi il server TURN in Nextcloud Talk

Apri l'area di amministrazione di Nextcloud e vai alle impostazioni di Talk. Aggiungi il server TURN utilizzando host e porta senza nome, non un http://URL https://. La documentazione attuale di Nextcloud su Talk afferma che lo schema TURN viene selezionato separatamente, quindi il campo server dovrebbe essere nel formato <server> turn.example.com:443.

Inserisci la stessa chiave segreta condivisa configurata in coturn e abilita i protocolli effettivamente accettati dal tuo server. Se utilizzi TLS, seleziona lo schema TURN corrispondente e assicurati che il certificato corrisponda al nome host TURN. Puoi anche utilizzare il tuo servizio TURN come server STUN, il che semplifica la gestione degli host, sebbene mantenere STUN e TURN separati possa essere utile quando si desiderano domini di errore indipendenti o relay distribuiti geograficamente.

Non divulgare il segreto condiviso in screenshot, ticket o esempi di configurazione pubblici. Nextcloud lo utilizza per generare credenziali TURN temporanee per i client.

Fase 5: testare i candidati ICE, quindi testare da una rete restrittiva

Dopo aver salvato la configurazione di Talk, utilizzare il controllo amministrativo che verifica se il server TURN restituisce candidati ICE utilizzabili. Un risultato positivo dimostra che il browser è riuscito a ottenere candidati funzionanti dal servizio TURN configurato. Ciò non garantisce che ogni rete utente, ogni percorso di inoltro e ogni chiamata di grandi dimensioni funzioneranno correttamente.

Ripeti una chiamata reale da almeno una rete restrittiva. Questo è importante perché un controllo lato server può avere esito positivo mentre una rete utente blocca ancora UDP, la risoluzione DNS o un particolare protocollo di trasporto. Se UDP fallisce ma TCP/TLS sulla porta 443 ha successo, mantieni il percorso di fallback. Se tutti i percorsi falliscono, controlla i log del firewall, i log di coturn, il DNS, la validità del certificato, la chiave segreta condivisa e il mapping NAT.

Quando è opportuno aggiungere il backend ad alte prestazioni?

TURN e il backend ad alte prestazioni risolvono problemi diversi. TURN inoltra il traffico quando i client non riescono a stabilire il percorso WebRTC richiesto. Il backend ad alte prestazioni modifica la gestione dei flussi multimediali multi-partecipante, in modo che ogni partecipante non debba caricare un flusso separato per ogni altro partecipante.

L'interfaccia Talk di Nextcloud avverte che l'esecuzione senza il backend ad alte prestazioni è pensata solo per chiamate di dimensioni molto ridotte, generalmente descritte nel progetto come chiamate con due o tre partecipanti. Se il problema si presenta solo all'aumentare del numero di partecipanti, l'aggiunta di TURN potrebbe rendere raggiungibili più client, ma non eliminerà il carico di upload e CPU peer-to-peer. Prima di scalare le chiamate di gruppo, consultare i requisiti di sistema di Nextcloud Talk e le linee guida del progetto relative al backend ad alte prestazioni.

Anche con il backend ad alte prestazioni, è importante mantenere TURN disponibile quando gli utenti si connettono da reti con restrizioni. Nextcloud documenta un intervallo di porte multimediali WebRTC predefinito 20000-40000per il backend e specifica che un client limitato alla porta 443 potrebbe comunque richiedere a TURN di inoltrare i pacchetti a tale intervallo di porte del backend.

TURN self-hosted vs TURN gestito

Lista di controllo pratica per la messa a punto

• Quando possibile, è preferibile utilizzare WebRTC diretto. In genere, riduce al minimo i costi di inoltro e la latenza.
• Fornire TURN per garantire l'affidabilità. Considerarlo come percorso di ripiego in caso di condizioni NAT e firewall complesse.
• Utilizzare prima UDP e poi TCP/TLS per la compatibilità. La porta 443 è la porta di ascolto più compatibile con i firewall, come raccomandato da Nextcloud.
• Estendere il raggio di inoltro, non solo il listener. Adattare le regole del firewall e del NAT alla configurazione min-porteffettiva max-port.
• Monitorare la larghezza di banda di TURN. Le chiamate inoltrate possono generare un traffico multimediale considerevole attraverso l'host TURN, pertanto la capacità di rete è spesso più importante della CPU.
• Distinguete i problemi di scalabilità da quelli di connettività. Per riunioni più numerose, valutate l'utilizzo del backend ad alte prestazioni anziché forzare un maggiore traffico attraverso TURN.
• Convalidare su reti di utenti reali. Un test ICE è necessario, ma le reti di hotel, aziende, VPN e dispositivi mobili possono comportarsi in modo diverso.

In conclusione

Se Nextcloud Talk funziona su alcune reti ma non su altre, configura un servizio TURN correttamente raggiungibile e verifica il listener, la chiave segreta condivisa, il mapping NAT e le porte di inoltro. Se le chiamate si connettono ma la qualità è scarsa, misura innanzitutto il carico della rete client e dell'endpoint, poiché TURN può aggiungere latenza anziché rimuoverla. Se il problema si aggrava con l'aumentare del numero di partecipanti, la soluzione architetturale più appropriata è solitamente l'utilizzo del backend ad alte prestazioni, mantenendo TURN come soluzione di compatibilità per le reti con restrizioni.