Keep one-way delay under 150 ms and never past 400 ms, hold jitter under 30 ms and packet loss under 5%, and keep round-trip time under 500 ms, per industry guidance. None of it holds unless you apply one rule: mark voice consistently and give it priority queuing at every hop, end to end.
TL;DR:
- For Teams, mark audio ports 50000–50019 as EF, DSCP 46, and video ports 50020–50039 as DSCP 34; keep signaling separate.
- Route real time media directly to the provider rather than through a VPN, which can add latency, jitter, and fragmentation; verify markings at every hop.
- Record a baseline, then compare ingress and egress captures with queue counters; Teams telemetry is limited for PSTN and individual calls.
QoS does not create bandwidth. As Cisco’s voice-quality guidance explains, it manages and prioritises the traffic you already have. In practice, you do four jobs on routers and switches:
The telephony service class needs low jitter and low loss, not high throughput. That is why a fast link still drops calls: a micro-burst from a file sync fills a queue for a few milliseconds, and voice packets arriving in that window are lost. Priority queuing lets voice skip that line.
Use these figures as acceptance criteria and as alert thresholds in your monitoring.
ITU-T G.114 sets 150 ms as the one-way delay target for high-quality voice, and treats anything above 400 ms as unacceptable for general network planning. Delays between the two figures are workable only with good echo control.
The same industry benchmarks that give the jitter, loss and round-trip numbers above also map to what callers hear:
Timing is the root problem. VoIP is sensitive to packet order and arrival time, and ITU-T guidance is why strict classification at the edge matters so much.
Plan per-call bandwidth from the codec, then add headers. As an illustration, G.711 carries about 64 kbps of payload plus roughly 16 kbps of IP, UDP and RTP headers, so budget about 80 kbps per call each way. Treat that as a planning figure, not a measurement of your network.
Several settings move that number:
On constrained links, use call admission control (CAC). Rejecting the call that would oversubscribe the priority queue is far better than degrading every call already in progress.
RFC 4594 recommends the EF (Expedited Forwarding) per-hop behaviour for the telephony service class, with marking and policing at ingress so voice stays inside its negotiated bounds. Mark voice media as EF (DSCP 46) and give signalling a different value, so signalling does not crowd the priority queue.
Microsoft Teams gives a concrete example:
Do both where you can. Endpoint marking is precise but easy for a device or policy to lose, while port-based ACL tagging on the router catches whatever arrives unmarked. On the WAN egress, put voice in a Low Latency Queue (LLQ) with a policer, so the priority class cannot grow without limit.
Pro Tip: Cisco’s DSCP policy documentation shows how to map DSCP to CoS in class maps and policy maps, so copy that structure rather than inventing your own.
QoS fails at the one hop that ignores it, and applying it only at the endpoints or only in the core is not enough. Work through the path in this order:
Pro Tip: Capture on both sides of each device that might rewrite DSCP. A mismatch between ingress and egress points straight at the culprit.
Combine active and passive methods. Place test calls and synthetic RTP streams across the same paths users take, and watch real traffic with NetFlow and packet captures. Then match symptoms to causes:
Record a baseline before any change. Without it, you cannot show that a fix worked.
We run these audits using the operating discipline we apply to our work. Our order is always the same: measure first, fix classification and edge configuration next, then tune queues and bandwidth. Call-quality complaints can trace back to markings lost at a device, as well as to a lack of capacity. Buying bandwidth before checking that is a costly guess.
— Geeshan
If voice quality is slipping and you would rather not chase it hop by hop, we can audit your network end to end, then implement and manage the fix. That covers classification, marking, queue design and ongoing monitoring against the targets above, as part of our Managed IT Services. If you need a one-time review or extra hands, our IT support services cover ad-hoc and co-managed work. You can also read how our cloud VoIP service is delivered, or see our guide to migrating to VoIP. Ask us for a network readiness assessment and we will schedule it.
G.711 carries about 64 kbps of payload plus roughly 16 kbps of headers, so budget about 80 kbps per call each way. Multiply by your peak concurrent calls, then add headroom for other traffic.
Voice needs one-way delay under 150 ms, low jitter and low loss. Mark it EF and give it priority queuing at every hop.
VoIP depends on your network. Congestion, packet loss or misconfigured QoS can degrade VoIP calls, which is why classification and queuing matter.
You need endpoints (IP phones or softphone clients), switches and routers that honour DSCP, and a provider connection. Check that each device keeps markings intact.
%20(1).avif){kind=logo}
%201.avif)
