VoIP Bandwidth Calculator
Estimate the bandwidth your VoIP traffic requires based on codec, packetization, concurrent calls, network overhead, and other factors.
Codec bit rate only describes the audio payload. On the wire, every packet also carries fixed headers, so packet overhead can make a significant difference, especially with low-bit-rate codecs. Use this calculator to estimate the actual bandwidth required per call.
Codec calculator
What does one voice stream cost with this codec?
Traffic cost calculator
How much link capacity does this traffic need? The codec and settings from Step 1 carry over. This adds your network framing, encryption and call count, and shows what each deployment scope costs.
Ethernet for LAN and most SIP trunks, PPPoE for broadband access, MPLS for carrier WAN.
When the SBC transcodes, each leg uses a different codec. Leave this on “Same” for pass-through.
Enable if your voice traffic uses SRTP. VPN or IPsec tunnel overhead is not included.
How the number is built
The calculation separates the audio payload from packet overhead. The payload changes with the codec, while the 40 bytes of IP, UDP and RTP headers are added to every packet.
All codecs at your current settings
Per stream, at the IP level. Change any input and this table recalculates.
| Codec | Payload rate | Packets/sec | Per stream (IP level) | Overhead share |
|---|
What this does and does not include
The calculation covers the RTP media stream used to size trunk bandwidth. SIP signaling, RTCP, silence suppression, and Layer 1 framing affect the calculation differently, so each is explained below.
- Headers assume IPv4. IPv6 adds 20 bytes per packet, which is about 8 kbps more per call at 20 ms.
- Results are for one call leg. An SBC that anchors media carries both legs, and with transcoding each leg has its own codec. The traffic calculator’s “both legs” rows account for this.
- Fax and data calls typically switch to G.711 passthrough; size them by selecting G.711. T.38 fax uses UDPTL, not RTP, and is not covered here.
- Multi-rate codecs are shown at one rate. AMR-WB has 9 modes from 6.6 to 23.85 kbps and can change mode during a call. G.726 runs at 16, 24, 32 or 40 kbps. Opus is configurable from about 6 to 510 kbps.
- Opus bitrate and FEC are simplified. Opus normally runs at a variable bitrate, so the figures here are averages and individual packets can be larger. In-band forward error correction (the useinbandfec option) adds a low-bitrate copy of the previous frame to each packet, increasing the bitrate. Neither is modelled.
- Redundancy is excluded. Redundant audio (RED, RFC 2198) repeats previous frames inside each packet, roughly doubling the payload. Stream duplication (RFC 7198) sends every packet twice.
- NAT traversal is not counted. A TURN relay adds bytes per packet and carries twice the traffic on the relay link. Recording or monitoring copies add one stream each.
- SIP signaling is excluded. It is small compared with the media stream and occurs mainly during call setup rather than continuously, so it has little effect on bandwidth capacity.
- RTCP is also excluded. The protocol is designed to use only a small fraction of session bandwidth, so its impact is minimal compared with the media stream.
- Silence suppression (VAD) is modeled here as a flat percentage, but the actual bandwidth reduction depends on your traffic. Hold music, background noise, and conversation patterns can significantly reduce the savings. Use the full bandwidth requirement for capacity planning unless you have measured your own traffic.
- Layer 1 framing adds additional overhead when you are sizing close to the physical capacity of a link. The Ethernet preamble and interframe gap add roughly another 20 bytes per packet, which can matter when only a few percent of capacity remains.
Use peak concurrent calls for sizing. Bandwidth sizing should be based on the number of calls running at the same time during your busiest period. Monthly call minutes do not provide that number. If you do not know your peak concurrent call volume, the SIP trunk sizing calculator can estimate it from call volume and average duration.
Voice traffic also needs proper QoS. Available bandwidth alone does not guarantee good voice quality. Without QoS marking, voice packets can queue behind other traffic and introduce jitter or packet loss even when average link utilisation is well within capacity. If the calculator shows enough bandwidth but call quality is still poor, check how voice traffic is being prioritized.
The SBC is where codecs are negotiated
Bandwidth depends on the codec negotiated on each leg. When your carrier and PBX prefer different codecs, the SBC negotiates each side independently. When transcoding is required, ProSBC handles G.711 variants in software; other codecs need DSP hardware in the path.
For a deeper look at how each codec compares in quality, licensing, and compatibility, see our VoIP codec guide. If you need to work out how many trunks your call volume requires before sizing the bandwidth, the SIP trunk sizing calculator works backwards from call volume and average duration.
Frequently asked questions
Need help sizing your network?
See how ProSBC handles codec negotiation, transcoding, and trunk sizing at the network edge.
By submitting this form, your information will be processed in accordance with our Privacy Policy.
Prefer to get hands-on first? Build a free ProSBC lab and test it yourself.