Verbeter de kwaliteit van Nextcloud Talk-videogesprekken en de verbinding met de TURN-server.

Problemen met Nextcloud Talk-gesprekken worden vaak omschreven als "slechte videokwaliteit", maar de onderliggende oorzaken zijn niet altijd hetzelfde. Een gebruiker kan voldoende bandbreedte hebben en toch geen verbinding kunnen maken omdat een firewall peer-to-peer WebRTC-verkeer blokkeert. Een ander gesprek kan wel succesvol tot stand komen via TURN, maar trager aanvoelen omdat alle media worden doorgestuurd. Een grotere vergadering kan zelfs met een perfect werkende TURN-server problemen ondervinden omdat de implementatie nog steeds gebruikmaakt van de ingebouwde peer-to-peer-topologie in plaats van de High Performance Backend.

De meest nuttige aanpak voor het oplossen van problemen is daarom om connectiviteit , mediapad en schaalbaarheid van elkaar te scheiden . Per 6 oktober 2026 beschrijft de upstream Talk-documentatie van Nextcloud nog steeds TURN als de fallback wanneer directe WebRTC-connectiviteit niet mogelijk is en adviseert poort 443 voor maximale compatibiliteit. Er wordt ook vermeld dat een TURN-server nog steeds nodig kan zijn wanneer de High Performance Backend in gebruik is. Zie de officiële Nextcloud Talk TURN-documentatie en de officiële coturn-installatiehandleiding voor Talk .

Wat moet je als eerste aanpakken: de bandbreedte, TURN of de krachtige backend?

Gebruik het symptoompatroon om de volgende actie te kiezen in plaats van meerdere instellingen tegelijk te wijzigen.

Stap 1: vaststellen of het probleem te wijten is aan een verbindingsprobleem of aan de kwaliteit van het medium.

Begin met twee korte tests. Plaats eerst een gesprek tussen twee clients via ongecompliceerde netwerken, zoals twee normale breedbandverbindingen. Herhaal dit vervolgens vanaf een beperkt netwerk, zoals bedrijfs-wifi, een VPN of een mobiele hotspot. Als alleen het beperkte netwerk niet werkt, is TURN een sterke verdachte. Als beide gesprekken tot stand komen, maar de videokwaliteit slecht is, verzamel dan bewijsmateriaal over het netwerk en de apparaten voordat u de relay-architectuur wijzigt.

De gedocumenteerde verbindingsprocedure van Nextcloud probeert eerst een directe peer-to-peerverbinding, gebruikt STUN om bereikbare adressen te vinden en vertrouwt op TURN wanneer een directe verbinding niet tot stand kan worden gebracht. Dat betekent dat TURN voornamelijk een back-up is voor connectiviteitsproblemen , en geen universele verbetering van de videokwaliteit. Een doorgeschakelde verbinding kan betrouwbaarder zijn, maar is ook langer en verplaatst de bandbreedte van de media naar de TURN-server.

Stap 2: configureer coturn voor Nextcloud Talk

Voor zelfgehoste implementaties is coturn de meest voorkomende TURN-implementatie die door Nextcloud wordt gedocumenteerd. Nextcloud raadt authenticatie met een gedeeld geheim aan voor deze integratie. Genereer een sterk, willekeurig geheim en gebruik dezelfde waarde in zowel coturn als de Talk-beheerinstellingen.

openssl rand -hex 32

Een minimale configuratie omvat doorgaans een luisterpoort, fingerprinting, authenticatie met een gedeeld geheim, een realm en peer-restricties. De exacte locatie van de bestanden is afhankelijk van uw besturingssysteem en pakket. Een voorbeeld van een configuratie is:

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

Oudere versies van Coturn vereisen mogelijk opties die nieuwere versies niet meer nodig hebben. Kopieer daarom niet zomaar een oude configuratie. De actuele documentatie van Nextcloud over Coturn geeft expliciet aan welke versie afhankelijk is van de configuratie. Controleer uw geïnstalleerde Coturn-versie aan de hand van de huidige instructies voor Nextcloud over Coturn .

Als Coturn zich achter een NAT-router bevindt, configureer dan de juiste mapping van het publieke naar het privé-adres. De configuratiehandleiding van Coturn zelf legt de external-ipmapping uit en vereist dat relaypoorten consistent door NAT heen worden gemapt. Zie het voorbeeldconfiguratiebestand van Coturn voor de upstream-omgeving .

