How much bandwidth does VoIP need?

A G.711 call is 64 kilobits a second. That is the number in every codec table, and it is not what the call costs on your connection. The real figure is 87.2 kilobits a second in each direction, and the extra 23.2 is headers: the addressing and sequencing that has to travel with every packet of audio.

Twenty-three kilobits does not sound like much until you multiply it. Eight people on the phone at once is 186 kilobits a second of pure overhead, and the whole conversation set is 0.70 megabits a second going out at the same time as it goes in. If your upload is the 10 megabits a business connection often comes with, that is seven percent of it, before anybody sends an email.

This article is where those numbers come from, and, just as importantly, what they cannot tell you.

A codec turns speech into bits at a fixed rate. G.711 does it at 64 kilobits a second, G.729 at 8. Those rates describe the audio and nothing else.

To get that audio across a network it has to be cut into packets, and every packet needs headers so the far end knows what it is, where it goes and where it sits in the sequence:

That is 58 bytes on every single packet. The critical word is every: headers are charged per packet, not per second, so how many packets you send decides how much you pay.

A G.711 call at the usual setting sends 50 packets a second, each carrying 20 milliseconds of audio. Twenty milliseconds of G.711 is 160 bytes. So each packet is 160 + 58 = 218 bytes, and:

218 bytes x 8 bits x 50 packets/s = 87,200 bits/s

Eighty-seven point two kilobits a second, of which 64 is voice and 23.2 is not.

Packet length is the one number in this arithmetic that people change without realising what it does.

Cut the packets to 10 milliseconds and you send 100 a second instead of 50. The audio is identical. The overhead doubles, and the call goes from 87.2 to 110.4 kilobits a second. Go the other way to 30 milliseconds and it drops to 79.5.

Twenty milliseconds is what nearly everything ships with and there is rarely a reason to move it. Shorter packets lose less audio when one goes missing, which matters on a network that loses packets, and cost you a third more capacity for the privilege. Longer packets are cheaper and leave a bigger gap when one is lost.

All figures below are one call, one direction, on Ethernet, with the headers counted:

Look at the bottom two rows. G.729 compresses the audio to an eighth of G.711 and only cuts the bandwidth by two thirds, because the 58 bytes of header per packet do not compress with it. The lower you push the codec rate, the larger a share of the call is overhead: on G.723.1 more than two thirds of what you send is not audio at all.

These come from Cisco's per-call bandwidth documentation, which publishes the whole table and the header sizes behind it. Our VoIP bandwidth calculator reproduces every row of it and shows the arithmetic beside each figure, so you can check it rather than take our word for it.

A conversation sends one audio stream each way, so the upload and download requirements are exactly the same size. This is the part that surprises people, because almost nothing else on an office network works that way.

What is not the same is what you were sold. A typical business connection carries several times more coming in than going out. So the same 0.70 megabits a second is a rounding error on a 150 megabit download and a real bite out of a 10 megabit upload, and it is the upload that sets the ceiling on how many calls can be up at once.

Work out your busiest moment, not your average. The relevant number is not how many calls you take in a day; it is the most that are up at the same time, which for a small team is usually just the number of people who answer. If you are not sure what that number should be, how many people do you need to answer calls works it out from your call volume.

Here is the honest limit of everything above.

The arithmetic tells you how much room the calls would take on a link with nothing else on it. It says nothing about whether your connection will actually carry them well, because what ruins a phone call is usually not a shortage of capacity. It is delay, variation in that delay, and packets that arrive late or not at all. A connection with room to spare can still produce calls that break up, and a connection advertised at the same speed as somebody else's can behave completely differently under load.

Nor would a quick measurement settle it. A test tells you about the route it took, on the device it ran on, at the minute it ran. It cannot promise the same result on a different laptop, on Wi-Fi rather than a cable, or at your busiest hour on a Tuesday afternoon. Treat any tool that hands you a green badge saying your network is ready for calls as telling you something it cannot know.

What is worth doing:

1. Size on the upload, at the busiest moment, with room above it. If the calls want 0.7 megabits, do not plan on having 0.8 free.
2. Put the phones on a cable where you can. Wi-Fi is where most small-office call quality problems actually live, and it is the cheapest variable to remove.
3. Check the real thing after you switch, on the connection you have, at the hour you are busy. That is the measurement worth having, and it is the only one that describes your network rather than a model of it.

Our own pricing is per seat and the minutes are included, so what a Ringfully plan costs does not change with how much bandwidth your calls use. We mention it only because the question "will my internet handle this" and the question "what will this cost" get asked together, and they have completely different answers.

Once the capacity question is settled, the part that decides whether a caller has a good experience is what happens after the call arrives: who it reaches, what they hear if nobody is free, and how it gets handed to the right person. That is what happens once a call is answered, and no amount of bandwidth substitutes for it.