Why a 64 kbps codec needs 87 kbps of link
A codec's bitrate describes the compressed speech and nothing else. To cross a network, that speech is chopped into packets, and each packet gets a 12-byte RTP header, an 8-byte UDP header and a 20-byte IPv4 header, then a layer 2 frame around all of it. Those 40 bytes of IP, UDP and RTP are fixed regardless of how much speech the packet carries, and voice packets carry very little speech.
At the default 20 ms interval, G.711 puts 160 bytes of audio in each packet, so the headers are a quarter of what leaves the interface. G.729 puts 20 bytes in, and the headers are close to three quarters of it. This is the central fact of voice network sizing: the overhead is per packet, and voice sends a great many small packets. It is why halving the codec bitrate does not halve the bandwidth, and why a codec comparison that quotes only 64 against 8 kbps is misleading by a factor of three.
The practical consequences are two. First, when you size a SIP trunk or a QoS priority queue you must use the on-the-wire figure, not the codec figure, or the queue will drop calls at exactly the load it was built for. Second, the packet rate matters independently of the bandwidth: 30 calls at 20 ms is 3,000 packets per second in total, and small-packet rates are what exhaust firewalls, SBCs and software routers long before their bandwidth ratings are approached.
The formula, term by term
Bandwidth = (payload + layer 3 headers + layer 2 headers) × 8 × packets per second. Three quantities feed it.
Payload per packet is the codec rate multiplied by the packetisation interval. Keep the units simple: kbps × ms ÷ 8 gives bytes directly, because the thousands cancel. G.711 at 20 ms is 64 × 20 ÷ 8 = 160 bytes; G.729 at 20 ms is 8 × 20 ÷ 8 = 20 bytes. Codecs have a natural frame size — 10 ms for G.711 samples, 10 ms for G.729 — and the packetisation interval bundles a whole number of those frames, which is why 20 and 30 ms are the common settings.
Packets per second is 1000 divided by the interval: 50 pps at 20 ms, 33.33 at 30 ms, 100 at 10 ms. It is the same in both directions for a normal two-party call.
Headers come in two blocks. IP, UDP and RTP together are 40 bytes on IPv4 (20 + 8 + 12) and 60 on IPv6, since the IPv6 header is 40 bytes. Compressed RTP, defined in RFC 2508, exploits the fact that most header fields are identical from packet to packet and reduces the three headers to 2 bytes, or 4 with a UDP checksum — but it is a link-layer optimisation negotiated hop by hop, so it applies to a leased line or a serial WAN link and not to a call crossing the public internet. Layer 2 adds 18 bytes for Ethernet with its frame check sequence, 22 with an 802.1Q tag, 6 for PPP or 4 for Frame Relay. Add another 20 for the Ethernet preamble and interframe gap if you are calculating actual wire occupancy rather than the figure a bandwidth-limited queue will police.
Silence suppression multiplies the result. Voice activity detection stops sending during silence, and since only one party speaks at a time in a real conversation, the saving is substantial. It is modelled here as a flat percentage because that is how vendors quote it, but treat any specific number as a claim to verify: music on hold, conference bridges and automated announcements produce continuous audio and save nothing.
Worked example: sizing a 30-call G.711 SIP trunk
A contact centre needs 30 simultaneous G.711 calls over an Ethernet handoff at the default 20 ms packetisation. Work out the circuit.
- Payload per packet. 64 kbps × 20 ms ÷ 8 = 160 bytes of speech.
- Packet rate. 1000 ÷ 20 = 50 packets per second in each direction.
- Bytes on the wire. 160 payload + 40 (IP 20, UDP 8, RTP 12) + 18 (Ethernet header 14 and FCS 4) = 218 bytes per packet.
- Per-call bandwidth. 218 × 8 × 50 = 87,200 bit/s = 87.2 kbps in each direction. This matches the figure Cisco publishes for G.711 over Ethernet.
- Header share. 58 of the 218 bytes are header, so 58 ÷ 218 = 26.6% of the bandwidth carries no speech.
- Scale to the trunk. 30 × 87.2 = 2,616 kbps = 2.616 Mbps in each direction, and 5.232 Mbps counting both.
- Check the packet rate. 30 calls × 50 pps × 2 directions = 3,000 packets per second through the firewall and session border controller.
- Reserve the queue. Provision at least 2.616 Mbps of priority bandwidth on the upstream, which is the direction that constrains an asymmetric access circuit.
Compare with G.729 on the same design: payload drops to 20 bytes, wire bytes to 78, and per-call bandwidth to 78 × 8 × 50 = 31.2 kbps, so the trunk needs 0.936 Mbps. The codec bitrate fell by a factor of 8 and the bandwidth by a factor of 87.2 ÷ 31.2 = 2.79, because the 58 bytes of header did not change.
How to use these numbers when designing
Size the priority queue on the one-way figure, and the circuit on both. Voice is symmetric, so each direction carries the full per-call bandwidth simultaneously. A low-latency queue on an interface polices one direction, so it needs the one-way total; the circuit itself must sustain that in each direction at once. On an asymmetric access product the upstream is almost always the binding constraint.
Leave the priority queue below about a third of the link. This is a widely used design convention rather than a derived limit: a strict-priority queue that can absorb the whole link starves everything else during a burst, and the guidance exists to keep data traffic viable. If your voice total approaches that share of the circuit, the answer is a larger circuit or a lower-rate codec, not a larger queue.
Watch the header share. The figure reported above tells you how much of your bandwidth is not speech. Below about a quarter, as with G.711 at 20 ms, the design is efficient and further tuning buys little. Above two thirds — G.729 at 10 ms, for instance — you are paying mostly for headers, and either a longer interval or header compression is worth the trade-off. Neither is free: a longer interval adds its own duration to the mouth-to-ear delay and makes each lost packet remove more speech, while cRTP costs CPU on both ends of a link and does not cross routed paths.
Do not forget the rest of the budget. Packetisation delay is one component of the one-way delay that ITU-T G.114 addresses with its widely cited 150 ms planning target for good quality; propagation, serialisation, jitter buffer and codec processing make up the rest. A 60 ms packetisation interval spends nearly half of a 150 ms budget before the packet has left the building.
Bandwidth per call by codec and layer 2, at 20 ms
| Codec | Payload (B) | Ethernet, 18 B | 802.1Q, 22 B | PPP, 6 B | Frame Relay, 4 B |
|---|---|---|---|---|---|
| G.711 / G.722, 64 kbps | 160 | 87.2 kbps | 88.8 kbps | 82.4 kbps | 81.6 kbps |
| G.726-32, 32 kbps | 80 | 55.2 kbps | 56.8 kbps | 50.4 kbps | 49.6 kbps |
| Opus wideband, 24 kbps | 60 | 47.2 kbps | 48.8 kbps | 42.4 kbps | 41.6 kbps |
| G.728 / Opus, 16 kbps | 40 | 39.2 kbps | 40.8 kbps | 34.4 kbps | 33.6 kbps |
| G.729 / G.729a, 8 kbps | 20 | 31.2 kbps | 32.8 kbps | 26.4 kbps | 25.6 kbps |
Every column differs from the Ethernet column by exactly the layer 2 header difference × 8 × 50 — for example PPP saves (18 − 6) × 400 = 4,800 bit/s, or 4.8 kbps, on every row.
Mistakes that undersize a voice network
- Sizing on the codec bitrate. Budgeting 64 kbps for a G.711 call undercounts actual consumption by 36% — the real figure, 87.2 kbps on Ethernet, is 36% above the codec rate — and the error is far worse for low-rate codecs.
- Counting one direction only. A call sends and receives simultaneously. A symmetric circuit must carry the total in each direction at the same time.
- Assuming silence suppression savings. Music on hold, conference audio and IVR prompts have no silence to suppress. Size on the unsuppressed figure unless you have measured your own traffic mix.
- Ignoring the packet rate. Firewalls, session border controllers and virtual routers hit packets-per-second limits long before bandwidth limits when the packets are 218 bytes long.
- Assuming cRTP works everywhere. Header compression is negotiated per link and does not survive a routed internet path, so it belongs in a WAN design and not in an internet SIP trunk estimate.
- Forgetting signalling, fax and video. SIP registration and call setup are small but continuous, T.38 fax runs at its own rate, and a single video call can exceed the whole voice trunk.
- Leaving no burst headroom. Concurrency figures are busy-hour averages. Sizing to exactly the expected peak means every unusual half hour degrades calls that are already established.
Where bandwidth sits among voice quality factors
Bandwidth is necessary and nowhere near sufficient. A voice call needs its packets to arrive with low delay, low jitter and almost no loss, and a link with plenty of capacity can still deliver terrible audio if a large data transfer queues ahead of the voice packets. That is why voice designs pair the capacity calculation on this page with a strict-priority queue, and why the queue's depth matters as much as its rate.
Two ITU-T references frame the quality side. G.114 gives the one-way delay planning guidance that most designs quote as a 150 ms target, and G.107 defines the E-model, which combines delay, loss and codec impairment into a single R-factor. Neither is a bandwidth calculation, but both determine whether the bandwidth you provisioned produces an acceptable call.
On the sizing side, the concurrency figure you feed this calculator is itself the output of a traffic model. Erlang B converts busy-hour call attempts and average duration into the number of simultaneous calls a given blocking probability requires, and that number is the input here. Getting concurrency wrong by 20% costs 20% of the trunk; getting the per-call figure wrong by using the codec bitrate costs far more.
For the surrounding network arithmetic, the MTU, MSS and packet overhead calculator shows what tunnels do to the same headers — a VoIP call inside an IPsec tunnel pays the ESP overhead on every one of its 50 packets per second, which is a large addition when the payload is 20 bytes. The network bandwidth requirement calculator combines voice with the other traffic classes on the same circuit, and the uptime and SLA downtime calculator translates a carrier's availability commitment into the minutes of lost calls it actually permits.