UDP, TCP of TLS: welke moet je inschakelen?

Voor realtime media is UDP doorgaans het geprefereerde transportprotocol omdat het TCP-herverzendingen en head-of-line blocking vermijdt. Sommige bedrijfs- en gastnetwerken blokkeren UDP echter volledig. TCP of TURN over TLS kan een bruikbaar alternatief bieden voor netwerken die alleen webverkeer toestaan.

Voor maximale bereikbaarheid raadt Nextcloud aan te luisteren op poort 443 en ondersteunt het TURN/TLS. Het gebruik van beide turn:verbetert turns:de compatibiliteit, maar betekent ook dat er certificaten en extra transportpaden beheerd moeten worden. Als alle gebruikers zich op beveiligde netwerken bevinden waar gegarandeerd UDP werkt, is een eenvoudiger ontwerp met UDP als primaire basis wellicht gemakkelijker te beheren. Als gebruikers regelmatig verbinding maken vanuit hotels, klantlocaties, beveiligde kantoren of VPN's, is een terugval naar TCP/TLS meestal de extra configuratie waard.

Stap 3: open de listener- en relaypoorten correct.

Een veelgemaakte fout is het openen van alleen de TURN-luisterpoort. De client neemt eerst contact op met coturn via zijn luisterpoort, maar coturn wijst ook relay-eindpunten toe voor media. De upstream-standaardinstellingen van coturn gebruiken UDP-poorten 49152-65535voor relay-toewijzingen. Als dat bereik wordt geblokkeerd door de hostfirewall, cloudbeveiligingsgroep, upstream-router of NAT-apparaat, kan authenticatie wel lukken, terwijl media nog steeds niet beschikbaar is.

U kunt het standaard relaybereik behouden of het bewust verkleinen met min-porten max-port. De afweging is eenvoudig: een breed bereik is operationeel eenvoudig en biedt voldoende toewijzingscapaciteit; een smal bereik is gemakkelijker te definiëren in firewallbeleid, maar kan een capaciteitsknelpunt worden als te veel gelijktijdige relays poorten nodig hebben. Bepaal de grootte van een kleiner bereik op basis van de verwachte gelijktijdigheid in plaats van een willekeurig klein getal te kiezen.

Als de TURN-host een privéadres achter een router heeft, behoud dan de één-op-één poorttoewijzing voor het geselecteerde relaybereik en stel de publieke adrestoewijzing in coturn in. Als de host een publiek IP-adres direct op zijn interface heeft, is de NAT-toewijzingsstap niet nodig.

Stap 4: Voeg de TURN-server toe in Nextcloud Talk.

Open het Nextcloud-beheergebied en ga naar de Talk-instellingen. Voeg de TURN-server toe met de hostnaam en poort, niet met een http://URL https://. Volgens de huidige Nextcloud Talk-documentatie wordt het TURN-schema apart geselecteerd, dus het serverveld moet de volgende vorm hebben: <servernaam> turn.example.com:443.

Voer hetzelfde gedeelde geheim in dat is geconfigureerd in coturn en schakel de protocollen in die uw server daadwerkelijk accepteert. Als u TLS gebruikt, selecteer dan het bijbehorende TURN-schema en zorg ervoor dat het certificaat overeenkomt met de TURN-hostnaam. U kunt ook uw eigen TURN-service als STUN-server gebruiken, wat het hostbeheer vereenvoudigt. Het gescheiden houden van STUN en TURN kan echter handig zijn als u onafhankelijke foutdomeinen of geografisch verspreide relays wilt.

Maak het gedeelde geheim niet openbaar in screenshots, tickets of openbare configuratievoorbeelden. Nextcloud gebruikt het om tijdelijke TURN-referenties voor clients te genereren.

Stap 5: test ICE-kandidaten en test vervolgens vanuit een restrictief netwerk.

Nadat u de Talk-configuratie hebt opgeslagen, gebruikt u de beheercontrole om te verifiëren of de TURN-server bruikbare ICE-kandidaten retourneert. Een succesvol resultaat bewijst dat de browser werkende kandidaten van de geconfigureerde TURN-service kon verkrijgen. Het bewijst echter niet dat elk gebruikersnetwerk, elk doorschakelpad en elk groot gesprek probleemloos zal verlopen.

