How to prepare your dealership network and firewall for Volie
Follow this guide to configure firewall rules, validate Internet capacity, and run pre-launch tests so agents can use Volie voice and Communication Center on your production network.
Before you start
To prepare your dealership network and firewall for Volie, you need:
IT administrator access to firewall policy, QoS/traffic shaping, and WAN circuit information
An agent workstation on the production VLAN and endpoint path agents will use (wired Ethernet is preferred; test Wi-Fi separately if agents rely on wireless)
The dealership size tier from Getting started with network readiness for Volie so you can compare speed-test results to minimum and recommended targets
Definitions
These terms appear when you prepare network and firewall settings for Volie:
Term | Meaning |
Twilio Network Test | A browser-based test from Twilio that checks TURN connectivity and voice codec tests on your network path |
TURN / UDP media | The preferred path for real-time call audio; blocked UDP media is a common cause of one-way audio or failed calls |
RTT (round-trip time) | Latency measured to Twilio; target is under 100 ms preferred and under 200 ms maximum |
realtime.volie.com | Volie's WebSocket endpoint for live agent state and queue updates; firewalls must allow stable long-lived connections |
Steps
Follow these steps to prepare your dealership network and firewall for Volie:
Confirm the test path. Run all tests from an actual agent workstation on the production network. Use wired Ethernet for baseline validation. If agents use Wi-Fi, repeat key tests on wireless and compare results.
Review Internet capacity. Compare your circuit to the minimum and recommended download/upload targets for your dealership size (see Getting started with network readiness for Volie). Plan extra headroom if the site runs cloud cameras, heavy guest Wi-Fi, centralized VPN/SASE egress, or other high-bandwidth services.
Configure firewall and connectivity for Twilio and Volie. Work with IT to allow the following on the agent network path:
Twilio signaling and media per Twilio Voice SDK network connectivity requirements, including UDP media to Twilio's IP ranges (for example, UDP ports 10000–60000 to 168.86.128.0/18 where your policy model uses CIDR rules)
TURN connectivity on ports commonly used for WebRTC fallback (for example, 3478 and 3479 when your firewall logs show blocks on those ports)
Stable WebSocket traffic to realtime.volie.com without aggressive session timeout or TLS inspection that breaks long-lived connections
QoS or traffic shaping that prioritizes real-time voice when the WAN is busy (strongly recommended on shared circuits)
Avoid common firewall mistakes. Confirm policy order does not block UDP media after a broader deny rule, WebRTC UDP sessions are not timed out too aggressively, and secure web gateways or TLS inspection do not break Twilio signaling or Volie WebSockets without an explicit exception.
Run Internet speed tests. Run at least three tests during normal business hours from the agent workstation. Record download, upload, idle ping, and loaded latency when the test reports it. Compare results to your dealership size tier.
Run the Twilio Network Test. Open Twilio Network Test in the same browser agents use for Volie (Chrome or Firefox recommended). Confirm TURN UDP/TCP/TLS connectivity passes and PCMU and/or Opus voice tests succeed. Record the Twilio edge location shown by the test.
Compare voice-path metrics. Check RTT, jitter, and packet loss against the targets in Getting started with network readiness for Volie. Do not pass the site solely because download speed is high.
Assign a readiness outcome. Classify the site as Ready, Conditional, or Needs remediation using the criteria in Getting started with network readiness for Volie. Save speed-test exports, Twilio Network Test results, firewall confirmation notes, and any documented exceptions with your go-live record.
What success looks like
When your dealership network and firewall are ready for Volie, speed tests meet at least the minimum tier for your size (recommended tier is the target), the Twilio Network Test passes TURN and voice checks, voice-path metrics are within target, and IT has confirmed Twilio media, signaling, QoS, and realtime.volie.com WebSocket requirements.
If the Twilio Network Test fails UDP media but passes TCP/TLS fallback, treat UDP as blocked until IT fixes the rule—fallback availability should not mask a blocked preferred media path. If the Twilio edge shown is unexpectedly distant for your geography (for example, an overseas edge for a U.S. site), capture the result and review DNS, VPN, SASE, or egress routing with IT before go-live.
Limitations
Preparing network and firewall settings for Volie has these verified limits:
Validation from IT's office network or a guest Wi-Fi segment does not replace testing on the agent production path.
A single speed-test screenshot during off-hours does not prove stability during peak dealership traffic—repeat tests during business hours.
Centralized Internet egress (VPN, SASE, or backhaul to a distant data center) can produce high latency even when local circuit speed looks adequate; validate the actual egress path agents use.
Common questions
Who at the dealership should run network readiness tests for Volie?
Your IT administrator or network vendor should configure firewall and QoS rules, while a dealership Admin or Manager should coordinate timing and ensure tests run from an agent workstation on the production network path agents will use for Volie.
Can we go live if we meet the minimum bandwidth but not the recommended tier?
You may proceed as Conditional only when measured download and upload remain above the minimum for your dealership size and voice-path metrics and the Twilio Network Test still pass. Document the bandwidth gap with IT and monitor call quality closely during launch.
Why does the Twilio Network Test show an unexpected edge location?
An unexpectedly distant Twilio edge can indicate DNS, VPN, SASE, or secure-web-gateway routing that steers voice traffic through a remote egress point. Capture the test result and work with IT to review egress and DNS before go-live.
Do we need to validate each rooftop separately?
Yes—when rooftops use different circuits, firewalls, or WAN paths, run the full validation procedure independently at each site before agents at that location use Volie voice.
Related articles
Getting started with network readiness for Volie
Troubleshooting Volie voice quality and network connectivity