VoIP Call Quality: What Latency, Jitter and Packet Loss Actually Do

Published by OttoCall Editorial Team · Published 9 November 2026 · Published automatically after quality, citation and claims checks

5 min read

VoIP call quality is easier to investigate when you separate three questions: How long did audio take to arrive? Did its arrival timing vary? Did any of its data fail to arrive? Latency, jitter and packet loss describe different problems, even though a caller may experience them together.

Start with the path from speech to playback

A voice conversation needs audio to move between participants in time for each person to respond. RTP, the Real-time Transport Protocol, provides network transport functions suited to real-time data such as audio. Its companion control protocol, RTCP, supports monitoring of data delivery. RFC 3550 describes both protocols.

The distinction between delivery and playback matters. Audio that arrives after a long wait presents a different conversational problem from audio data that never arrives. Likewise, a changing arrival pattern is different from a consistently delayed one. These distinctions help turn a report that a call sounded wrong into questions a technical team can investigate.

Latency: how long audio takes to travel

Latency is delay. For a call, one useful question is how much time passes as speech travels in one direction. ITU-T's G.114 recommendation addresses one-way transmission time and lists guidance on one-way delay for Voice over IP.

Imagine that both participants can hear every word, but each response arrives noticeably later than expected. The conversation can feel awkward: one person may start speaking before the other's response arrives, and the two may talk over each other. The problem in this example is the timing of the exchange, not necessarily missing words.

One-way delay and a measurement made over a round trip answer different questions. When reviewing a delay figure, note what it measures and where it was taken. A single number without that context is a weak basis for deciding which part of a call needs attention.

Jitter: variation in timing

Jitter describes variation in packet arrival timing. Think of two streams that have the same overall delay: in one, audio data arrives at a steady pace; in the other, the spacing changes. Those patterns present different playback challenges even if a summary delay figure looks similar. G.114 also lists an appendix addressing delay variation on unshared access lines.

A receiving system may hold some arriving audio before playing it, giving unevenly arriving data time to reach playback. This is a timing trade-off: allowing more time can help accommodate variation, but the added wait also contributes to delay. A packet that arrives after its playback opportunity is not the same thing as a packet that never reached the receiver, even though either situation can leave audio unavailable when needed.

When investigating jitter, keep its timing pattern in view. A summary figure alone may not show whether variation was brief or sustained, or whether it coincided with the part of the conversation that sounded wrong.

Packet loss: missing audio data

Packet loss concerns data that was sent but did not reach the receiving side. In a packet-based audio stream, missing data can leave a gap in the information available for playback. Depending on how the receiving system handles that gap, a listener may notice an interruption or distorted speech rather than simply a longer wait.

Loss and delay should not be treated as interchangeable labels. A delayed packet may arrive; a lost packet does not. The distinction also matters when reviewing reports: check whether a measurement describes network delivery, playback availability or another stage. Those observations can support different explanations.

RFC 3550 describes RTP as suitable for real-time applications and RTCP as a way to monitor delivery. Monitoring is a starting point for investigation, not a reason to assume that every missing or late audio event has the same cause.

How the three can interact

A call can have more than one timing or delivery issue. For example, variable arrival times can make it harder to have the right audio available at the right playback time. Adding a waiting period may change that timing, while also making the conversation slower. Separately, missing packets remove data from the receiving side altogether.

Use the caller's description to frame the investigation, not to settle it. Overlapping speech suggests a reason to examine delay; interruptions suggest a reason to examine delivery and playback timing. Neither observation, on its own, identifies the cause. Compare what happened with the relevant measurements before choosing a change.

A practical investigation sequence

1. Describe the experience. Record whether the issue was conversational lag, interruptions, inconsistent sound or a combination. Note when it occurred within the call.
2. Define each measurement. For delay, establish whether the figure is one-way or round-trip. For delivery observations, establish what was measured and at which point.
3. Compare timing and delivery. Look at delay, variation and loss separately, then compare them with the reported problem. Avoid treating a single summary as the whole story.
4. Review the direction of the affected audio. If observations are available for each direction, compare them rather than assuming the two sides experienced the same path in the same way.
5. Change one thing and compare again. Keep the original observations so the effect of a change can be assessed against the reported experience and subsequent measurements.

The available evidence matters as much as the terminology. If a measurement is unavailable, record that limitation instead of filling the gap with an assumed cause.

What the standards can and cannot tell you here

ITU-T describes G.107 as the E-model, a computational model for transmission planning. G.114 addresses one-way transmission time, while RFC 3550 describes transport for real-time data and monitoring through RTCP. Together, they offer useful starting points for thinking about call quality.

The source material used here does not provide a universal threshold for judging an individual call, a complete troubleshooting procedure or a finding about a particular network. Use measurements and the actual call experience to guide the next step.

Sources

• https://www.itu.int/rec/T-REC-G.107
• https://www.itu.int/rec/T-REC-G.114
• https://www.rfc-editor.org/rfc/rfc3550

Contact OttoCall to discuss your VoIP needs.

This article is general information, not legal, compliance or financial advice. Check current rules and provider terms for your situation.