Video Call Quality Test: Latency, Jitter, and Loss

Video Call Quality Test: Latency, Jitter, and Loss

Three metrics determine video call quality. Round-trip time sets the delay between what one participant says and when the other hears it; 150 ms is the threshold above which callers feel the conversation is lagging¹. Jitter determines whether that delay is consistent or erratic; 20 ms of jitter forces the application's jitter buffer to add a matching fixed delay to smooth out arrival variation². Packet loss drops frames and audio samples; above 3%, most video codecs cannot conceal the gaps and visible artifacts appear³.

Measuring all three over a direct peer-to-peer WebRTC path gives you the real quality numbers your call application experiences, not an idealized server-to-client measurement. Corporate firewalls, symmetric NAT, and ISP congestion affect the P2P path in ways that a server ping does not reveal. This tool establishes a WebRTC data channel between two browser instances and runs continuous probe traffic so all three metrics stabilize over a 30-second window.

How RTT, jitter, and loss interact in video calls

High RTT without jitter produces a noticeable conversation delay but intelligible audio. Both participants adapt to the fixed delay within a few exchanges. High jitter with moderate RTT is more disruptive; the jitter buffer must grow to absorb timing variation, adding its own fixed delay on top of the network RTT. Packet loss compounds both effects: the codec concealment algorithm works well up to 3% loss but degrades quickly above that³, and error correction codecs add redundant data that further increases bandwidth consumption. Consequently, 80 ms RTT with 5 ms jitter and 0.5% loss produces a far better call experience than 50 ms RTT with 30 ms jitter and 2% loss.

Why jitter and loss dominate perceived call quality

Jitter and packet loss together have a larger impact on perceived call quality than raw RTT at moderate latency levels. A stable 150 ms connection with 2 ms jitter and 0% loss produces better call quality than an unstable 50 ms connection with 30 ms jitter and 2% loss, even though the second connection has lower latency. The reason is that jitter and loss cause audible clicks, video freezes, and codec degradation, while a fixed 150 ms delay is something callers adapt to within a few exchanges.

Quality benchmarks for video call applications

WebRTC-based video calls typically perform well within these bounds: RTT below 150 ms, jitter below 20 ms, and packet loss below 1%. Zoom, Google Meet, and Microsoft Teams publish similar thresholds in their network requirement documentation⁴. Building on these thresholds, a connection with RTT of 100 ms but 0% loss and 3 ms jitter will perform better than a connection with 60 ms RTT, 25 ms jitter, and 2% loss, even though the second connection has lower latency. Jitter and loss together matter more than raw RTT for perceived call quality at these moderate latency levels. CapyToolkit reports all three metrics simultaneously with the same thresholds these platforms publish, so you can compare your readings directly against the published requirements for whichever video conferencing platform you rely on.

Using the simulation sliders to verify your application

The loss and latency simulation sliders let you introduce controlled degradation to your P2P path. Slide the loss rate to 3% and observe whether your video call application handles the drops gracefully or begins producing visual artifacts. Add 100 ms artificial latency and verify the conversation echo behavior. Furthermore, combining 5% simulated loss with 50 ms artificial latency replicates a congested mobile network, and testing this combination reveals whether your application adapts its codec or drops to audio-only mode under those conditions. Running a five-minute test under combined 3% loss and 80 ms latency simulates a congested residential ISP path during peak hours, which is the most common real-world video call degradation scenario that home users experience when other household members are streaming or downloading in the background.

How bandwidth saturation affects RTT, jitter, and loss simultaneously

Bandwidth saturation elevates all three quality metrics at once because the mechanism is queue overflow. When upload capacity is fully consumed by a competing transfer, the router delays or drops packets from all outbound streams uniformly⁵. RTT rises as probe packets wait in the full queue; jitter increases because queue depth fluctuates as packets enter and leave; packet loss spikes when the queue overflows and the router begins dropping rather than delaying. Recognizing this three-metric simultaneous rise identifies upload saturation as the cause rather than an ISP path problem.

Uploading a large file saturates most residential upload links and causes all three quality metrics to spike together. The fix is either closing the competing upload or enabling QoS on the router to prioritize real-time UDP. Testing with and without a competing upload confirms the diagnosis: all three metrics return to baseline when the background transfer stops.

Bandwidth requirements for common video call configurations

Google Meet requires 3.2 Mbps upload for HD 720p and 4 Mbps for 1080p group video⁶. Microsoft Teams requires 1.5 Mbps per participant for group HD video⁷. Zoom requires 3.8 Mbps for group HD⁴. These are per-session upload figures; on a 20 Mbps upload connection you have headroom for one high-quality video call with several Mbps remaining for background traffic. Enabling QoS and reserving 10 Mbps for video call UDP traffic while limiting background transfers prevents saturation-driven quality degradation even when other household members are active.

Platform network requirements and compliance testing

Zoom, Google Meet, and Microsoft Teams all publish minimum and recommended network requirements in their official support documentation. Zoom specifies 600 kbps for 360p, 1.2 Mbps for 720p HD, and 3.8 Mbps for group HD. Google Meet specifies 3.2 Mbps for HD 720p and 4 Mbps for 1080p in group calls. Microsoft Teams specifies 1.5 Mbps for full-screen HD video. All three platforms share similar latency and jitter thresholds: RTT below 150 ms, jitter below 20 ms, and packet loss below 1% for consistently high-quality calls.

Verifying compliance before a deployment means measuring all three metrics using this tool during a representative network load window. Running the test during expected peak-use hours, with typical background applications active, reveals whether the connection meets thresholds under realistic conditions rather than during off-peak idle periods. CapyToolkit does not enforce any platform-specific thresholds; it reports the raw RTT, jitter, and loss numbers so you can compare them against whichever platform's requirements you need to meet.

Documenting network conditions for IT support escalation

When reporting call quality problems to IT support or an ISP, screenshots of this tool's metric display with timestamps provide concrete diagnostic evidence. Capture the sparkline, average RTT, jitter, and loss percentage during the problem window. Note the ICE candidate type; "relay" suggests the network is forcing relay routing that adds latency beyond the platform's design assumptions. This documentation distinguishes network-layer problems from application or hardware problems before the escalation begins.

Attaching the timestamps turns a subjective complaint into a measurable record that support staff can correlate with their own logs on the same connection. A sparkline showing relay routing during the problem window is far more persuasive than describing the call as choppy after the fact. Keeping a short history of these captures across several sessions also reveals whether the issue is specific to one meeting platform or present on every call over the same network path.

When to use this

Run this test before an important video call to verify your network path, when callers report audio or video quality problems you cannot reproduce in a speed test, or when you are matching your ISP link to Zoom's bandwidth minimums before committing to a new video conferencing platform.

Examples