Voice

VoIP Bandwidth

Pick the codec, the concurrent calls, the packetization and the layer-2 overhead and get the per-call and total bandwidth of your VoIP trunk. Includes header compression (cRTP) and a codec comparison table.

redzilla.cl — voip

Per call

—

Trunk total

—

Packets per second

—

per call

Per call —

Total —

Packet —

Bandwidth by codec

With the selected packetization and overhead. The highlighted row is the chosen codec.

Codec	Payload	kbps/call	Total

How it is calculated · payload, headers and pps

1. pps = 1000 / ms. With 20 ms of voice per packet that is 50 pps.

2. payload (B) = (codec_bps / 8) × (ms / 1000). G.711 at 64 kbps with 20 ms = 160 B.

3. Headers per packet: RTP+UDP+IP = 40 B (or ~2 B with cRTP) plus the layer-2 overhead (Ethernet=18 B, +VLAN=22 B, MPLS=4 B).

4. bw_per_call (bps) = (payload + headers) × 8 × pps. The total = bw_per_call × number of calls.

Runs locally in your browser · no sign-up · nothing leaves your browser.

How it works

The calculator estimates the real bandwidth of a VoIP trunk from four inputs: the codec (G.711, G.729, G.722, G.726-32, iLBC or Opus), the number of concurrent calls, the packetization interval (10, 20 or 30 ms) and the layer-2 overhead (Ethernet 18 B, Ethernet with VLAN 22 B, MPLS 4 B or none). It returns the kbps per call, the trunk total, the packets per second and the on-wire size of each packet, along with a comparison table for every codec.

The math mirrors what is used to size SIP trunks: pps = 1000 / ms, the voice payload is (codec_bitrate / 8) × (ms / 1000) bytes, and each packet adds the RTP + UDP + IP = 40 byte headers (or about 2 bytes with cRTP, the header compression from RFC 2508) plus the layer-2 overhead. Bandwidth per call is (payload + headers) × 8 × pps, and the total is that value multiplied by the number of calls. G.711, G.722, G.726 and G.729 are ITU-T standards; Opus is the codec from RFC 6716.

Example: 10 G.711 calls at 20 ms over Ethernet

At 20 ms per packet there are 1000 / 20 = 50 pps per call, and the G.711 payload (64 kbps) is (64000 / 8) × 0.02 = 160 B.
Headers: RTP+UDP+IP 40 B + Ethernet 18 B = 58 B; each packet is 160 + 58 = 218 B on the wire.
Per call: 218 × 8 × 50 = 87,200 bps ≈ 87.2 kbps. With 10 calls the trunk needs 872 kbps.

Frequently asked questions

Why does a 64 kbps G.711 call consume about 87 kbps?

Because 64 kbps is only the encoded audio. Packetizing it every 20 ms adds 40 bytes of RTP+UDP+IP headers and 18 bytes of Ethernet per packet, 50 times per second. That overhead adds roughly 23 kbps, which is why the real LAN bandwidth is about 87.2 kbps per direction.

How much bandwidth does a G.729 call use?

With G.729 (8 kbps) at 20 ms the payload is only 20 bytes, but the headers are still 58 bytes over Ethernet: the packet ends up at 78 bytes and the call consumes about 31.2 kbps. If you also enable cRTP over an MPLS link, headers drop to 6 bytes and the call falls to about 10.4 kbps.

What happens if I change packetization from 20 to 30 ms?

Each packet carries more voice, so there are fewer packets per second (33 instead of 50) and the header overhead weighs less: G.711 drops from 87.2 to about 79.5 kbps per call. The cost is more packetization latency and more audio lost when a packet drops; 20 ms is the usual sweet spot in IP telephony.

What is cRTP and when should I enable it?

cRTP (RFC 2508) compresses the RTP+UDP+IP headers from 40 bytes down to about 2 bytes per packet. It is used hop by hop on low-bandwidth point-to-point WAN links, where the savings are huge with low-bitrate codecs. It does not apply on a typical Ethernet LAN and does not cross the Internet, because both ends of the link must support it.

Was this tool useful?

Disclaimer

We take great care to keep every tool accurate and review it thoroughly; even so, we can't guarantee it is free of errors or take responsibility for how the results are used. We recommend double-checking anything critical.

Found an error? Let us know →