Per-call and total Layer-2 kbps for any codec, packetization, header, and overhead combination — matched to Cisco's published values.
The Voice Bandwidth Calculator gives you the Layer-2 per-call bandwidth for any combination of codec, packetization period, transport header, and overhead option — including cRTP compression, SRTP authentication, and Voice Activity Detection. Multiply by your concurrent calls and you have the WAN capacity you actually need, not the codec bitrate marketing number. Use it for MPLS CE sizing, branch internet sizing for SIP trunks, SD-WAN policy design, and QoS LLQ bandwidth reservations. Formulas match Cisco's VoIP Per-Call Bandwidth Consumption document and the values you'll see in CVDs.
Fill in the form and click Calculate — per-call and total kbps appear here.
The per-call number × concurrent calls is the priority kbps you configure inside your LLQ class. Round up to the next 8 kbps and add a 10% overhead buffer for retransmissions.
Voice should take at most 33% of a WAN link. If the tool says you need 1.7 Mbps of voice, provision a 5 Mbps circuit minimum to leave room for data, video, and control-plane traffic.
VAD suppresses silence during a call — typical savings 30–40%. Don't rely on it for your worst-case plan. Size for no-VAD; use VAD savings as headroom, not capacity.
Layer-2 per-call bandwidth comes from a single formula: BW = (payload + L3 header + L2 header) × 8 × packets_per_second. Everything else is just plugging in numbers. For a G.711 call at 20 ms packetization over Ethernet: the codec emits 64 kbps, so 20 ms of audio is 64,000 × 0.02 / 8 = 160 bytes of payload. Add the RTP header (12 B), UDP (8 B), and IPv4 (20 B) for 40 bytes of L3 header. Add Ethernet (14 B header + 4 B FCS) for another 18 bytes. Total packet = 160 + 40 + 18 = 218 bytes = 1,744 bits. The call sends one of those every 20 ms, so 50 packets per second × 1,744 bits = 87,200 bits per second = 87.2 kbps. That matches Cisco's published value exactly, and it's the number to use for QoS LLQ reservations.
G.729 is the one codec people most often get wrong. The raw codec bitrate is 8 kbps, so a 20 ms packet carries only 20 bytes of payload — but the 40-byte IP/UDP/RTP header is unchanged. That's why the overhead ratio is crushing: 87% of a G.729 packet is header. Enable cRTP on a WAN link and the header compresses to 2 bytes, taking G.729 from 31.2 kbps to 11.6 kbps over PPP. That's a 63% saving — worth the CPU on slow links, not worth it over gigabit.
Packetization period (the ptime in SDP) is a tradeoff: longer packets mean less overhead but more audio lost per dropped packet. 20 ms is Cisco's default and the right answer for almost every deployment. 30 ms shows up on satellite and very high-latency links; 10 ms on low-latency trading floors. Avoid 40+ ms unless you've profiled voice quality — one lost packet = 40 ms of gap, which listeners do notice.
SRTP adds a 4-byte authentication tag per packet and approximately 4 bytes of SRTCP overhead every 5 seconds. In practice, add 4 bytes per packet to the L3 size — on a 20 ms call that's 1.6 kbps extra. It's worth having in the calculation if you're sizing a circuit close to capacity. VAD and header compression are the two knobs that make a real difference; SRTP is always on in any security-conscious deployment and just sits as a constant overhead.
For ATM the math is different. ATM sends fixed 53-byte cells. The AAL5 layer fragments your IP packet into 48-byte chunks (with an 8-byte trailer), and each 48-byte chunk gets a 5-byte ATM header. So a 218-byte Ethernet frame becomes ceil((218 + 8) / 48) = 5 cells × 53 bytes = 265 bytes on the wire — roughly 22% more than Ethernet for G.711, and 40%+ more for G.729. The tool handles this cell-tax automatically when you pick ATM. ATM is rare on modern networks but still shows up on legacy branch DSL and some healthcare environments.
64 kbps is the raw codec bitrate. 87.2 kbps is the Layer-2 per-call consumption on Ethernet after adding the 40-byte IP/UDP/RTP header and the 18-byte Ethernet + FCS header every 20 ms. That overhead is what your WAN actually carries, so it's the number to use for capacity planning.
cRTP compresses the 40-byte IP/UDP/RTP header to 2–4 bytes, cutting G.729 bandwidth from 31.2 to about 11.6 kbps on PPP. It matters on slow or expensive WAN links. On Ethernet and gigabit WAN, enabling cRTP rarely justifies the CPU cost.
SRTP adds a 4-byte authentication tag per packet — roughly 1.6 kbps extra on top of a 20 ms G.711 call. The tool adds this automatically when you toggle SRTP.
This tool sizes RTP audio only. SIP signalling is bursty and averages 1–3 kbps per active call — factor it as 2 kbps per concurrent call for sizing. Video goes in our Video Bandwidth Calculator.
Concurrent calls is what your WAN sees. If you only have BHCA (busy-hour call attempts), convert with: concurrent = BHCA × avg-call-duration / 3600. For a 3-minute average handle time and 800 BHCA: 800 × 180 / 3600 = 40 concurrent.
We assume a fixed 40 kbps Opus rate (Webex default for wideband voice). Opus actually ranges 6–510 kbps depending on mode — for a tight estimate, run the calc at 40 kbps for normal calls and 64 kbps for music-on-hold or conferencing.
Mid-size branch, Ethernet hand-off, SRTP on, no cRTP, no VAD.
Legacy branch over a 1.5 Mbps T1, PPP encapsulation, cRTP enabled.
Cloud contact center over internet, Opus not available, 400 concurrent at peak.
The Network & UC Health Assessment is a written, independent review of your actual environment — not vendor marketing. Includes per-site voice bandwidth sizing, QoS LLQ policy review, and SD-WAN policy alignment with voice priorities.