Call quality monitoring means measuring what callers actually hear, then tying every bad call back to the network path, site or carrier that caused it. For a VoIP network that means tracking MOS, latency, jitter and packet loss on every site, alerting on trends rather than single calls, and keeping enough detail to trace a complaint to its cause. This is different from call-center quality assurance, where a supervisor scores how an agent handled a conversation. This guide covers the network side: the metrics, the common failures (including one-way audio), a troubleshooting order that works, and how to run it across many locations.
TL;DR
- Voice quality is judged on two things: how clear the audio is (listening quality) and how natural the conversation feels (conversational quality). Measure both with MOS plus loss, jitter and delay.
- Alert on aggregates, such as the share of calls below a threshold per site, instead of on single calls. That cuts false alarms.
- One-way audio usually means call signaling worked but the voice packets (RTP) failed in one direction. Start with firewall, NAT and routing.
- Multi-site networks need active tests, call detail records and packet capture working together, with per-site views.
- Fixing the pattern matters more than fixing the call: recurring problems point to a carrier, a link or a QoS setting.
Table of Contents
- Two kinds of call quality monitoring
- The voice quality metrics that matter
- Common VoIP call quality issues and how to spot them
- One-way audio: why it happens and how to troubleshoot it
- A troubleshooting order for voice quality problems
- How to monitor call quality across many locations
- Our perspective
- Put monitoring and managed voice under one provider
- A starting checklist for your own environment
- FAQ
- Sources
Two kinds of call quality monitoring
The phrase covers two separate jobs, and most top-ranking pages are about only one of them.
Agent-side quality monitoring is a contact-center discipline. Supervisors or AI tools listen to recordings, score them against a form and coach agents. It measures behavior: greeting, empathy, compliance, resolution.
Network-side voice quality monitoring is what IT and network teams do. It measures whether the audio arrived intact: whether words were clipped, whether there was an echo, whether one party could not hear the other. It works from technical data such as packet statistics and estimated scores.
The two meet in practice. A call center agent scored poorly for "asking customers to repeat themselves" may be working on a line with 3% packet loss. If your business runs phones across many sites, network-side monitoring is the foundation, because no amount of agent coaching fixes a jittery link.
The ITU describes the network-side approach formally. Its Recommendation G.1029 sets out a voice-service diagnosis framework that uses speech-quality assessment models to spot common voice-quality problems in live networks and to help diagnose likely causes once a problem is detected. Detect first, then diagnose: that order is the backbone of everything below.
The voice quality metrics that matter
You do not need dozens of numbers. You need a small set, read together.
MOS: the headline score
Mean Opinion Score is a 1 to 5 rating of how good a call sounds. It can come from subjective tests, where people listen and rate, or from objective models that estimate the score from network conditions. ITU-T G.1029 describes both approaches, and distinguishes listening quality from conversational quality. Listening quality is how clean the audio is. Conversational quality adds delay and echo, which make people talk over each other even when each word is clear.
In live monitoring, MOS is almost always an estimate. Google Cloud's documentation, for example, defines its voice MOS metric as an estimate of call sound quality measured on voice probes, and states that MOS is a function of loss, latency and jitter. That is the key point for IT teams: a MOS number is a summary of the three metrics below, so when it drops, those three tell you why. For a deeper walk-through of scoring and alert thresholds, see our guide to MOS for VoIP: how to measure, alert and fix.
Packet loss
Voice travels as a stream of small packets. Lost packets never reach the receiver, and the listener hears gaps, clipping or robotic distortion. Even modest loss can hurt voice, and it hurts other real-time traffic too: our write-up on fax over IP failures caused by about 2% packet loss shows how a small percentage breaks a service that looks fine for web browsing.
Jitter
Jitter is variation in packet arrival time. Phones use a jitter buffer to smooth it out, but if packets arrive too unevenly the buffer overflows or runs dry, and the result is the same as loss: choppy audio. Jitter often appears first on congested links and on busy Wi-Fi. If your complaints come from video meetings, our piece on fixing jitter and packet loss on business Wi-Fi applies directly.
Delay (latency)
One-way delay is the time a voice packet takes from speaker to listener. High delay does not damage the sound, but it wrecks conversation: pauses, interruptions and people talking over one another. Delay also feeds the MOS estimate, which is why a clean-sounding call over a satellite or badly routed path can still score poorly.
Echo and signal level
G.1029 recommends accompanying MOS with voice and noise level and echo metrics, alongside transmission statistics such as packet loss, jitter and delay. Levels matter because a call can be perfectly delivered and still be too quiet to understand. Echo is often a device or gateway issue rather than a network one, which is why it is worth tracking separately.
| Symptom callers report | Most likely metric to check | Typical place to look |
|---|---|---|
| Words cut out, robotic voice | Packet loss | Congested WAN link, bad carrier hop, Wi-Fi |
| Choppy, stuttering audio | Jitter | Wi-Fi, shared uplinks, missing QoS |
| Talking over each other | Delay | Routing path, backhaul, VPN or tunnel design |
| I can hear them, they cannot hear me | RTP direction, not a score | Firewall, NAT, asymmetric routing |
| Hollow or repeating voice | Echo | Handsets, headsets, gateways |
| Calls fine, but quiet | Signal level | Endpoint settings, codec transcoding |
Common VoIP call quality issues and how to spot them
Most voice problems fall into a handful of patterns. Equipment makers describe them the same way: audible symptoms such as one-way audio and broken, choppy or garbled sound, backed by counters in device logs. AudioCodes' voice quality troubleshooting guide lists RTP packet loss and packet reordering counters in syslog as the markers to look for.
The practical lesson is that complaints are the last place you want to find out. If packet loss and reorder counters are visible in logs, they can be collected, graphed and alerted on before a user dials the help desk.
One-way audio: why it happens and how to troubleshoot it
One-way audio is one of the most searched VoIP problems because it is so confusing. The phone rings, the call connects, the timer runs, and one person hears nothing.
The reason is that call setup and voice are separate. Signaling (SIP) sets up the call. The voice itself travels as RTP media packets. Cisco's troubleshooting guidance explains that a call can be connected at the signaling level before the phones start sending and receiving RTP, and that RTP travels point to point unless a media resource is involved. So "the call connected" proves nothing about audio.
Likely causes, in the order we check them
- Firewall rules. If the firewall allows SIP but drops the RTP port range, the call connects and audio fails. Voice port ranges vary by manufacturer, so confirm the range your platform and handsets use rather than assuming a default.
- NAT. A misconfigured address translation can advertise a private address in the call setup, so the far side sends audio to an address it cannot reach. Short NAT timeouts can also close the return path mid-call.
- Asymmetric routing. If the return path takes a different route from the forward path, with different policies or behavior, voice may pass one way and be dropped the other.
- Endpoint or codec mismatch. Less common, but a device that cannot negotiate a shared codec can leave one direction silent.
A packet-capture check
Cisco recommends confirming the phones' local and remote IP addresses and ports, then using packet captures to look for RTP packets that are out of sequence, corrupted, malformed or empty. A capture taken at both ends tells you quickly where the stream stops: if packets leave site A and never appear at site B, the loss is in between, and you know whether to look at a firewall, a carrier or a tunnel.
A troubleshooting order for voice quality problems
When a user reports a bad call, resist guessing. This sequence keeps the work short.
- Pin down the scope. One user, one site, one carrier, or everyone? Scope alone eliminates half the causes. A single desk points to a headset or port; a whole site points to the WAN or Wi-Fi.
- Pull the call record. Check the MOS estimate, loss, jitter and delay for that call and the calls around it.
- Read the direction. Loss on the way out and clean on the way back means a path problem, not a phone problem. Remember that a full call is two independent voice streams, one in each direction, so test each direction separately.
- Check traffic priority. Confirm voice is marked and queued ahead of bulk traffic end to end. Our reference on VoIP QoS settings: what to configure and where lists the settings by device. Remember that markings can be reset when traffic crosses the public internet.
- Look at the path. Compare the site's other calls over the same circuit and carrier. If one hop is dropping traffic, every call crossing it will show it.
- Capture packets only when needed. Capture is precise but heavy. Use scores and counters to narrow the problem first.
- Record the fix and the cause. A repeat problem is only visible if causes are logged against a site and circuit.
How to monitor call quality across many locations
Single-site monitoring is a phone and a spreadsheet. Across 5, 50 or 500 sites, you need layers that cover each other's blind spots:
- Active testing. Simulated voice streams run continuously between sites or to a cloud endpoint, giving a baseline for MOS, jitter and latency even when nobody is on a call. Because tests run at 3 a.m., they catch a failing circuit before the morning shift does.
- Call detail records. Your phone platform records quality data for real calls, including MOS. This shows what users really experienced, including problems caused by devices and Wi-Fi that synthetic tests never touch.
- Packet capture and protocol analysis. The deep-dive tool for a specific failure, used sparingly.
- Path visibility. Seeing which hop and which carrier a call crossed turns "voice is bad at the Fresno store" into "loss starts at this handoff."
The goal is a per-site view with a global summary: one screen showing which sites are healthy, and a way to drill from a site into a single call.
Alert on patterns, not single calls
One bad call is noise. ITU-T G.1029 advises decision processes built on thresholds and sampling, preferring aggregate or proportion-based triggers over single-call alerts to reduce false positives. In practice: alert when more than a set share of a site's calls in a window fall below your MOS threshold, not when one call does. Tune the threshold per site type, since a branch office on a 4G backup link will not look like a headquarters on fiber.
Alert volume is its own problem. If your voice alerts arrive alongside thousands of syslog and SNMP messages, the important ones get ignored. See how to reduce alert fatigue with AI-assisted monitoring for a method that turns raw noise into prioritized incidents.
Use the data to find recurring problems
Monitoring pays for itself when you read it across weeks, not minutes. Look for:
- The same time of day. Quality dips every afternoon at one site suggest saturation, often from a backup job or video traffic.
- The same carrier or circuit. If several sites on one carrier degrade together, take it to the carrier with evidence.
- The same hop. Per-hop loss data, when you can see it, ends arguments about whose network is at fault.
- After every change. A new firewall policy or QoS change is the most common cause of a new one-way audio ticket.
SD-WAN deployments add useful levers here. Our guides on SD-WAN tuning that fixes voice quality and the SD-WAN SLA metrics worth monitoring explain how path selection and per-link thresholds keep voice off a degrading circuit.
Our perspective
Most voice problems we see are not phone problems. They are network problems that show up on the phone first, because voice is the least forgiving traffic on the circuit. A website tolerates a slow second. A call does not.
That is why we treat voice quality as part of network operations, not as a separate feature. Our Netverge platform is built to give real-time observability across every site on one dashboard, so loss, jitter and delay are visible beside the circuit and carrier that carry them. When a site degrades, our engineers see the same data you do and can diagnose without a truck roll.
We also think the carrier question matters more than most buyers expect. We source from 50+ carriers and are carrier-neutral, so when the evidence says a circuit is the cause, the fix can be a different path rather than a longer ticket. Add a 24/7 U.S.-based NOC and a single engineer to call, and the pattern we aim for is simple: the problem is found by monitoring, not by your users.
Jim
Put monitoring and managed voice under one provider
If you run phones across several California locations and your IT team is lean, the hardest part is rarely the tooling. It is correlating a voice complaint across a carrier, a firewall, a switch and a phone platform, owned by different vendors.
We design, deploy and monitor the full stack ourselves. Netverge monitoring provides AI-powered, real-time observability across your sites, and our UCaaS hosted PBX is backed by a 99.999% uptime SLA on voice and a 99.99% SLA on data, with a 24/7 U.S.-based NOC behind both.
If you want to see how your sites would look on one dashboard, start with our network monitoring service or the Netverge observability platform, and talk to an engineer about your locations.
A starting checklist for your own environment
Whether you build it yourself or work with a provider, this is a sensible first month:
- Inventory every site by circuit type, carrier and phone platform.
- Turn on call-quality data collection in your phone platform and confirm MOS, loss, jitter and delay are recorded per call.
- Add active voice tests between your most important sites and to your phone provider.
- Set per-site thresholds, and alert on the share of calls below target in a window.
- Verify voice priority end to end, from handset through switch, firewall and WAN edge.
- Document your RTP port range and NAT behavior, so one-way audio tickets start from known facts.
- Review a monthly report by site, carrier and hour, and log the cause of every incident.
FAQ
How do you measure call quality?
Combine an estimated score with transmission statistics. MOS gives a 1 to 5 summary of how a call sounds, and packet loss, jitter and delay explain why. ITU-T G.1029 recommends reading MOS together with level, echo and those transmission statistics. Collect them from live calls and from simulated test calls.
What causes one-way audio on VoIP calls?
Usually the call setup succeeded but the voice packets failed in one direction. The usual suspects are a firewall blocking the RTP port range, NAT advertising the wrong address or timing out, and asymmetric routing. A packet capture at both ends shows where the stream stops.
What is the difference between call quality monitoring and call center quality monitoring?
Call center quality monitoring scores agent behavior from recordings. Network call quality monitoring measures the technical delivery of the audio: MOS, loss, jitter, delay and echo. A business with many sites usually needs both, but poor network quality will undermine any agent score.
Should I alert on every bad call?
No. Single-call alerts create false positives. ITU-T G.1029 advises thresholds and sampling that favor aggregate or proportion-based triggers. Alert when a meaningful share of a site's calls fall below your target in a time window.
Sources
- Recommendation ITU-T G.1029: Voice service diagnosis framework
- Monitoring metrics, Network Intelligence Center (Google Cloud)
- AudioCodes Quick Reference Guide: Voice Quality Troubleshooting
- How to troubleshoot one-way / no audio issues (Cisco Community)