Docs
Get startedGuidesReferenceBlogChangelog
  1. Home
  2. Guides
  3. Privacy & security
  4. Networking guide

Networking Guide

Corporate networks often use firewalls, web security appliances, deep packet inspection, VPNs, and other tools to protect internal systems. These tools can sometimes interfere with Daily calls by blocking the connections needed for audio, video, and screen sharing. This guide explains how to configure your network to allow Daily calls to work smoothly.

Understanding network requirements

There are two kinds of connections that need to happen for a Daily call:

  1. Standard client-server web requests
  2. Peer-to-peer WebRTC connections to send and receive call media

For more on how different types of WebRTC media connections work, see WebRTC Media Connection Types below.

For web requests, you’ll need to allow connections to the following hostnames on port 443:

  • *.daily.co, or your Daily subdomain (for general Daily functionality)
  • *.wss.daily.co, or the sfu servers listed in the IP list (for call signaling)
  • b.daily.co and c.daily.co (for accessing Daily CDN resources)
  • gs.daily.co (dispatch server)
  • prod-ks.pluot.blue (ICE negotiation)

You’ll need to allow the following connections for WebRTC media:

  • STUN: Required for all media connection types. You'll need at least one of these, but we recommend both for the best call experience.
  • UDP direct connection to media servers for the best call quality:
    • *.wss.daily.co over TCP/443 and UDP/40000-49999, or all of the sfu hostnames and port ranges in the IP list
  • TURN for relaying media over UDP, TCP, or TLS. You'll need at least one of these, but we recommend both for the best call experience.

If your network tools don’t allow for whitelisting wildcard hostnames, you can get the full list of IPs for all Daily hostnames from the IP list. The sfu key includes IPs for *.wss.daily.co call servers, used for both WebSocket signaling and UDP media. The web key includes the IPs for web requests (all of the daily.co and pluot.blue subdomains).

Twilio’s TURN server IPs are available from their documentation.

Important Considerations

If your network tools are blocking access to some of those hostnames, your users may see a few different problems:

  • They won’t be able to load the call interface at all
  • They won’t be able to load virtual backgrounds
  • They will load the call interface, but they won’t be able to connect to the call
  • They will connect to the call, but they won’t be able to send or receive audio and video

Proxies that decrypt and re-encrypt traffic can break WebRTC, causing users to connect to a call but not be able to send or receive media. Make sure to exclude TURN, STUN, and ICE traffic from inspection.

If you use a VPN, configure it to use split tunneling to bypass the VPN for Daily traffic. This can significantly improve call quality. At a minimum, exempt port 443 for the Twilio IP ranges above. Ideally, exempt UDP traffic altogether.

If you've implemented the recommendations in this guide and you still have some users that have problems connecting, you can use Daily's Network Test page to diagnose connection problems. It will help you pinpoint which connections are failing.

Advanced Tools (If Necessary)

In some cases, your customers may not be able to allow access to the servers listed above. We have two features that can help with that: Self-hosted IP Proxy and Self-hosted TURN. Contact us for more information about our Advanced Firewall Control add-on.

WebRTC Media Connection Types

WebRTC supports a few different kinds of connections for call participants to send and receive media to and from the call server.

The ideal option is a direct connection to the call server using UDP. This provides the lowest latency and highest throughput. To use a direct connection, a participant needs to be able to send UDP traffic to *.wss.daily.co over UDP ports 40000-49999, and receive UDP traffic via UDP hole punching from the call server. Most home networks and standard firewall configurations allow this traffic.

If a direct connection isn’t possible, the next best option is to use a relay (TURN) server. To use TURN, a participant needs to be able to connect over UDP or TCP on port 3478. We use Cloudflare and Twilio as our TURN providers. This option adds a small amount of latency to the media connection (TCP more so than UDP). That isn’t ideal, but it’s usually not noticeable to other participants.

The last fallback option is TURN over TLS on TCP/443. This is the worst option because it adds a some latency with TCP overhead, and then more latency by TLS encrypting every packet. This will degrade quality a bit more, but sometimes it’s the only option for a very restrictive network. Fortunately, TURN/TLS traffic looks like any other encrypted internet traffic to most firewalls, so it works as a fallback in almost all cases.

Previous