QoS for VoIP: What to Enable, Which Settings to Use

Quality of Service (QoS) tells your network which traffic goes first when the connection is crowded. For VoIP, that means marking voice packets with DSCP 46 (Expedited Forwarding) at the network edge and giving them a priority queue on the device that sits between your office LAN and your internet connection. Do that, measure before and after, and your calls stay clear even when someone uploads a large file. Skip the measuring and you are guessing.

This guide covers when QoS is worth turning on, the numbers your network has to hit, the settings that matter, and what to check when calls still sound bad. It is written for business owners and the people who look after their phones in small and mid-sized offices, shops and plants.

TL;DR

QoS matters when your internet upload or your WAN link can fill up. If it never does, modern gear may already handle voice well without manual work.
Mark voice and call signaling with DSCP 46 at the edge, then use Low Latency Queuing (LLQ) on the device at your internet hand-off.
Aim for one-way latency under 150 ms, jitter of 20 ms or less, and minimal packet loss.
Baseline your call quality first, change one thing at a time, and compare results afterward.
If calls are still choppy, check bandwidth, lost or delayed packets, and device processor load before adding more rules.

What QoS actually does for a phone call
Should you enable QoS for VoIP?
The numbers your network has to hit
Which traffic to prioritize, and the DSCP value to use
How to set up QoS for VoIP, step by step
Wi-Fi, VPNs and cloud phone systems
How to verify QoS is working
If call quality is still poor
Common mistakes to avoid
Perspective
Let us handle the network under your phones
FAQ
Sources

What QoS actually does for a phone call

Voice over IP turns your speech into small packets and sends them every few milliseconds. Unlike an email or a file download, a voice packet that arrives late is useless. The listener hears a gap, a robotic warble or a clipped word. Cisco's own design guidance describes VoIP as extremely sensitive to delay and jitter, which is why voice needs dedicated bandwidth and priority queuing to match the feel of a traditional phone line.

QoS does two jobs:

Performance: it keeps latency and jitter low for real-time traffic.
Protection: it reserves bandwidth for voice when the link is congested.

Notice what QoS does not do. It does not create bandwidth, and it does not repair a bad cable, a failing switch port or a weak Wi-Fi signal. It decides who waits when there is a line. If there is no line, it has nothing to decide.

Should you enable QoS for VoIP?

In most business offices, yes, with one condition: you should know where congestion can happen before you configure anything.

Congestion almost always appears at one spot: the hand-off between your local network and your internet connection, especially on the upload side. A cloud backup that starts at 10 a.m., a team syncing large drawings or a video meeting can fill an upload pipe quickly. When it fills, voice packets queue behind everything else. That is exactly where QoS earns its keep.

Inside the building, the picture is often easier. Many modern switches and routers detect VoIP traffic automatically and place it in high-priority queues, and wired and wireless LANs frequently have enough bandwidth that calls and data coexist without approaching saturation. So on a healthy gigabit LAN, you may not need elaborate internal rules.

A practical way to decide:

Your situation	What to do
Upload bandwidth gets saturated at times (backups, cloud sync, video)	Configure QoS at the internet hand-off, and mark voice at the edge
Multiple sites connected by a VPN or private WAN	Mark voice and use LLQ on each WAN gateway
Single office, ample bandwidth, newer managed switches	Verify what the gear already does, then add rules only where measurements show a need
Call problems with no clear cause	Baseline and measure first, before changing anything

The last row reflects a caution from the telephony engineers themselves. Avaya's design documentation says there is no all-inclusive QoS rule because every network and traffic mix is different, and it recommends baselining IP telephony performance without QoS before applying QoS as needed. The same page warns against switching on several QoS features at once without understanding how they interact. That is sound advice: QoS done carefully works, and QoS done by checking every box in the router menu is how you create new problems for the rest of your traffic.

The numbers your network has to hit

Before touching settings, know the targets. These are the figures engineers use to judge whether a network is fit for voice.

Metric	Target	Source
One-way latency	Under 150 ms (up to 300 ms tolerated on international or satellite calls)	Cisco
One-way delay for best quality	80 ms or less; 80 to 180 ms is sufficient for business-grade calls	Avaya
Jitter	20 ms or less, or less than half the sample size, for best quality	Avaya
Bandwidth per call	Roughly 21 kbps to 320 kbps of priority bandwidth depending on codec and sampling; some sources cite 32 to 64 kbps for standard G.711	Cisco design guide
Packet loss	As close to zero as you can get; lost voice packets are not resent in time to matter	Same guidance on voice quality

