VoIP Bandwidth Requirements Calculator for SIP Trunks (2027)

Quick Answer: A VoIP bandwidth requirements calculator multiplies your peak number of simultaneous calls by the true on the wire bitrate of your codec, then adds a safety margin. With the common G.711 codec sending 20 ms packets over Ethernet, each call uses 87.2 kbps in each direction, so 10 concurrent calls need about 0.87 Mbps of upload and the same again of download. If you only know call volume, the Erlang B formula turns busy hour traffic into the number of SIP trunk channels you actually need. Add roughly 20% headroom and always size against your upload speed.

Key Points

  • The codec’s advertised rate is only the audio. Every packet also carries 40 bytes of IP, UDP, and RTP headers, which adds 16 kbps per call at 50 packets per second.
  • G.729 squeezes audio eight times smaller than G.711, yet on Ethernet it only cuts per call bandwidth to about a third, because the headers stay the same size.
  • Encryption, VLAN tags, IPv6, and VPN tunnels each add bytes to every packet, so a calculator that ignores them will undersize your link.
  • Most call quality problems come from latency, jitter, and packet loss, not raw bandwidth. Cisco’s design targets are under 150 ms one way delay, under 30 ms jitter, and under 1% loss.
  • Silence suppression can lower average traffic, but size the circuit as if everyone talks the whole time.

How Does a VoIP Bandwidth Calculator Work?

A VoIP bandwidth calculator works by adding the voice payload, the protocol headers, and the link layer framing for one packet, multiplying by packets per second, then multiplying by concurrent calls. The three inputs that matter most are the codec, the packetization interval, and your peak simultaneous calls.

The formula behind nearly every tool, including the figures people expect from a Cisco bandwidth calculator, comes from Cisco’s published per call reference:

Bandwidth per call = (payload bytes + 40 header bytes + link layer bytes) × 8 × packets per second

For G.711 at 20 ms, the payload is 160 bytes, the IP/UDP/RTP headers are 40 bytes, and Ethernet adds 18 bytes. That is 218 bytes, sent 50 times a second, which works out to 87.2 kbps. Because a phone call is full duplex, that rate flows in both directions at once.

What most articles miss is that “per direction” matters. Cable and DSL plans usually offer far less upload than download, so upload is the ceiling you hit first.

G.711 Codec Bandwidth Compared With Other Codecs

G.711 codec bandwidth is 64 kbps of audio but 87.2 kbps on an Ethernet link at 20 ms packetization, while G.729 needs 31.2 kbps under the same conditions. The codec you choose is the single biggest lever on total bandwidth.

CodecAudio bitratePacket intervalPer call on Ethernet (each direction)Typical use
G.711 (PCMU/PCMA)64 kbps20 ms87.2 kbpsDefault for most SIP trunks; toll quality
G.72264 kbps20 ms87.2 kbpsHD (wideband) voice between compatible phones
G.72632 kbps20 ms55.2 kbpsOlder compressed links
iLBC15.2 kbps20 ms38.4 kbpsLossy networks
G.7298 kbps20 ms31.2 kbpsBandwidth limited WAN links
G.723.16.3 kbps30 ms21.9 kbpsVery low bandwidth, rare today
Opus at 32 kbps32 kbps20 ms55.2 kbpsWebRTC, softphones, apps

Opus is flexible: the IETF standard (RFC 6716) allows 6 kbps to 510 kbps, usually at a variable bitrate. For planning, use the highest bitrate your platform is configured for.

In practice, G.711 is the safe choice when bandwidth is plentiful, since almost every carrier supports it. Reach for G.729 only when the link is genuinely tight, and avoid transcoding between codecs, which degrades quality.

What Adds Hidden Overhead to VoIP Bandwidth?

Hidden VoIP overhead comes from anything that adds bytes to every packet: VLAN tags, PPPoE, IPv6, SRTP encryption, and VPN tunnels. Because a call sends 50 packets per second at 20 ms, every extra byte costs 0.4 kbps per call, per direction.

