QoS for VoIP in Practice: Configuration That Actually Works

QoS (Quality of Service) tells your network to treat voice packets differently from everything else. The concept is simple: when the network is busy, VoIP packets go first. The implementation varies by vendor and the details matter.

This is the hands-on companion to Quality of Service: Telling Your Network What Matters and QoS: Telling Your Network What Traffic Matters Most. Those posts explain the concepts. This one walks through the configuration on the equipment you are likely to have.

The fundamentals in 30 seconds

VoIP phones mark their packets with DSCP 46 (Expedited Forwarding). Your network equipment needs to do two things:

1. Trust the marking. Do not strip the DSCP value at the switch or router.
2. Act on it. Put DSCP 46 packets in a priority queue so they are transmitted first when there is contention.

That is the entire idea. The vendor-specific configurations below implement exactly this.

Where QoS actually works (and where it does not)

Before diving into configuration, set the right expectation: QoS only operates on your own network. Your ISP strips DSCP markings at their network edge or ignores them entirely. This is not a bug or a misconfiguration — it is standard practice across virtually all consumer and business internet connections. If ISPs honored customer-set priority markings, every customer would mark all their traffic as high priority and the system would collapse.

This means the configurations below protect your voice traffic from congestion between your phones and your router's WAN interface. Once packets enter your ISP's network, they travel the same best-effort path as everything else. If your VoIP quality problems originate on the internet leg — between your ISP and your VoIP provider — QoS on your end will not help.

So why bother? Because local network congestion is one of the most common and most fixable causes of VoIP quality problems. When someone in the office starts a large upload, a cloud backup kicks in, or Windows Update downloads a feature update, your router's outbound queue fills up. Without QoS, voice packets wait in line behind bulk data. With QoS, voice packets skip the line. The internet path is the same either way, but the local leg is clean.

If your quality problems persist after implementing QoS, the issue is likely upstream. A dedicated internet connection helps not because of end-to-end QoS, but because DIA provides consistent, uncontested bandwidth with SLA-backed performance. The connection itself is better, which matters more than packet markings.

DSCP values for VoIP

The standard markings per RFC 4594:

| Traffic type | DSCP value | DSCP name | Per-hop behavior | |-------------|-----------|-----------|-----------------| | Voice media (RTP) | 46 | EF | Expedited Forwarding — strict priority | | Voice signaling (SIP) | 24 | CS3 | Higher than default, lower than media | | Video conferencing | 34 | AF41 | Assured Forwarding, high priority | | Default (everything else) | 0 | BE | Best Effort |

Most VoIP phones mark RTP at DSCP 46 and SIP at DSCP 24 out of the box. Check your phone's admin interface to confirm. If the phone is not marking correctly, fix it at the phone — it is easier than having the network remark traffic.

Ubiquiti (UniFi / EdgeRouter)

UniFi: Smart Queues (the easy way)

Smart Queues use SQM (Smart Queue Management) with fq_codel to manage bufferbloat. This is the simplest effective QoS for most networks.

In the UniFi controller:

1. Go to Settings > Internet (or Settings > Networks > WAN)
2. Enable Smart Queues
3. Set the Download and Upload speeds to approximately 85-90% of your actual connection speed. This is critical — the queue only works if it is the bottleneck, not the ISP link. If you set it too high, packets queue in the modem instead of the router, and SQM cannot manage them.

Run a speed test to determine your actual throughput, then set Smart Queues to 85% of that number.

Smart Queues do not prioritize VoIP specifically — they prevent any single flow from monopolizing the link and keep latency low for all traffic. For most small offices, this is sufficient because it eliminates bufferbloat which is the primary cause of VoIP quality degradation under load.

EdgeRouter: Strict priority queue

For more control, EdgeRouter supports traffic shaping with priority queues:

set traffic-policy shaper VOIP-QOS bandwidth 100mbit
set traffic-policy shaper VOIP-QOS default bandwidth 80%
set traffic-policy shaper VOIP-QOS default queue-type fair-queue

set traffic-policy shaper VOIP-QOS class 10 bandwidth 20%
set traffic-policy shaper VOIP-QOS class 10 ceiling 100%
set traffic-policy shaper VOIP-QOS class 10 priority 0
set traffic-policy shaper VOIP-QOS class 10 queue-type strict-priority
set traffic-policy shaper VOIP-QOS class 10 match VOIP ip dscp 46

set interfaces ethernet eth0 traffic-policy out VOIP-QOS