The bandwidth range is wide because codecs differ. A compressed codec can use a fraction of what an uncompressed one uses, and overhead from IP headers adds to every call. To size your priority queue, multiply the per-call figure for your codec by the number of calls you expect at the busiest moment, then add headroom. Your phone provider can tell you which codec your phones use.

If you want a deeper explanation of how latency, jitter and loss shape what callers actually hear, this overview of VoIP audio quality metrics breaks the terms down in plain language.

Which traffic to prioritize, and the DSCP value to use

QoS works on packets that carry a label. That label is the Differentiated Services Code Point (DSCP), a value in the IP header. Routers and switches read it and place the packet in the right queue.

The standard practice, and the one Cisco documents, is to mark voice traffic with DSCP 46, Expedited Forwarding. That value tells every device along the path to treat the packet as low-latency, high-priority.

Prioritize two kinds of traffic:

Voice media (RTP): the actual audio stream. This is the traffic that suffers from jitter and delay. Mark it DSCP 46.
Call signaling (SIP or the equivalent): the messages that set up, ring and end calls. It is light but important: if signaling is delayed, calls fail to connect or drop. Cisco's guidance is to prioritize voice and signaling together. Many deployments give signaling its own, smaller guaranteed share rather than the same strict priority as audio.

Do not mark everything as high priority. A priority queue that contains video, file transfers and voice is just a normal queue with extra steps. Keep DSCP 46 for voice only.

How to set up QoS for VoIP, step by step

The sequence below follows the approach Cisco describes: classify and mark at the edge, then protect with a priority queue where congestion occurs.

Step 1: Baseline before you change anything

Record call quality on a normal busy day and on a day when you deliberately load the network. Capture latency, jitter and packet loss from your phone system's call quality reports or a monitoring tool. This is the "before" you will compare with later. It also tells you whether you have a congestion problem at all.

Step 2: Find where congestion can happen

Sketch the path a call takes: handset, switch, router or firewall, internet connection, provider. The narrowest point is the candidate. For most offices it is the upload side of the internet circuit. Wi-Fi can be a second one if phones or softphones run wirelessly.

Step 3: Mark voice at the edge

Configure your switches, access points or phone provisioning so voice traffic carries DSCP 46. Many IP phones can mark their own packets, and a dedicated voice VLAN lets the switch recognize phone traffic cleanly. Marking close to the source means every device downstream can act on the label without re-inspecting packets.

Step 4: Create a priority queue at the WAN hand-off

On the router or firewall that connects you to the internet or to other sites, implement Low Latency Queuing (LLQ). Cisco recommends intelligent output queuing such as LLQ so voice packets are serviced first. Set the priority bandwidth to what your peak call count needs, with headroom, and leave the rest of the link for everything else.

Two practical details:

Set shaping slightly below your real circuit speed so the queue forms on your device, where you control it, rather than at the provider's equipment, where you do not.
Cap the priority queue. A strict-priority class with no limit can starve other traffic.

Step 5: Understand what you cannot control

QoS on your side governs traffic leaving your network. Traffic coming down from the internet is a different matter. Your router cannot reorder packets that have already crossed a congested link to reach you, so downstream protection generally depends on your internet provider cooperating or configuring it. If upstream rules are in place and callers still complain about what they hear on your end, ask your provider what they can do on the downstream side.

Step 6: Change one thing at a time and measure

This is where most DIY attempts go wrong. Apply a marking rule, test. Add the queue, test. Compare each result with your baseline from Step 1. Stacking several changes at once makes it impossible to know which one helped or hurt.

Wi-Fi, VPNs and cloud phone systems

Wi-Fi. Wireless networks are shared and contend for airtime, so voice on Wi-Fi needs attention beyond wired settings. Enable the wireless equivalent of voice prioritization on your access points, keep signal strong and avoid overloaded channels. If you can, use wired connections for desk phones.

VPNs and multi-site. When calls cross a site-to-site tunnel, the tunnel can hide the DSCP marking inside encryption. Make sure your gateway copies the marking to the outer header, or classify voice before it enters the tunnel, so the WAN queue still sees it.

Cloud phone systems. With a hosted phone service, the provider handles QoS inside its own platform. Your job is the stretch between your phones and your internet hand-off, plus having enough upload bandwidth. That is the part you can check and tune. A well-run cloud voice deployment starts with a network readiness check rather than plugging phones in and hoping.

How to verify QoS is working

Configuration is not proof. Verify in three ways:

