Skip to main content

Troubleshooting Volie voice quality and network connectivity

How to fix choppy or one-way Volie calls, slow inbound delivery, and WebRTC or firewall issues on the agent network

S
Written by Sadie Timmons

Troubleshooting Volie voice quality and network connectivity

Use this guide when agents report choppy or one-way audio, long delays before inbound calls arrive, dropped calls, or browser connection issues while using Volie voice and Communication Center.

Symptoms

You may need this article when agents or managers see:

  • Robotic, choppy, or one-way audio on Volie calls

  • Long waits on Available before inbound calls connect

  • Calls that fail to connect or drop mid-conversation

  • Browser errors related to microphone access or WebRTC

  • Queue or agent status updates that lag or stop updating during the workday

Checks and fixes

Try these checks to fix Volie voice quality and network connectivity issues:

  1. Confirm browser and headset basics — Use Chrome or Firefox with an up-to-date version. Grant microphone permission for the Volie site. Confirm the correct headset is selected in the browser and operating system. Close unnecessary tabs and extensions that block WebRTC.

  2. Retest on wired Ethernet — If the agent uses Wi-Fi, reproduce the issue on a wired connection to the same VLAN. If quality improves on Ethernet, review Wi-Fi coverage, congestion, roaming, and channel utilization before relying on wireless for production calling.

  3. Run the Twilio Network Test again — On the affected workstation, open Twilio Network Test during normal business hours. If TURN UDP, voice codec tests, or connectivity checks fail, escalate to IT with the exported results and the Twilio edge location shown.

  4. Compare speed and voice-path metrics — Run at least three Internet speed tests from the affected workstation. Compare download, upload, RTT, jitter, and packet loss to the targets in Getting started with network readiness for Volie. High WAN utilization during peak hours can cause symptoms even when off-peak speed tests look fine.

  5. Review firewall and WebSocket rules with IT — Confirm UDP media to Twilio ranges (for example, UDP 10000–60000 to 168.86.128.0/18), signaling/TURN ports (for example, 3478 and 3479 when blocked), and stable WebSocket access to realtime.volie.com are allowed on the agent path. Re-check policy order, UDP session timeouts, TLS inspection, and secure-web-gateway exceptions.

  6. Check routing and egress architecture — When latency is high despite adequate circuit speed, review whether SD-WAN, SASE, VPN, DNS filtering, or proxying sends voice or WebSocket traffic through a distant egress point. Capture public egress IP, ISP/circuit details, and whether the issue affects all agents or one segment/VLAN.

  7. Rule out local saturation — Guest Wi-Fi, cloud camera uploads, large software downloads, or backup jobs can consume upload or download headroom. Isolate or rate-limit non-business traffic where possible so real-time voice retains capacity.

  8. Collect call examples for support — When poor quality persists, note example Volie/Twilio Call SIDs, timestamps, affected users, and whether the agent was wired or wireless. Include Twilio Network Test and speed-test exports.

Limitations

Volie voice quality troubleshooting has these verified limits:

  • Browser-based voice depends on the agent workstation path; fixing WAN rules at one rooftop does not fix a different site on a separate circuit.

  • Meeting minimum bandwidth tiers does not override failed Twilio connectivity tests or RTT/jitter/loss above target—both capacity and voice-path quality must be addressed.

  • Volie cannot override firewall or ISP restrictions from the application; IT must apply network changes on the dealership side.

Common questions

Why do Volie calls sound fine in the Twilio test but bad on live calls?

The Twilio Network Test confirms connectivity at test time from one workstation; live call quality can still degrade when the WAN is saturated during peak hours, Wi-Fi is congested, or routing changes under load. Repeat tests during business hours and monitor utilization.

Why are inbound calls slow to reach agents who show Available in Volie?

Delayed inbound delivery can indicate an unstable WebSocket connection to realtime.volie.com, high latency on the agent path, or firewall/session timeout behavior that interrupts long-lived connections. Have IT verify WebSocket stability and review the Calls Waiting indicator with managers to confirm queue behavior.

What should we do if UDP media fails but TCP/TLS passes on the Twilio test?

UDP is the preferred media path for Volie voice. Do not treat the site as ready until IT resolves the UDP block or restriction; TCP/TLS fallback availability should not mask a blocked preferred media path.

When should we re-run the full network readiness procedure?

Re-run validation after ISP or circuit changes, firewall policy updates, office moves, new SD-WAN/SASE rollout, or when a new rooftop comes online on a different network path.

Still stuck?

If you are still stuck after these checks, contact Volie Support and include:

  • Account / organization name and affected site / rooftop

  • Who was affected (agent names or roles, if relevant)

  • When issues occurred (date, time, and timezone)

  • Where agents were working (wired vs Wi-Fi, VLAN if known)

  • What you expected vs what happened (for example, inbound delay, one-way audio)

  • Twilio Network Test results and speed-test exports from the affected workstation

  • Public egress IP, ISP/circuit info, and whether SD-WAN, SASE, VPN, or secure web gateways are in use

  • Example Call SIDs and timestamps for poor-quality calls, when available

  • Screenshots of errors or test failures (avoid customer PII)

Related articles

  • Getting started with network readiness for Volie

  • How to prepare your dealership network and firewall for Volie

Did this answer your question?

Related Articles