Revision History
Date | Version | Description | Author |
Jun 17, 2026 | 1.0 | Initial Doc Creation | Michael Foye |
Jun 18, 2026 | 1.1 | Added two new sections: WebRTC Audio and Volie Realtime Connectivity & Volie Realtime Websocket Connection | Michael Foye |
|
|
|
|
Do Not Bypass Web Filtering For All 443
You should leave normal web filtering in place for general internet browsing.
Instead, create a specific allow rule for Twilio signaling over TCP 443 to Twilio’s required signaling hosts, not a blanket 443 bypass. Twilio Voice SDK connectivity requires access to Twilio signaling servers and media servers; Twilio’s own network requirements say Voice SDK applications need connectivity to Twilio infrastructure for calls to work.
For example, the rule should be scoped to Twilio signaling destinations such as Twilio’s documented Voice SDK signaling hosts/FQDNs, not any destination / TCP 443.
Prioritize The UDP Media Traffic, Not Generic HTTPS
The main QoS target should be:
Destination/source: Twilio media ranges
168.86.128.0/18
54.172.60.0/30
54.244.51.0/30
Protocol: UDP
Ports: 10000-60000
Action: Allow
QoS: High priority / voice / real-time
Twilio’s current Voice SDK network connectivity guidance includes media server and signaling requirements, and third-party Twilio migration notices consistently reference the newer Twilio voice media range 168.86.128.0/18 with UDP ports 10000-60000.
The older Virginia and Oregon /30 ranges can be included if Twilio or the application vendor still documents them for your environment, but the 168.86.128.0/18 range is the important modern media range.
In short:
Required Twilio media IP ranges:
● Virginia: 54.172.60.0/30
○ 54.172.60.0
○ 54.172.60.1
○ 54.172.60.2
○ 54.172.60.3
● Oregon: 54.244.51.0/30
○ 54.244.51.0
○ 54.244.51.1
○ 54.244.51.2
○ 54.244.51.3
● Additional Twilio range:
○ 168.86.128.0/18
Required media ports:
● Enable UDP from/to these Twilio IP ranges over ports 10000-60000.
Volie FW Setup Recommendations | 2026
Use Firewall Traffic Shaping, Not Just DSCP Hope
DSCP only helps if the network honors it. If the firewall, switches, access points, SD-WAN, or ISP strip or ignore DSCP, then DSCP markings alone do nothing useful.
Create a traffic-shaping / QoS policy on the firewall that matches Twilio UDP media traffic and places it into a high-priority real-time queue. Optionally mark or re-mark that traffic with an appropriate DSCP value, then confirm the LAN/WAN path preserves it.
For voice, many networks use DSCP EF / 46 for RTP media, but the exact marking should match their QoS design. The key is that the firewall must actively classify and queue the Twilio media traffic. The rule being “2nd policy” only affects rule matching order; it does not automatically prioritize traffic.
Suggested Firewall Policy Order
Policy 1
Name: Twilio WebRTC Signaling
Source: Agent/user VLANs
Destination: Twilio Voice SDK signaling FQDNs / required Twilio app endpoints
Destination FQDNs:
- voice-js.roaming.twilio.com
- voice-js.ashburn.twilio.com
- voice-js.umatilla.twilio.com
- eventgw.twilio.com
Service: TCP 443
Action: Allow outbound
Security:
Keep normal web filtering for general internet 443.
Do not create a blanket 443 bypass.
If TLS inspection breaks the Twilio Voice SDK signaling connection, bypass/decrypt-exempt only these Twilio FQDNs, not all 443 traffic.
Volie FW Setup Recommendations | 2026
QoS:
Normal or medium priority is usually fine for signaling. High priority should be reserved for Twilio UDP media.
Policy 2
Name: Twilio WebRTC Media
Source: Agent/user VLANs
Destination: 168.86.128.0/18, 54.172.60.0/30, 54.244.51.0/30 Service: UDP 10000-60000
Action: Allow
Security: No TLS inspection applicable; this is UDP media QoS: High priority / real-time voice queue
Optional DSCP: Mark EF 46 if their network uses EF for voice
Policy 3
Name: General Web
Source: Users
Destination: Internet
Service: TCP 80/443
Action: Allow
Security: Normal web filtering
QoS: Normal
Volie FW Setup Recommendations | 2026
Suggested Firewall Policy Order (#5)
Regarding Concern:
Your concern about not broadly allowing or bypassing all 443 is valid. We do not want to exempt general HTTPS traffic from web filtering.
The correct approach is to keep normal web filtering for general 443 traffic, but create narrow Twilio-specific rules for the traffic Twilio WebRTC actually needs.
For Twilio signaling, allow TCP 443 only to the required Twilio signaling/application destinations, not to all internet destinations. That should avoid creating a broad 443 bypass while still allowing the WebRTC session setup traffic to work.
For the actual voice/media path, create a dedicated rule for Twilio UDP media:
● Twilio media IPs
○ 168.86.128.0/18
○ 54.172.60.0/30
○ 54.244.51.0/30
● Protocol/ports
○ UDP 10000-60000
● Action
○ Allow
● QoS
○ Assign this rule to the real-time/voice/high-priority traffic queue
For QoS, DSCP by itself may or may not help depending on whether the firewall, switches, wireless, SD-WAN, and ISP preserve the markings. The stronger solution is to have the firewall classify the Twilio UDP media traffic directly and place it into a priority traffic-shaping queue. If the network uses DSCP, the firewall can also mark or re-mark this Twilio media traffic as voice/real-time, such as EF/46, but the priority queue is the important part.
The fact that the policy sits second in the rulebase only means it should match before lower rules. It does not guarantee prioritization unless that firewall rule is tied to a QoS or traffic-shaping profile.
So the recommendation is: do not open or prioritize all 443. Keep normal web filtering for generic 443, allow Twilio signaling over scoped 443 destinations, and prioritize the Twilio UDP 10000-60000 media traffic to Twilio’s IP range
1
WebRTC Audio and Volie Realtime Connectivity
To ensure the best experience with Volie calling and realtime application updates, please review the following firewall and network settings.
WebRTC Audio: UDP Inactivity Timeout
Volie uses WebRTC-based audio through Twilio. WebRTC voice traffic uses UDP media streams, which need to remain open and stable during active calls.
Please ensure that UDP session or inactivity timeouts are not set too aggressively for WebRTC media traffic. If a firewall expires UDP sessions too quickly, active calls may experience symptoms such as silence, one-way audio, dropped audio, or intermittent call quality.
Recommended setting:
UDP session/inactivity timeout: 300 seconds or higher
This should be applied to WebRTC/Twilio media traffic:
Protocol: UDP
Ports: 10000-60000
Twilio media IP ranges:
168.86.128.0/18
54.172.60.0/30
54.244.51.0/30
We also recommend prioritizing this traffic using a real-time/voice QoS policy where available. Volie FW Setup Recommendations | 2026
Volie also maintains a secure realtime connection to keep the application updated while agents are working. This connection is used for agent status, call state updates, screen updates, and other realtime application events.
Please allow secure WebSocket traffic to: wss://realtime.volie.com/connect
At the firewall level, this usually means allowing:
Destination FQDN: realtime.volie.com
Protocol: TCP 443 / HTTPS / WSS
WebSocket / HTTP Upgrade traffic
Because this is a long-lived connection, please ensure it is not prematurely closed by firewall, proxy, SSL inspection, or secure web gateway policies.
Recommended settings:
● Allow outbound TCP 443 to realtime.volie.com
● Permit WebSocket / WSS traffic
● Allow HTTP Upgrade traffic
● Avoid aggressive TCP or WebSocket idle timeouts
● Bypass SSL/TLS inspection for realtime.volie.com, if inspection interferes with the WebSocket connection ● Avoid forcing this traffic through a proxy that does not fully support long-lived WebSocket connections ● If SD-WAN is in use, keep this traffic on a stable path during active sessions
Why These Settings Matter
The Twilio/WebRTC UDP media path and the Volie realtime WebSocket connection serve different purposes.
WebRTC UDP media affects call audio quality. If UDP media sessions are blocked, timed out, or deprioritized, users may experience silence, one-way audio, dropped audio, or poor call quality.
The Volie realtime WebSocket connection affects application state and live updates. If the WebSocket connection is interrupted, users may see disconnects, delayed status updates, stale call state, or missed realtime events.
For best results, both paths should be allowed and stable.