> ## Documentation Index
> Fetch the complete documentation index at: https://docs.daily.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Networking Guide
> Configuring corporate/enterprise networks to support Daily calls.
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 web requests, you'll need to allow connections to the following hostnames on port 443:
* `*.daily.co`, `*.dailywebrtc.com`, and `*.dailywebrtc.net`, or your Daily subdomain (for general Daily functionality)
* `*.wss.daily.co`, `*-wss.daily.co`, `*.wss.dailywebrtc.com`, `*-wss.dailywebrtc.com`, `*.wss.dailywebrtc.net`, and `*-wss.dailywebrtc.net`, or the `sfu` servers listed in [the IP list](https://ip-info.daily.co/ips/ip-info.json) (for call signaling)
* `b.daily.co`, `c.daily.co`, `b.dailywebrtc.com`, `c.dailywebrtc.com`, `b.dailywebrtc.net`, and `c.dailywebrtc.net` (for accessing Daily CDN resources)
* `gs.daily.co`, `gs.dailywebrtc.com`, and `gs.dailywebrtc.net` (dispatch server)
* `prod-ks.pluot.blue` (ICE negotiation)
`dailywebrtc.com` and `dailywebrtc.net` are fallback domains that mirror the `daily.co` infrastructure, with the same subdomains pointing at the same servers and IPs. They let calls keep working if the `.co` top-level domain has a DNS outage. If you allowlist by IP rather than by hostname, they're already covered, since the IPs are shared.
You'll need to allow the following connections for WebRTC media:
* **STUN:** Required for all media connection types. We recommend both for the best call experience.
* `stun.cloudflare.com` over UDP/3478 and UDP/53
* `*.stun.twilio.com`, or at least `global.stun.twilio.com`; [IPs and ports documented here](https://www.twilio.com/docs/stun-turn/regions)
* **UDP direct connection to media servers** for the best call quality:
* `*.wss.daily.co`, `*-wss.daily.co`, `*.wss.dailywebrtc.com`, `*-wss.dailywebrtc.com`, `*.wss.dailywebrtc.net`, and `*-wss.dailywebrtc.net` over TCP/443, TCP/40000-49999, UDP/23000-26999, and UDP/40000-49999, or all of the `sfu` hostnames and port ranges in [the IP list](https://ip-info.daily.co/ips/ip-info.json)
* **TURN** for relaying media over UDP, TCP, or TLS. We recommend both for the best call experience.
* `turn.cloudflare.com` over UDP and TCP 3478, UDP/53, TCP/80, TCP/5349, and TCP/TLS 443, [documented here](https://developers.cloudflare.com/realtime/turn/)
* `*.turn.twilio.com`, [documented here](https://www.twilio.com/docs/stun-turn/regions)
## Using the IP list
If your network tools don't allow wildcard hostnames, you can build an allowlist from [the IP list](https://ip-info.daily.co/ips/ip-info.json). It's a JSON document with these keys:
* `ipAddressInfo.sfu.hosts`: the call servers behind `*.wss.daily.co` and `*-wss.daily.co`. These carry call signaling and direct UDP media. Each host includes its `ipAddress`, the exact `portRanges` it uses, and a `region` tag.
* `ipAddressInfo.web.hosts`: the IPs behind the web hostnames listed above.
* `ipAddressInfo.sip.hosts`: the SIP servers for [dial-in and dial-out](/docs/guides/features/dial-in-dial-out) telephony. You only need these if you use Daily's SIP features. They aren't required for normal video calls.
* `lastUpdated`: when the list last changed.
Because the `dailywebrtc.com` and `dailywebrtc.net` fallback domains resolve to these same IPs, allowlisting by IP already covers them. The STUN and TURN IPs are not in this file: get Twilio's [from Twilio's documentation](https://www.twilio.com/docs/stun-turn/regions), and Cloudflare's [from Cloudflare's documentation](https://developers.cloudflare.com/realtime/turn/).
The `sfu` hosts are tagged with a `region` (for example `eu-central-1`, `eu-frankfurt-1`, `uk-london-1`). If you pin your rooms to a [`geo`](/reference/rest-api/rooms/create-room#body-properties-geo) region, you can keep only the hosts for the region(s) you use and drop the rest. Two cautions: the file uses more than one name for the same city (for example both `eu-central-1` and `eu-frankfurt-1` are Frankfurt), so keep every host whose region maps to your city. And allow the whole region's host set, not a single host, since a session can move between servers within a region.
The list is dynamic. The IPs are stable day-to-day, but they do change, and a single snapshot is not permanent. When a change is coming, the file is updated 3 days before the change reaches production, which gives you lead time to update your firewall rules. There is no push notification or changelog, so poll the file on a schedule, compare `lastUpdated` (or diff the contents) against your last copy, and apply changes when it moves.
## Important considerations
If your network tools are blocking some of those hostnames, users may experience:
* Not being able to load the call interface at all
* Not being able to load virtual backgrounds
* Loading the call interface but being unable to connect to the call
* Connecting to the call but being unable 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. 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. At a minimum, exempt port 443 for the Twilio IP ranges above. Ideally, exempt UDP traffic altogether.
If you've implemented these recommendations and some users still have problems connecting, use Daily's [Network Test page](https://network-test-v2.daily.co/) to diagnose which connections are failing.
## Advanced tools
In some cases, customers may not be able to allow access to the servers listed above. We have two features that can help: **Self-hosted IP Proxy** and **Self-hosted TURN**. [Contact us](https://www.daily.co/contact) for more information about our Advanced Firewall Control add-on.
## WebRTC media connection types
WebRTC supports a few different kinds of connections for sending and receiving media:
**Direct UDP connection** is the ideal option. It provides the lowest latency and highest throughput. A participant needs to be able to send UDP traffic to `*.wss.daily.co`, `*.wss.dailywebrtc.com`, or `*.wss.dailywebrtc.net` over ports 23000-26999 and 40000-49999, and receive UDP traffic via [UDP hole punching](https://en.wikipedia.org/wiki/UDP_hole_punching). Most home networks and standard firewall configurations allow this.
**TURN relay** is the next best option. A participant needs to connect over UDP or TCP on port 3478. We use Cloudflare and Twilio as TURN providers. This adds a small amount of latency to the media connection (TCP more so than UDP) but is usually not noticeable to other participants.
**TURN over TLS/TCP 443** is the last fallback. It adds latency from both TCP overhead and TLS encryption per packet. This will degrade quality a bit more. However, this traffic looks like any other encrypted internet traffic to most firewalls, so it works in almost all cases.
## The minimal allowlist
If you can't open everything above, here is the smallest set that still lets a Daily call connect, plus what you give up by stopping there.
**The absolute minimum:**
1. **Web and signaling, over TCP/443:** `*.daily.co` (or your subdomain), `b.daily.co`, `c.daily.co`, `gs.daily.co`, `prod-ks.pluot.blue`, and the `*.wss.daily.co` / `*-wss.daily.co` signaling servers (the `web` and `sfu` IPs in the list). Without these, the call interface won't load or won't connect. None of this is optional.
2. **STUN:** `stun.cloudflare.com` and `global.stun.twilio.com`. At least one STUN provider is required for every media path; allow both for resilience.
3. **One media path, TURN over TLS/TCP 443:** `turn.cloudflare.com` and `*.turn.twilio.com`. This is the single most compatible media path, because the traffic looks like ordinary HTTPS and gets through almost any firewall.
That set will connect a call in nearly any network. It is the floor, not the recommendation.
**What you give up by stopping at the minimum:**
* All media is relayed through a TURN server over TCP and TLS. You pay added latency from TCP overhead and per-packet encryption, on top of the relay hop.
* TCP behaves badly under packet loss. It retransmits and stalls the whole stream (head-of-line blocking), while WebRTC over UDP would rather drop a packet and conceal the gap. On a lossy network, TURN over TCP sounds and looks noticeably worse.
* Quality drops most on video and on larger calls. One-to-one audio is usually fine. Multi-party video is where users feel it.
* You have no fallback. If the relay path has a problem, there's no direct UDP path to fall back to.
**The recommended minimum** adds **direct UDP media to the SFU IPs** (the `sfu` hosts, on UDP 23000-26999 and 40000-49999). This gives WebRTC a low-latency path and uses TURN only when UDP can't get through. For most networks this is the difference between "the call works" and "the call is good."
If you can open only one thing beyond signaling and STUN, open direct UDP to the SFU IPs rather than TURN over TCP. UDP is the path that makes calls feel good. Keep TURN over TLS/443 as the fallback when you have room for it.
## Why traffic inspection breaks WebRTC media
A common reason calls connect but carry no audio or video is a proxy or appliance that tries to inspect the media. Exclude STUN, TURN, ICE, and the SFU media traffic from any decrypt-and-re-encrypt or deep-packet-inspection rule.
**Why inspection breaks it:**
* WebRTC media is encrypted end to end with DTLS-SRTP. The keys are negotiated in a DTLS handshake between the client and Daily. An inspection box in the middle doesn't have those keys, so when it intercepts the handshake or rewrites packets, key agreement fails and no media flows. The call connects (signaling worked) but stays silent and black.
* ICE, the part that finds a working path, depends on the client seeing its real public address and on consistent source ports. A proxy that rewrites or buffers these connectivity checks breaks candidate gathering, so the call never finds a path.
**Why inspecting this traffic is counterproductive:**
* There's nothing readable to inspect. The payload is already encrypted audio and video frames. A DPI box sees opaque SRTP, not content. It can't scan it for data loss or threats, because it can't decrypt it.
* Inspection appliances are built to reassemble TCP streams. WebRTC media is a high rate of small, independent, real-time UDP packets. Buffering them for inspection adds delay and jitter, which is exactly what degrades a live call, in exchange for no readable data.
* Real-time media tolerates a little loss but not added delay. Inspection adds delay. So it harms the one thing it can't even read.
* The security goal is better served another way. The destinations are a known, fixed set of Daily SFU and relay IPs you can allowlist (that's what this guide is for). Allowlisting where the encrypted media is allowed to go is far more effective than trying to inspect what's inside it.