The question behind this page is usually 'will VoIP work on my internet connection?' The honest answer: almost certainly yes on raw capacity, and possibly not on consistency. A single call consumes less bandwidth than a music stream. What voice cannot tolerate is variable delay, bursts of loss, or a router that mangles SIP traffic. This guide covers the numbers to check, in the order they usually cause trouble.
Two framing points before the numbers. First, voice is symmetric: your microphone audio goes up the same access link that downloads use, so the upload direction matters exactly as much as the download direction, and on asymmetric plans (cable, DSL, some fixed wireless) upload is the scarce side. Second, voice is real-time: a packet that arrives 200 ms late is as useless as one that never arrives, so averages matter less than worst-case behavior during your busiest hour.
Bandwidth per concurrent call
Per-call bandwidth is set by the codec plus packet overhead. G.711, the PSTN-compatible default, produces a 64 kbit/s audio payload. Each 20 ms of audio then travels in its own packet with RTP, UDP, and IP headers (40 bytes at 50 packets per second adds about 16 kbit/s), plus link-layer framing. The practical planning figure for G.711 is roughly 85-100 kbit/s per direction, per call. Compressed codecs cost less: Opus for voice typically runs 16-40 kbit/s of payload (call it 35-60 kbit/s with overhead), and G.729 runs 8 kbit/s of payload (roughly 30-40 kbit/s with overhead).
| Codec | Audio payload | Planning figure per direction | Notes |
|---|---|---|---|
| G.711 (PCMU/PCMA) | 64 kbit/s | ~85-100 kbit/s | Default at the PSTN border. No license cost, no compression artifacts. |
| Opus | 6-40 kbit/s (voice modes) | ~30-60 kbit/s | Default in WebRTC. Adapts bitrate to conditions; supports wideband. |
| G.729 | 8 kbit/s | ~30-40 kbit/s | Legacy low-bandwidth choice. Narrowband only; tandem transcoding degrades it. |
| G.722 | 48-64 kbit/s | ~85-100 kbit/s | Wideband at G.711-class bandwidth. Common on SIP desk phones. |
These numbers are why capacity alone rarely blocks VoIP: a 10 Mbit/s uplink can theoretically carry a hundred G.711 calls. The catch is the word 'theoretically.' Voice packets share that uplink with backups, cloud sync, video meetings, and whatever else the office does, and voice loses politely: it does not retransmit, it just sounds bad.
Latency, jitter, and loss targets
Three metrics predict whether a network can carry voice well. They are covered in depth in call quality; the working targets are worth memorizing.
| Metric | Target | Symptom when exceeded |
|---|---|---|
| One-way latency (mouth to ear) | Under ~150 ms (ITU-T G.114 guidance); conversation degrades noticeably past ~250-300 ms | Talk-over and doubled starts: both parties speak at once, then both stop. Conversations turn into walkie-talkie exchanges. |
| Jitter (variation in packet arrival) | Under ~30 ms | Robotic, warbled, or stretched audio as the jitter buffer discards late packets or slews playback. High jitter also forces a larger buffer, which adds latency. |
| Packet loss | Under ~1%, and not in bursts | Dropouts, clipped syllables, missing words. Concealment hides isolated single-packet loss; a burst of 3-4 consecutive lost packets is audible on any codec. |
The receiver absorbs jitter with a jitter buffer: it holds packets briefly so they can be played at a steady rate even if they arrived unevenly. Adaptive buffers grow when jitter rises and shrink when it settles. The buffer is a trade: every millisecond of buffering is a millisecond added to one-way latency, so a network with 80 ms of jitter cannot be fixed by buffering without breaking the latency budget. The fix for high jitter is the network, not the endpoint.
Why Wi-Fi is the usual culprit
When a call sounds fine on a wired desk phone and bad on a laptop in the same room, the Wi-Fi hop is the difference. Wi-Fi is a shared, half-duplex medium with retransmission at the radio layer: contention with other devices, microwave and Bluetooth interference on 2.4 GHz, and distant clients transmitting at slow rates all show up as jitter and burst loss on everyone else's packets. Roaming makes it worse: when a laptop or phone hands off between access points mid-call, many client and AP combinations drop or delay packets for hundreds of milliseconds, which is a full audible gap.
- Prefer wired Ethernet for fixed positions: desk phones, reception, anyone on calls all day.
- On Wi-Fi, prefer 5 GHz (or 6 GHz) over 2.4 GHz: more channels, less interference, faster airtime per packet.
- Enable WMM (Wi-Fi Multimedia) so voice frames get radio-level priority; it is on by default on most business APs.
- Check AP density and roaming: a site survey matters more than router marketing. 802.11k/v/r assisted roaming reduces handoff gaps when clients support it.
- Keep one slow client in mind: a single device at the edge of range consumes disproportionate airtime and raises jitter for the whole cell.
QoS: marking and the upstream bottleneck
Quality of Service only matters where packets queue, and packets queue at the slowest link, which for most offices is the upload side of the internet connection. That is where QoS must act. The standard marking for voice media is DSCP EF (Expedited Forwarding, decimal 46) on RTP packets, with signaling often marked CS3 or AF31. Endpoints and PBXs usually mark correctly by default; the question is whether anything honors the marks.
- On the LAN: managed switches and APs can honor DSCP so voice is not stuck behind a file transfer. On an uncongested gigabit LAN this rarely matters.
- At the router: configure the upstream shaper (SQM, fq_codel, or the vendor's QoS feature) to your real uplink rate, slightly below the provisioned speed, and prioritize EF traffic. Without shaping, the queue forms invisibly in the ISP modem where you cannot control it.
- Across the internet: DSCP marks are usually ignored or stripped past your ISP. QoS protects your own bottleneck; it cannot fix the far side or the middle.
SIP ALG, NAT, and firewalls
Consumer and small-business routers often ship with a SIP ALG (Application Layer Gateway) enabled. The ALG rewrites SIP headers as they pass through NAT, in theory to help. In practice ALG implementations are a leading cause of one-way audio, calls that drop at exactly 30 seconds or 15 minutes, phones that unregister randomly, and inbound calls that never ring. Modern providers handle NAT properly on their side, so the ALG only interferes. The standing recommendation from nearly every VoIP vendor is to disable SIP ALG.
The correct NAT traversal machinery lives at the endpoints and the provider: STUN lets a client discover its public address, TURN relays media when a direct path is impossible (mandatory planning for WebRTC on strict networks), and registration keep-alives (small packets every 15-60 seconds) hold the NAT pinhole open so inbound calls can reach a phone behind the firewall. Firewall rules should allow outbound SIP (usually TLS on 5061 or UDP/TCP 5060) and the provider's published RTP port range, and should not rate-limit or inspect that traffic aggressively.
Concurrent-call math for an office
Sizing is multiplication, not mystery. Estimate peak concurrent calls (not headcount: a 40-person office rarely has 40 simultaneous calls; 25-35% of seats on calls at peak is a common planning ratio for general offices, higher for contact centers). Multiply by the per-call planning figure for your codec, then compare against the uplink after subtracting everything else the uplink carries at the same hour.
- Peak concurrent calls: for example, 12 for a 40-person office.
- Per-call figure: 100 kbit/s (G.711, conservative).
- Voice budget: 12 × 100 kbit/s = 1.2 Mbit/s each direction.
- Headroom: keep voice under about a third of the uplink so bursts from other traffic do not queue voice. 1.2 Mbit/s of voice wants roughly 4-5 Mbit/s of clean uplink, or strict QoS on a smaller one.
- Recheck after growth, new video-meeting habits, or moving backups into business hours.
How to test before switching
Test the path you will actually use, toward the region where the provider's media servers live, during your busiest hours. A speed test proves capacity; it says nothing about jitter or sustained loss, which are what break calls.
- Run a continuous ping (or better, a UDP-based test) to the provider's recommended test host for 15-30 minutes during peak: watch for jitter above ~30 ms, loss above ~1%, or periodic latency spikes.
- Use the provider's own pre-qualification test if offered: these typically simulate RTP streams and report a MOS estimate per concurrent-call count.
- Test from the real network segment: the Wi-Fi the laptops use, the VLAN the phones will use, not just a wired port next to the router.
- Repeat while the network is loaded: start a large upload during the test and confirm latency stays flat. If ping times balloon during an upload, fix upstream QoS (bufferbloat) before deploying phones.
- Test failover if voice is critical: what do latency and loss look like on the backup connection? See VoIP reliability.
A network that passes these tests will carry VoIP without drama. A network that fails them will generate quality tickets no matter which provider or codec sits on top of it.