Replace 100mbit with your actual upload speed (at 85-90%). Replace eth0 with your WAN interface. This creates a strict priority queue for DSCP 46 traffic that can burst to 100% of the link but is guaranteed 20%.

Fortinet (FortiGate)

FortiGate firewalls support traffic shaping through the GUI and CLI.

GUI method

1. Go to Policy & Objects > Traffic Shapers

2. Create a new shaper:

   • Name: VoIP-Priority
   • Type: Shared
   • Maximum bandwidth: your WAN upload speed
   • Guaranteed bandwidth: 20% of your WAN upload speed
   • Priority: High

3. Go to Policy & Objects > Traffic Shaping Policy

4. Create a new shaping policy:

   • Source: your VoIP VLAN/subnet
   • Destination: any
   • Service: SIP, H.323, or a custom service group including UDP ports 5060 and 10000-20000
   • Shaper: VoIP-Priority
   • Reverse Shaper: VoIP-Priority

CLI method with DSCP matching

config firewall shaper traffic-shaper
    edit "VoIP-Priority"
        set guaranteed-bandwidth 20000
        set maximum-bandwidth 100000
        set priority high
    next
end

config firewall shaping-policy
    edit 1
        set srcintf "lan"
        set dstintf "wan1"
        set tos 0xB8
        set tos-mask 0xFC
        set traffic-shaper "VoIP-Priority"
        set traffic-shaper-reverse "VoIP-Priority"
    next
end

The TOS value 0xB8 with mask 0xFC matches DSCP 46 (EF). Adjust the bandwidth values to match your connection.

Cisco Meraki MX

Meraki's traffic shaping is configured in the dashboard.

1. Go to Security & SD-WAN > SD-WAN & Traffic Shaping

2. Under Global bandwidth limits, set appropriate per-client limits

3. Under Traffic shaping rules, create a rule:

   • Definition: Custom expression matching your VoIP subnet or DSCP marking
   • Or use VoIP & video conferencing as the application category
   • Priority: High
   • Per-client bandwidth limit: Do not limit (or set generously)

4. Under Uplink configuration, enable Load balancing if you have multiple WAN links and select a preference for VoIP traffic

Meraki's approach is less granular than Fortinet or Ubiquiti CLI — it works at the application layer rather than DSCP level. For most deployments, selecting the VoIP application category and marking it high priority is sufficient.

Switch configuration: Trust DSCP

Your router QoS is only effective if the switches between the phones and the router preserve the DSCP markings. Many switches rewrite DSCP to 0 by default on untrusted ports.

Ubiquiti UniFi switches

In the UniFi controller, go to Settings > Networks. If you have a dedicated VoIP VLAN, ensure it is configured correctly. UniFi switches trust DSCP markings by default on all ports, so typically no additional configuration is needed.

Cisco / Meraki switches

On Cisco IOS switches, trust DSCP on the voice VLAN ports:

interface range GigabitEthernet1/0/1-24
 mls qos trust dscp

Meraki MS switches trust DSCP by default when a voice VLAN is configured on the port.

HP / Aruba switches

interface range 1-24
 qos trust dscp

The general principle: any switch port connected to a VoIP phone should trust DSCP markings so the priority tags survive from the phone all the way to the router.

Verifying it works

Configuration without verification is hope, not QoS. Here is how to confirm your QoS is actually protecting voice traffic:

The load test

1. Run our VoIP quality test with the network idle. Record the jitter, packet loss, and latency.
2. Generate heavy load: start a large file upload, run a speed test on another device, or have someone stream video in both directions.
3. Run the VoIP quality test again during the heavy load.

Without QoS: the second test will show significantly higher jitter and latency. You may see packet loss.

With QoS working correctly: the second test should show similar results to the first. Voice quality should remain stable even while the network is saturated with other traffic.

If the results are the same loaded vs. unloaded, your QoS is working. If quality degrades under load, something is not configured correctly — check that DSCP is being trusted on all switches in the path, that the shaper speed is set correctly (85-90% of actual), and that the QoS policy is applied to the right interface.

DSCP verification

Capture packets at the router's WAN interface and verify that VoIP packets still carry DSCP 46. If they are arriving at the router as DSCP 0, something in the path (a switch, another router) is stripping the marking. Trace the path and find where the marking is being lost.

Use the bandwidth calculator to right-size your QoS reservation. Calculate how many concurrent calls you expect at peak and the per-call bandwidth for your codec. Your guaranteed VoIP bandwidth should cover that number with some headroom.

For the conceptual foundation, see Quality of Service: Telling Your Network What Matters. For the network context, see QoS: Telling Your Network What Traffic Matters Most.