Herhaal een daadwerkelijke oproep vanaf ten minste één restrictief netwerk. Dit is belangrijk omdat een servercontrole kan slagen terwijl een gebruikersnetwerk UDP, DNS-resolutie of een specifiek transport nog steeds blokkeert. Als UDP mislukt maar TCP/TLS op poort 443 wel lukt, behoud dan het fallback-pad. Als alle paden falen, controleer dan de firewall-logboeken, coturn-logboeken, DNS, certificaatvaliditeit, het gedeelde geheim en NAT-mapping.

Wanneer moet je de krachtige backend toevoegen?

TURN en de High Performance Backend lossen verschillende problemen op. TURN stuurt verkeer door wanneer clients het vereiste WebRTC-pad niet tot stand kunnen brengen. De High Performance Backend verandert de manier waarop media met meerdere deelnemers worden verwerkt, zodat niet elke deelnemer een aparte stream naar elke andere deelnemer hoeft te uploaden.

De Nextcloud Talk-interface zelf waarschuwt dat het gebruik zonder de High Performance Backend alleen bedoeld is voor zeer kleine gesprekken, in het project doorgaans omschreven als gesprekken met twee tot drie deelnemers. Als het probleem zich alleen voordoet wanneer het aantal deelnemers toeneemt, kan het toevoegen van TURN ervoor zorgen dat meer clients bereikbaar zijn, maar het zal de peer-to-peer upload- en CPU-belasting niet wegnemen. Raadpleeg de systeemvereisten van Nextcloud Talk en de richtlijnen voor de High Performance Backend van het project voordat u groepsgesprekken opschaalt.

Zelfs met de krachtige backend is het belangrijk om TURN beschikbaar te houden wanneer gebruikers verbinding maken vanuit netwerken met beperkingen. Nextcloud documenteert een standaard WebRTC-mediabereik 20000-40000voor de backend en merkt specifiek op dat een client die beperkt is tot poort 443 mogelijk nog steeds TURN nodig heeft om pakketten naar dat backendbereik door te sturen.

TURN in eigen beheer versus TURN in beheer

Praktische afstelchecklist

• Geef waar mogelijk de voorkeur aan directe WebRTC. Dit minimaliseert doorgaans de relaykosten en de latentie.
• Zorg voor TURN voor betrouwbaarheid. Beschouw het als een terugvaloptie voor lastige NAT- en firewallomstandigheden.
• Gebruik eerst UDP en daarna TCP/TLS voor compatibiliteit. Poort 443 is de meest firewallvriendelijke luisterpoort die Nextcloud aanbeveelt.
• Open het relaybereik, niet alleen de listener. Stem de firewall- en NAT-regels af op de daadwerkelijke min-portconfiguratie max-port.
• Monitor de TURN-bandbreedte. Doorgeschakelde gesprekken kunnen aanzienlijke hoeveelheden mediaverkeer via de TURN-host verwerken, waardoor netwerkcapaciteit vaak belangrijker is dan CPU-kracht.
• Scheid schaalproblemen van connectiviteitsproblemen. Evalueer voor grotere vergaderingen de krachtige backend in plaats van meer verkeer via TURN te leiden.
• Valideer met behulp van echte gebruikersnetwerken. Een ICE-test is noodzakelijk, maar hotel-, bedrijfs-, VPN- en mobiele netwerken kunnen zich verschillend gedragen.

Kortom

Als Nextcloud Talk op sommige netwerken wel werkt en op andere niet, configureer dan een goed bereikbare TURN-service en controleer de listener, het gedeelde geheim, de NAT-mapping en de relay-poorten. Als gesprekken wel tot stand komen, maar de kwaliteit slecht is, meet dan eerst de belasting van het clientnetwerk en het eindpunt, omdat TURN de latentie eerder kan verhogen dan verlagen. Als het probleem groter wordt naarmate het aantal deelnemers toeneemt, is de meest geschikte architectuuroplossing meestal de High Performance Backend, waarbij TURN behouden blijft als compatibiliteitsoplossing voor netwerken met beperkingen.