How much bandwidth does a VoIP call use?

A VoIP call uses bandwidth in two layers: the digitized audio itself, and the network packaging that wraps around it. A codec turns your voice into a digital stream at a set bitrate, 64 kbps for the standard G.711 codec or 8 kbps for the compressed G.729.[3][5] That stream is sliced into small packets, usually holding 20 milliseconds of audio each, and every packet gets a 40-byte header so the network knows where to send it.[1][7] Because a device sends 50 of those packets every second at the 20 millisecond interval, the headers alone add about 16 kbps in each direction, which is why the number you actually provision is always higher than the codec's raw bitrate.[1][7]

The payload is only part of the number

The audio payload sets the floor, not the total. A G.711 call carries 64 kbps of voice, but once you add the 40 bytes of IP, UDP, and RTP headers on every packet plus the framing the physical link adds, the call consumes roughly 87 kbps in each direction over Ethernet.[1][11] The same math hits a compressed codec harder in relative terms, because G.729 sends only 8 kbps of audio yet the fixed header cost pushes each call to about 31 kbps, so the eight-to-one compression ratio shrinks to closer to three-to-one on the wire.[1][2]

A call runs in both directions

Every figure so far describes one direction of audio. A phone call is full duplex, meaning both people can talk at once, so a live conversation carries a stream each way and you double the one-direction number to size the whole call.[9] A G.711 call that reads as 87 kbps per direction therefore occupies close to 174 kbps of total capacity while it is connected, split evenly between the upload and download sides.[1][9]

G.711 is the codec most business phone systems default to, and it consumes about 87 kbps in each direction per call.[1][11] It digitizes voice with pulse code modulation at 64 kbps and applies almost no compression, so the audio matches the quality of a traditional landline, which keeps it the common choice on networks that have bandwidth to spare.[3] The overhead is the reason the call needs 87 kbps rather than 64: 50 packets per second, each carrying 160 bytes of audio and 40 bytes of headers plus Ethernet framing, work out to roughly 87 kbps once multiplied through.[1] For most office connections that cost is easy to absorb, and the payoff is audio that sounds clean without the artifacts heavier compression can introduce. G.711 also handles fax tones and analog signaling more reliably than compressed codecs, so it is often kept in place for fax lines and alarm circuits even where regular voice moves to something lighter.[2]

G.722 uses about the same bandwidth as G.711, near 87 kbps per direction, but spends it on a wider slice of the audio spectrum to produce high-definition voice.[4][11] Where narrowband codecs carry frequencies up to roughly 3.4 kHz, G.722 encodes up to about 7 kHz within the same 64 kbps envelope, so speech sounds fuller and consonants are easier to make out, which matters most on conference calls with several people talking.[4][8] The bandwidth cost is effectively a wash against G.711, so the choice between them is about audio quality and endpoint support rather than saving capacity. Many IP desk phones and softphones support G.722, and a call only uses it when both ends agree to it during setup, so a wideband call between two compatible devices falls back to narrowband the moment it reaches a device or carrier that does not offer it.[8]

G.729 shrinks a call to about 31 kbps in each direction, roughly a third of what G.711 needs, by compressing the audio down to an 8 kbps payload.[2][5] It models speech with a technique called conjugate-structure algebraic-code-excited linear prediction rather than sampling it directly, which trades a small amount of fidelity for a large saving on the audio portion of the call.[5] The saving is real but smaller than the raw codec numbers suggest, because the 40-byte header on every packet does not compress along with the audio: an eight-to-one payload ratio becomes closer to three-to-one once headers are counted, so G.729 delivers meaningful relief only on links where bandwidth is genuinely tight.[1][2] It tends to fit branch offices on slower connections, high-density call centers packing many simultaneous calls onto one circuit, and older WAN links, and it is worth confirming any licensing terms your platform attaches to it before you standardize on it.

Opus does not have one fixed bandwidth figure, because it adjusts its bitrate to the network in real time, ranging from 6 kbps for low-quality narrowband speech up to 510 kbps for high-fidelity stereo.[6] For a typical voice call it settles in the tens of kilobits per second, often around 24 to 40 kbps for wideband speech, and it can drop lower when a connection degrades so the call stays up rather than failing.[6][8] That adaptability is why most modern softphones, browser-based calling tools, and cloud platforms use Opus or a similar variable codec instead of a fixed one. Microsoft Teams is a useful reference point: for one-to-one audio it lists 10 kbps as the minimum, 58 kbps as the recommended bitrate, and 76 kbps for best performance, each measured per endpoint in each direction.[10] The practical effect is that a cloud call often uses less bandwidth than a G.711 call while sounding better, since the codec spends its bits on audio quality rather than on fixed overhead.

The codec sets the baseline, but a handful of other factors move the real per-call figure up or down, sometimes enough to matter when you are sizing a link.

Packet size and packet rate

Smaller packets mean lower delay but more overhead, because each packet carries the same 40-byte header no matter how little audio is inside it.[7][12] The common 20 millisecond interval produces 50 packets per second; stretching it to 30 or 40 milliseconds sends fewer, larger packets and trims the header overhead, at the cost of a little added latency and the fact that any lost packet then removes more speech.[12] Most systems stay near 20 milliseconds because it balances the two reasonably well.

The fixed header tax

Every packet carries 40 bytes of IP, UDP, and RTP headers, and the physical link adds its own framing on top, around 18 bytes for Ethernet.[1][7] That overhead is constant regardless of codec, so it weighs far more heavily on a compressed call than a raw one: the same 16 kbps of header cost is trivial next to G.711's 64 kbps of audio but larger than G.729's entire 8 kbps payload.[1] It is the single reason no codec ever uses only its advertised bitrate on a real network.

Two-way audio

A conversation is full duplex, so the capacity a call occupies is double the one-direction figure, split between upload and download.[9] Sizing only for the download side understates the need, and on connections where upload is slower than download, the upload side is usually what limits how many calls fit.[13]

Encryption

Encrypting the media and signaling, now standard on business systems, adds a small amount of per-packet overhead on top of the codec and headers.[12] The increase is modest for a single call, but it is worth including in the margin when you plan capacity for many calls at once.

A practical way to size a connection is to multiply your peak number of simultaneous calls by about 100 kbps in each direction, then add headroom.[11][13] The 100 kbps figure is deliberately higher than any single codec needs, because it leaves room for headers, the occasional retransmission, and normal fluctuation, so you are not sizing to the theoretical floor.[9]

Working the numbers

For a team that might have 20 calls active at once, that formula points to roughly 2 Mbps of dedicated capacity in each direction for voice, before any other traffic.[13] A useful sanity check on the load is data volume rather than rate: an hour on a G.711 call moves on the order of 600 MB, while the same hour on G.729 moves closer to 220 MB, which is why compressed codecs still matter on metered or capped links.[9] Because voice is symmetric, plan the upload side with the same care as the download, since residential and many business broadband plans give far less upload, and that is where call quality tends to break first under load.[11][13]

Bandwidth alone does not guarantee a clean call

Having enough capacity is necessary but not sufficient, because voice is sensitive to how packets arrive, not just how many fit.[13] Even with plenty of raw speed, a call degrades when packets arrive at uneven intervals, a problem called jitter, or when some packets are lost outright, and high latency adds delay of its own.[13] Prioritizing voice with quality-of-service settings and reserving capacity for it usually does more for call quality than simply buying a bigger connection.[11] The compression trade-off runs the same way, because a codec like G.729 saves bandwidth but gives up some audio fidelity, so it earns its place on constrained links and adds little on a connection that can comfortably carry G.711 or a wideband codec.[2]