The VoIP bandwidth calculation every vendor hands you underestimates actual network load by 25% or more, because it treats codec bitrate as the whole picture while ignoring protocol headers, Wi-Fi airtime loss, and the real behavior of Philippine ISP links under congestion.
TL;DR: A G.711 call needs roughly 87.2 Kbps per direction with full protocol overhead, not the 64 Kbps the codec spec promises. Multiply that gap across 50 or 100 concurrent calls on a congested Philippine enterprise link, and you’re short by megabits. Proper call quality budgeting requires calculating total packet size at every protocol layer, measuring real throughput (goodput), and reserving dedicated bandwidth through QoS policy or SD-WAN voice allocation.
Codec Specs Tell You the Wrong Number
Why does VoIP bandwidth calculation break down at the planning stage? Because every vendor datasheet lists codec bitrate in isolation, as if voice packets travel naked across your network. They don’t. Every voice packet carries a stack of protocol headers (IP at 20 bytes, UDP at 8 bytes, RTP at 12 bytes) plus a Layer 2 frame header that varies by transport. Cisco’s voice bandwidth documentation defines the real formula: total packet size equals the L2 header plus the IP/UDP/RTP header plus the voice payload size.
The protocol overhead per packet is 40 bytes minimum for IP/UDP/RTP alone. On Ethernet, add another 18 bytes for the frame header, bringing per-packet overhead to 58 bytes. With G.711’s default 20-millisecond packetization interval, each packet carries a 160-byte voice payload, meaning overhead accounts for 26.6% of every packet’s total size. That overhead percentage climbs sharply with compressed codecs. G.729 sends only 20 bytes of voice payload per packet at its default interval, so the same 58-byte overhead now represents 74.4% of the total packet.
Here’s what that means in actual throughput per call direction, according to Vonage’s bandwidth reference:
| Codec | Codec Bitrate | With IP/UDP/RTP + Ethernet Overhead | Overhead as % of Total |
|---|---|---|---|
| G.711 | 64 Kbps | ~87.2 Kbps | 26.6% |
| G.729 | 8 Kbps | ~31.2 Kbps | 74.4% |
| G.722 | 64 Kbps | ~87.2 Kbps | 26.6% |
| Opus (20ms) | 16-64 Kbps (variable) | ~39.2-87.2 Kbps | varies |
| iLBC (30ms) | 13.3 Kbps | ~29.0 Kbps | 54.1% |
When your SIP trunk provider prefers G.729 for bandwidth savings but your internal IVR or voicemail system only handles G.711, transcoding kicks in and doubles the bandwidth on the internal segment. As Ecosmob’s PBX migration guide warns, mismatched codecs between trunk and endpoint cause “dead air” unless your PBX or session border controller handles transcoding in real time. If you’re selecting codecs for bandwidth-constrained Philippine networks, codec overhead Philippines networks actually experience matters far more than the theoretical bitrate number.
Warning: The AgentCalc VoIP bandwidth calculator defaults to 20 Kbps of overhead per call. That default works for basic estimation, but Ethernet-connected desk phones with G.729 carry closer to 23.2 Kbps of overhead per direction. For 50 concurrent G.729 calls, that 3.2 Kbps difference adds up to 320 Kbps of unaccounted bandwidth, both upstream and downstream.
Philippine Link Conditions Create a Goodput Gap
The second piece of evidence against trusting vendor calculations: real-world Philippine ISP connections deliver substantially less usable throughput than their rated speed. Industry measurements show that Wi-Fi environments lose approximately 25% of available bandwidth to airtime contention, retransmissions, and environmental interference. Wired connections perform better, but Philippine enterprise links from PLDT, Globe, and Converge still contend with shared last-mile infrastructure, peering congestion during business hours (typically 9 AM to 5 PM in Metro Manila), and asymmetric upload speeds that throttle outbound voice streams.
The correct metric for network capacity planning is goodput, defined as actual usable bandwidth minus protocol overhead, retransmissions, and environmental losses. A 100 Mbps fiber line delivering 75 Mbps of goodput during peak hours can theoretically support 860 concurrent G.711 calls (75,000 Kbps divided by 87.2 Kbps per call direction). But that math assumes voice traffic gets 100% of the link. In reality, data traffic from email, CRM applications, cloud ERP, and web browsing competes for the same pipe.
TechTarget’s VoIP budgeting guide states directly: “Failing to include all items will result in an inaccurate voice-over-IP budget.” That guidance extends beyond line items on an invoice. Network capacity planning must inventory every application consuming bandwidth during peak hours, then subtract that from your goodput figure before allocating voice capacity.
Here’s a practical example. A 50-seat BPO operation in Cebu with a 50 Mbps symmetric fiber link might measure 37.5 Mbps of goodput (75% of rated) during peak afternoon hours. If data applications consume 22 Mbps during those peaks, remaining capacity for voice is 15.5 Mbps. With G.711 at 87.2 Kbps bidirectional (174.4 Kbps per call counting both directions), maximum concurrent calls come to 88. With G.729 at 31.2 Kbps bidirectional (62.4 Kbps per call), the ceiling rises to 248 concurrent calls.
Those numbers look comfortable for 50 seats. But they assume zero headroom for traffic spikes, zero packet loss, and zero jitter. Call quality budgeting requires a safety margin. The standard engineering practice is to reserve no more than 33% of available bandwidth for voice, which drops that G.711 ceiling from 88 to 29 concurrent calls and the G.729 ceiling from 248 to 82. Suddenly, 50 agents all on calls simultaneously won’t fit on G.711 without degradation.
A 50 Mbps link that looks generous on paper supports only 29 concurrent G.711 calls once you account for goodput loss, competing data traffic, and the 33% reservation ceiling.
This is why running a VoIP pilot program before full migration catches capacity problems that spreadsheet math misses. And it’s why proper QoS configuration on your routers determines whether those 29 calls actually get clean, low-jitter delivery.
SD-WAN Voice Allocation Changes the Arithmetic
The third piece of evidence: SD-WAN redraws the bandwidth equation entirely by pooling multiple links and applying application-aware traffic policies. The Philippine SD-WAN market is expanding rapidly, with Globe Telecom constructing 116 new sites and upgrading 812 existing sites to LTE in Q1 2024 alone, partly to support SD-WAN overlay deployments. Even the Philippine Bureau of Internal Revenue issued an SD-WAN procurement specification in 2025, signaling government-level adoption of the technology for wide-area connectivity.
SD-WAN voice allocation works differently from static QoS on a single link. Instead of carving a fixed percentage of one connection for voice, SD-WAN platforms (Fortinet, Cisco Viptela, VMware VeloCloud) classify voice packets in real time and route them across whichever available link offers the lowest latency and packet loss at that moment. If your primary PLDT fiber link degrades, SD-WAN shifts voice to a backup Globe connection within milliseconds, without dropping the call.
For Philippine enterprises with branch offices across Metro Manila, Cebu, and Davao, this changes the math fundamentally. Rather than sizing each branch’s single link to handle peak voice load plus data plus a 33% safety margin, you size two or three cheaper links whose aggregate goodput exceeds your requirements. A branch with a 30 Mbps PLDT fiber link (22.5 Mbps goodput) plus a 20 Mbps Globe LTE backup (15 Mbps goodput) gets 37.5 Mbps of aggregate goodput, with automatic failover protecting call quality.
The hybrid SD-WAN and cloud PBX integration pattern that Australian enterprises adopted at 68% rates applies equally to Philippine deployments, though Philippine bandwidth costs per Mbps remain 2x to 3x higher than Australian equivalents, making efficient allocation even more critical.
Tip: When evaluating SD-WAN for voice, test with actual G.729 and G.711 traffic, not synthetic ICMP pings. SD-WAN platforms make routing decisions based on application signatures. Voice packets classified correctly get priority treatment; voice packets misidentified as generic UDP don’t. Verify your SD-WAN vendor’s SIP/RTP classification accuracy during the pilot phase.
The Three-Layer Bandwidth Audit
I’m proposing a framework called the Three-Layer Bandwidth Audit for any Philippine enterprise planning VoIP migration:
Layer 1, Per-Call Packet Math. Calculate true bandwidth per call using the full formula: L2 header plus 40 bytes IP/UDP/RTP overhead plus codec payload, multiplied by packets per second. Don’t trust vendor datasheets listing codec bitrate alone. For G.711 with 20ms packetization on Ethernet, the answer is 87.2 Kbps per direction, or 174.4 Kbps bidirectional per call.
Layer 2, Goodput Measurement. Run 72-hour throughput tests on your actual links during business hours. Measure upload and download separately (Philippine links are often asymmetric). Subtract measured data application consumption. Apply a 25% Wi-Fi penalty for any segment touching wireless. The number you’re left with is your real voice-available bandwidth.
Layer 3, Policy Reservation. Configure QoS marking (DSCP EF for voice media, DSCP CS3 for SIP signaling) or deploy SD-WAN with voice-class traffic policies. Reserve no more than 33% of Layer 2 goodput for voice, giving you your maximum concurrent call ceiling. If that ceiling falls below your peak concurrent call requirement, you need a fatter pipe, a more compressed codec, or both.
For enterprises scaling their IP telephony deployment across multiple branches, run this audit per site. Aggregate numbers hide the weakest link. A site in Davao with a 10 Mbps connection and 7.5 Mbps goodput can only support 14 concurrent G.711 calls after the 33% reservation, even if your Makati headquarters has capacity to spare.
The Claim, Revisited
Vendor bandwidth calculators remain useful as starting points. The Packetizer calculator and AgentCalc tool both produce correct per-call figures when you input the right parameters. The problem is that Philippine IT teams feed them codec bitrate, multiply by headcount, compare against their ISP’s rated speed, and declare the network ready.
That approach ignores 40 bytes of per-packet protocol overhead (raising G.729 from 8 Kbps to 31.2 Kbps, a 290% increase). It ignores the 25% goodput gap between rated and real throughput on Philippine links. It ignores competing data traffic, asymmetric upload speeds, and the 33% reservation ceiling that separates clean voice from jittery, clipped calls. And it ignores the SD-WAN voice allocation patterns that can rescue an undersized single link by pooling multiple connections with application-aware steering.
Run the Three-Layer Bandwidth Audit before you migrate. The codec overhead Philippines networks carry is identical to what any network carries, but the link conditions and ISP realities here amplify every calculation error. A VoIP bandwidth calculation that works on paper fails in production when the paper didn’t account for the real network underneath it.
