TURN and Strict Networks
Most people connect directly. For the rest, Meet has a relay.
Calls normally travel over UDP between the person and Meet's media servers. Some company, school and hotel networks block UDP or block the ports Meet uses. For those people Meet offers a TURN relay that carries the call through ports firewalls tend to leave open. You do not set anything up. Meet gives each person's browser short-lived relay credentials when the call connects, and the browser uses the relay only if a direct connection fails.
What to allow#
Give this list to a network admin. All traffic goes to meet.respiresoft.com, outbound only.
| Port | Protocol | For |
|---|---|---|
| 443 | TCP | The page, the API and the call signalling |
| 3479 | UDP and TCP | TURN relay |
| 5350 | TCP, TLS | TURN relay over TLS, for the strictest networks |
| 40000 to 49999 | UDP | Direct media, the fastest path |
If the admin allows only 443 and 5350, calls still work through the TLS relay, with a little more delay.
How it behaves#
- Credentials are made for each connection (a TURN REST credential that expires in a few hours), so a leaked one is of little use.
- The browser tries direct first. A relay is used only when nothing else connects, so most calls cost the relay nothing.
- The relay cannot read the call. Media is encrypted between the browser and Meet.
If a call will not connect#
- Open the room on the same network in a normal browser. If that fails too, the network blocks even 443 to Meet or inspects TLS.
- Ask for 3479 and 5350 as above. Test again.
- Check that the browser is not using a VPN or proxy that blocks WebRTC.
- Send us the
Request-Idof a failing API call and the time, and we will look at the server side.
Embedded calls use the same relay. Nothing in your page changes.