STUN- en TURN-servers: wat een videogesprek nodig heeft om verbinding te maken

Op het eerste gezicht zou een videogesprek in de browser eenvoudig moeten zijn. WebRTC stuurt audio en video rechtstreeks van het ene apparaat naar het andere, zonder server ertussen. Dan test je het buiten je eigen netwerk, en sommige gesprekken gaan over, worden opgenomen en blijven dan stil en zwart. Meestal is er niets mis met de code. Wat ontbreekt is een STUN-server, een TURN-server of allebei.

In dit artikel lees je wat elk van beide doet, waarom een gesprek ze nodig heeft, wat er komt kijken bij een eigen TURN-server, en wat je doet met de gesprekken die zelfs een relay niet kan verbinden.

Waarom twee apparaten niet zomaar verbinding maken

Bijna geen enkel apparaat op internet heeft een eigen openbaar adres. Een laptop thuis zit achter een router, een telefoon achter zijn mobiele provider en een kantoorcomputer achter een firewall. Elk van hen kent alleen zijn privéadres, zoals 192.168.1.23, en dat zegt de andere kant van het gesprek niets.

Voordat een gesprek kan beginnen, moet elk apparaat uitzoeken hoe het andere bereikbaar is, en moeten de twee die wegen proberen tot er één werkt. WebRTC doet dat met ICE, dat voor elk apparaat kandidaatadressen verzamelt en ze in paren test. Een deel van die kandidaten komt van STUN en TURN.

Wat een STUN-server doet

Een STUN-server beantwoordt één vraag: “wat is mijn adres, zoals jij het ziet?” Een apparaat stuurt hem een klein verzoek, en de server antwoordt met het openbare adres en de poort waar het verzoek vandaan kwam. Het apparaat voegt dat adres toe aan zijn kandidaten, de andere kant probeert het, en op de meeste thuisnetwerken komt het gesprek dan rechtstreeks tot stand.

STUN kost weinig. Hij ziet een paar kleine pakketjes aan het begin van een gesprek en daarna niets meer, dus één STUN-server kan heel veel gesprekken bedienen, en er zijn openbare servers die iedereen mag gebruiken. Als er een directe weg is, heeft een gesprek niet meer nodig dan STUN.

Wat een TURN-server doet

Soms is er geen directe weg. Een strenge firewall laat niets binnen, een mobiele provider geeft een telefoon voor elke nieuwe bestemming een andere openbare poort, of een bedrijfsnetwerk staat alleen webverkeer toe. Het adres dat STUN doorgaf werkt dan niet voor de andere kant, en het gesprek mislukt.

Een TURN-server is een relay voor die gesprekken. Beide apparaten maken een uitgaande verbinding met hem, en hij geeft hun audio en video aan elkaar door. Omdat de apparaten alleen uitgaande verbindingen maken, die bijna elk netwerk toestaat, komt het gesprek door waar een directe verbinding dat niet kan.

Een relay kost iets wat STUN niet kost: elke seconde audio en video gaat erdoorheen, in beide richtingen, zolang het gesprek duurt. Een videogesprek tussen twee mensen kan er meerdere megabits per seconde doorheen sturen. Daarom zijn er wel openbare STUN-servers, maar geen betrouwbare gratis TURN-servers: een relay die voor iedereen openstaat, vervoert al snel verkeer dat de eigenaar nooit wilde vervoeren, en wordt dan gesloten of achter inloggegevens gezet.

Je eigen TURN-server draaien

Er bestaan opensource-TURN-servers die goed werken, en veel teams beginnen daarmee. Wat er bij komt kijken:

• Een server met een openbaar adres en veel bandbreedte, dicht bij je gebruikers. Een relay op een ander continent voegt vertraging toe die mensen horen.
• De juiste poorten. De gebruikelijke poort is 3478, via UDP en TCP. Voor netwerken die alleen webverkeer toestaan, moet de relay ook antwoorden op poort 443 met TLS, en dan heb je een certificaat voor zijn naam nodig dat op tijd wordt vernieuwd.
• Inloggegevens die verlopen. Een TURN-server mag nooit een vaste gebruikersnaam en wachtwoord accepteren die in je pagina staan, zodat iedereen ze kan kopiëren. De gebruikelijke manier is een geheim dat je app en de relay delen: je server maakt voor elk gesprek een gebruikersnaam en wachtwoord die na een tijdje niet meer werken.
• Meer dan één, naarmate je groeit. Eén relay is één plek waar elk gesprek kan mislukken. Gebruikers in andere regio’s willen er een bij hen in de buurt, en elke relay vraagt toezicht, updates en ruimte om te groeien.
• Testen vanaf echte netwerken. Een relay die vanaf je kantoor werkt, kan mislukken vanaf een telefoon op een mobiel netwerk of een laptop op hotelwifi. Test vanaf de netwerken waar je gebruikers op zitten.

Niets hiervan is moeilijk, maar het is een dienst die je draaiende moet houden zolang je app gesprekken heeft.

Als zelfs TURN een gesprek niet kan verbinden

Een relay lost de meeste mislukte gesprekken op, maar niet allemaal. Sommige netwerken blokkeren het UDP waar de relay de voorkeur aan geeft, en sommige verstoren lange verbindingen zelfs op poort 443. Voor die netwerken kan een gesprek nog een stap verder gaan, naar een ruimte op een mediaserver, het soort waarop groepsgesprekken draaien. De twee mensen sturen dan naar de mediaserver en ontvangen elkaar via die server, een weg die standhoudt op netwerken waar peer-to-peer media van welke soort ook het moeilijk hebben.

Een gesprek dat daar pas naartoe kan nadat het mislukt is, zou eerst ophangen. Beter is het om het gesprek gaande te houden terwijl het overstapt naar een andere weg, zodat de mensen erin een moment van stilstand merken, geen verbroken gesprek.

Hoe WordPlus Cloud gesprekken verbindt

WordPlus Cloud draait alle drie de wegen, dus een gesprek tussen twee mensen komt altijd tot stand, op elk netwerk:

1. Rechtstreeks, tussen de twee apparaten, op de meeste netwerken. De snelste weg.
2. Via onze relays, als een firewall de directe weg blokkeert. Ze antwoorden op de poorten van het web, 443 en 80, en ook op 3478, dus een gesprek komt overal door waar websites doorkomen. Elke persoon in elk gesprek krijgt eigen relay-inloggegevens die na een paar uur verlopen, zodat niemand de relays buiten je gesprekken kan gebruiken.
3. Via onze mediaservers, als zelfs de relays het gesprek niet kunnen vervoeren. Het verhuist daarheen en gaat door, zonder op te hangen.

Gesprekken zijn op elke weg end-to-end versleuteld, met een sleutel die alleen je server uitgeeft, dus de relays en mediaservers vervoeren wat ze niet kunnen lezen. Gesprekken tussen twee mensen zijn inbegrepen in elk plan, via een relay of niet. Je server bepaalt nog steeds wie wie mag bellen, en de cloud dwingt dat af.

Het werkt hetzelfde in Better Messages op WordPress en in je eigen apps op Next.js, Laravel, Django en andere stacks, met onze SDK’s. Videogesprekken en groepsgesprekken voor je app laat zien wat de SDK’s je geven, en hoe gesprekken werken in onze documentatie laat de code zien.