Headers and framing are 27% of what goes on the wire
For informationEach packet carries 160 bytes of audio inside a 218-byte frame, 50 times a second. The codec is quoted at 64 kbps; the link sees 87.2 kbps per direction.
Everything is computed from packet sizes in your browser. The default almost everywhere. Uncompressed, so the codec itself costs no quality — only bandwidth.
10 concurrent calls need 0.87 Mbps of upload and the same downstream — 1.74 Mbps in total if your provider counts both directions against one figure. The codec is quoted at 64 kbps.
| Layer | Bytes | Share of the frame |
|---|---|---|
| G.711 (PCMU / PCMA) payload | 160 | 73% |
| RTP header | 12 | 6% |
| UDP header | 8 | 4% |
| IPv4 header | 20 | 9% |
| Ethernet frame | 18 | 8% |
| On the wire | 218 | 27% of it is not audio |
50 packets a second, each way, per call. Packet rate matters as much as bandwidth on small routers and firewalls, which run out of packets per second long before they run out of megabits.
Each packet carries 160 bytes of audio inside a 218-byte frame, 50 times a second. The codec is quoted at 64 kbps; the link sees 87.2 kbps per direction.
“G.711 is 64 kbps” is true about the codec and wrong about the circuit. Sizing a connection on the codec rate is how an office ends up with calls that break up on the twelfth one.
12 bytes of RTP, 8 of UDP, 20 of IPv4 — 60 if IPv6. At 50 packets a second that is 16 kbps of headers regardless of what the audio costs.
18 bytes for an Ethernet frame, 22 with a VLAN tag, 26 over PPPoE. A switch port spends another 20 on the preamble and the gap between frames.
IPsec in tunnel mode adds a new IP header, the ESP headers, an initialisation vector, padding to the cipher block and an integrity check — around 60 bytes on a packet that might only hold 20 bytes of compressed audio.
This is why the compression ratio of a codec is not the ratio of the bandwidth it saves. G.729 compresses the audio eight-fold against G.711 and uses about a third of the bandwidth on an Ethernet link, because the headers are identical in both cases. At a 10 ms packetisation interval it is worse still: 10 bytes of audio inside a 68-byte frame, with 85% of the link carrying overhead.
The calculator derives these from packet sizes rather than looking them up, so they hold for whatever combination you choose. These are the common ones.
| Codec | Payload | IP layer | With Ethernet | Note |
|---|---|---|---|---|
| G.711 | 64 kbps | 80 kbps | 87.2 kbps | Uncompressed, supported everywhere, and what most providers bill for. |
| G.722 | 64 kbps | 80 kbps | 87.2 kbps | Identical cost to G.711, wider audio band. Use it wherever both ends agree. |
| Opus at 32 kbps | 32 kbps | 48 kbps | 55.2 kbps | Better than G.711 at half the payload. The WebRTC default family. |
| G.726 at 32 kbps | 32 kbps | 48 kbps | 55.2 kbps | ADPCM. Still common on older gateways and DECT handsets. |
| G.729 | 8 kbps | 24 kbps | 31.2 kbps | Eight-fold audio compression, under four-fold bandwidth saving. |
| G.723.1 at 6.3 kbps | 6.3 kbps | 17.1 kbps | 21.9 kbps | 30 ms frames, so the codec itself adds delay. Long thin links only. |
Having worked out the figure, it is worth saying plainly: an office with enough bandwidth and bad calls is the normal case, not the exception. Calls fail on jitter, on loss, and on latency that rises when the link gets busy — and all three can happen on a connection that is nowhere near its throughput limit.
The usual culprits are a router whose queue fills on uploads and delays everything behind it, the absence of any prioritisation so a backup competes with a call on equal terms, wireless rather than the wired path the arithmetic assumed, and a packet rate that exhausts a small firewall long before its stated throughput. Sixty calls at 50 packets a second each way is six thousand packets a second, which is a different question from 5 Mbps.
So use this to size a circuit and to check that a VPN has not quietly doubled the cost — then measure the connection you actually have. The VoIP quality test reports jitter, loss and an estimated MOS from your browser, and the bufferbloat test shows how far latency rises under load, which is the single most common reason calls sound bad on a fast connection.
64 kbps is the audio. At the standard 20 ms packetisation that audio arrives as 160 bytes per packet, fifty times a second, and each packet also carries a 12-byte RTP header, an 8-byte UDP header, a 20-byte IPv4 header and 18 bytes of Ethernet framing. 218 bytes at 50 packets a second is 87.2 kbps. Those 58 bytes of overhead are 27% of the frame — a 36% surcharge on top of the audio — and they do not shrink when the codec does, which is why a compressed codec saves less than its bitrate suggests.
Yes, and it costs delay. Doubling the interval from 20 ms to 40 ms halves the packet rate, so the headers are sent half as often: G.711 over Ethernet drops from 87.2 to 75.6 kbps. But a packet cannot be sent until its audio exists, and the receiver's jitter buffer then holds a packet or two more, so you have added something like 60 ms of one-way delay against a 150 ms budget. On a constrained link that is a reasonable trade. On an office LAN it is giving away call quality for bandwidth you have.
Divide the usable upload by the per-call figure — and leave a fifth of the link unused. A link driven to its limit queues, and queuing delay destroys call quality long before the arithmetic says the link is full. A 20 Mbps upload arithmetically carries 229 G.711 calls and practically carries 183, and in both cases the real limit is usually the router's packet rate or the absence of any traffic prioritisation rather than the bandwidth.
Because ESP pads the encrypted payload to the cipher's block size, which is 16 bytes for AES. A 200-byte G.711 packet pads by 6 bytes; a 60-byte G.729 packet pads by 2. The published figures — 'IPsec adds 73 bytes' and similar — are one particular packet size's answer presented as a constant. This calculator computes the padding for the packet you actually chose, which is why a compressed codec inside a VPN saves proportionally less than it does without one.
It genuinely halves the traffic on paper, because each endpoint stops transmitting while that person is listening. Two caveats. First, the saving is an average rather than a ceiling: both parties occasionally talk at once and the link still has to carry the peak, so size the circuit for full activity and treat suppression as headroom. Second, it interacts badly with music on hold, fax, and some DTMF relay methods, and the clipped onset of speech is audible to some people. Most deployments leave it off.
G.711 if bandwidth is not the constraint, because it is uncompressed and universally supported. G.722 in preference to it wherever both ends support it — identical bandwidth, noticeably better audio. Opus where you control both endpoints, because it sounds better than G.711 at half the rate. G.729 only where the link is genuinely the limit, and never where the call will be transcoded again later: compressing an already-compressed call is where the quality really goes.
Voice is the least forgiving thing on a network and the first to be blamed on the platform. We run UCaaS and the network under it together, which is the only way the question of whose fault it is stops being a conversation between two vendors.