Compare metrics. Run the same load test and compare latency, jitter and loss with your baseline. Cisco's guidance is to compare call quality before and after implementation.
Check queue counters. Your router or firewall should show packets passing through the priority class. If the counter stays at zero, your marking is not reaching the queue.
Watch device load. Avaya cautions administrators to monitor processor load after enabling QoS, because moving classification or marking from hardware into software (process switching) can reduce performance.

Test under load, not just on a quiet afternoon. QoS only shows its value when the link is busy.

If call quality is still poor

When QoS is on and calls still choppy, work through this list in order:

Bandwidth. Cisco's troubleshooting guidance for choppy voice starts with confirming there is enough network bandwidth and looking for lost or delayed voice packets. A priority queue sized too small for your peak calls will drop voice just as surely as no queue.
Marking that gets stripped. Some devices reset DSCP values to zero. Check each hop between the phone and the WAN edge.
Processor load. A firewall or router near its CPU limit can add delay no matter what the QoS policy says.
Wi-Fi. Interference, roaming handoffs and weak signal produce jitter that wired QoS cannot fix.
Duplex and cabling. Mismatched settings and bad cables cause errors that look like congestion.
The ISP link itself. If loss appears on the circuit even when your own traffic is light, the problem sits outside your walls and needs a ticket with the provider.

A useful habit is to treat call-quality complaints as data. Note the time, the user, the device and the type of call, and match them against what else was running. Patterns show up quickly, and they point to the layer that needs work. For more on separating phone-system issues from network issues, see this guide on diagnosing voice quality problems.

Common mistakes to avoid

Prioritizing everything, which cancels the benefit.
Setting the priority queue by guesswork instead of calls multiplied by codec bandwidth.
Configuring QoS on the LAN while the real bottleneck is the internet upload.
Leaving no one responsible for monitoring, so a change months later quietly breaks marking.
Forgetting to document the policy, so the next technician undoes it.

That last point matters more than it sounds. A QoS policy is infrastructure. It needs an owner, documentation and a review whenever you change internet providers, add a site or swap a firewall. Our example IT service level agreement shows how we define response and ownership for the systems we manage.

Perspective

Most voice complaints we see do not start with a missing QoS rule. They start with nobody owning the network end to end. The phone vendor blames the internet provider, the provider blames the firewall, and the office manager is left holding a headset that crackles.

That is why we treat voice as part of the managed stack, not a separate project. When we run your infrastructure for a fixed cost per user, the same team that watches your firewall, switches and internet circuit 24/7 is the team that knows how your voice traffic is marked and queued. Nothing is an add-on, and nothing falls between two vendors.

Our advice for a Wisconsin manufacturer, law office or dental practice is the same: measure first, mark voice at the edge, protect it where the link can fill up, and keep monitoring so you catch drift before your customers do. Documented, proactive and boring is the goal. A phone system should be the thing nobody thinks about.

Dustin Collett

Let us handle the network under your phones

If you would rather not baseline, mark, queue and monitor this yourself, that is what we do. Our VoIP and cloud phone systems run on a network we manage, and our Managed IT Services cover your switches, firewall, internet circuit and monitoring for a fixed cost per user, with local support in Southeastern Wisconsin. You can see how our voice plans are laid out on the voice pricing page.

The quickest first step is our paid IT & Security Assessment, which documents what is on your network today and where the risks and bottlenecks sit.

Book the IT & Security Assessment

FAQ

Should I enable VoIP QoS?

Enable it when your upload bandwidth or a WAN link can fill up, because that is when voice packets get delayed. If your network is rarely busy and your equipment already prioritizes voice, manual configuration may be unnecessary. Baseline your call quality first so you know which case you are in.

What is a QoS requirement for VoIP calls?

A common target is one-way latency under 150 ms and jitter of 20 ms or less, with packet loss as low as possible. Cisco gives the 150 ms figure, and Avaya describes 80 ms or less as best quality. Bandwidth per call depends on the codec, so check what your phones use.

What DSCP value should I use for VoIP?

Use DSCP 46, Expedited Forwarding, for voice media. Signaling is typically prioritized too, often in its own smaller class. Apply the marking at the network edge so every device downstream can place the packets in a low-latency queue.

Is it better to have QoS on or off?

On, when it is configured deliberately and measured against a baseline. The risk comes from enabling many QoS features at once without understanding how they interact. Change one setting at a time, test under load and watch device processor load.

Can I fix poor incoming call quality with QoS on my router?

Only partly. Your router controls what leaves your network, while congestion on the way in usually needs your internet provider's involvement. Confirm your upstream settings, then open a ticket with the provider if loss or delay persists on the circuit.