BroadNet
Operations BroadNet answer

What determines VoIP call quality?

Last reviewed 2 min readReviewed by BroadNet engineering
Quick answer

VoIP call quality is decided by four network impairments — latency, jitter, packet loss, and the codec — summarised by a single Mean Opinion Score (MOS). Because voice is carried as RTP packets over IP, delayed, out-of-order, or dropped packets degrade the audio the listener hears. Managing these with QoS, jitter buffers, and the right codec is what keeps calls clear at scale.

Plain-language definitionVendor-neutralReviewed July 22, 2026
The long answer

Everything worth knowing, nothing that isn't.

§01

How VoIP quality is measured: MOS

Mean Opinion Score (MOS) rates call quality from 1 (bad) to 5 (excellent); 4.0+ is toll quality, below 3.5 is noticeably degraded. Originally a human listening test, MOS is now estimated automatically (per ITU-T models) from measured latency, jitter, and packet loss. It is the single number carriers and platforms track to compare routes and diagnose a bad call path. See /answers/what-is-mos.

§02

The impairments that lower quality

Latency (one-way delay above ~150ms makes conversation feel like a walkie-talkie); jitter (variation in packet arrival that garbles audio unless a jitter buffer smooths it); and packet loss (missing RTP packets heard as clipping or dropouts — above ~1% is audible). These accumulate across every hop, which is why direct, well-provisioned routes sound better than long ones. See /answers/what-is-jitter and /answers/what-is-rtp.

§03

Codecs and the quality-vs-bandwidth trade-off

The codec sets the ceiling. G.711 is uncompressed toll-quality at ~64 kbit/s; Opus adapts bitrate and is resilient to loss; low-bitrate codecs save bandwidth but cap MOS. Transcoding between codecs along the path costs quality and adds delay, so matching codecs end to end matters. See /answers/what-is-voice-codec and /answers/what-is-sip.

§04

How to protect quality

Prioritise voice with QoS/DiffServ so RTP is not queued behind bulk data; size jitter buffers to trade a little delay for smoother audio; pick loss-resilient codecs like Opus on lossy paths; and choose direct routes with few hops. Continuous MOS, ASR, and PDD monitoring surfaces a degrading route before customers complain. See /answers/what-is-asr, /answers/what-is-pdd, and /products/voice.

§05

Where poor quality actually comes from

Most bad VoIP is not the codec — it is the network path. Grey or over-hopped wholesale voice routes add latency and loss at each transit carrier, congested access links starve RTP of bandwidth, and unmanaged Wi-Fi introduces jitter. Diagnosing quality means correlating MOS with the route and the KPIs (ASR, ACD, PDD) that reveal a weak carrier leg. See /answers/programmable-voice and /platforms/signaling-cdr.

§06

What is a good MOS score for VoIP?

A MOS of 4.0 or above is considered toll quality — indistinguishable from a landline to most listeners. 3.5-4.0 is acceptable, 3.0-3.5 is noticeably degraded, and below 3.0 frustrates callers. G.711 on a clean path tops out near 4.4; the goal of QoS, jitter buffers, and direct routing is to keep the delivered MOS as close to that ceiling as the network allows. See /answers/what-is-mos and /products/voice.

BNWritten by the BroadNet engineering team·Operating carrier-grade messaging since 2003, headquartered in Dubai·Editorial standards
Build with this

Need help wiring this up?

The pages below are the products and integration guides that put this concept on the wire. If you'd rather walk through it live, our engineering team takes calls same-day during MENA working hours.

Talk to our engineering team
References

Source documents we cite.

Standards bodies and regulators referenced in this page. Open in a new tab.

Feedback

Was this answer helpful?

Your vote helps us prioritise which answers to expand with examples, diagrams, and code snippets.

Was this answer helpful?
Thanks — noted. We'll keep this answer maintained.
Got it. Tell us what was missing — send a quick note.

How we write and review content

Still need help?

Talk to a real engineer about your build.

We reply within one business day, and production accounts get 24/7 support. Our solutions engineers ship code, not scripts.

$ curl -X POST https://api.broadnet.me/sms/sendSms
Response SLA
Test-access requestsReply within 1 business day
Production24 / 7 · < 15 min
Operator NOC24 / 7 · pager