Intermittent Voice Quality on a Converged WAN
A call center has 300 agents on a single site. Voice runs on a dedicated VLAN over the same WAN circuit as data. Agents report choppy audio during the 10:00-11:00 peak, roughly three times per week, but not every day. The WAN circuit is 100 Mbps and monitoring shows utilization peaks at 92 percent during those windows. QoS is configured with priority queueing for voice, but the data class also has a priority queue configured by a previous engineer. Ping tests from the voice gateway to the carrier edge show 0 percent loss but occasional 180 ms spikes in jitter. The carrier's SLA covers availability but not latency or jitter.
1. Given the symptoms, what is the most likely cause of the choppy audio, and what evidence would confirm it?
Read the worked answer
The most likely cause is contention in the priority queue. Two classes are marked priority: voice and data. Priority queueing is strict; when both classes have traffic, the scheduler serves them according to its implementation, and a burst of priority-marked data can delay voice packets even though voice is nominally protected. The 92 percent peak utilization and the timing correlation with peak hours support congestion-driven delay.
The jitter spikes (180 ms) without packet loss are consistent with queueing delay variation, not with a carrier fault. To confirm: capture queue statistics on the WAN egress interface during a peak window, specifically drop and depth counters per class. If the priority queue depth rises and voice packets experience variable delay while data bursts arrive, the diagnosis holds. Also check whether data is marked priority by an application classification rule; a misclassified bulk transfer (e.g., backup) in the priority class would explain the intermittent pattern.
2. Propose a QoS configuration change and a validation plan.
Read the worked answer
Remove priority from the data class. Keep a single strict-priority queue for voice (EF), cap it (e.g., 10-15 percent of link bandwidth) so voice cannot starve other classes, and give interactive data a bandwidth guarantee rather than priority. Put bulk and backup traffic in a scavenger class with a small minimum and a low ceiling. Classify with DSCP trust boundaries at the access edge; do not trust markings from endpoints.
Validation: before the change, baseline per-class delay and jitter for a week using IP SLA or a probe. After the change, compare during the same peak windows. Success criteria: voice jitter under 30 ms, no priority-queue drops for voice, and data throughput within SLA. Also verify that the cap does not cause voice admission failures; if call volume is near the cap, use call admission control.
Finally, address the carrier SLA gap: negotiate a jitter/latency SLA or add a second path for voice.
3. What should be done about the carrier SLA gap, and how would you present it to management?
Read the worked answer
The SLA covers availability only, so the carrier is not accountable for jitter even though jitter is the user-visible problem. Options: negotiate an SLA addendum with latency and jitter thresholds and credits, or design around the gap by routing voice over a second circuit with diverse path, or by using a managed voice service with end-to-end guarantees.
Present it in business terms: three incidents per week affecting 300 agents, with estimated lost productivity, versus the cost of the SLA addendum or second circuit. Include the measured jitter data and the correlation with peak utilization to show the issue is real and quantified. Recommend the option with the best cost per avoided incident, and note that fixing internal QoS is a prerequisite; otherwise the carrier will point to internal congestion as the cause.