Work out VoIP bandwidth per call and for every concurrent call: codec, packet size, Ethernet, VPN and cRTP overhead, plus an estimated MOS score.
A VoIP call uses far more bandwidth than its codec’s headline bit rate, because every few milliseconds of audio travels in its own packet and every packet carries the same fixed headers. G.711 is a 64 kbps codec, but at the usual 20 ms packetisation it needs 87.2 kbps in each direction on Ethernet. G.729 is an 8 kbps codec and needs 31.2 kbps. Those two figures match Cisco’s published per-call bandwidth table, and this calculator reproduces them exactly so you can check its arithmetic before trusting it with anything else.
Calls are symmetric: each one sends and receives a stream of the same size at the same time. Ten G.711 calls therefore need about 872 kbps of upload and 872 kbps of download. On cable and DSL connections the upload side is almost always the one that runs out first.
Per-call bandwidth is packet size multiplied by packets per second:
At 20 ms, headers are more than a quarter of every G.711 packet and two thirds of every G.729 packet. That is why low-bit-rate codecs save less than you might expect, and why packet size matters as much as the codec.
| Codec | Payload | Ethernet | PPP / FRF.12 | PPP with cRTP |
|---|---|---|---|---|
| G.711 (64 kbps) | 160 bytes | 87.2 kbps | 82.8 kbps | 67.6 kbps |
| G.722 (64 kbps, HD) | 160 bytes | 87.2 kbps | 82.8 kbps | 67.6 kbps |
| G.729 (8 kbps) | 20 bytes | 31.2 kbps | 26.8 kbps | 11.6 kbps |
| Opus at 24 kbps | 60 bytes | 47.2 kbps | 42.8 kbps | 27.6 kbps |
Opus is variable-bit-rate by default, so its real usage moves with the audio. The calculator treats the chosen Opus rate as a constant target, which is the right number to plan capacity against.
Longer packets carry more audio per header, so they use less bandwidth: G.711 drops from 87.2 kbps at 20 ms to about 79.5 kbps at 30 ms. The cost is delay and fragility. Each extra 10 ms of packetisation adds 10 ms of mouth-to-ear delay, and a lost packet takes a bigger bite out of the conversation. 20 ms is the default on nearly every phone, trunk and softphone for that reason. Opus only supports frames of 2.5, 5, 10, 20, 40 or 60 ms, so 30 ms is disabled when an Opus codec is selected.
Running voice through a site-to-site VPN wraps every small packet in a second set of headers, so the overhead is large relative to the payload. With an IPsec ESP tunnel using AES-CBC and HMAC-SHA1-96, a G.711 call grows from 87.2 kbps to about 112.8 kbps on Ethernet: a new 20-byte IP header, 8 bytes of ESP header, a 16-byte IV, padding to the 16-byte cipher block, a 2-byte trailer and a 12-byte integrity check. NAT traversal adds another 8-byte UDP header. AES-GCM uses a shorter IV and 4-byte alignment, so it costs slightly less. WireGuard adds 60 bytes plus padding to a 16-byte boundary, about 114.4 kbps for the same call. The breakdown table in the tool shows each layer so you can see where the bytes go.
Compressed RTP shrinks the 40-byte IP/UDP/RTP header to 2 bytes (or 4 with UDP checksums) and roughly halves G.729 bandwidth. It works hop-by-hop on serial links such as PPP, MLPPP and Frame Relay. It is not available on Ethernet and does not apply inside an encrypted tunnel, so the calculator disables it in those cases.
Not a real one, and no web page can. A browser cannot send RTP voice packets over UDP to an arbitrary server, so a “VoIP speed test” inside a page is measuring HTTP or WebSocket traffic and estimating from that. The honest approach is to measure the three things that decide call quality yourself and enter them here:
ping -c 50 <host> on macOS or Linux, or ping -n 50 <host> on Windows, ideally pointed at your VoIP provider’s SIP server. Use the average round-trip time, and the spread between pings as a rough jitter figure.The quality score uses a simplified version of the ITU-T G.107 E-model, the method most VoIP monitoring tools use. It starts from a default R-factor of 93.2 and subtracts two impairments. The delay impairment grows slowly up to about 177 ms of one-way mouth-to-ear delay and steeply after it. The equipment impairment combines the codec’s own distortion with packet loss, using planning values from ITU-T G.113: G.711 with packet loss concealment loses about 3.6 points at 1% random loss, while G.729 starts 11 points lower before any loss at all. Mouth-to-ear delay is estimated as half the ping round trip, plus a jitter buffer of twice the jitter, plus the packetisation interval and the codec’s look-ahead. The R-factor is then converted to a 1–5 MOS.
| R-factor | MOS (approx.) | What callers notice |
|---|---|---|
| 90–100 | 4.3–4.5 | Excellent; indistinguishable from a good landline |
| 80–89 | 4.0–4.3 | Good; most users satisfied |
| 70–79 | 3.6–4.0 | Fair; some users notice |
| 60–69 | 3.1–3.6 | Poor; many complain |
| Below 60 | Below 3.1 | Bad; calls are hard work |
Treat the result as an estimate. Echo, background noise, headsets and bursty loss are not modelled, and wideband codecs such as G.722 and Opus have no narrowband E-model values, so they are scored with G.711 values as a stand-in and usually sound better than the number suggests.
With G.711 at 20 ms packetisation, 87.2 kbps in each direction on Ethernet. With G.729 it is 31.2 kbps. A useful rule of thumb is about 100 kbps per call each way for G.711 once you allow for VLAN tags and other overhead, and more if the call runs through a VPN.
Yes. Each call sends and receives a stream of the same size at the same time, so ten calls need the same amount of upload as download. On asymmetric connections such as cable and DSL the upload side is usually the limit.
Every packet carries 40 bytes of IP, UDP and RTP headers plus the layer 2 header, and at 20 ms there are 50 packets a second. For G.711 that adds 23.2 kbps on Ethernet; for G.729 headers are about two thirds of each packet.
Use G.711 (or G.722 for HD voice) when bandwidth is available, because it has the best quality and the most tolerance for packet loss. G.729 saves roughly 56 kbps per call and makes sense on constrained links, at the cost of a lower quality ceiling.
No, and no web page can run a true one: browsers cannot send RTP voice packets over UDP. Measure upload speed with any speed test and latency, jitter and loss with ping to your provider, then enter them here to see how many calls fit and an estimated MOS.
Above 4.0 is good and above 4.3 is excellent. Between 3.6 and 4.0 some callers notice problems, and below 3.6 complaints are common. G.711 tops out at about 4.4 on the narrowband E-model.
A lot, relative to the tiny voice packets. An IPsec ESP tunnel with AES-CBC and SHA-1 takes a G.711 call from 87.2 to about 112.8 kbps on Ethernet, and WireGuard to about 114.4 kbps. The tool shows the exact per-packet overhead for each tunnel type.
20 ms. Longer intervals save bandwidth but add delay and make each lost packet more audible; shorter ones cost more bandwidth. Change it only if your provider or a constrained link requires it.
Calculate network latency, ping distance, and data transfer times between geographic locations. Free tool for network engineers.
Calculate IPv4/IPv6 subnets instantly. Get network ranges, subnet masks, usable hosts & CIDR notation. Free professional tool - no registration needed.
Calculate optimal TCP window sizes, bandwidth-delay product, and buffer settings. Generate OS-specific tuning commands to maximize throughput on high-latency links.