Troubleshooting · Symptoms
Call Quality Collapses at Peak Hours
The most honest symptom in VoIP: calls are clear at 8am, ragged by 11, fine again after 3. Nothing about the phones changes on that schedule — but the network's load does, and voice, which needs a tiny steady stream, loses every fight against bulk traffic in a full queue. A peak-hours pattern is not a mystery to solve; it is a timetable to match against everything else that runs on a timetable.
This guide is the workflow: prove the correlation, find the elephant, and fix it with scheduling and QoS policy — the two remedies that cost nothing in bandwidth.
The usual elephants (all scheduled, all findable)
- Cloud backup and sync windows: workstation backups, photo/drive sync storms at logon, and a server backup someone set for 'lunch, when it's quiet' — quiet for people, peak for the uplink.
- Operating-system and software update distribution: fleets pulling updates simultaneously mid-morning.
- Guest and neighbor traffic: guest Wi-Fi without rate limits; in shared buildings, a neighbor tenant on shared infrastructure whose peak is your peak.
- Legitimate business peaks: the call center's busiest hour coinciding with everyone's data peak — capacity is genuinely short, and the fix is QoS plus honest sizing.
- ISP-side congestion: oversubscribed cable segments degrade at neighborhood peak times; provable with captures (clean LAN-side, degraded WAN-side) and patience.
Proof before remedies
Peak-hour tickets die in 'we changed something and it seems better'. Replace impressions with three artifacts: (1) a call-quality log — time-stamped examples with jitter/loss from captures or the provider's MOS reports, showing the degradation window; (2) a bandwidth timeline — your router's utilization graph for the same days, uplink especially; (3) a suspect schedule — the backup/sync/update timetables from IT. When the three align, the argument is over and the fix is obvious. When bandwidth is NOT saturated during bad calls, stop and reconsider: you may have a Wi-Fi airtime peak (everyone in the conference rooms at 11) or a provider-side peak — the two-point capture method from the jitter guide separates LAN, WAN-edge and upstream cleanly.
Fix sequence
- Build the three artifacts above for 2–3 bad days before changing anything.
- Move or throttle the elephants: backups and bulk sync to off-hours or rate-limited classes — this resolves the majority of cases outright.
- Enforce QoS at the WAN edge: DSCP-based priority for voice (EF) and signaling (CS3) with a proper queueing policy, verified by markings surviving in captures (see the QoS guide).
- Cap guest/bulk traffic classes during business hours as policy, not per-incident.
- If the WAN itself is the constraint after policy is right (sustained >~70% utilization in peaks), size up the circuit or add the second circuit for voice — now bandwidth is genuinely the answer, and you have the graphs to prove it.
- Re-measure through the same peak window for a week; the quality log should show the degradation window gone, not moved.
Frequently asked questions
- Our MOS dashboard shows bad scores but users don't complain (or vice versa).
- MOS estimates (from loss/jitter/delay models) and perception diverge at the edges — PLC hides loss from listeners while scoring it, and echo annoys users without denting MOS. Trust the pairing: investigate where either signal fires, decide using both.
- Why does only one office suffer at peak?
- Each office has its own uplink, timetable and elephants. The suffering office's backup window or a tenant difference is the norm; compare its bandwidth timeline to a healthy office's before comparing phone settings.
- Can the provider's network be the peak-hour problem?
- Yes — carrier and ISP aggregation peaks exist. Your evidence (clean captures at your WAN edge during bad calls, across days) is what elevates the ticket beyond 'check your network'. Bring graphs, not adjectives.