VoIP That Sounds Right

The complaint always arrives in the same words: "it sounds like a robot". The manager was closing a deal over the phone and the voice on the other end dissolved into metallic gibberish. The first thing support checked was bandwidth — and there were gigabits to spare. That's the trap with voice over IP: it's almost never a weight problem. A phone call is one of the lightest flows crossing your network, and by far the most impatient. It doesn't ask for room. It asks for punctuality.

Punctuality, not weight

Let's put numbers on "light". A G.711 call — the classic, uncompressed codec — consumes 87.2 kbps per direction with all its Ethernet overhead included. A single 5 Mbps HD video stream equals 57 simultaneous calls. On any modern link, the sheer volume of voice is a rounding error.

What voice demands is something else. Think sushi delivery: nobody cares that the order is small — it has to arrive fresh, and the rolls have to arrive in order. Recommendation ITU-T G.114 sets the budget: 150 ms maximum mouth-to-ear, one way. Up to that point conversation flows; beyond it, both sides start talking over each other and the call turns into a walkie-talkie session. Add two more limits: jitter under 30 ms (the variation between packet arrivals) and loss under 1%.

Why so strict? Because voice rides RTP over UDP, with no retransmissions. And that's the right call: a word that arrives late is useless — playing it two seconds later would be an absurd echo, so the late packet simply gets dropped. TCP, with its "say that again?", is perfect for files and hopeless for conversation. The practical consequence: in VoIP, nothing rescues you from an unpunctual network. It arrives on time, or it doesn't arrive at all.

Packet anatomy: 160 bytes of voice, 58 of paperwork

Let's dissect a G.711 call. The codec samples audio 8,000 times a second at 8 bits per sample: 64 kbps of raw voice. The phone doesn't ship samples one by one: it collects 20 ms of audio — 160 bytes — and sends them off in one packet. That's 50 packets per second, in each direction of the call.

Those 160 bytes never travel alone: 12 bytes of RTP (sequence number and timestamp, for reordering and measuring jitter), 8 of UDP and 20 of IP. Layer-3 total: 200 bytes, which at 50 packets per second works out to 80 kbps. And on the LAN there's still the outer envelope: the Ethernet frame adds 18 more bytes (header plus FCS), leaving 218 bytes on the wire — that is, 87.2 kbps of real bandwidth per direction.

Look at the ratio: 26.6% of the packet is bureaucracy. And watch out for a field classic: calls are bidirectional, so on a symmetric link you reserve 87.2 kbps each way. You can play with codecs, packetization and layer-2 overhead in the VoIP bandwidth calculator.

Codecs: the call's vocal cords

The codec decides how much the voice weighs and how it sounds. Three names cover 95% of what you'll meet in the field:

• G.711 — the reliable grandfather (1972 and still going). No compression: 64 kbps of bitrate and the exact sound of a landline. Its MOS of 4.1 is the yardstick everything else is measured against. It's a spender, but adds almost no delay or CPU.
• G.729 — the penny-pincher. It squeezes voice down to 8 kbps (8× less!) in exchange for a MOS of 3.9, some CPU, and 15 ms of algorithmic delay. It sounds slightly "compressed" but perfectly serviceable. It was born for expensive WAN links, and that's still where it earns its keep.
• Opus — the modern one. Royalty-free, variable bitrate and wideband: it captures up to twice the spectrum of the human voice, which is why its MOS of 4.3 beats the good old landline. It's the WebRTC codec, so you already use it in every browser call.

Notice the table's paradox: compressing 8× (G.729) only cuts real consumption to a third, not an eighth. Blame the 58 bytes of headers, which don't compress: the smaller the payload, the bigger the paperwork's share. The full comparison — with AMR-WB, G.722 and friends — lives in the voice codec calculator.

MOS and its three assassins

The MOS (Mean Opinion Score) is the grade a human ear gives the call, from 1 (unintelligible) to 5 (perfect). Above 4.0 nobody can tell it's VoIP; below 3.5 the complaints start and people hang up and redial. Codecs start out with their factory grade — the one on the thermometer — and the network can only drag it down from there.

So what pushes it down? Three assassins, in order of how quickly your ear notices them:

