Waarom UDP zo belangrijk is voor Meet
Google Meet gebruikt WebRTC voor real-time audio en video. WebRTC werkt het beste over UDP, omdat UDP geen verbindingsstatus bijhoudt en niet wacht op bevestiging van elk pakket. Bij pakketverlies gaat de stream gewoon door: een gemist frame is acceptabeler dan een bevroren beeld terwijl TCP op retransmissie wacht.
Meet transporteert de media als SRTP (Secure Real-time Transport Protocol) over UDP. Daarnaast gebruikt het STUN (Session Traversal Utilities for NAT) om de NAT-traversal te regelen, zodat je client zijn eigen publieke adres ontdekt en een directe mediaverbinding kan opzetten.
Wanneer UDP geblokkeerd is, probeert Meet automatisch een fallback via TURN over TCP 443. Die verbinding werkt, maar de kwaliteit lijdt eronder: hogere latency, meer buffering en bij netwerkproblemen minder soepele degradatie. Volgens Google verlaagt het gebruik van TCP of een geproxyde TCP-verbinding de algehele vergaderkwaliteit.
Welke poorten je opent
Google noemt twee groepen poorten. Voor media (audio en video) gebruik je UDP, voor webverkeer en authenticatie gebruik je poort 443.
| Protocol | Poort(en) | Doel |
|---|---|---|
| UDP uitgaand | 3478 en 19302-19309 | SRTP-media en STUN |
| TCP en UDP uitgaand | 443 | Signaling, authenticatie en TURN-fallback |
Alle verbindingen zijn uitgaand vanaf de client. Je hoeft geen inkomende poorten te openen. De firewall-regel komt erop neer dat interne hosts op UDP 3478 en 19302-19309 verbinding mogen maken met de Google-bestemmingen.
Wil je niet alle externe IP-adressen openzetten, dan publiceert Google specifieke ranges voor de mediarelay (TURN). Op het moment van schrijven zijn dat onder andere 74.125.250.0/24 en het IPv6-bereik 2001:4860:4864:5::/64 voor Workspace-verkeer, gepubliceerd via de SNI workspace.turns.goog. Controleer altijd de actuele lijst in de Google-documentatie, want deze ranges kunnen wijzigen.
Maak de poortregel breed, beperk per zone
Stuur op poortnummer in plaats van op losse IP-adressen. Google wisselt regelmatig van relay-server, dus een regel op IP-niveau is lastiger te onderhouden. Beperk de regel wel per interne zone: werkstations en vergaderzalen wel, servers niet.
Testen of UDP-poorten open zijn
Tijdens een vergadering:
Open in je Meet-gesprek het menu Meer opties en kies Probleemoplossing en hulp. Daar zie je realtime de netwerkstabiliteit, je verbinding en of er pakketverlies of latency optreedt. Dit is de plek die Google nu aanwijst voor deelnemers, en die vervangt de oudere losse diagnostics-pagina.
Voor beheerders:
In de Admin-console vind je onder Apps > Google Workspace > Google Meet > Meet-kwaliteitstool geaggregeerde data per gesprek en per gebruiker, inclusief het gebruikte transportprotocol, jitter, pakketverlies en latency. Handig om te zien of een hele locatie op TCP-fallback draait.
Via command-line:
# macOS / Linux: stuurt een UDP-pakket naar de STUN-poort
nc -u stun.l.google.com 19302
Omdat UDP connectieloos is, geeft een gelukte test geen harde bevestiging zoals bij TCP. Een betrouwbaardere methode is nmap:
sudo nmap -sU -p 3478,19302-19309 stun.l.google.com
Let op: op Windows test Test-NetConnection standaard alleen TCP. Gebruik voor UDP een externe tool zoals nmap of leun op de Meet-kwaliteitstool in de Admin-console.
UDP-regel aanmaken in Windows Firewall
- Open Windows Defender Firewall met geavanceerde beveiliging.
- Klik op Uitgaande regels en daarna op Nieuwe regel.
- Kies Poort als regeltype.
- Selecteer UDP en voer
3478, 19302-19309in als poortbereik. - Kies Verbinding toestaan.
- Selecteer alle profielen: Domein, Privé en Openbaar.
- Geef de regel een naam, bijvoorbeeld
Google Meet UDP. - Klik op Voltooien.
QoS instellen: wat Google echt aanraadt
Hier zit een veelvoorkomend misverstand. Veel oudere handleidingen adviseren om Meet-verkeer prioriteit te geven met Quality of Service (QoS) en DSCP-markering. Google raadt dit nu juist af.
In de actuele documentatie staat het expliciet: gebruik geen QoS voor Meet, omdat Meet zich automatisch aanpast aan de netwerkomstandigheden. Er is ook geen aan- of uitknop voor DSCP-markering in de Admin-console; die optie bestaat niet.
Heb je toch een dwingende reden, zoals aantoonbare congestie op je WAN, dan implementeer je QoS zelf op netwerkniveau en houd je een volledig end-to-end QoS-model aan. Google noemt dan de Expedited Forwarding (EF)-klasse voor de media en raadt aan de markering te zetten op de client (bijvoorbeeld via een Windows QoS-beleid) of aan de netwerkrand, en die markering te strippen voordat het verkeer het publieke internet op gaat. Doe je dat half, dan kan QoS de kwaliteit eerder verslechteren dan verbeteren.
Geen Admin-console DSCP-schakelaar
Vertrouw geen handleiding die je naar een vermeende DSCP-instelling in de Admin-console stuurt. Die optie bestaat niet in Google Meet. DSCP-markering hoort op je eigen netwerkapparatuur thuis, en alleen als je het volledige pad beheert.
Wat als UDP geblokkeerd moet blijven
Sommige organisaties blokkeren UDP om beleidsredenen. Meet werkt dan via TCP 443, maar reken op merkbaar mindere kwaliteit:
- Hogere latency en meer buffering.
- Grotere kans op bevriezing bij pakketverlies, omdat TCP op retransmissie wacht.
- Meer afhankelijkheid van de TURN-relays in plaats van een directe peer-verbinding.
Is UDP echt geen optie, zorg dan dat TCP 443 naar de Google-bestemmingen zonder SSL-inspectie wordt doorgelaten. SSL-inspectie of TLS-interceptie op Meet-verkeer veroorzaakt certificaatfouten en verbreekt de verbinding.
Bandbreedte als tweede knelpunt
Open poorten lossen niets op als de bandbreedte tekortschiet. Voor groepsvergaderingen rekent Google met grofweg 1 Mbps uitgaand en 1,3 Mbps inkomend per deelnemer als praktische ondergrens. Voor scherpe 1080p-beelden ligt de behoefte hoger, rond 3,2 tot 3,6 Mbps per deelnemer. Sinds de kwaliteitsverbetering die Google in 2026 uitrolt, kan het verbruik bij grotere gesprekken oplopen, waarbij Meet de resolutie automatisch terugschroeft als de bandbreedte krap is.
Mijn UDP is open maar de kwaliteit is nog steeds slecht. Wat nu?
Controleer eerst de bandbreedte per deelnemer en kijk of er pakketverlies optreedt via de probleemoplossing in het Meet-menu. Controleer daarna of er SSL-inspectie actief is op het Meet-verkeer en of een IPS- of DPI-regel pakketten dropt. Een korte packetcapture op de uplink laat snel zien waar het verkeer vastloopt.
Welke STUN-servers gebruikt Google Meet?
Meet gebruikt de publieke STUN-servers stun.l.google.com en stun1.l.google.com tot en met stun4.l.google.com op poort 19302 voor de NAT-traversal. Blokkeer die hostnames niet in je DNS- of webfilter.
Welke poort heeft voorrang, 3478 of 19302-19309?
Google noemt beide groepen als geldige mediapoorten. In de praktijk probeert de client te verbinden en valt terug op de andere poort als de eerste geblokkeerd is. Open daarom liever de hele set in plaats van een keuze te maken.
Moet ik QoS of DSCP instellen voor Meet?
Nee, niet standaard. Google raadt QoS voor Meet af, omdat de client zich automatisch aanpast. Zet je het toch in, dan moet dat op je eigen netwerk met een volledig end-to-end model, niet via een knop in de Admin-console.
Hoe controleer ik als beheerder of een hele locatie op TCP-fallback draait?
Gebruik de Meet-kwaliteitstool in de Admin-console onder Apps > Google Workspace > Google Meet. Daar zie je per gesprek het gebruikte transportprotocol. Zie je structureel TCP in plaats van UDP voor één locatie, dan staat daar vrijwel zeker een firewall- of proxyregel UDP te blokkeren.