Voice simulations fail for some users but not others
Last updated: November 10, 2026
Your allowlist can be correct and voice simulations can still fail, for some users and not others. Three different network controls produce that pattern. This article helps you tell them apart and fix each one.
Apply the Network allowlist guide first, and come back here if the problem continues after that.
Symptoms
The simulation loads and the scenario appears, but the voice call never connects.
It works for some users and fails for others, with no clear pattern by office or device.
The same user can fail for an hour and then succeed, without anything changing on their machine.
Chat simulations are unaffected.
Messages that point at the network
A learner sees one of these when the call cannot reach the voice service. Any of them can come from any of the three causes below, so the message on its own does not tell you which.
The voice service closed the call before your audio reached it. Check your network or firewall settings and try again.
We can’t reach the voice service from your network. If this keeps happening, ask your IT team.
We couldn’t connect to the voice service. Check your network or firewall settings and try again.
Your connection to the voice service dropped, so the call ended. Check your network, then start a new attempt.
Ask the learner how long the call loaded before the message appeared, then use the timing table below. A call that loads and never connects, with no message at all, is the last row of that table. Every other message a learner can see during a call is listed in Error messages during a simulation call.
Start with how long it takes to fail
Time the gap between pressing Start and the error appearing. It is the fastest way to narrow the cause.
Time to fail | Most likely cause |
|---|---|
About sixteen seconds | TLS inspection of the signalling connection |
About one second | TLS inspection of the call API |
Never fails, but never connects | AI application isolation |
Ask the user to note the time, or watch them do it once on a call.
Why it affects some users and not others
Secure web gateways send users out through different egress nodes, and policy can differ between them. We have seen one user fail repeatedly for two hours and then succeed from the same address, with no change on their side.
Treat "it works for me" from your network team as weak evidence. Test with a user who fails reliably, and test more than once.
Cause 1: TLS inspection of the signalling connection
This is the most common cause we see.
A voice call opens a WebSocket to the provider's signalling hostnames to set the call up. Allowing those hostnames is not enough. If your proxy decrypts and re-encrypts that connection, the call software cannot complete it. It retries three times and gives up after about sixteen seconds.
To fix it, exempt these six hostnames from TLS inspection as well as allowing them:
*.wss.daily.coand*-wss.daily.co*.wss.dailywebrtc.comand*-wss.dailywebrtc.com*.wss.dailywebrtc.netand*-wss.dailywebrtc.net
Both forms matter, because the call software switches between them while it retries.
Cause 2: AI application isolation
Secure web gateway and SASE platforms, including Zscaler, Netskope, Palo Alto Prisma Access, Island and Menlo, can isolate any application they classify as an AI tool. Solidroad's voice provider is often classified this way.
Isolation is not the same as a block. A block rejects the request and leaves a clear failure in your logs and in the browser console. Isolation reroutes the session through a remote browser, so the request appears to succeed, nothing is recorded as blocked, and the call setup never completes.
To fix it, add vapi.ai to your AI isolation policy exceptions. That is a separate policy object from your allowlist, so adding a host to one does not add it to the other.
Confirming it without reading any logs
Ask an affected user to open vapi.ai in their normal browser, on the machine where simulations fail. Then ask them to open perplexity.ai as a control.
What they see | What it means |
|---|---|
Both open inside an isolation frame, or show a gateway notice | Isolation is active. Add |
| Isolation is still active for that user. |
Neither isolates | Isolation is unlikely. Read causes 1 and 3. |
Run the same test on a machine where simulations work. A side by side comparison is the fastest way to show your network team the difference.
Recategorising instead of excepting
Some teams recategorise vapi.ai as a business application, on the basis that Solidroad uses it as the voice transport for a licensed training tool rather than as a general purpose AI assistant your team prompts directly. It reaches the same outcome as an exception and is sometimes easier to get approved.
Cause 3: TLS inspection of the call API
Before a call starts, the browser asks api.vapi.ai for permission to send its request. Some proxies pass an ordinary request to that address but interfere with the permission step.
This one is easy to misread. The address is reachable, so a connectivity test against it passes, and the problem looks like something other than the network. The failure happens in about a second.
To fix it, exempt api.vapi.ai from TLS inspection as well as allowing it.
A note on daily.co
Earlier guidance said daily.co belongs on your allowlist but rarely needs special treatment. That is no longer accurate. The signalling hostnames under daily.co, dailywebrtc.com and dailywebrtc.net need a TLS inspection exemption, as described in cause 1, and they are the most common cause of this problem.
Definitive check in the browser
On a machine where simulations fail:
Open Chrome DevTools and go to the Network tab.
Tick Preserve log.
Start a voice simulation.
Filter for
vapi, then filter again forwss.
Compare the result against a machine where simulations work. On the affected machine, either the call setup request to api.vapi.ai does not complete, or the WebSocket to a wss hostname does not open.
If it still fails
Send the Solidroad team the following, and we can confirm what the call attempt looked like from our side.
The date, time and timezone of a failed attempt.
The user's email address.
The exact message shown on screen, and how long it took to appear.
Whether the same user has ever succeeded on the same machine.
Related articles
If you have any further questions, contact the Solidroad team via the Help tab in the platform.