# VoIP QoS Settings: Reduce Jitter, Latency, Packet Loss

Choppy audio and talking over each other usually comes from congestion, not “bad VoIP.” QoS fixes that by identifying voice traffic, marking it, and giving it priority where your network actually gets busy—most often the internet upload.

In this guide, you’ll learn practical targets for voice quality, how to mark RTP and signaling, where to place queues and shaping, and how to validate that DSCP markings survive end-to-end.

## What “Good Voice” Looks Like

VoIP quality is mainly controlled by three numbers: delay, jitter, and packet loss. Keep one-way delay around 150 ms or less for natural conversations. Jitter is packet delay variation, and once it rises, phones rely more on the jitter buffer.

That buffer smooths variation, but it also adds delay, so “fixing jitter” by buffering can make calls feel sluggish. Packet loss should be kept very low—aim near 0–1% for clean audio, because loss forces concealment and dropouts.

MOS can help as a summary score, but the actionable work is controlling those three inputs. Once you know your targets, you can take focused steps to [improve VoIP call quality](https://www.blueridge.tech/2025/01/27/addressing-poor-voice-clarity-in-voip/) instead of guessing.

## Step 1 — Identify Your Voice Traffic (RTP Media vs Signaling) and Where It Flows

QoS only works when you know what you’re prioritizing. Start by separating RTP media (the actual audio stream) from SIP signaling (call setup, ringing, hold, transfer). Media is the “must protect” traffic; signaling is important, but it’s tiny compared to RTP.

Map your voice app: desk phones, softphones, or a platform like Teams/Zoom. Then trace the path: endpoint → switch/Wi-Fi → router/firewall → WAN/ISP → provider. Identify the first choke point. In many small offices, it’s the internet uplink during backups, file sync, or large uploads. If you don’t find the congestion point, QoS becomes a label that changes nothing.

## Step 2 — Mark Voice Correctly (DSCP EF 46 + Layer-2 CoS Where Needed)

Voice works best when packets are marked consistently end-to-end. The common standard is DSCP EF (46) for voice media, and CoS/802.1p priority (often CoS 5) on links that use Layer-2 tagging. Marking is how your network knows “this is voice,” but marking alone isn’t QoS.

You must also ensure your switches, Wi-Fi, and WAN edge preserve and act on the marking. If you use a hosted platform, align your policies to its recommended media types and port ranges, then verify the markings at capture points.

### DSCP EF (46) for voice media—why it matters

EF (Expedited Forwarding) is designed for low-loss, low-latency handling. When RTP is marked EF, your router can place it into a low-latency queue so voice isn’t stuck behind bulk traffic. Don’t mark everything EF.

Keep EF reserved for actual voice media, or you’ll dilute its priority and create contention inside the “fast lane.” For signaling, use a lower-priority real-time class if needed, but keep the voice media class clean and predictable.

### Trust boundaries + remarking (don’t lose markings)

DSCP can be stripped or remarked at boundaries: unmanaged switches, guest networks, VPNs, ISP edges, or misconfigured firewalls. Decide where you “trust” markings—often the access layer for phones, then your core/WAN edge. If endpoints can’t be trusted, mark/remark on the switch or voice VLAN instead.

The goal is simple: RTP leaves your LAN with the right DSCP, and it stays intact across your network devices. Validation matters more than intention, so plan to prove it with metrics and captures.

## Step 3 — Prioritize the Right Queue at the Right Place (WAN Edge First)

Most VoIP problems happen when the uplink is congested. Put QoS where congestion occurs—typically the firewall/router WAN interface—so voice gets a low-latency queue and bulk traffic is shaped. Use a priority/LLQ-style queue for EF-marked RTP and keep it size-limited so it can’t starve everything else.

Then apply shaping for general traffic to avoid bufferbloat and long queues. Prioritize voice media, not every “real-time” app. If video, screen sharing, and cloud backups all claim priority, voice loses. QoS is a policy decision, not just a feature toggle.

## Step 4 — Fix the Two Biggest QoS Killers: Saturated Upload and “Too Many Priority Apps”

If your upload is pegged at 95–100%, no amount of marking will save calls. Cap or schedule heavy uploads and keep the priority class small so voice doesn’t compete with other “urgent” traffic. Put cloud backups and large file sync into off-hours windows, or throttle them so they never consume the whole uplink.

Next, audit your QoS classes. If you’ve labeled Teams video, Zoom, IPTV, guest Wi-Fi, and “business apps” as priority, you’ve recreated congestion inside the priority queue. Protect RTP first. Everything else earns its place.

## Step 5 — Wi-Fi and Switch Settings That Protect Voice (WMM, Voice VLAN, Roaming)

Wi-Fi adds jitter when airtime is busy or roaming is messy. Use WMM so voice frames get the right wireless priority, prefer 5 GHz (or well-designed 6 GHz) for cleaner airtime, and keep SSIDs simple to reduce roaming confusion. On switching, segment phones and voice apps so they aren’t competing with noisy devices.

A voice VLAN helps you apply consistent policies, reduce broadcast noise, and keep “random endpoints” from sharing the same lane as voice. Don’t mix printers, cameras, and guest devices with phones. QoS and segmentation work together: QoS protects during congestion; segmentation reduces the chance of congestion and broadcast chatter.

### Wi-Fi voice basics (WMM + 5 GHz + roaming discipline)

Enable WMM, avoid overloaded channels, and ensure AP coverage supports stable roaming. Too many SSIDs increases management overhead and airtime use. Keep power levels balanced so clients roam at the right time.

If calls drop during movement, roaming and RF design are often the culprit—not the PBX. Test a real call while walking common paths and watch jitter and loss.

### Voice VLAN and “don’t mix printers with phones”

Use a voice VLAN for phones/voice devices, and apply DSCP trust/remarking there. Keep IoT and printers in separate VLANs.

This reduces unnecessary broadcasts and helps you enforce clean access rules. You’ll also have clearer troubleshooting, because voice traffic is easier to identify and measure.

## Step 6 — Validate QoS End-to-End (Prove Markings and Measure Improvement)

QoS isn’t “set and forget”—you validate it. First, confirm DSCP markings survive across the LAN/WAN: check at the phone/softphone, at the switch/Wi-Fi edge, and at the router WAN egress.

Packet captures or flow tools can prove whether RTP is EF and whether it gets remarked. Next, measure before and after under real load. Create controlled congestion (like a large upload) and compare jitter, loss, and one-way delay from call quality reports or monitoring tools.

If the WAN queue shows voice staying small and stable while bulk traffic grows, QoS is working. If voice still spikes, revisit shaping, class definitions, and trust boundaries.

## Conclusion

QoS success is marking + correct queueing at the congestion point + controlling uplink contention + validating DSCP end-to-end. Jitter buffers help, but they add delay, so prevention beats compensation.

Keep the priority class small, protect RTP first, shape bulk traffic, and prove improvements with real measurements—not assumptions.