# VoIP traffic monitoring: Metrics, QoS validation, and troubleshooting Voice traffic tolerates almost nothing. Data applications shrug off network conditions that make calls unusable, which is why a network can look healthy on every general dashboard while voice quality collapses on specific links at specific hours. Monitoring VoIP means watching the handful of metrics voice actually depends on, verifying that prioritization works as deployed rather than as designed, and keeping the history that turns vague complaints into named causes. This page covers all three. ## In this guide: - The four metrics that decide call quality, and the thresholds that define voice-grade. - Why QoS needs validation rather than trust, and how DSCP visibility provides it. - A troubleshooting path from "calls were bad" to a fixable cause. ## The four metrics that decide call quality Latency is the delay between speaking and being heard. ITU-T G.114 guidance places one-way latency at 150 milliseconds or less for good conversational quality; beyond that, speakers start talking over each other because the timing cues conversations depend on arrive late. Jitter is the variation in packet arrival timing, and it is the metric most correlated with choppy, robotic audio. Practitioners hold it under roughly 30 milliseconds. Buffers absorb small jitter at the cost of added latency, so the two metrics trade against each other. Packet loss above about 1 percent becomes audible, because voice codecs reconstruct audio from a continuous stream and every missing packet is a gap the codec papers over with guesswork. Loss also tends to arrive in bursts, and burst loss sounds far worse than the same percentage spread evenly. MOS, the Mean Opinion Score, condenses the metrics above into one quality number on a 1-to-5 scale. Scores around 4.0 and above correspond to quality users accept without complaint, common narrowband codecs top out in the low 4s, and sustained scores below the high 3s generate tickets. The per-path trend matters more than any single reading. Measure all four per path rather than in aggregate, because averages across paths hide the one bad link, and the one bad link is usually the entire story. ## Why VoIP needs its own monitoring lens General traffic monitoring answers general questions: utilization, top talkers, application mix. Voice fails inside conditions those views call healthy. A link at 60 percent utilization with jitter spikes during bursts passes every capacity check and ruins calls anyway. Voice-aware monitoring measures path conditions the way calls experience them, typically through synthetic operations such as Cisco IP SLA tests that simulate voice traffic between network points and record the latency, jitter, loss, and MOS a real call on that path would have scored. ## Validate QoS instead of trusting it Voice quality plans live or die on QoS configuration, and configurations drift. Voice is assigned a priority class, typically Expedited Forwarding (DSCP 46), and the assignment only helps if every device along the path honors it. One misconfigured hop that strips or remarks tags quietly demotes voice to best-effort, and the resulting complaints look random because they follow paths rather than sites. Monitoring traffic by DSCP marking closes the gap between QoS as designed and QoS as deployed. It shows whether voice actually travels in its assigned class end to end, how much bandwidth each class consumes, and which device on which path is the one mishandling tags, because class distribution anomalies point at the hop that created them. ## See what voice competes against Poor call quality on a link is frequently a story about the other traffic on that link. Conversation-level visibility shows what shared the circuit during the bad calls: the backup job that ran early, the video streams nobody prioritized, the update wave that saturated the branch uplink at 9am. Top-talker and application views turn "calls were bad this morning" into "calls were bad while this specific transfer held most of the link," which is a solvable problem with a name. ## Troubleshooting from symptom to segment Call complaints arrive vague, and the path from vague to fixed runs through three questions in order. First, confirm the metrics: which paths breached latency, jitter, or loss thresholds, and during which windows. Second, check the class: did voice stay in its DSCP class end to end through those windows, or did a hop demote it. Third, identify the competition: what else consumed the affected links while the thresholds breached. Each question maps to a view, and retained history means the 9am complaint can be investigated at 2pm with the morning's evidence intact. Most investigations end at question three with a scheduling, prioritization, or capacity fix. ## VoIP monitoring with ManageEngine NetFlow Analyzer ManageEngine NetFlow Analyzer pairs voice-path measurement with the traffic context that explains breaches, on the infrastructure you already run. ### Feature highlights: - Path quality measurement: IP SLA-based latency, jitter, loss, and MOS tracking between the points that matter. - Voice-grade thresholds: alerts at the lines voice depends on, per path, routed to your notification channels. - DSCP visibility: per-class traffic distribution that validates prioritization as deployed. - Conversation context with history: what shared the link during every breach window, retained for after-the-fact investigation. ## FAQs on VoIP monitoring ### What metrics matter most for VoIP quality? Jitter, one-way latency, packet loss, and MOS. Practitioner thresholds hold jitter under roughly 30 ms, latency at or under 150 ms one-way per ITU-T G.114 guidance, and loss under about 1 percent, with MOS summarizing the result on a 1-to-5 scale. ### What is a good MOS score? Scores around 4.0 and above correspond to quality most users accept without complaint, and common narrowband codecs top out in the low 4s. Sustained scores below the high 3s produce noticeable complaints. Watch the per-path trend rather than any single reading. ### Why are calls bad only at certain times? Because voice shares links with everything else, and the competition follows schedules: backups, updates, and streaming peaks. Conversation-level visibility during the bad windows identifies what consumed the link, which converts a recurring mystery into a QoS or scheduling fix. ### How do I verify QoS is working for voice? Monitor traffic by DSCP marking and confirm voice travels in its assigned class, typically Expedited Forwarding (DSCP 46), end to end at expected volumes. Devices that strip or remark tags reveal themselves as class distribution anomalies on the paths they touch. ### Does VoIP monitoring require agents on phones? No. Synthetic operations such as IP SLA run between network devices and measure the path conditions calls experience, and flow data describes the traffic context. Both come from infrastructure you already operate. ## Author ![Author](https://cdn.manageengine.com/itom/images/author/shynu.webp) **By Shynu,** ManageEngine Team Lead product marketer for ManageEngine's FSO suite who enjoys turning the dense world of network traffic analysis into content practitioners actually use. Writes mostly about network monitoring and bandwidth management, and lately about where flow data fits in network detection and response.