The most common bandwidth mistake in call centers is buying more of it to fix a problem that is not bandwidth.
How much you actually need
Voice is a remarkably light application. The numbers surprise people.
| Codec | Per call, per direction | 10 agents | 50 agents |
|---|---|---|---|
| G.711 (ulaw/alaw) | ~87 kbps | 0.9 Mbps | 4.4 Mbps |
| G.729 | ~31 kbps | 0.4 Mbps | 1.6 Mbps |
| Opus (typical) | ~40 kbps | 0.4 Mbps | 2.0 Mbps |
Fifty agents on G.711 need under 5 Mbps in each direction. A modern connection has this many times over.
Where the overhead comes from
G.711 encodes 64 kbps of audio. The wire figure is 87 kbps because every 20 ms packet carries:
Audio payload 160 bytes
RTP header 12 bytes
UDP header 8 bytes
IP header 20 bytes
Ethernet framing 18 bytes
------------------------------
Total 218 bytes × 50 packets/sec × 8 = 87.2 kbpsSmaller packets mean more overhead. Some operators use 30 ms packetisation to reduce it, at a small cost in latency.
Size for peak plus headroom: take your maximum concurrent calls, add 50%, and leave the rest of the connection for everything else the office does.
The three numbers that actually matter
| Metric | Good | Acceptable | Problem |
|---|---|---|---|
| Latency (one-way) | < 100 ms | 100-150 ms | > 150 ms |
| Jitter | < 20 ms | 20-30 ms | > 30 ms |
| Packet loss | 0% | < 1% | > 1% |
Latency is delay. Beyond about 150 ms one-way (ITU-T G.114), people start talking over each other because the natural conversational rhythm breaks. It is the metric agents describe as "the customer keeps interrupting me."
Jitter is variation in packet arrival. Voice needs packets at even intervals; when they arrive irregularly, the jitter buffer either waits (adding latency) or discards them (creating gaps). Jitter produces the robotic, choppy sound.
Packet loss is unrecoverable. TCP retransmits; voice cannot — a packet arriving late is useless. Loss becomes missing syllables.
Testing properly
Speed tests are close to useless for this. They measure throughput on a single TCP stream to a nearby server. You need loss and jitter over time, to the place your calls actually go.
Continuous ping
The simplest useful test — run for at least an hour during peak:
ping -i 0.2 -c 3000 sip.yourprovider.com | tail -3Look at min/avg/max/mdev. mdev is your jitter. A max far above avg means periodic congestion.
MTR — where the problem is
mtr --report --report-cycles 100 sip.yourprovider.comMTR shows loss at each hop. Loss appearing at one hop and continuing to the destination is real. Loss at a single intermediate hop that does not persist downstream is usually just ICMP de-prioritisation, not a genuine fault — a distinction that saves many pointless support tickets.
Under load
Test while the connection is busy. Start a large download, then run the ping test. A connection that is perfect when idle and terrible under load has a bufferbloat problem, fixed with queue management (fq_codel or cake) on the router, not with more bandwidth.
Fixing quality problems
Prioritise voice with QoS
On the office router, mark RTP traffic (DSCP EF, value 46) as highest priority. Without this, one agent's large file download can degrade every call in the building.
Wire everything
Wi-Fi is the single largest source of unexplained call quality complaints. Interference, roaming between access points, and shared airtime all produce exactly the symptoms above, intermittently, which makes them maddening to diagnose. Run Ethernet.
Turn off SIP ALG
Consumer and small-business routers frequently include "SIP ALG," which attempts to rewrite SIP messages passing through NAT. It almost always corrupts them. Disable it. This one setting is responsible for a remarkable share of VoIP failures.
Separate voice and data
If budget allows, a dedicated connection for voice removes the entire class of "someone started a backup and calls broke."
Check the server
Choppy audio can be server-side. On the dialer:
uptime # load average vs core count
free -m # swap in use is a red flag
iostat -x 1 5 # %util near 100 means disk saturation
asterisk -rx "core show channels"Call recording writes constantly. On an undersized VPS with slow storage, disk I/O saturation produces audio artefacts that look exactly like network problems.
Diagnostic table
| Symptom | Likely cause | Check |
|---|---|---|
| One-way audio | NAT or RTP ports blocked | externip, firewall UDP 10000-20000 |
| No audio either way | Codec mismatch | SIP 488; compare allow= lines |
| Choppy / robotic | Jitter | ping mdev; Wi-Fi; QoS |
| Missing syllables | Packet loss | mtr |
| Echo | Acoustic feedback | Headset, not speakerphone; check gain |
| Talking over each other | Latency > 150 ms | ping avg; carrier route |
| Audio dies after ~30 s | NAT keepalive / firewall timeout | qualify=yes, session timers |
| Fine when quiet, bad at peak | Congestion or bufferbloat | Test under load |
| Fine on some destinations only | Carrier route quality | Test alternate route |
| Crackling on one agent only | Headset or USB port | Swap hardware first |
Home-based agent minimums
For remote agents, set a floor and test it before they start:
- 10 Mbps down / 3 Mbps up minimum, wired
- Latency to your server under 100 ms
- Jitter under 20 ms, loss under 0.5%, measured over an hour at their normal working time
- No Wi-Fi, no mobile hotspot, no shared VPN
- UPS if local power is unreliable
Have every remote candidate run a one-hour ping test and send you the output before their first shift. It takes them ten minutes and saves weeks of ambiguous quality disputes.
Where to go next
- VoIP fundamentals: SIP, codecs, and DIDs — the underlying concepts.
- ViciDial installation guide — server-side configuration.
- Work-from-home call center setup — remote agent infrastructure.
Frequently asked questions
How much bandwidth does one VoIP call use?
About 87 kbps in each direction using G.711 with 20 ms packets, once RTP, UDP, IP and Ethernet headers are counted. G.729 reduces this to roughly 31 kbps per direction. Ten simultaneous agents on G.711 therefore need under 1 Mbps each way, which is far less than most people expect.
Why do my calls sound choppy on a fast connection?
Choppy audio is almost always jitter or packet loss, not insufficient bandwidth. A 500 Mbps connection with 60 ms of jitter sounds worse than a stable 10 Mbps line. Common causes are Wi-Fi, an overloaded router, ISP congestion at peak hours, or SIP ALG corrupting packets.
Should call center agents use Wi-Fi?
No. Wi-Fi introduces variable latency and packet loss that degrade voice quality unpredictably, and it is the most common cause of complaints that appear random. Run wired Ethernet to every agent position. It is the cheapest quality improvement available.
What is an acceptable packet loss rate for VoIP?
Below 1 percent is acceptable and generally imperceptible. Between 1 and 3 percent produces noticeable dropouts. Above 3 percent makes conversation difficult. Unlike file transfers, voice cannot retransmit lost packets, so loss translates directly into missing audio.