VoIP QoS Settings: What to Configure and WhereGood VoIP QoS comes down to five settings, applied in order. Put phones on a voice VLAN, mark RTP voice with DSCP 46 (EF) and SIP signaling with CS3, trust those markings at the access switch, give voice a strict priority queue on every congested link, and then measure latency, jitter and loss to prove it works. This guide walks through each setting, why it matters, and where to apply it across a multi-location network.

TL;DR

• Mark voice media (RTP) as DSCP 46 (EF) and SIP signaling as CS3 (DSCP 24), as close to the phone as possible.
• Put phones on a dedicated voice VLAN and trust markings only on ports that connect to them.
• Give voice a priority queue (low-latency queuing) on the WAN or internet edge, because that is where calls actually get squeezed.
• Aim for under 150 ms one-way delay, and keep jitter low rather than relying on a bigger jitter buffer.
• Verify with measurements after every change, per site, not just once at rollout.

Table of Contents

• What QoS does for a voice call
• The targets you are configuring toward
• Step 1: Find where voice actually competes
• Step 2: Mark voice with the right DSCP values
• Step 3: Build the voice VLAN
• Step 4: Turn on QoS on the switches
• Step 5: Prioritize voice on the WAN edge
• QoS for SIP: signaling and media are separate
• Jitter buffer settings: leave them alone until QoS is right
• Test and troubleshoot with measurements
• Keeping QoS consistent across many sites
• Our perspective
• Get voice QoS designed and monitored for every site
• FAQ
• Sources

What QoS does for a voice call

Voice is unlike email or file downloads. A late packet is a useless packet, and the call cannot pause to wait for it. Cisco describes VoIP as extremely bandwidth- and delay-sensitive, needing priority to deliver voice quality close to the traditional phone network.

QoS helps in several ways. According to Cisco's VoIP QoS guide, it prioritizes voice packets, supports dedicated bandwidth, improves loss characteristics and manages congestion and jitter. The same guide says to classify and mark packets near the network edge so every hop downstream can apply its policy without reclassifying.

That last point shapes the whole configuration. QoS is not one switch you turn on. It is a chain: the phone or switch marks, each device trusts and queues, and the WAN edge enforces. A gap anywhere in the chain means voice competes with everything else at that point.

For a wider view of why this matters to a business voice deployment, see our IT manager's guide to QoS in business voice.

The targets you are configuring toward

Before touching a device, know what "good" means. Three measurements drive voice quality:

The jitter figure deserves attention. Cisco notes that jitter buffers add end-to-end delay and are usually effective only for delay variations under 100 milliseconds. So the buffer is a safety net, not a fix. The goal of QoS is to keep jitter small enough that the buffer rarely has to work hard.

If you want the difference between the two most confused measurements, our piece on jitter versus latency covers what each one breaks and how to fix it.

Step 1: Find where voice actually competes

QoS only matters where a link can become congested. On a modern gigabit LAN, voice rarely struggles inside the building. The pinch point is almost always the uplink: the internet circuit, the MPLS or SD-WAN link, or a wireless backup path with far less capacity than the primary.

So start with an inventory per site:

1. List every WAN and internet link and its real upload speed. Upload is usually the scarce direction for voice.
2. Count peak simultaneous calls and note what else runs at the same time: video meetings, cloud backups, point-of-sale syncs, guest WiFi.
3. Identify every device that handles voice traffic: phones, access switches, WiFi controllers, firewalls, routers.
4. Note which devices can mark, trust and queue by class, and which cannot.

That last list tells you where QoS will break. A firewall that rewrites or ignores markings, or an unmanaged switch in a closet, can undo careful work elsewhere. Our bandwidth management playbook goes deeper on sizing and shaping once you know your peaks.

Step 2: Mark voice with the right DSCP values

DSCP is the six-bit field in the IP header that tells every device what class a packet belongs to. The standard answer for voice media is Expedited Forwarding. RFC 4594 recommends EF, decimal 46, for VoIP to get low-loss, low-delay, low-jitter treatment, and says voice should be marked at the network edge with core devices configured to recognize those markings.

Signaling is a separate matter. Per Cisco's guidance, RTP media is typically marked EF (46) and placed in a low-latency priority queue, while signaling often gets its own class such as CS3 (DSCP 24).

A practical marking plan looks like this:

Treat the video row as a common convention to confirm against your own policy rather than a rule. The two voice rows are the ones that matter here.

Where the marking should happen

There are two choices, and the better one depends on your phones:

• Phone marks its own traffic. Most business IP phones can be set to send RTP as DSCP 46 and SIP as CS3 through provisioning. This is the cleanest option because the markings are right from the first hop. The switch then simply trusts them.
• Network re-marks at the edge. If phones or softphones do not mark correctly, the access switch or firewall classifies by VLAN, port or address range and applies the marking itself.

Either way, do it once at the edge. Cisco and Dell equipment both support classifying and trusting markings at the edge, which avoids reclassifying at every following hop.

