> ## Documentation Index > Fetch the complete documentation index at: https://docs.quarterzip.ai/llms.txt > Use this file to discover all available pages before exploring further. # Network requirements > What your firewall needs to allow for Quarterzip calls to connect and carry audio. Quarterzip calls run in the browser over WebRTC, using [Daily](https://www.daily.co) for call media. Most networks work without changes. If callers on your network see **"We couldn't access your audio devices"**, **"Your network blocked the audio"** or **"The connection failed"**, your firewall or proxy is blocking part of the call. This page is for the IT team that manages that network. ## Choose a configuration There are two supported configurations. Pick one, and apply it completely. | | Minimal (TCP media) | Recommended (UDP) | | - | - | - | | What it opens | Web traffic and a relay over TLS on port 443 | Adds direct UDP to the call servers | | Call quality | Works, with added latency; worse on lossy networks | Best: lowest latency, handles packet loss well | | UDP to call servers | **Must be fully blocked** | **Must be fully allowed** | > [!WARNING] > > **Do not partially allow UDP.** This is the most common cause of failed calls. > > If a firewall lets connection checks through but drops the encrypted media that follows, the browser sees UDP working, picks it, and no audio ever arrives. Either allow UDP to the call servers fully (Recommended) or block it fully (Minimal). ## Step 1: Allow the required hosts These rules are needed for **both** configurations. ### Web and call setup (TCP 443) | Host | Used for | | - | - | | `*.quarterzip.ai` | The Quarterzip app, API and call pages | | `*.daily.co` `*.dailywebrtc.com` `*.dailywebrtc.net` | Call setup | | `*.wss.daily.co` `*-wss.daily.co` `*.wss.dailywebrtc.com` `*-wss.dailywebrtc.com` `*.wss.dailywebrtc.net` `*-wss.dailywebrtc.net` | Call signalling | | `b.daily.co` `c.daily.co` `b.dailywebrtc.com` `c.dailywebrtc.com` `b.dailywebrtc.net` `c.dailywebrtc.net` | Call resources | | `gs.daily.co` `gs.dailywebrtc.com` `gs.dailywebrtc.net` | Call routing | | `prod-ks.pluot.blue` | Connection negotiation | > [!NOTE] > > `dailywebrtc.com` and `dailywebrtc.net` are Daily's fallback domains. A wildcard on `daily.co` does not cover them, so allow them alongside it. > [!TIP] > > If your firewall cannot use wildcard hostnames, or applies hostname rules poorly to UDP, allowlist by IP using Daily's [published IP list](https://ip-info.daily.co/ips/ip-info.json) (the `sfu` and `web` hosts). The list changes over time, so poll it on a schedule. See Daily's [Networking Guide](https://docs.daily.co/docs/guides/privacy-and-security/corporate-firewalls-nats-allowed-ip-list) for details. ### STUN connection checks | Host | Protocol and ports | | - | - | | `stun.cloudflare.com` | UDP 3478 and UDP 53 | | `global.stun.twilio.com` (or `*.stun.twilio.com`) | [Ports listed by Twilio](https://www.twilio.com/docs/stun-turn/regions) | ## Step 2: Apply one configuration **Option 1: Minimal (TCP media)** The smallest set that connects a call on almost any network. All call media is relayed over TLS on port 443, which looks like ordinary HTTPS to most firewalls. **1. Allow the TLS relay hosts** over **TCP/TLS 443**, in addition to the required hosts: * `turn.cloudflare.com` * `*.turn.twilio.com` **2. Block outbound UDP for call traffic completely:** | Block | Hosts | Ports | | - | - | - | | Call servers | `*.wss.daily.co` and the other signalling hosts above | UDP 23000-26999 and 40000-49999 | | Relays | `turn.cloudflare.com`, `*.turn.twilio.com` | UDP 3478 and 53 | Calls then go straight to the TLS relay instead of trying a UDP path that will not carry media. STUN over UDP stays allowed. **What you give up:** relayed TCP adds latency and copes badly with packet loss. One-to-one voice calls are usually fine; quality drops on lossy networks. **Option 2: Recommended (UDP)** **1. Allow the TLS relay hosts** from Option 1 over **TCP/TLS 443**, in addition to the required hosts. Do **not** apply Option 1's UDP block. * `turn.cloudflare.com` * `*.turn.twilio.com` **2. Allow direct media to the call servers:** | Hosts | Ports | | - | - | | `*.wss.daily.co` `*-wss.daily.co` `*.wss.dailywebrtc.com` `*-wss.dailywebrtc.com` `*.wss.dailywebrtc.net` `*-wss.dailywebrtc.net` | UDP 23000-26999 UDP 40000-49999 TCP 40000-49999 | Allow this in both directions for the full call. Calls then use the low-latency UDP path and fall back to the TLS relay only when they need to. ## Step 3: Check TLS inspection and VPNs * **Let Daily's call resources load unchanged.** Each call starts by downloading a JavaScript file from `c.daily.co` (or `c.dailywebrtc.com` / `c.dailywebrtc.net`). Content filters, file-type rules or sandboxing that block, delay or replace JavaScript from these hosts stop the call before it connects. * **Do not inspect call traffic.** Exclude STUN, TURN and the call servers above from any decrypt-and-re-encrypt or deep packet inspection rule. Call media is already encrypted end to end, so inspection has nothing to read, and it breaks the connection. * **Use split tunnelling for VPNs and secure web gateways** (for example Zscaler) so call traffic bypasses the tunnel. * **Route call traffic the same way on every operating system.** Some clients tunnel TCP but send UDP directly out of the local network. This recreates the partial-UDP problem above on some machines only. ## Still not working? 1. Run Quarterzip's [network test](https://network-debugger.vercel.app/) from an affected machine to see which connections fail. 2. Email [support@quarterzip.ai](mailto:support@quarterzip.ai) with the results and the time of the failed call. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.