FactorExtra bytes per packetApproximate added kbps per call (20 ms)
802.1Q VLAN tag41.6
PPPoE (DSL)83.2
IPv6 instead of IPv4208
SRTP with 80 bit authentication tag104
IPsec tunnelaround 60 (varies with cipher and padding)about 24
cRTP header compressionsaves 36 to 38saves about 15 (serial WAN links only)

Cisco notes that compressed RTP shrinks the 40 byte header to 2 or 4 bytes, but it is not available on Ethernet. That is why cRTP shows up in older WAN guides and almost never helps a modern office internet connection.

Most people discover the VPN effect the hard way: a remote worker on a full tunnel VPN can push a G.711 call from 87 kbps to over 100 kbps.

How to Calculate VoIP Bandwidth Step by Step

To calculate VoIP bandwidth, find your peak concurrent calls, multiply by the per call rate for your codec and network, then add headroom. Here is the full process for a typical small business.

  1. Find your codec. Ask your SIP trunk or hosted VoIP provider which codec they use. Many providers default to G.711.
  2. Pick the per call rate. Use the codec table above, then add any overhead from the second table.
  3. Estimate peak concurrent calls. Pull the highest number of simultaneous calls from your phone system’s reports, or estimate it with Erlang B (next section).
  4. Multiply. Peak calls × per call rate gives the minimum bandwidth in each direction.
  5. Add headroom. Many providers and calculators plan for about 20% extra to cover bursts and signaling.
  6. Compare against your upload speed, and leave room for everything else the office does online.

Worked example: 15 peak calls on G.711 with SRTP over Ethernet. The per call rate is 87.2 + 4 = 91.2 kbps. Fifteen calls need 1,368 kbps, and with 20% headroom that becomes about 1.64 Mbps up and 1.64 Mbps down, reserved for voice.

Concurrent Call Calculator: Using Erlang B to Size SIP Trunks

An Erlang B calculator converts your busiest hour of calling into the number of trunk channels you need for a chosen blocking rate, usually 1%. It answers the question a plain bandwidth calculator cannot: how many calls will actually overlap.

An Erlang is one hour of continuous call traffic. You calculate busy hour traffic like this:

Erlangs = calls in the busy hour × average call length in minutes ÷ 60

North American telecom reports sometimes use CCS instead; 1 Erlang equals 36 CCS.

Say a 40 person office averages 160 calls in its busiest hour, each lasting 3 minutes. That is 160 × 3 ÷ 60 = 8 Erlangs. Running 8 Erlangs through the Erlang B formula shows that 15 channels hold blocking just under 1%, meaning fewer than 1 in 100 callers hits a busy signal. So this office needs a SIP trunk with 15 channels and about 1.3 Mbps of G.711 bandwidth before headroom.

Here’s the trust note. Erlang B assumes blocked calls simply disappear and do not queue or retry. That fits a business phone line well, but a call center where callers wait on hold should use Erlang C instead, because queued calls change the math.

SIP Trunk Bandwidth Calculator: Quick Reference Table

This SIP trunk calculator table shows bandwidth per direction for common call counts, including 20% headroom, over Ethernet at 20 ms.

Concurrent callsG.711 (87.2 kbps)G.729 (31.2 kbps)
50.52 Mbps0.19 Mbps
101.05 Mbps0.37 Mbps
252.62 Mbps0.94 Mbps
505.23 Mbps1.87 Mbps
10010.46 Mbps3.74 Mbps

Add 10% to 15% on top if your calls are encrypted or run through a VPN.

Does a Longer Packet Interval or Silence Suppression Save Bandwidth?

Yes, both reduce bandwidth, but each comes with a trade off that makes it risky to rely on for sizing.

