Most teams run VoIP testing too late. By the time you find a problem, your customers already have.
After testing VoIP infrastructure across multiple AI voice agent deployments with Cekura, here's what actually breaks call quality, and how to fix it before your customers notice.
Why VoIP Calls Fail
AI voice agent deployments have grown by 340% year-over-year, and most run on standard VoIP infrastructure that wasn't built with agents in mind. There are four failure modes behind most incidents.
- Jitter above 100ms exhausts jitter buffers, which forces packets to drop, but the problems start much earlier. Humans adjust mid-sentence and keep going, but an AI agent loses its place in the turn-taking window and can't recover.
- Latency above 150ms one-way starts breaking interactive voice. Callers notice at 250ms roundtrip. Most teams only discover this under production load and miss it during clean tests.
- Packet loss at even 1% corrupts call quality. A lost packet leads to misread intent that sends the agent down the wrong branch before anyone catches it.
- SIP ALG and missing QoS are the less obvious culprits. SIP ALG rewrites packets that the receiving end can't parse. Without QoS rules, a file transfer at the wrong moment can saturate most active calls on the network.
VoIP Testing: How to Run a Full Test in 4 Steps
Most VoIP tests take under five minutes. The machine you test carries more weight than the tool you pick.
Step 1: Test From the Right Network Path
Start by running the test from the exact machine and connection that your calls use. That means an agent's workstation on the office LAN, or a remote agent's home setup. A random laptop on guest Wi-Fi skews results in ways that have nothing to do with your actual call path.
Plug in via Ethernet when you can. Wireless introduces jitter variability that muddies the results.
Step 2: Use a VoIP-Specific Test
A generic speed test only gives you download and upload numbers. However, VoIP call quality hinges on jitter, packet loss, and latency, which require a purpose-built test to surface.
Look for a tool that simulates actual VoIP traffic and reports jitter, latency, packet loss, and ideally a MOS score or concurrent call capacity estimate.
Step 3: Test Twice, Quiet and Busy
One clean result during off-hours doesn't tell you much. Run the test during a low-usage window, then again when the network is active. Track how jitter, latency, and packet loss shift as traffic picks up. That difference is where most problems surface.
Step 4: Record These Four Numbers
After each run, note bandwidth (upload and download), latency in ms, jitter in ms, and packet loss as a percentage. If your tool gives a MOS score or call capacity estimate, keep that too. Having both sets of numbers gives you something concrete to compare after a fix.
How to Diagnose Your VoIP Connection
One number in isolation rarely points anywhere useful. Here's how to read them together and get to a specific problem.
When and Where Does the Problem Occur?
Before running any test, narrow the scope. Are calls dropping only for remote workers? Only at peak hours? Only on outbound calls? Remote-only issues usually sit outside the central infrastructure. They originate at the home network or ISP.
Peak-hour degradation almost always stems from congestion or missing QoS. Outbound-only drops are usually a SIP configuration problem.
Match the Pattern to the Problem
Most metric combinations point to a recognizable root cause. High jitter with normal latency usually means something on the same pipe is contending for bandwidth. Meanwhile, elevated latency with stable jitter often implicates the ISP or routing path.
Packet loss that surfaces only under load suggests insufficient bandwidth or absent QoS, while packet loss on a quiet network points to hardware. A failing switch, a degraded cable, or a firewall silently discarding RTP packets can all be the culprit.
For AI voice agents specifically, Cekura replays production calls under different network conditions so you can isolate whether a failure came from the agent itself or from the infrastructure underneath it.
How to Fix Bad VoIP Testing Results
Most of the time, the fix is already in your router settings.
1. Get Off Wi-Fi for Critical Endpoints
Ethernet cuts packet loss and handles interference better than wireless, especially in dense environments. If cabling every device isn't realistic, create a dedicated SSID or VLAN for voice and ban heavy downloads from that segment.
2. Turn On QoS and Prioritize Voice Traffic
Configure your router to tag voice packets with DSCP value 46 and give them strict priority over other traffic. If your switch supports Trust Mode, enable it. Restart the router after making changes.
3. Right-Size Bandwidth for Concurrent Calls
If you notice quality degrading as simultaneous calls climb, the link's probably under-provisioned.
You should estimate your bandwidth per call, multiply by peak concurrency, add headroom for data traffic, and compare against your measured throughput. If they're close, the uplink likely warrants an upgrade.
4. Disable SIP ALG and Check Firewall Rules
For call drops, one-way audio, or sporadic failures behind specific routers, SIP ALG is usually the culprit. Disable it in your router settings.
Then confirm SIP (port 5060) and RTP (typically 10000-20000) ports are open and not being mangled by firewall rules.
5. Standardize Remote Agent Network Checks
Treat remote agents' home setups as part of your production environment. Have them run a VoIP-specific test at shift start, plug in via Ethernet when possible, suspend bandwidth-heavy applications beforehand, and flag results outside agreed thresholds before picking up calls.
How to Prevent VoIP Problems in the Future
If you test on a schedule, you're more likely to catch problems before customers notice. These five habits keep issues from reaching calls in the first place:
- Run VoIP-specific tests on a schedule. Do this weekly or monthly, from your key locations and a sample of remote agents. VoIP testing on a fixed cadence surfaces jitter drift before it becomes audible on calls.
- Test under load before major changes. Before adding new agents, switching ISPs, or rolling out an AI voice agent deployment, run your assessment while the network carries realistic call volume instead of during a quiet window.
- Document minimum network requirements. Define target ranges for latency, jitter, packet loss, and bandwidth per call leg. Include mandatory QoS and SIP ALG settings. Share it with IT, facilities, and any MSP so every new connection gets vetted against the same baseline.
- Set up continuous monitoring. Ongoing tracking of jitter, latency, and packet loss over time lets you catch drift before it crosses your quality threshold, instead of finding out from a frustrated caller. Cekura's production monitoring does this automatically across all your active call legs.
- Make a VoIP test part of remote agent onboarding. Require it before the first shift and after any infrastructure change (new router, ISP switch, office relocation). Catching a misconfigured home setup early tends to be far less disruptive than chasing dropped calls mid-deployment.
Your VoIP Infrastructure Passes, but Your Agent Still Needs a QA Layer
A passing VoIP test covers the network, but that's not enough. Agent behavior under pressure, unexpected inputs, and workflow failures only show up in production.
This is what Cekura is built for.
You can add Cekura on top of whichever platform you're using for workflow testing and production monitoring.
It runs structured simulations, tests infrastructure conditions like interruptions and background noise, reviews production calls, and catches regressions before and after launch.
Every time you update a prompt, swap a model, or change a voice provider, CI/CD integration runs your full test suite automatically before anything goes live. When something breaks in production, conversation replay lets you reconstruct exactly what happened and verify the fix held.
Native integrations work out of the box for Retell, VAPI, ElevenLabs, LiveKit, Pipecat, Bland, and more.
You don't have to rebuild anything. You add a testing and monitoring layer on top of what you already have, so you can catch issues long before they become serious problems.
SOC 2-, HIPAA-, and GDPR-compliant: transcript redaction, role-based access, and audit trails.
Book a demo to see how Cekura tests voice and chat AI agents before they reach your customers.
Frequently Asked Questions
What Is a Good MOS Score for VoIP?
A MOS score of 4.0 or above is generally considered good for VoIP. At 3.5 and below, call quality starts affecting comprehension noticeably. Most teams use 3.5 as their minimum threshold and aim to stay above 4.0 in production.
What Causes Poor VoIP Call Quality?
Poor VoIP call quality typically comes from four sources: high jitter, high latency, packet loss at even 1%, or misconfigured hardware.
SIP ALG and missing QoS rules are common culprits that produce the same symptoms without showing up in basic speed tests.
What's the Difference Between a VoIP Test and a Regular Speed Test?
A regular speed test measures download and upload bandwidth. A VoIP test simulates actual voice traffic and measures jitter, latency, packet loss, and MOS score. Bandwidth figures alone don't reveal whether voice packets are arriving in order and on time.
How Often Should You Run a VoIP Test?
Running a VoIP test at least monthly is a reasonable baseline, with additional tests before any major infrastructure change (new ISP, additional agents, or a new voice platform).
Remote agents benefit from running a test at shift start, particularly after any change to their home network setup.
For teams managing AI voice agents, regular VoIP testing should be a core part of the deployment checklist.