VoIP Quality Test: Latency, Jitter, and Packet Loss

VoIP Quality Test: Latency, Jitter, and Packet Loss

VoIP quality degrades before users notice why. A 2% packet loss rate translates to roughly one dropped word per sentence in a standard 50-word-per-minute conversation, audible but not always attributed to the network. At 30 ms jitter, the receiver's playout buffer must add 30 ms of fixed latency to smooth out arrival variation, often pushing end-to-end delay above the 150 ms threshold for natural conversation¹. Understanding these three metrics and how they combine gives you the diagnostic data to identify the actual cause of a poor call before blaming the codec or application.

This tool measures RTT, jitter, and packet loss over a direct peer-to-peer WebRTC path using probe packets between two browser instances. The path mirrors the one your VoIP application uses when it connects directly between participants, revealing the real network conditions rather than a cleaner server-to-client baseline.

ITU-T G.114 thresholds for VoIP quality

ITU-T G.114 defines 150 ms one-way delay as the threshold for interactive voice; above this, callers notice the gap between speaking and receiving a response. Round-trip time in this tool is approximately twice the one-way delay, so 300 ms RTT represents the ITU-T boundary¹. G.114 also notes that above 400 ms RTT, the quality of interaction degrades significantly regardless of codec or application. Furthermore, the ITU-T E-model (R-value) combines delay, jitter, and packet loss into a single quality score: R above 70 is acceptable, above 80 is good, and 90 or higher is toll-quality audio². CapyToolkit reports the same RTT, jitter, and loss values the E-model uses, so you can compare your readings against these thresholds without needing a separate E-model calculator.

How the E-model combines RTT, jitter, and loss into one score

The E-model treats delay, jitter, and packet loss as independent degradations that subtract from a maximum achievable quality score. At 300 ms RTT with 20 ms jitter and 1% loss, the R-value lands near 70, which is the minimum acceptable threshold for business use. Reducing any single metric raises the score: cutting jitter from 20 ms to 5 ms at the same RTT adds roughly 10 points to the R-value, making improvement efforts targeting the most degraded metric the most effective use of troubleshooting time.

How VoIP codecs handle jitter and loss

VoIP codecs use adaptive jitter buffers to absorb timing variation. The buffer holds incoming audio packets temporarily and replays them at a fixed rate, smoothing out arrival jitter at the cost of added fixed delay. A jitter buffer configured for 40 ms of jitter adds 40 ms of delay to every call, regardless of what the actual jitter is during that interval. Building on this, packet concealment algorithms (built into all modern codecs including Opus, G.711, and G.729) generate synthetic audio for lost packets up to about 3%³. Above that threshold, concealment sounds unnatural and callers hear audible dropouts. The codec's built-in forward error correction (FEC) adds redundant data alongside primary audio packets, allowing the receiver to reconstruct some lost packets without perceptible quality loss at moderate loss rates up to 2 to 3 percent.

Diagnosing VoIP problems using P2P metrics

A VoIP call that sounds distant or delayed maps to high RTT; check the average RTT in this tool. Clipping or choppy audio maps to high jitter; check both average jitter and the max jitter spike visible in the sparkline. Audio that drops out in short bursts maps to packet loss; check the real loss percentage. Conversely, audio with distortion or compression artifacts is a codec or bandwidth issue, not a network metric problem; this tool does not measure audio bandwidth. Identifying which metric is out of range narrows the diagnosis to a specific layer before attempting any fix. CapyToolkit reports the three network inputs to call quality (RTT, jitter, and loss) as separate values, so you can determine which one is the dominant problem before changing any router or ISP settings.

Codec selection and DSCP marking for VoIP prioritization

VoIP codec choice sets the quality ceiling for any given network path. Opus, the dominant codec in WebRTC and modern SIP deployments, adapts bitrate in real time from 6 kbps to 510 kbps based on detected network conditions³. G.711 (PCM audio), the standard codec for enterprise SIP trunks and PSTN connections, uses a fixed 64 kbps payload with no adaptive bitrate or forward error correction⁴. Because G.711 transmits no redundancy, it is more sensitive to packet loss than Opus: 2% loss produces audible gaps in G.711 while Opus's built-in FEC recovers most lost frames at the same loss rate. When evaluating this tool's loss readings, the acceptable threshold differs by codec.

DSCP tagging classifies outbound RTP audio packets for router-level QoS prioritization. The standard DSCP value for VoIP media is EF (Expedited Forwarding, DSCP 46)⁵; routers recognizing this marking place tagged packets in the highest-priority queue ahead of HTTP downloads and best-effort traffic. Most enterprise routers and gaming routers honor DSCP markings on the WAN interface. Applying DSCP 46 to VoIP audio prevents competing file transfers from delaying audio packets in the upload queue, reducing jitter without requiring per-port traffic shaping rules.

Configuring DSCP marking on common platforms

On Windows, the Group Policy DSCP marking policy (under Computer Configuration > Windows Settings > Policy-based QoS) applies DSCP 46 to outbound traffic from a specific application. Cisco IP Communicator, Zoom Phone, and Teams VoIP all support DSCP configuration through enterprise management interfaces. For home VoIP adapters, DSCP marking is typically configured per-port in the ATA (Analog Telephone Adapter) settings panel, often labeled "QoS" or "DSCP marking" under the device's web interface.

One-way audio failures and asymmetric path diagnostics

One-way audio means one participant hears the other clearly but their own voice does not reach the far end. This failure almost never appears in symmetric RTT measurements because probe packets complete the round trip successfully; the asymmetry is in the application-layer audio path, not the probe path. The most common cause is a SIP ALG (Application Layer Gateway) on the router rewriting SDP port numbers in the SIP INVITE message, creating a mismatch between the negotiated RTP port and the port the application actually uses⁶.

Disabling SIP ALG on the router resolves most one-way audio issues on consumer hardware. Find this setting under Firewall or WAN settings labeled as SIP ALG, SIP Passthrough, or SIP Helper depending on the firmware. After disabling SIP ALG, disconnect and reconnect the VoIP client to force a fresh SDP negotiation. If one-way audio persists after disabling SIP ALG, a firewall rule is blocking inbound UDP on the RTP port range and requires a port forwarding or allow rule for the remote endpoint's IP address.

Identifying asymmetric path blocks with this tool

Swapping sender and receiver roles mid-test starts with your device as the probe sender; note the loss counter, then reverse roles (the other browser becomes the sender) and note the second loss counter. Matching loss rates confirm a symmetric path; a loss rate appearing only in one direction confirms an asymmetric block. For VoIP troubleshooting, if your instance shows 0% loss as sender but 100% loss as receiver, inbound UDP on the return port is blocked at the router level, isolating the issue before any ISP escalation begins.

Running the two roles back to back on the same session isolates the direction of the block, which a single one-directional test would completely miss. An inbound-only drop almost always means a firewall or NAT rule is rejecting return UDP, since outbound packets clearly reached the peer. Capturing both counters before contacting a provider prevents the common misdiagnosis of blaming codec quality when the real fault is an asymmetric filter on the return path that no amount of bandwidth will fix.

When to use this

Run this test when VoIP call quality is consistently poor, when callers report choppy audio that a speed test cannot explain, or when deploying a VoIP system and verifying that the network path meets ITU-T G.114 requirements.

Examples