1. Home
3. Guides
5. Privacy & security
7. NAT and firewall traversal

Navigating a corporate or restrictive network

Corporate companies deploy firewalls at the boundary between the company's internal network and the external network, typically the internet. These firewalls inspect incoming and outgoing network traffic, acting as a filter to allow or block packets based on predefined rules. To assist our customers that work with companies with restrictive firewalls, we offer three solutions:

1. Allow lists: Specify a list of hostnames that a network administrator should not block access to, including whitelisting entire subdomains for *.daily.co and *.wss.daily.co. For companies with strict security policies, we offer static IP addresses to customers on enterprise support plans.
2. IP proxy: Route the signaling traffic via a self-hosted proxy
3. Self-hosted TURN: Override Daily's default TURN URLs with a self-hosted TURN server URL

Testing & troubleshooting

Please run Daily's network test to see if your network configuration allows for Daily to function. It will test all possible connections methods and will indicate what is and isn't working.

Allow lists

Daily uses a variety of domains, IP addresses, ports, and protocols to connect participants in a call. If you're trying to make calls to and from a network behind a corporate firewall, or through a corporate's Virtual Private Network (VPN), you'll need to make sure to configure the corporate network to allow the following set of domains and IP addresses.

Please see the below resources to understand exactly what domains, IP addresses, ports and protocols you need to unblock to have a successful call on Daily.

Daily network resources

Each section below describes a stage in establishing of a WebRTC call. They're in a rough order (but not technically precise) of how they happen when a new call is established.

Each stage must work for the call to work overall. Each stage further outlines multiple options, in order of preference, for making this particular stage work.

Daily resources

These are Daily specific resources that must always work.

http://b.daily.co and c.daily.co must be reachable on TCP/443. Daily SDKs pull in various resources at runtime that aren't included in SDKs.

Your Daily domain must also be reachable on TCP/443. Used for various in-meeting communication. For example. If Joe Bloggs made a Daily domain, it might be bloggs.daily.co. So that domain should be reachable on TCP/443 too. The best solution is to whitelist all Daily domains like so *.daily.co

Call initiation

All of these must be reachable for call initiation to work.

• http://gs.daily.co/ must be reachable on TCP/443. This is a dispatch server that helps to identify which location to use to connect the call to.
• prod-ks.pluot.blue must be reachable on TCP/443. This is a Daily-owned server used for ICE negotiation.
• Twilio STUN *.stun.twilio.com must be reachable on TCP/UDP/3478 or TCP/443.

Signaling

In WebRTC signaling is what establishes the initial connection for a call.

Daily uses its own SFUs for signaling. For this to work, *.wss.daily.co should be reachable on TCP/443. Clients use WSS (Secure WebSockets) connection with SFUs.

Media streaming

This is how the actual media streams get to/from all the call participants.

1. The ideal option is a direct connection to SFU over UDP. This provides the smallest latency / lag for call participants. Clients need to connect to .wss.daily.co over TCP/443 & UDP/40000-65534 for media streaming. This allows Daily to work without relying on TURN servers and is the preferred solution.
2. The next best option is to use TURN over TCP/UDP on port 3478. We use Cloudflare and Twilio as our TURN provider. Please see below for more details. This option adds less than 50ms of latency because media stream has to relay thru TURN. It's not ideal, but not too noticeable to call participants.
3. The least user friendly option is TURN over TLS on TCP/443. This is the worst option because it adds more than 50ms of latency, which causes noticeable lag for audio/video experience due to extra overhead of TCP & TLS.
4. Some corporate firewalls let in just enough traffic to fool WebRTC into thinking a connection was successfully established. Breaking our automatic fallback to TURN relay servers. When this happens, users can connect to a call, but never send or receive media. We recommend making sure your corporate firewalls do not do that. However, if you cannot resolve the issue on your end, we have a way to force use of a TURN server. Please reach out to us if you encounter this issue.
5. If you would prefer to run your own TURN server, please reach out to us as that is something we can also help with.

Information on TURN providers

Daily will connect you a TURN server that provides the best latency. In most cases, this will be Cloudflare. However, there may be some circumstances where Twilio or Xirsys TURN servers are selected. To successfully connect to a call using the TURN providers, you must allowlist the following domains for TURN over TCP/UDP on port 3478 or in a worst case scenario, TCP/443:

• turn.cloudflare.com
• *.turn.twilio.com
• *.xirsys.com

Configuring VPN split tunnel

