What is network bandwidth in my VoIP setup?

Calls clip or sound robotic during uploads. The real limit is not magic. It is bandwidth and how I protect it.

Network bandwidth is the maximum data rate on my links. VoIP uses small, steady streams. I must size for simultaneous calls, add overhead, leave headroom, and protect voice with QoS.

Bandwidth alone is not the full story. Delay, jitter, and loss turn small gaps into big problems. Good design keeps voice first. The rest fits around it. Now let us break it down and do the math.

How much bandwidth do SIP calls and video need per user?

People ask, “How many calls fit on my line?” The answer depends on codec, packet size, and overhead. The numbers are simple and practical.

Per-call bandwidth = codec payload + IP/UDP/RTP + L2/VPN overhead. With 20 ms packets: G.711 ≈ 80–90 kbps one way, G.729 ≈ 24–32 kbps, Opus wideband ≈ 32–50 kbps.

Dive deeper Paragraph:

Why payload is not the full rate

A codec’s bitrate (like 64 kbps for G.711) is only the audio payload. Each packet also carries IP, the User Datagram Protocol (UDP) ¹, and the Real-time Transport Protocol (RTP) ² headers (40 bytes). Layer-2 adds more (Ethernet ~18 bytes). VPNs add 5–50+ bytes. Packetization interval (ptime) changes how often I send those headers. Short ptime sends more packets per second. That raises overhead and bandwidth but lowers mouth-to-ear delay. Long ptime saves bandwidth but raises delay and loss risk.

If you want the canonical specs behind the planning numbers, start with the G.711 PCM recommendation ³ and the Opus wideband codec RFC ⁴.

Quick reference table (20 ms ptime, typical LAN/WAN, one way)

These ranges include common Layer-2 and IP header costs. They vary with VLAN tags, PPPoE, GRE/IPsec, or SRTP.

Packetization and its trade-offs

• 10 ms ptime: Higher bandwidth. Lower latency. Better PLC. More packets, more CPU.
• 20 ms ptime: Good balance for most SIP trunks.
• 40 ms ptime: Lower bandwidth. Higher delay. More damage when a packet drops. Use with care.

Video and screen share (rough planning, per stream)

Capacity formula I use

• Total per direction ≈ concurrent external call legs × per-call kbps
• Add headroom: +20–30% for bursts, FEC, and codec swings
• Remember symmetry: voice is per direction; size uplink and downlink separately

Example: 20 calls on Opus ~45 kbps one way → 20 × 45 = 900 kbps. Add 30% = 1.17 Mbps. I reserve ≥1.2–1.5 Mbps each way for clean margin.

How do I measure my available upload and download bandwidth?

Guessing leads to surprise. Measure real sustained rates, not only speed test peaks. Measure when staff works, not at midnight.

Run multi-minute tests for up and down. Watch sustained throughput, latency under load, and jitter. Verify at peak hours. Then log interface rates on edge devices.

Dive deeper Paragraph:

What to test, and why it matters

A short speed burst hides bufferbloat. I care about steady throughput with latency under load. So I use tests that saturate the link for 1–3 minutes and record RTT and jitter during the run. I test both directions because uplink is usually the choke point for VoIP. I repeat during busy hours. I save results over time to catch slowdowns or ISP shaping.

Tools and signals to collect

• Interface counters on the router or firewall: bits per second, errors, drops.
• Latency under load (ping during upload): if RTT jumps by 100+ ms, calls may clip.
• Jitter and loss: these reveal queuing stress, not just line rate.
• 95th percentile throughput: good for planning recurring peaks.
• MOS or R-factor from active probes: reflects real call quality, not only bandwidth.

A simple test plan

Where tests go wrong

• Testing from Wi-Fi instead of wired.
• Testing during off hours only.
• Ignoring VPN overhead.
• Using a single stream when ISP favors speed test CDNs.
• Skipping long enough runs to fill buffers.

When results swing, I check for background syncs, cloud backups, software updates, and camera uploads. Those kill uplinks first.

Will low bandwidth cause jitter, choppy audio, or dropped calls?

Low bandwidth alone is not always the culprit. Unmanaged queues cause delay spikes and loss. That sounds like jitter and chop.

When the uplink saturates, packets queue and drop. Jitter rises. RTP arrives late or not at all. A small call stream suffers, even though it needs only tens of kbps.

Dive deeper Paragraph:

The real enemy is congestion and bufferbloat

Voice packets are tiny but frequent. Bulk transfers like backups and video chunks fill queues. Without smart queuing, RTP waits behind large packets. That adds variable delay (jitter). Jitter buffers hide small swings, but when spikes exceed the buffer, playout gaps appear. Listeners hear robots, repeats, or silence. If queues overflow, loss climbs. PLC and FEC help a little, but they cannot recover long bursts.

Symptoms and quick checks

Practical thresholds I aim for

• Uplink reserve: keep 20–30% free headroom.
• Jitter (p95): < 20 ms wired, < 30 ms Wi-Fi/Internet.
• Loss: < 0.3% average, zero bursts > 100 ms.
• One-way latency: < 150 ms end-to-end for clean conversation.

What not to expect from jitter buffers

A bigger buffer does not create bandwidth. It only smooths arrival times at the cost of extra delay. Beyond ~150–200 ms one way, conversation suffers even with perfect audio frames. If I must increase buffers to survive, I then fix the congestion root cause.

How can I prioritize VoIP bandwidth with QoS, VLANs, and codecs?

Voice wins when I mark it, queue it right, and keep paths short. I also choose codecs that fit my links and users.

Mark RTP EF (DSCP 46). Put voice in a strict low-latency queue. Shape bulk traffic below line rate with FQ-CoDel/PIE. Use a voice VLAN. Pick Opus or G.711 per site.

Dive deeper Paragraph:

QoS: marking and queuing that actually works

Set phones, PBX, and SBC to mark DiffServ Expedited Forwarding (EF, DSCP 46) ⁵ for RTP and CS3/AF31 for SIP signaling. On switches and routers, trust only the ports that connect to known devices. Rewrite at the edge for everything else. Place EF into a strict priority or low-latency queue with a small buffer. Cap other classes so EF never starves. On small links, enable Smart Queue Management like FQ-CoDel smart queue management ⁶. Set an egress shaper a bit below the ISP rate (for example, at 95–98%). This prevents the ISP’s big buffer from adding delay.

VLANs and clean paths

Use a voice VLAN for phones. This reduces broadcast noise and gives phones a separate DHCP scope with options for provisioning. Keep PoE phones on wired where possible. If Wi-Fi is required, use 5 or 6 GHz, 20 MHz channels, -67 dBm minimum RSSI, and enable Wi-Fi Multimedia (WMM) ⁷ mapping for voice. Limit clients per AP to protect airtime.

Codec choices for each site

Avoid frequent transcoding. Keep end-to-end codec the same across trunks and phones. Transcoding adds delay and artifacts.

VPNs, tunnels, and MTU

Tunnels add overhead. Budget +5–20% per call. Clamp MSS to avoid fragmentation. Verify DSCP preservation through the tunnel. If the VPN cannot preserve EF, prioritize by port and flow on the outer header.

A simple deployment checklist

With these steps, voice keeps flowing even when someone uploads large files. Calls stay clear. Complaints drop.

Conclusion

Size calls with overhead, keep 20–30% headroom, and protect RTP with QoS and clean VLANs. Pick codecs to fit links. Measure often and adjust.

Footnotes