Step 3: Build the voice VLAN

A voice VLAN lets one access port carry phone traffic on one VLAN and PC traffic on another. The phone plugs into the switch, the computer plugs into the phone, and the switch keeps the two streams separate. Meraki's VoIP deployment guide describes this setup: configure the VLANs and QoS mappings on the switch ports and use phones that support LLDP or CDP so they learn the voice VLAN automatically.

A sensible voice VLAN configuration includes:

• A dedicated VLAN ID and subnet for voice at every site, with a consistent numbering scheme so troubleshooting stays predictable.
• Phones learning the VLAN through LLDP-MED or CDP, or through DHCP options, so nobody types VLAN IDs on handsets.
• Trust of DSCP or CoS markings only on phone-facing ports, never on ports where users could mark their own traffic as priority.
• A separate DHCP scope and a provisioning path for phones.
• Access control so voice traffic reaches only the call platform and provisioning servers it needs.

Separating voice at Layer 2 also helps security and troubleshooting. A broadcast storm on the data VLAN will not flood your phones, and a packet capture on the voice VLAN contains only voice.

If WiFi carries voice (handsets, softphones), the same logic applies to the wireless side. Our managed WiFi service includes designing SSIDs and QoS mapping for voice, and a site survey shows where coverage will not hold a call.

Step 4: Turn on QoS on the switches

Switch behavior differs by vendor, so check the defaults before you assume anything. Three examples from vendor documentation:

• Cisco Catalyst. On a Catalyst 9400, you can configure an auto qos voip option on the interface. According to Cisco's configuration guide, Auto-QoS creates and attaches policies, configures trust and maps traffic to queues, for ports connected to IP phones or softphones. It is a strong starting point, which you then review rather than blindly accept.
• Dell N-Series. These switches default to trusting dot1p markings. They can be set globally to trust DSCP using the classofservice trust ip dscp command. If your phones mark DSCP and the switch trusts only dot1p, your markings will be ignored.
• Cisco Meraki. Meraki switches can map DSCP tags to CoS queues and trust tags from configured phones. If you run Meraki across sites, our Meraki deployment and licensing page explains how we handle it.

The common mistake is a mismatch: the phone marks DSCP, the switch trusts CoS, or the uplink trunk strips the tag. After configuring, check that a voice packet leaves the far side of every hop with the same EF marking it entered with.

Step 5: Prioritize voice on the WAN edge

This is where QoS earns its keep. The router, SD-WAN appliance or firewall at the edge of each site decides what goes first when the uplink fills.

Cisco recommends a priority queue for VoIP, and says low-latency queuing (LLQ) is the right choice because it is flexible and easy to configure. In practice:

1. Create a strict priority class matching DSCP EF and cap it at a bandwidth sized to your peak concurrent calls, with headroom.
2. Create a class for CS3 signaling with a smaller guaranteed share so calls still set up and tear down under load.
3. Leave the remainder to best effort, or to other defined classes.
4. Shape outbound traffic to the real link speed, slightly under the contracted rate, so queuing happens in your device where you control it, not in the provider's.

The priority class needs a ceiling. RFC 4594 explains that voice is inelastic: it cannot slow down in response to loss or delay, so policing at ingress is recommended to keep voice within negotiated bounds. Without a cap, a misbehaving device marking everything EF can starve the other classes.

A caution for multi-site operators: markings are honored on networks you or your provider control. Across a general internet path, nothing guarantees your DSCP values survive. That is why voice-critical sites do better on dedicated or managed circuits, and why SD-WAN path selection matters. Our write-up on SD-WAN tuning levers for voice quality covers that side.

QoS for SIP: signaling and media are separate

SIP carries call setup, and RTP carries the audio. They take different paths, use different ports and need different treatment.

• RTP gets EF and the strict priority queue. This is the traffic that suffers audibly from jitter and loss.
• SIP signaling gets CS3 and a guaranteed share. Signaling is low volume, but when it is delayed you see failed calls, slow ring, one-way audio on answer and dropped registrations.
• Firewalls and SIP ALG. Check how your firewall treats SIP. Features that rewrite SIP headers can break registration or audio, and the firewall must preserve the markings you set. Our managed firewall service is set up with voice flows in mind.

RFC 4594 also notes that signaling protocols such as SIP, H.323 and H.248 negotiate call admission, which helps ensure voice flows stay within network capacity. If your platform supports call admission control per site, set it to match your priority queue size. Ten calls in a queue sized for eight is how everyone's audio breaks at once.

Jitter buffer settings: leave them alone until QoS is right

Most phones and session border controllers offer adaptive jitter buffers. The temptation is to enlarge the buffer when calls sound choppy. That trades one problem for another, because every millisecond of buffer adds delay to a budget already limited to about 150 ms one-way.

A workable approach:

• Keep the adaptive jitter buffer on unless the platform vendor tells you otherwise.
• If you must set a fixed value, start at the vendor default and change it in small steps, measuring after each.
• Treat any need for a buffer beyond roughly 100 ms as a sign the network has a problem, since Cisco's guidance says buffers are generally effective below that level.
• Fix the source of jitter: an unprioritized queue, a saturated uplink, a wireless hop, or a backup circuit with high variance.

Test and troubleshoot with measurements

Configuration is a hypothesis. Measurement settles it.

1. Baseline before changes. Record latency, jitter and loss to your call platform at a quiet time and at peak.
2. Generate load. Saturate the uplink with a large transfer while a test call runs. Voice should stay clean if the priority queue works.
3. Capture and check markings. A packet capture on the phone-facing port and on the WAN-facing interface shows whether EF and CS3 survive.
4. Read queue counters. Drops in the priority class mean it is undersized or policed too tightly. Drops in best effort during load are expected.
5. Compare against targets. One-way delay under 150 ms, low jitter, minimal loss.

Symptom guide:

For chronic problems unrelated to marking, our bandwidth issues troubleshooting guide is a good next step. And to understand what a provider promises versus what QoS does for you, read SLA versus QoS.

Keeping QoS consistent across many sites

One site is a configuration. Fifty sites is a governance problem. The failure pattern is familiar: the headquarters is tuned, branch offices were set up by whoever was available, and a firmware update at one location resets a trust setting.

What helps:

• A single template for marking, trust and queue policy, applied to every site.
• Consistent voice VLAN IDs and naming.
• Monitoring that alerts on jitter and loss per site, not just on circuit up or down.
• A change process that includes a test call and a queue-counter check.

Our perspective

We see the same pattern across multi-location networks: QoS is rarely missing, it is inconsistent. One site trusts DSCP, another trusts CoS, a third has a priority queue sized for a headcount that changed two years ago. Each choice is defensible alone. Together they produce the complaint IT hears most: "calls are bad at the Fresno office on Tuesdays."

That is why we engineer voice end to end instead of treating it as a phone setting. Our engineers design each site, we source circuits from 50+ carriers so voice rides a path that fits the job, and our U.S.-based NOC watches the network around the clock. Our Netverge platform is built to give real-time visibility into the network, so jitter and loss show up as data before they show up as help desk tickets.

For a lean IT team, the practical benefit is one provider and one engineer to call, not a carrier, a phone vendor and a firewall vendor each pointing at the others. We back data with a 99.99% uptime SLA and voice with 99.999%, and we say plainly that an SLA and QoS do different jobs: the SLA is about availability, and QoS and good design are what make an available circuit sound good.

Jim

Get voice QoS designed and monitored for every site

If you run voice across several California locations and would rather not hand-tune each one, we design, deploy and monitor it as part of a managed service. That includes managed SD-WAN with voice-aware path selection, dedicated fiber where a site needs a clean path, and hosted voice (UCaaS) with the phones and network configured together.To see how it would apply to your sites, start from the California Telecom home page and talk to an engineer.

FAQ

What DSCP value should I use for VoIP?

Use DSCP 46, Expedited Forwarding (EF), for RTP voice media, as recommended in RFC 4594. Mark SIP signaling separately, commonly as CS3 (DSCP 24). Mark at the edge and make sure every device in the path trusts and queues on those values.

How much jitter is acceptable for VoIP?

As little as you can get. Jitter buffers compensate for variation, but they add delay and are generally effective only for variation under about 100 ms, per Cisco's QoS guidance. Keep total one-way delay under 150 ms and fix the cause of jitter rather than enlarging the buffer.

Do I need a voice VLAN if I already have QoS?

They work together. The voice VLAN separates phone traffic at Layer 2 and gives the switch a clear place to trust markings, while QoS decides how that traffic is queued. Using both is the standard deployment described in Meraki's VoIP guide.

Can I just use Auto-QoS on my switches?

Often it is a good starting point. On Cisco Catalyst switches, the auto qos voip command family configures trust and queue mappings for phone ports. Review the generated policy, and still configure the WAN edge, where congestion usually happens.

Sources

• Quality of Service for Voice over IP (Cisco)
• Quality of Service for Voice over IP, PDF (Cisco)
• RFC 4594: Configuration Guidelines for DiffServ Service Classes (IETF)
• Quality of Service Configuration Guide, Catalyst 9400 (Cisco)
• Quality of Service for Voice on Dell Networking N-Series (Dell)
• Cisco Meraki Voice-over-IP Deployment Guide
• MS Series: VoIP Deployment Guide (Meraki)

Recommended

• The Role of QoS in Business Voice: IT Manager's Guide
• Prevent E911 and QoS Failures: 5 Point VoIP over LTE Checklist for IT
• 3 SD‑WAN Tuning Levers That Fix Voice Quality
• 1.0–5.0 MOS Explained for IT Teams: Measure, Alert, Fix VoIP Quality