Network allowlist guide
Corporate firewalls, web security appliances, deep packet inspection and VPNs can block the connections that Solidroad voice and video simulations need. This article is for IT and network admins. It lists the hostnames and ports to allow, explains what users see when something is blocked, and tells you what to check if simulations still fail afterwards.
Symptoms
If your network blocks some of the hostnames below, your users may see one of these problems:
The simulation call interface does not load at all.
The call interface loads, but the call never connects.
The call connects, but no audio or video is sent or received.
Chat simulations are not affected by any of this. If voice simulations fail for only some users with no pattern by office or device, see Voice simulations fail for some users but not others instead.
Why it happens
A voice or video simulation needs two kinds of connection: standard HTTPS requests to load the app and set up the call, and WebRTC media connections to send and receive audio and video. Solidroad uses Vapi for voice and Daily for the WebRTC infrastructure, so traffic to both providers has to be allowed, not only traffic to solidroad.com. Network tools that only allow HTTPS on port 443 will let the app load but block the media.
Quick start
If you only need the HTTPS domains, allow traffic on port 443 to these wildcard domains:
This is enough for the app to load and the call to be set up. For audio and video to actually flow you also need the STUN and TURN hosts and UDP ports in the next section.
Full list of hostnames and ports
Allow the following HTTPS connections on port 443.
Hostname | Purpose |
|---|---|
Web UI | |
Sign in | |
Sign in | |
Voice and video | |
*.daily.co | WebRTC infrastructure |
*.wss.daily.co, or the sfu servers listed in the IP list | Call signaling |
b.daily.co and c.daily.co | Provider CDN resources |
Dispatch server | |
ICE negotiation |
Allow the following WebRTC media connections. For STUN and TURN you need at least one provider from each row, and both is recommended for the best call experience.
Connection type | Hostnames and ports |
|---|---|
STUN (required for all media connections) | stun.cloudflare.com over UDP/3478 and UDP/53. *.stun.twilio.com, or at least global.stun.twilio.com, IPs and ports documented here |
UDP direct connection to media servers (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 (relays media over UDP, TCP or TLS) | turn.cloudflare.com over UDP and TCP 3478, UDP/53, TCP/80, TCP/5349 and TCP/TLS 443, documented here. *.turn.twilio.com, documented here |
Twilio’s TURN server IPs are available from their documentation.
Proxies and VPNs
Proxies that decrypt and re-encrypt traffic can break WebRTC. Users connect to the call but cannot send or receive media. Exclude TURN, STUN and ICE traffic from inspection.
If your users are on a VPN, configure split tunnelling so that traffic to the Daily and Twilio hosts above bypasses the VPN. This can noticeably improve call quality. At a minimum, exempt port 443 for the Twilio IP ranges in their documentation linked above. Ideally, exempt UDP traffic altogether.
If that doesn’t work
If you have applied everything above and some users still cannot connect, run the Network Test page from an affected machine. It shows which connections are failing.
If the failures affect only some users and there is no clear pattern by office or device, your security platform may be isolating the voice provider rather than blocking it. See Voice simulations fail for some users but not others.
Related articles
If you have any further questions, contact the Solidroad team via the Help tab in the platform.