QoS for VoIP — How to Actually Configure It End to End
Quality of Service is one of the most consistently misunderstood parts of VoIP deployments. Engineers either over-engineer it into a multi-tier policy nightmare, or skip it entirely on the assumption that “the network is fast enough.” Both approaches generate support tickets.
The reality is simpler: QoS is about protecting voice traffic during congestion. It doesn’t create bandwidth, fix a bad ISP, or compensate for a poorly designed wireless network. What it does is ensure that when a circuit gets busy, voice packets move first and everything else waits. That single behavior is what separates consistent call quality from the kind that prompts users to say “Teams sounds terrible.”
This guide covers end-to-end QoS configuration for VoIP environments using Cisco IOS. For the Teams-specific configuration — enabling QoS in the Teams Admin Center, DSCP policies for endpoints, and Group Policy/Intune deployment — see Teams Calling QoS — Network Requirements for Production Voice Quality. That article and this one together cover the full stack.
What QoS Actually Does
Before touching configuration, it’s worth being clear on what QoS can and can’t fix.
QoS does not: increase bandwidth, fix packet loss from a damaged circuit, repair a congested ISP handoff, or compensate for a poorly designed wireless network.
QoS does: prioritize voice packets over competing traffic during congestion, reduce jitter by keeping voice in a dedicated queue, and make call quality consistent and predictable under load.
Without QoS, VoIP traffic competes equally with everything else on the network. A large file transfer, a backup job hitting the WAN, or a software update pushing out to endpoints can all degrade call quality — not because the network is broken, but because voice packets are waiting in line behind bulk data. QoS creates a carpool lane for voice so that congestion affects lower-priority traffic first.
The Three VoIP Problems QoS Solves
Latency is the delay between one party speaking and the other hearing it. At low levels it’s imperceptible. Beyond 150ms one-way it makes conversation feel stilted. Beyond 300ms people start talking over each other. QoS reduces the variable component of latency — the part caused by packets waiting in queues — by ensuring voice packets don’t wait.
Jitter is inconsistent packet arrival timing. VoIP codecs expect packets at regular intervals. When packets arrive in bursts instead of steadily, the audio output stutters, clips, or sounds robotic. A jitter buffer can absorb some variation, but large or unpredictable jitter overwhelms it. QoS keeps voice in a priority queue where arrival timing stays consistent.
Packet loss means voice packets that were dropped rather than delivered. Any packet loss in a VoIP stream is audible — missing syllables, broken words, or sudden silence. QoS prevents loss from competing traffic by processing voice packets before the queue reaches the drop threshold.
DSCP Markings for VoIP
DSCP values are the labels that tell network devices how to treat a packet. Voice traffic should always be marked DSCP 46 — Expedited Forwarding (EF) — which is the highest-priority class in the DSCP model and the standard for voice across virtually all QoS implementations.
For Microsoft Teams deployments specifically, Microsoft recommends three separate DSCP classes:
| Traffic Type | DSCP Value | Class |
|---|---|---|
| Audio (voice) | 46 | EF — Expedited Forwarding |
| Video | 34 | AF41 — Assured Forwarding |
| Screen sharing | 18 | AF21 — Assured Forwarding |
Marking is necessary but not sufficient. DSCP values do nothing unless the network devices downstream are configured to act on them. This is where most partial QoS implementations fail — the endpoints mark traffic correctly, but switches strip the markings or routers don’t have queuing policies that honor them.
Step 1 — Enable QoS Globally and Trust DSCP on Phone Ports
The first configuration step on Cisco IOS switches is enabling QoS globally:
mls qos
Then trust DSCP markings on every port connected to a VoIP phone, SBC, or other trusted VoIP endpoint:
interface GigabitEthernet1/0/10
description VoIP Phone
mls qos trust dscp
Without mls qos trust dscp, the switch will either strip DSCP markings or replace them with its own default value — and your carefully marked voice packets will arrive at the router looking like best-effort data.
Trust boundary decisions matter. Only trust DSCP markings from known, controlled devices — IP phones, certified SBCs, and managed infrastructure. Do not blindly trust all DSCP markings from all ports. An endpoint that marks all of its traffic EF can effectively abuse the priority queue. Standard practice is to trust at phone-facing access ports and remark at the network edge if needed.
Verify trust configuration:
show mls qos interface GigabitEthernet1/0/10
Step 2 — Separate Voice VLANs
Voice VLANs aren’t strictly required for QoS to function, but they’re strongly recommended in production environments. Separating voice and data traffic at the VLAN level makes QoS classification cleaner, troubleshooting faster, and security policy enforcement easier.
Standard configuration on a Cisco access port:
interface GigabitEthernet1/0/10
switchport mode access
switchport access vlan 10
switchport voice vlan 20
mls qos trust dscp
Data traffic lands on VLAN 10. Voice traffic is tagged by the IP phone to VLAN 20. This separation also makes packet captures significantly easier when you’re troubleshooting a call quality issue and need to isolate voice traffic quickly.
Step 3 — Classify Traffic with Class Maps
Before you can prioritize traffic, the router needs to know how to identify it. Class maps define the matching criteria.
For a Teams deployment, build three class maps — one per traffic type:
class-map match-any VOICE
match ip dscp ef
class-map match-any VIDEO
match ip dscp af41
class-map match-any SCREEN-SHARE
match ip dscp af21
Step 4 — Build the QoS Policy Map
The policy map defines what to do with each class of traffic. For a Teams voice deployment, give strict priority to audio, allocate bandwidth for video and screen sharing, and let everything else use what remains:
policy-map WAN-VOICE-QOS
class VOICE
priority percent 30
class VIDEO
bandwidth percent 20
class SCREEN-SHARE
bandwidth percent 10
class class-default
bandwidth remaining percent 100
fair-queue
priority percent 30 gives voice strict priority queuing — voice packets are always processed first, up to 30% of interface bandwidth. Strict priority means voice never waits, even during heavy congestion.
bandwidth percent for video and screen sharing gives those classes a guaranteed minimum allocation without strict priority — they get their share first but can burst into unused bandwidth when available.
bandwidth remaining percent 100 with fair-queue on the default class gives all other traffic fair access to whatever bandwidth the priority queues haven’t consumed.
The 30% audio allocation is a starting point. Right-size it based on actual concurrent call volume — approximately 100 Kbps per simultaneous call for G.722. If you have 20 concurrent calls on a 100 Mbps WAN link, audio needs 2 Mbps. If you’re on a 10 Mbps circuit with 20 concurrent calls, the math looks different.
Step 5 — Apply the Policy to the WAN Interface
Apply the policy outbound on the WAN-facing interface — this is where congestion occurs and where prioritization matters most:
interface GigabitEthernet0/0
description WAN Uplink
service-policy output WAN-VOICE-QOS
Apply outbound only in most cases. The congestion point is almost always on the outbound path toward the internet or WAN circuit.
Step 6 — Verify the Implementation
Configuration without verification is incomplete. Run these commands during an active call period — QoS queue behavior is invisible when the network is idle.
Check queue statistics and confirm voice traffic is hitting the priority queue:
show policy-map interface GigabitEthernet0/0
This shows packet counts, byte counts, and drops per class. You’re looking for voice traffic populating the VOICE class and near-zero drops. If drops are occurring in the priority queue, the 30% allocation may be undersized.
Check interface-level QoS statistics:
show mls qos interface GigabitEthernet0/0 statistics
Check queue depth and current activity:
show queue GigabitEthernet0/0
Verify DSCP markings are being trusted on access ports:
show mls qos interface GigabitEthernet1/0/10 statistics
QoS and Wi-Fi
Most VoIP complaints in modern environments are wireless problems, not wired QoS problems. A perfectly configured wired QoS implementation doesn’t help if voice traffic is competing on a congested 2.4GHz radio or dropping packets during a roam between access points.
Key wireless considerations for VoIP:
- Use 5GHz for voice clients — 2.4GHz is too congested in most environments
- Implement WMM (Wi-Fi Multimedia) on access points — this is the wireless equivalent of DSCP prioritization and most enterprise APs support it
- Configure QoS policies at the wireless controller level, not just on wired infrastructure
- Ensure access point placement provides adequate coverage without large gaps that force roaming mid-call
- Consumer or SOHO access points are not suitable for production VoIP — the lack of proper QoS implementation and poor roaming behavior will cause problems regardless of wired configuration
Microsoft Teams — Platform-Specific Configuration
The Cisco IOS configuration in this guide handles the network side of Teams QoS. The Teams side requires additional steps: enabling QoS globally in the Teams Admin Center, deploying DSCP endpoint policies via Group Policy or Intune for Windows clients, and validating with Call Quality Dashboard after go-live.
Teams uses the following source port ranges for traffic classification at the network layer:
| Traffic Type | Source Port Range | DSCP |
|---|---|---|
| Audio | 50,000–50,019 | 46 (EF) |
| Video | 50,020–50,039 | 34 (AF41) |
| Screen sharing | 50,040–50,059 | 18 (AF21) |
These port ranges are what your router ACLs use to classify Teams traffic from endpoints that don’t insert their own DSCP markings — Mac clients, mobile devices, and browser-based participants. For the complete Teams-side implementation, see Teams Calling QoS — Network Requirements for Production Voice Quality.
Webex Calling — Same Network, Same Principles
The network-side QoS configuration in this guide applies equally to Webex Calling deployments. The Cisco IOS class maps, policy maps, VLAN separation, and WAN queuing work identically — the network doesn’t know or care whether the voice traffic came from a Teams client or a Webex app.
The differences are platform-specific: Webex Calling uses different source port ranges and DSCP values than Teams, and QoS is enabled through Cisco’s Control Hub rather than the Teams Admin Center. The endpoint policy configuration also differs for Webex-managed devices.
For the Webex-specific configuration — port ranges, DSCP values, Control Hub settings, and device policy — see Webex Calling Network Requirements — QoS, Firewall Ports, and Split Tunneling once that article is live.
What Goes Wrong
Marking without queuing. DSCP values on packets accomplish nothing if the router doesn’t have a queuing policy that acts on them. This is the most common incomplete QoS implementation — endpoints mark correctly, the network ignores it.
Trusting all ports. Applying mls qos trust dscp globally or on all ports lets any device mark its traffic EF and get priority treatment. A laptop running a backup job marked EF will compete directly with voice in the priority queue.
Applying policy to the wrong interface. A service policy applied to an internal LAN interface instead of the WAN uplink does nothing useful — congestion happens at the constrained WAN link, not on the gigabit LAN fabric.
Never verifying under load. Run show policy-map interface during peak usage to confirm voice traffic is hitting the priority queue and drops are not occurring. QoS behavior is invisible when the network is idle.
Assuming QoS fixes everything. If a circuit is genuinely undersized for call volume, QoS helps but won’t fully solve the problem. 20 simultaneous calls on a 1 Mbps circuit isn’t a QoS problem — it’s a bandwidth problem.
The Bottom Line
QoS for VoIP is not complicated when you approach it with the right goal: protect voice traffic during congestion by giving it a dedicated queue that gets processed before everything else. The implementation follows a consistent pattern regardless of scale — mark at the endpoint, trust at phone-facing ports, classify at the router, queue on the WAN interface, verify under load.
Get those five steps right and voice traffic survives network congestion. Skip any one of them and you’ll be troubleshooting call quality complaints trying to find the gap.
Microsoft reference: Implement Quality of Service (QoS) in Microsoft Teams
Cisco reference: Cisco IOS QoS Configuration Guide