Network allowlist guide
Last updated: September 18, 2026
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 administrators. It lists the hostnames and ports to allow, explains what users see when something is blocked, and tells you how to test before you roll out. Chat simulations are not affected by any of it.
Before you change anything
Two things account for most of the cases where a team has already allowed Solidroad and still cannot run a simulation.
Allowing the hostname is not always enough. If your proxy decrypts and re-encrypts traffic, you also need the exemptions in Proxies and TLS inspection below.
The call provider uses three domain families rather than one:
daily.co,dailywebrtc.comanddailywebrtc.net. Allow all three. A list that covers onlydaily.cokeeps working until the provider routes your users to another family.
A voice or video simulation needs two kinds of connection: ordinary HTTPS requests to load the app and set up the call, and WebRTC media connections to carry audio and video. A rule that allows HTTPS on port 443 and nothing else lets the app load and then blocks the media, which is why the sections on UDP, STUN and TURN matter as much as the hostname list.
Hostnames to allow on port 443
Allow these over HTTPS and WSS, then add the media, STUN and TURN entries below.
*.solidroad.com*.vapi.ai*.daily.co*.dailywebrtc.com*.dailywebrtc.netprod-ks.pluot.blue
Some policy products do not treat a wildcard as covering a hyphenated subdomain. If yours is one of them, add these six names as well:
*.wss.daily.coand*-wss.daily.co*.wss.dailywebrtc.comand*-wss.dailywebrtc.com*.wss.dailywebrtc.netand*-wss.dailywebrtc.net
The call software switches between the two forms while it retries, so allowing only one form means the retry fails.
What each host does
Hostname | Purpose |
|---|---|
| Web site |
| The application, and sign in |
| Creates the call. Blocked here, nothing starts. |
| Loads the call software. Blocked here, nothing starts. |
| Finds the room for the call |
| Provider resources |
| Call signalling. The most common cause of a failed start. |
| ICE negotiation |
The b., c. and gs. hosts also exist on dailywebrtc.com and dailywebrtc.net. Allow those too.
Direct audio over UDP
Allow UDP ports 23000 to 26999 and 40000 to 49999 to all six signalling hostnames listed above.
STUN and TURN
STUN is needed for every media connection.
Hostname | Ports |
|---|---|
| UDP/3478, UDP/53 |
| UDP/3478, UDP/53 |
TURN carries audio when a direct connection is not possible. Without it, calls work for some people and fail for others on the same network.
Hostname | Ports |
|---|---|
| UDP/3478, TCP/3478, UDP/53, TCP/80, TCP/5349, TCP/TLS 443 |
| UDP/3478, TCP/3478, UDP/53, TCP/80, TCP/5349, TCP/TLS 443 |
Twilio publishes its TURN server IP ranges in its own documentation. Do not copy IP addresses into a static rule. Both providers assign addresses per call, so a fixed list goes out of date without warning.
Proxies and TLS inspection
Proxies that decrypt and re-encrypt traffic can break a call. Sometimes the call connects and no audio passes. Sometimes it never starts at all.
Exempt all of the following from inspection:
TURN, STUN and ICE traffic.
The six signalling hostnames listed above.
api.vapi.ai.
The last two matter even when the hostname is already allowed. Inspecting the signalling connection is the most common reason a simulation fails after a team has allowed every address on this page. Inspecting api.vapi.ai can break the browser's permission check against it while leaving the address reachable, which makes the problem look like something other than the network.
VPNs
If your users connect through a VPN, configure split tunnelling so traffic to the hosts on this page bypasses it. This noticeably improves call quality. At a minimum, exempt port 443 for those hosts.
What users see when something is blocked
What the user sees | Check this first |
|---|---|
A network or firewall message about a second after they press Start |
|
Unable to set up call. Please try to rejoin. after about sixteen seconds | The six signalling hostnames, and TLS inspection on them |
The call connects but nobody can hear anything | UDP ports, TURN, and TLS inspection on TURN and STUN |
It works for some people at one site and not others | Browser profile and network path. Collect the evidence below before assuming a cause. |
Test before you roll out
Choose one machine on each network path you support: office, home, VPN, VDI and any outsourced site.
Run a real two-way simulation on each machine for at least one minute.
Check that the recording plays back afterwards.
Repeat on each managed browser profile your users have.
Running the Network Test page from an affected machine shows which connections are failing, which is quicker than working through this list by hand. [Confirm the Network Test page is still available and add its link.]
If it still fails
Send Solidroad support the following. Do not disable a security product to test, since every change on this page can be scoped to named hostnames.
The date, time and timezone of the attempt.
The user's email address.
The exact message shown on screen.
The site or network the user was on.
If the failures affect only some users with no pattern by office or device, your security platform may be isolating the voice provider rather than blocking it. Voice simulations fail for some users but not others covers that case.
Related articles
If you have any further questions, contact the Solidroad team via the Help tab in the platform.