The number everybody quotes for a phone call is the codec's rate: 64 kilobits a second for G.711, 8 for G.729. Neither is what the call costs on a wire. Every packet also carries an RTP header, a UDP header, an IP header and a layer 2 header, and those are charged on every packet rather than on every second, so the smaller you cut the packets the more overhead you pay. A G.711 call in 20 millisecond packets on Ethernet is 87.2 kilobits a second, not 64. About a quarter of it is not voice.
Work out your own
What turns speech into bits. The rate in brackets is the codec's own rate, and it is not what the call costs on a wire.
Shorter packets mean more packets a second, and the headers are charged on every one of them. 20 ms is the usual setting.
Takes 40 bytes a packet down to 2. It is a technique for a point-to-point link between two routers, so do not assume it on an ordinary internet connection.
Not calls a day. The most that are up at once, which for a small team is usually the number of people who answer.
Optional, and nothing is guessed. Leave either one blank and this tool says nothing about it.
Your numbers stay in your browser. Nothing is uploaded and nothing is stored.
What the calls ask for
- Upload the calls need
- 0.35 Mbps
- Download the calls need
- 0.35 Mbps
- One call, each direction
- 87.2 kbit/s
- The codec's own rate
- 64 kbit/s
- Headers, per call each direction
- 23.2 kbit/s
- Share of the wire that is voice
- 73.4%
- Packets a second, per call
- 50
- Voice in one packet
- 160 bytes
- Headers on one packet
- 58 bytes
- One packet on the wire
- 218 bytes (1,744 bits)
The two directions are the same size, because a conversation sends one stream each way. They are listed separately because almost nobody buys a link with the same speed in both directions, and it is the upload that runs out first.
This is arithmetic on a published standard. Nothing here has touched your network, and a calculation cannot tell you whether your connection is good enough. It tells you how much room the calls would take on a link with nothing else on it.
What this does not do
This page does not test anything. It sends no packets, opens no connection and measures no delay, jitter or loss. People searching for a VoIP test usually want a verdict on their connection, and this is not that. It is the other half of the question: how much room the calls need, worked out from a published standard, with the arithmetic shown so you can check it.
Capacity is not quality. A link with plenty of room can still produce calls that break up, because what ruins a phone call is usually not the quantity of bandwidth. It is delay, variation in that delay, and packets that arrive late or not at all. Two connections advertising the same speed behave completely differently once something else on the network starts using them.
The figures are a floor, on an empty link. They describe the audio and nothing else: no call setup, no video, no screen sharing, and none of the rest of what an office does with its connection at the same time. Treat the answer as the minimum the calls would need if they had the line to themselves, and leave room above it.
And a short measurement would not settle it either. Even a real test would only ever describe the route it took, the device it ran on and the minute it ran in. It could not promise the same result on a different laptop, on the office Wi-Fi rather than a cable, or at your busiest hour on a Tuesday. Anybody offering a green badge that says your network is fine for calls is telling you something they cannot know.
Where the numbers come from
The method is Cisco's, and so are the header sizes. IP, UDP and RTP together are 40 bytes per packet, or 2 where compressed RTP is in use on a point-to-point link. Below that sits a layer 2 header whose size depends on what is carrying the packet: 18 bytes on Ethernet, including the four-byte frame check sequence, and 7 bytes on Multilink PPP or FRF.12, which is a six-byte header plus the one-byte end-of-frame flag.
From there it is three lines. Add the layer 2 header, the IP, UDP and RTP headers and the voice payload to get the size of one packet. Divide a thousand by the packetisation interval in milliseconds to get how many of those go out every second. Multiply the packet size in bits by the packet rate, and that is one call, one direction.
A calculator that is wrong by one header byte still returns an entirely plausible number, so the only useful claim is one you can check. The table below is the codec table the source publishes, and beside each published figure is what this page computes from the sizes above. The same comparison is a set of assertions in npm run check:bandwidth, so the table cannot quietly stop being true.
| Codec | Audio per packet | Voice payload | Packets a second | MP or FRF.12 | With cRTP | Ethernet |
|---|---|---|---|---|---|---|
| G.711 (64 Kbps) | 20 ms | 160 / 160 bytes | 50 / 50 | 82.8 / 82.8 | 67.6 / 67.6 | 87.2 / 87.2 |
| G.729 (8 Kbps) | 20 ms | 20 / 20 bytes | 50 / 50 | 26.8 / 26.8 | 11.6 / 11.6 | 31.2 / 31.2 |
| G.723.1 (6.3 Kbps) | 30 ms | 24 / 24 bytes | 33.3 / 33.3 | 18.9 / 18.9 | 8.8 / 8.8 | 21.9 / 21.9 |
| G.723.1 (5.3 Kbps) | 30 ms | 20 / 20 bytes | 33.3 / 33.3 | 17.9 / 17.9 | 7.7 / 7.7 | 20.8 / 20.8 |
| G.726 (32 Kbps) | 20 ms | 80 / 80 bytes | 50 / 50 | 50.8 / 50.8 | 35.6 / 35.6 | 55.2 / 55.2 |
| G.726 (24 Kbps) | 20 ms | not printed / 60 bytes | 50 / 50 | 42.8 / 42.8 | 27.6 / 27.6 | 47.2 / 47.2 |
| G.728 (16 Kbps) | 30 ms | 60 / 60 bytes | 33.3 / 33.3 | 28.5 / 28.5 | 18.4 / 18.4 | 31.5 / 31.5 |
| G722_64k (64 Kbps) | 20 ms | 160 / 160 bytes | 50 / 50 | 82.8 / 82.8 | 67.6 / 67.6 | 87.2 / 87.2 |
| iLBC mode 20 (15.2 Kbps) | 20 ms | 38 / 38 bytes | 50 / 50 | 34 / 34 | 18.8 / 18.8 | 38.4 / 38.4 |
| iLBC mode 30 (13.33 Kbps) | 30 ms | 50 / 50 bytes | 33.3 / 33.3 | 25.867 / 25.867 | 15.73 / 15.73 | 28.8 / 28.8 |
Source: Voice Over IP: Per Call Bandwidth Consumption, Cisco, read 2026-09-07. The source leaves the voice-payload cell blank on the G.726 24 Kbps row; the figure beside it is derived from that codec's own frame size, and its three published bandwidth cells are what confirm it. The evidence note behind this table is docs/seo/tools/bandwidth-evidence.md.
The worked example, step by step
The source prints one calculation in full: a G.729 call with compressed headers over Multilink PPP. Six bytes of layer 2 header, two bytes of compressed IP, UDP and RTP, and a twenty-byte voice payload come to 28 bytes, which is 224 bits. At 50 packets a second that is 11.2 kilobits a second per call. This page reproduces every line of it, not only the answer, because a check on the last number alone passes for an implementation that reached it by the wrong route.
One thing worth knowing about that example: it adds the six-byte header and leaves out the one-byte end-of-frame flag the same page lists separately, while every cell of its own table counts both. So the example comes to 11.2 kilobits a second and the table's corresponding cell says 11.6. Both are reproduced above and both are asserted by the check script. Picking one and calling the source self-consistent would have been the easy thing to do and the wrong one.
How it works underneath
A packet holds a whole number of codec frames, which is why the payload is not simply the bit rate multiplied by the time. G.723.1 at 6.3 kilobits a second over 30 milliseconds works out at 23.625 bytes; the codec emits a 24-byte frame, and that is what goes in the packet. Rounding the shortcut would put this page two rows out of step with the standard it claims to reproduce, and the check script has an assertion whose only job is to fail the day somebody tries it.
That is also why the packet length is a list rather than a free-text box. A codec with a 30 millisecond frame cannot fill a 20 millisecond packet, so the tool offers only the lengths the chosen codec can actually produce, and changing the codec moves the length to its nearest offered value rather than showing you an error for a choice you did not make.
Upload and download are reported as two lines even though the two numbers are identical. A conversation sends one stream each way, so they always will be. The reason to keep them apart is that hardly anybody buys a connection with the same speed in both directions, so the same requirement is a small fraction of the download and a large one of the upload, and it is the upload that sets the ceiling on how many calls can be up at once.
Absurd input is named rather than answered. Zero calls has an arithmetic answer, and printing “0 kilobits a second” under a heading that reads “what the calls ask for” would be true and useless. A packetisation interval of zero is infinitely many packets a second, and the honest form of that is a sentence rather than a number. Neither ever reaches the screen as a figure.
All of it runs in your browser, in a few dozen floating-point operations. There is no endpoint behind this page, no upload, and no request to anything: what codecs you are considering and how many calls your business runs are none of ours.
Questions
How much bandwidth does a VoIP call need?
On an ordinary office network, a G.711 call in 20 millisecond packets asks for about 87 kilobits a second in each direction, and a G.729 call asks for about 31. Those are the figures with the headers counted, which is why they are higher than the 64 and 8 the codecs are named after. Multiply by the number of calls that are up at the same time, and remember that you need that much going out as well as coming in.
Why is a G.711 call 87 Kbps and not 64?
Because 64 kilobits a second is the rate the codec turns speech into bits at, and the call also has to carry headers. Every packet gets 12 bytes of RTP, 8 of UDP and 20 of IP, plus a layer 2 header that depends on what the packet is travelling over: 18 bytes on Ethernet. At 50 packets a second that is 58 extra bytes fifty times over, which is 23.2 kilobits a second of overhead on top of the 64. About a quarter of what the call uses is not voice.
Does this test my internet connection?
No. Nothing on this page touches your network. It is arithmetic on a published standard, and it tells you how much room a given number of calls would take on a link with nothing else on it. Whether your connection actually carries them well depends on delay, on how steady that delay is, on how many packets go missing and on what else is using the line at four in the afternoon, and none of those are things a calculation can know.
Is upload or download the one that runs out?
Upload, almost always. A conversation sends one stream in each direction, so the two requirements are identical in size. What is not identical is what you bought: a typical business connection carries far less going out than coming in, so the upload figure is the one that becomes the ceiling on how many calls can be up at once. Size against the upload and the download takes care of itself.
What packet length should I use?
20 milliseconds unless something in your setup says otherwise, which is the default nearly everything ships with. The trade is straightforward: shorter packets add less delay if one goes missing, and cost more, because the headers are charged on every packet rather than on every second. Halving the packet length from 20 milliseconds to 10 doubles the overhead. Going the other way to 30 saves bandwidth and gives you a bigger gap in the audio when a packet is lost.
How many calls will my connection carry?
Divide your upload speed by the per-call figure and you have an arithmetic answer, which the worksheet above will give you. Treat it as a ceiling and not a plan. Voice shares the line with everything else in the building, and a call that has just enough room when nothing else is happening is a call that breaks up when somebody starts a large upload. Leave room, and check the real thing after you switch rather than trusting a number from before.
Once you know the number
Capacity is the easy half. What decides whether a caller has a good experience is what happens to the call after it arrives: who it reaches, what they hear while they wait, and where it goes when nobody is free. If you are working out whether your connection is ready for a move, the reasoning is in how much bandwidth VoIP needs, and we are happy to look at your situation with you.