If you have a VPN, Daily calls will have much better quality if you can configure Daily's traffic to bypass it. You can usually do that by configuring split tunneling. You'll at least want to exempt port 443 for the Twilio IP ranges listed below. If you can exempt UDP traffic altogether, that's even better.

• Cloudflare's IP ranges
• Twilio's IP ranges
• Xirsys's IP ranges

Using a self-hosted IP proxy for signaling

If Daily domains are blocked by a corporate security policy, you can fall back to routing Daily's traffic through your own HTTP and WebSocket proxy (IP proxy). This option works for products that have already deployed a web proxy that is allowed by the end-user’s IT administrator, but do not yet have Daily's signaling servers unblocked.

For an end user that observes HTTP or WSS connection failures to Daily’s infrastructure, you can reconfigure the Daily call frame to specify your own IP proxy URL. Daily will automatically use the proxy URL for subsequent network requests.

For example, if the connection to https://gs.daily.co/ fails, a firewall will most likely return a HTTP Response code of 403 (Forbidden).

In this case, you can use your self-hosted IP proxy (e.g., https://proxy.example.net:8080) by specifying the proxyUrl property in dailyConfig. Daily will then send requests to https://proxy.example.net:8080/gs.daily.co/rooms/check/sub-domain/room-name instead of https://gs.daily.co/rooms/check/sub-domain/room-name.

For more details, refer to our documentation. With Prebuilt, you'll need to set proxyUrl property when instantiating the call frame. With Daily's client SDKs, call the setProxyUrl() call object instance method.

1
// Example: pass configuration properties to createFrame()
2
call = window.Daily.createFrame({
3
  iframeStyle: {
4
    position: 'fixed',
5
    width: '375px',
6
    height: '450px',
7
  },
8
  dailyConfig: {
9
    proxyUrl: 'https://proxy.example.org:8080',
10
  },
11
  showLeaveButton: true,
12
  showFullscreenButton: true,
13
});
14
call.join({ url: 'DAILY_ROOM_URL' });
15

Using a self-hosted TURN for media

If Daily's TURN URLs are blocked, you may fall back to routing the media through your own self-hosted TURN servers, which should already be allowlisted by the end user’s IT administrators.

Similar to the IP proxy configuration, your custom TURN servers are passed into dailyConfig by setting the iceServers property.

We encourage our customers to work with their IT departments to allowlist Daily’s TURN servers. Daily's servers are already scaled out and handle millions of media packets per second.

For more details, refer to our documentation. With Prebuilt, you'll need to set the iceConfig property in the call frame. With Daily's client SDKs call the setIceConfig() instance method.

1
call = window.Daily.createFrame({
2
  iframeStyle: {
3
    position: 'fixed',
4
    width: '375px',
5
    height: '450px',
6
  },
7
  dailyConfig: {
8
    iceConfig: {
9
      iceServers: [
10
        {
11
          urls: ['stun:turnserver.example.org', 'turns:turnserver.example.org'],
12
          username: 'webrtc',
13
          credential: 'turnpassword',
14
        },
15
      ],
16
      placement: 'replace',
17
      iceTransportPolicy: 'all',
18
    },
19
  },
20
  showLeaveButton: true,
21
  showFullscreenButton: true,
22
});
23
call.join({ url: 'DAILY_ROOM_URL' });
24

Addendum

WebRTC terminology

• STUN - Session Traversal Utilities for NAT. Used to establish a direct UDP connection between two clients
• TURN - Traversal Using Relay around NAT. Used to establish a relayed UDP or TCP connection between two clients. Here, the traffic must be relayed through the TURN server to bypass restrictive firewall rules, and the preference is UDP over TCP because TCP's guaranteed ordered delivery of packets implies overhead that is undesirable for real-time communications.
• TURNS - Secure Traversal Using Relay around NAT. Used to establish a relayed TCP/TLS connection between two clients. Here, the traffic must be relayed through the TURN server and through a TLS socket to bypass extremely restrictive firewall rules.
• ICE - Interactive Connectivity Establishment is a standard for using STUN and TURN to establish connectivity between two endpoints. ICE takes all of the complexity implied in the discussion above, and coordinates the management of STUN, TURN, and TURNS to a) optimize the likelihood of connection establishment, and b) ensure that precedence is given to preferred network communication protocols.
• SFU - Selective Forwarding Unit. An SFU is a media server component capable of receiving multiple media streams and then deciding which of these media streams should be sent to which participants. Its main use is in supporting group calls and live streaming/broadcast scenarios.