Moving G.711 from 20 ms to 40 ms packets halves the packet rate, which drops the Ethernet rate from 87.2 kbps to 75.6 kbps. The cost is extra delay, because each packet now waits for 40 ms of audio before it leaves. ITU recommendation G.114 notes that most applications are not significantly affected below 150 ms of one way delay, and every millisecond spent on packetization eats into that budget.

Silence suppression, also called voice activity detection, stops sending packets during pauses. It lowers average traffic, yet a busy morning with everyone talking can still spike to full rate. Size the circuit for full activity and treat any savings as a bonus.

Why Do VoIP Calls Sound Bad on a Fast Connection?

VoIP calls sound bad on fast connections because voice suffers from delay, jitter, and packet loss long before it runs out of bandwidth. A 500 Mbps line with no traffic prioritization can still drop words when someone starts a large upload.

When you actually use VoIP on a shared office network, three fixes matter more than buying a faster plan:

  • Quality of Service (QoS): Mark voice packets with DSCP value 46 (Expedited Forwarding) and configure your router to send them first.
  • Wired phones where possible: WiFi adds variable delay, which shows up as jitter.
  • Bufferbloat control: Smart queue management on the router keeps uploads from filling buffers and delaying voice.

The mechanism is simple: voice uses UDP, so lost packets are never resent, and a late packet is as useless as a missing one.

FAQ

What is a good internet speed for VoIP?

A good speed is one where your upload covers your peak calls plus headroom and still leaves room for normal work. For most small offices that is a few Mbps of upload reserved for voice. Stability matters more than headline speed.

Is VoIP bandwidth the same for upload and download?

Yes. A call sends and receives audio at the same rate at the same time, so each call uses identical bandwidth in both directions.

How many VoIP calls can a 10 Mbps connection handle?

With 10 Mbps of upload, roughly 114 G.711 calls fit in theory. After 20% headroom and other traffic, plan on far fewer, often around 90 or less if the line is shared.

Does SIP signaling use much bandwidth?

No. SIP messages travel only when a call starts, changes, or ends. The audio stream (RTP) accounts for almost all voice traffic.

What is the difference between a SIP trunk channel and a concurrent call?

They mean the same thing in practice. One channel carries one active call, inbound or outbound, so a 10 channel trunk supports 10 simultaneous calls.

Do video calls use the same bandwidth as voice?

No. Video uses many times more bandwidth than a voice call. Size video separately using the requirements published by your meeting platform.

Does HD voice need more bandwidth?

G.722, the most common HD voice codec, uses the same 64 kbps audio rate as G.711. You get wideband sound with no extra bandwidth.

Should I use G.729 to save bandwidth?

Only if your link is truly constrained. It saves about two thirds of the bandwidth but lowers audio quality, and some providers do not support it.

What blocking rate should I use in an Erlang calculator?

A 1% grade of service (P.01) is the common business standard. Some businesses choose 0.1% for lines where a busy signal is costly, such as emergency or sales lines.

Does Erlang B work for call centers?

Not well. Call centers queue callers instead of blocking them, so Erlang C, which models waiting time, gives more accurate staffing and trunk numbers.

Can a speed test tell me if my network is ready for VoIP?

Partly. A speed test shows capacity, but you also need a VoIP quality test that measures jitter and packet loss over several minutes, ideally during your busiest hours.

Does cRTP help on a normal office internet connection?

Usually not. Cisco documents that compressed RTP is not available over Ethernet, so it mainly helped older serial and Frame Relay WAN links.

Do I need a separate internet line for VoIP?

Not always. A single line with proper QoS often works well for small offices. A dedicated circuit makes sense when your data traffic regularly saturates the link.

Conclusion

Getting VoIP bandwidth right comes down to three numbers: your real per call rate including overhead, your peak simultaneous calls, and a sensible margin on top. Measure peaks from your phone system reports when you can, use Erlang B when you can’t, and keep upload speed at the center of every decision. Before you change plans, run a VoIP quality test on your network, compare providers with our business phone system guide, and review how QoS settings protect call quality.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *