Kilobytes to Kilobits Converter for VoIP Bandwidth

Turning a Speech Codec's Byte Rate Into Call Bandwidth

Every voice codec has a byte rate: the bytes of encoded audio it emits per second. Every circuit, SIP trunk and access link, meanwhile, is sold in bits per second. Sizing a voice deployment means moving constantly between the two, because the codec table in a PBX manual and the capacity figure on a carrier order form are never written in the same unit. Multiplying by eight is where a per-call bandwidth budget starts.

Factor: Kb = KB × 8, because one byte is eight bits. G.711 emits 8 KB/s of encoded audio, so 8 × 8 = 64 kbps of payload — the familiar 64 kbps figure that a single toll-quality voice channel has carried since the days of the digital trunk.

Payload Is Only Part of the Bill

Each packet carries an RTP, UDP and IPv4 header — 12 + 8 + 20 = 40 bytes. At 50 packets per second that is 16 kbps of headers on top of the payload, and Ethernet framing adds another 18 bytes per frame, or 7.2 kbps. A 64 kbps G.711 stream therefore occupies roughly 87.2 kbps on a switched LAN.

Packetisation Interval Sets the Overhead

The standard 20 ms interval means 50 packets per second. Drop to 10 ms and you double the packet rate: header cost jumps from 16 kbps to 32 kbps while the payload is unchanged. Move to 40 ms and headers fall to 8 kbps, at the price of extra one-way delay and a chunkier loss when a packet goes missing.

Two Directions per Conversation

A call is a pair of one-way streams, each carrying its own payload and its own headers. Per-call figures are normally quoted one way, so an access link that must carry 30 concurrent G.711 calls needs about 2.6 Mbps in each direction — and it is the upstream side that usually runs out first.

Compression Shrinks Payload, Not Headers

G.729 squeezes the payload to one eighth of G.711 — 1 KB/s against 8 KB/s. On the wire the saving is far smaller, because the 40-byte header rides on every packet regardless: 31.2 kbps against 87.2 kbps is a ratio of about 2.8 to 1, not 8 to 1.

Sizing One Call, Then the Trunk

Start from the codec's byte rate

Enter the encoder output in KB per second — 8 for G.711 or G.722, 4 for G.726 at 32 kbps, 1 for G.729. A comma or a dot works as the decimal separator and spaces are ignored, which helps when pasting from a vendor table.

Read the payload bitrate

The kilobit figure appears as you type. Treat it as payload only: it is the number in the codec specification, before RTP, UDP, IP and link-layer framing are added by the network.

Check what one packet looks like

G.711 at 20 ms puts 160 bytes of audio in each packet. Pick bytes and bits in the searchable dropdowns to see that as 1 280 bits, then compare it against the 40 bytes of header riding alongside — the clearest way to see why small payloads are expensive.

Swap when the spec sheet leads with bits

Trunk capacity and carrier quotes arrive in kbps, while capacity planners and traffic captures often work in bytes per second. Press swap to run kilobits back into kilobytes, or copy either field as bare digits into your sizing sheet.

Codec Payload Rates and What They Cost on the Wire

The table converts each codec's encoded byte rate into a payload bitrate, then shows the same call once network headers are counted. The IP column adds the 40-byte RTP/UDP/IP header at 50 packets per second; the Ethernet column adds the further 18 bytes of frame header and checksum. Figures are per direction.

Codec	Encoder output	Payload bitrate	With RTP/UDP/IP	On Ethernet
G.711 (A-law / µ-law)	8 KB/s	64 kbps	80 kbps	87.2 kbps
G.722 wideband	8 KB/s	64 kbps	80 kbps	87.2 kbps
G.726 ADPCM at 32 kbps	4 KB/s	32 kbps	48 kbps	55.2 kbps
Opus, wideband speech setting	4 KB/s	32 kbps	48 kbps	55.2 kbps
Opus, constrained narrowband	3 KB/s	24 kbps	40 kbps	47.2 kbps
G.729	1 KB/s	8 kbps	24 kbps	31.2 kbps

Read across a row and the sizing falls out. A 10 Mbps uplink dedicated to voice carries about 114 concurrent G.711 calls at 87.2 kbps each, or roughly 320 G.729 calls at 31.2 kbps — but only if signalling, jitter-buffer margin and everything else on the link have been accounted for separately. Header compression on a point-to-point circuit can shrink the 40-byte header to a handful of bytes and claw back most of that 16 kbps, which is why the same codec is quoted at very different rates in different documents.

Per-second and per-packet in one place

Because both fields take input, you can size a whole second of audio and then a single 20 ms frame without opening a second calculator.

Bit and byte units side by side

The searchable dropdowns hold kilobits, kilobytes, megabits and megabytes, so a per-call figure and a trunk capacity can be compared without changing pages.

Paste-ready numbers for a capacity sheet

Each field's copy button gives the bare number with no unit or spacing, which drops cleanly into the cell of a bandwidth spreadsheet or a change record.

Fine-grained results for low-rate codecs

Output keeps up to eight decimals, so fractional byte rates from variable-bitrate encoders stay precise instead of being rounded into a whole kilobit.

Call Bandwidth Questions

Why does a 64 kbps codec consume around 87 kbps of my access link?

The 64 kbps is payload alone. Voice is sent in small, frequent packets, and every one of them carries a 12-byte RTP header, an 8-byte UDP header and a 20-byte IPv4 header. At 50 packets per second those 40 bytes cost 16 kbps, taking the stream to 80 kbps at the IP layer. Ethernet then adds its own 18 bytes per frame — another 7.2 kbps — for about 87.2 kbps. On links with additional encapsulation the figure climbs further still.

How many simultaneous calls fit on a 10 Mbps circuit?

Divide the usable capacity by the per-call wire rate: 10 000 kbps ÷ 87.2 kbps gives about 114 G.711 calls, or roughly 320 with G.729 at 31.2 kbps. Never plan to the ceiling, though. Leave headroom for signalling, for data traffic sharing the link, and for the burstiness that causes jitter long before the link is genuinely full.

Would a 40 ms packetisation interval save meaningful bandwidth?

It halves the header cost: 25 packets per second instead of 50 means 8 kbps of RTP/UDP/IP rather than 16, plus 3.6 kbps of Ethernet framing rather than 7.2, so a G.711 call drops from about 87.2 kbps to 75.6 kbps. The trade is delay and loss behaviour — each packet now holds 40 ms of speech, adding to the delay budget, and one lost packet removes twice as much audio.

Does G.729 really use one eighth of the bandwidth of G.711?

Only in the payload. G.729 encodes 20 bytes per 20 ms frame against G.711's 160, so the audio itself really is eight times smaller. On the wire the header is identical for both, so the comparison becomes 31.2 kbps against 87.2 kbps — about 2.8 to 1. Weigh that against the cost: G.729 is narrowband and licensed on many platforms, and stacking it with transcoding or a second low-rate leg degrades quality noticeably.

Should a trunk be sized for both directions of every call?

Yes. Voice is symmetric, so a G.711 call needs about 87.2 kbps upstream and the same downstream, and silence suppression is unreliable enough that most designs ignore any saving from it. On an asymmetric access line the upstream direction is the constraint: plenty of download capacity with a modest upload ceiling runs out of room for outbound audio first, heard as choppy speech at the far end.

Kilobytes to Kilobits