• Delay — the most annoying and the first one people notice. It doesn't degrade the sound: it degrades the conversation. Past 150 ms one-way, turns start colliding; at 300 ms you're on a walkie-talkie. And it accumulates silently: codec, packetization, queues, distance (fiber adds about 5 ms per 1,000 km) and the jitter buffer itself.
• Jitter — packets leave every 20 ms sharp but arrive like a drummer with jet lag: 18, 25, 19, 40… The jitter buffer re-aligns them, until the variation exceeds what the buffer tolerates and it starts discarding latecomers. Above 30 ms of jitter, it's already dropping.
• Loss — the most forgivable, thanks to PLC (packet loss concealment), which patches holes by interpolation. Up to 1% of scattered loss is barely audible; a burst of 3 back-to-back packets is 60 ms of vanished syllable, and that you hear.

The good news: all three are measurable from a capture. RTP packets carry their own sequence numbers and timestamps, so Wireshark or tshark compute jitter and loss for you:

$ tshark -q -z rtp,streams -r call.pcap
========================= RTP Streams =========================
Src 10.1.20.14:16384 → Dst 190.98.x.x:18210   SSRC 0x4C3A11F2
Payload: g711U   Pkts: 2890   Lost: 6 (0.2%)
Max jitter: 11.3 ms   Mean jitter: 4.1 ms     [OK]

How many trunks? Erlang without tears

So far we've talked about one call. The other question in every telephony project is how many simultaneous calls you must support — in other words, how many trunks to buy. The answer has had a surname since 1917: Erlang B, the formula Agner Erlang used to size Copenhagen's exchanges. The unit is the Erlang: 1 Erlang equals one line busy 100% of the time.

The tempting intuition is "5 Erlangs of traffic = 5 lines". Nope: calls arrive whenever they please, entirely uncoordinated. Sometimes 3 are up, sometimes 8. Erlang B computes the probability that a peak finds every trunk busy — the blocking — and you decide how much blocking the business tolerates. A full worked example:

1. Measure busy-hour traffic. Your PBX logs 100 calls per hour, averaging 3 minutes each: 100 × 3 = 300 minutes of conversation per hour. In Erlangs: 300 ÷ 60 = 5 Erlangs.
2. Set the service target. Blocking ≤ 1%: at most 1 in 100 busy-hour calls hits a busy tone.
3. Discard the intuition. With 5 trunks for 5 Erlangs, Erlang B says 28.5% blocking: more than one in four calls rejected. Randomness charges a steep fee.
4. Iterate upward. With 8 trunks, blocking drops to 7.0%; with 10 it reaches 1.84% — close, but still not compliant.
5. With 11 trunks: 0.83%. The first count that dips below 1%. Answer: 11 trunks — more than double the average traffic, and that margin is exactly what you're paying to absorb the peaks.
6. Translate it to bandwidth. If the trunk is SIP with G.711: 11 × 87.2 kbps = 959 kbps ≈ 1 Mbps symmetric reserved for voice. Check the whole exercise in the Erlang calculator — and while you're there, look at Erlang C, which answers the sibling question: how many agents a call center needs.

QoS: voice flies first class

You now know what a call needs (punctuality) and how many fit (Erlang). What's left is guaranteeing it when the link fills up — because it will, right in the middle of the important call. The standard recipe has three ingredients:

• Mark voice as EF (Expedited Forwarding, DSCP 46) as close to the phone as possible, and SIP signaling as CS3. The DSCP/QoS converter translates between all the notations when a box asks for the number in a different currency.
• Strict priority queue for EF on every interface that congests — typically the WAN router. Strict priority means voice leaves first, always; the policer that comes with it stops mismarked traffic dressed up as EF from starving everyone else. The fine detail — queues, shaping, token buckets — is in the QoS for Real guide.
• A well-sized jitter buffer at the receiving end. It's a trade, not a free knob: every millisecond of buffer absorbs jitter but adds to the mouth-to-ear delay — it spends your G.114 budget. Modern adaptive buffers float between 30 and 50 ms on their own; size yours and check the total delay with the jitter buffer calculator.

One border warning: your DSCP marking rules inside your network, but ISPs routinely wipe or rewrite it at their edge. Over Internet links, real priority is enforced by your egress router, queueing before the bottleneck — don't expect the cloud to honor your EF.

Operational summary: reserve 87.2 kbps per G.711 call (or 39 with Opus) each way, size trunks with Erlang B instead of guessing, mark EF and queue with priority before the bottleneck. Keep delay under 150 ms, jitter under 30 and loss under 1%, and the call sounds like a person instead of a robot — and the manager closes the deal without ever learning your name, which is the definition of success in telephony.