SD-WAN QoS for Voice: Policy Design for Clear Calls

Voice stays clear on an SD-WAN when three things line up: calls are identified and marked at the edge, they are placed in a strict-priority queue on every WAN interface, and the overlay steers them onto the healthiest path when a link degrades. Marking alone does nothing without queuing, and queuing alone cannot rescue a path that has gone bad. This guide sets out the targets, the policy structure, the bandwidth arithmetic and the checks that make a voice policy hold up in production. It is written for network architects and IT managers running multi-site estates, including Cisco SD-WAN deployments.

TL;DR

• Mark voice media as DSCP EF (46) and signalling as CS3, and apply the marking as close to the endpoint as possible.
• Give voice strict-priority (low-latency) queuing on the WAN interface, sized from peak concurrent calls plus 20 to 30% headroom, not from average calls.
• Aim for one-way delay under 150 ms, loss under 1% and jitter well under 30 ms; use app-aware path selection to move calls off paths that miss those targets.
• QoS has to be consistent end to end: voice VLAN, switch ports, SD-WAN edge and the underlay all need to agree on markings.
• Test with real calls and per-path telemetry after every policy change, and rehearse failover with voice running.

Table of Contents

• Why voice needs QoS in an SD-WAN
• Voice quality targets to design against
• Step 1: identify and mark voice at the edge
• Step 2: queue voice with strict priority
• Step 3: plan bandwidth from peak concurrent calls
• Step 4: keep QoS consistent from the desk to the underlay
• Step 5: steer voice by path quality and plan for failover
• Step 6: test and monitor with real calls
• Common reasons voice still sounds bad
• How Re-Solution can help
• FAQ
• Sources

Why voice needs QoS in an SD-WAN

Without QoS, a router places all traffic into a single first-in-first-out queue. Voice is very sensitive to delay, so a call packet can end up stuck behind traffic where a few extra milliseconds do not matter, as Microsoft’s QoS guidance explains. The result is audible: missing syllables, people talking over each other, speech that is hard to follow.

Microsoft names three problems QoS addresses for real-time audio:

• Jitter: media packets arriving at uneven intervals, which causes missing words or syllables.
• Packet loss: dropped packets that lower voice quality and make speech hard to understand.
• Round-trip delay: noticeable lag between two parties.

In an SD-WAN, queuing and forwarding decisions happen in the overlay, above the traditional IP interface, which lets voice receive priority in both directions across whichever paths are available. The same IEEE newsletter notes that jitter buffering can be done inline in the network, by measuring gaps between packets and spacing them evenly on the far side. Traditionally that job sat with application servers and endpoints such as IP phones.

The practical point is that SD-WAN gives you more levers than a classic router: classification, scheduling and path choice. Each needs to be configured for voice deliberately.

Voice quality targets to design against

Targets turn “good call quality” into numbers you can alarm on. The Cisco QoS baseline, reproduced in a Pearson sample chapter, sets out the following for voice:

These are design targets for a well-managed network, not a promise of what every internet underlay will deliver. Treat them as the thresholds your SLA classes and monitoring use. If you set SLA classes in the overlay, set the voice class to the tightest of these values your circuits can realistically meet, so path selection has something meaningful to enforce.

Step 1: identify and mark voice at the edge

Classification is where most voice policies succeed or fail. Marking should happen as close to the source as possible, on the LAN side, so that every later hop can trust the value.

A typical Cisco Catalyst SD-WAN design, as laid out in an implementation guide’s QoS policy chapter, maps the Voice class to DSCP EF (46) with a low-latency queue and strict priority. Classification uses class maps that match DSCP EF, Cisco phones, SIP and RTP audio. The marking policy sets DSCP EF on the LAN interface, and the scheduling policy applies the priority bandwidth on the WAN interface.

A workable sequence:

1. Separate voice onto its own VLAN. A dedicated voice VLAN makes classification simple and keeps voice out of broadcast noise from data devices.
2. Trust phone markings only where you control the endpoint. On access ports, trust or re-mark based on the device type, so a user laptop cannot claim EF.
3. Mark media as EF and signalling as CS3. A common Cisco example marks RTP audio EF and SIP signalling CS3, giving the RTP stream a priority queue and signalling a small guaranteed share of bandwidth.
4. Match on more than one attribute. Combining DSCP, protocol (SIP, RTP) and device type is more resilient than relying on a single field, especially when softphones and cloud UC clients are in the mix.
5. Keep the class list short. Voice, interactive video, signalling, business-critical data and default is enough for most estates. Every extra class is another thing to verify.

Softphones and cloud UC clients deserve special attention. Microsoft’s guidance describes using DSCP markings together with port-based access lists to identify, mark and classify real-time streams, so your edge policy needs to cover the port ranges those clients use as well as the physical handsets.

Step 2: queue voice with strict priority

Marking only labels packets. Scheduling decides who is served first when a link is congested. For voice, that means a strict-priority, low-latency queue (LLQ) on the WAN-facing interface of every SD-WAN edge.

The implementation guide above allocates 10% of bandwidth to the Voice class as an LLQ with strict priority. Treat that as a starting point from one design, not a rule: the right figure comes from your call arithmetic (see the next section) and the circuit speed. A 10% allocation on a 100 Mbps link is generous; on a 10 Mbps broadband circuit it may be too little for a busy site.

Two cautions apply when sizing the priority queue:

• Cap it. Strict priority is policed, so a misbehaving or mislabelled flow cannot starve everything else. Do not give voice more than it needs.
• Shape to the real circuit rate. If the SD-WAN edge sends faster than the underlay can carry, the queue builds in the provider’s equipment, where your policy does not apply. Shape outbound traffic slightly below the contracted rate so queuing happens on your device.

On a Microsoft-style rule of thumb, apply QoS first and then add bandwidth where necessary, because increasing connection size is often cost-prohibitive. That ordering is sound: a correct policy usually costs less than a bigger circuit.

Step 3: plan bandwidth from peak concurrent calls

Bandwidth per call depends on the codec and the header overhead. One VoIP planning guide puts G.711 at roughly 87 kbps per call and G.729 at roughly 32 kbps, both including IP, UDP and RTP headers. The same guide advises calculating peak concurrent calls, not average calls, and adding 20 to 30% headroom for bursts, retransmissions, RTCP and SIP signalling.

A worked example for a site expecting 40 simultaneous calls at its busiest:

On a 50 Mbps circuit, a 10% priority class gives 5 Mbps, which covers the G.711 case. On a 20 Mbps circuit, 10% gives 2 Mbps, which covers G.729 but not G.711. That is the kind of mismatch to catch at design time, not after users complain.

Summing bandwidth is only half of the job. Academic work on VoIP traffic engineering points out that planners should consider both packet throughput (packets per second) and bit throughput, because devices can constrain call capacity before the link is full. Voice sends many small packets, so a low-end edge router or a busy firewall can hit its forwarding limit well below the link rate. Check the published forwarding performance of the edge platform at small packet sizes, with QoS and encryption enabled, before you assume the link is the only limit.

This matters more as call volumes grow. If you are adding automated call handling, for example an AI phone agent answering inbound lines, those sessions count towards peak concurrent calls and packets per second just like human calls, so include them in the sums.

Step 4: keep QoS consistent from the desk to the underlay

A policy that works on the SD-WAN edge but breaks on the LAN or in the underlay still produces bad calls. Check each segment in turn:

• Access switches: voice VLAN configured, trust boundary set, EF preserved up to the uplink.
• Distribution and core: queuing for EF applied on every congested hop, not just the WAN edge.
• Wireless: Wi-Fi is often the weakest link for voice. Capacity, coverage and per-radio client counts decide whether handsets and softphones perform; our guide to Wi-Fi capacity planning covers the radio side.
• SD-WAN edge: marking preserved across the tunnel, so the outer header carries the same class as the inner packet.
• Underlay: this is where it gets harder. On a private circuit with a carrier QoS agreement, markings can be honoured across the carrier network. On public internet links they usually cannot be enforced.

That last point is why SD-WAN path selection matters. Where QoS cannot be enforced across an uncontrolled network, the overlay compensates by measuring each path and putting voice on the best one. It is worth confirming with each carrier which DSCP values they honour, and whether they remap or bleach them, since a remarked EF packet loses its priority at the next hop.

If you are still choosing the design, our notes on Cisco SD-WAN design decisions cover what to settle before rollout, and the pilot architecture and checklist shows how to validate a voice policy on a small number of sites first.

Step 5: steer voice by path quality and plan for failover

QoS manages congestion on a link you are using. Path selection decides which link you use. For voice, define an SLA class with loss, latency and jitter thresholds and attach it to a data policy that matches your voice class. When the active path breaches the thresholds, the overlay moves calls to a path that meets them.

The IEEE newsletter describes the remediation tools SD-WAN can add on top of steering. Forward error correction or packet duplication is enabled once packet loss is identified on a path. Duplicates are sent over one or several paths; the destination forwards the first copy it receives and drops the rest, and if a packet was lost, the duplicate takes its place. This trades extra bandwidth for resilience, so use it for voice classes where a clean call is worth the overhead, and include the duplicate traffic in your bandwidth sums.

Failover needs a rehearsal with voice running, not just a ping test. Check:

• Does the backup path carry the same markings and queue? A 4G or secondary broadband link often has a different shaping rate, and the priority queue has to be resized to it.
• Is there enough capacity on the backup for peak calls? If not, decide which calls matter most and police accordingly, instead of letting congestion degrade every call.
• How long does a call survive the switch? Test with calls in progress and note whether they drop, glitch or continue.
• Does traffic return cleanly? Flapping between paths can hurt voice more than staying on a mediocre path, so use hold-down timers.

Our SD-WAN failover design playbook goes through these decisions in more detail for network architects.

Step 6: test and monitor with real calls

A policy is only proven when calls run through it under load. Build a short, repeatable test routine:

1. Baseline the quiet network. Record loss, latency and jitter per path with no congestion.
2. Generate load. Saturate the link with bulk data while placing test calls, and confirm voice stays within the targets in the table above.
3. Verify counters. Check that the priority queue is incrementing and that EF packets are not landing in the default class. A policy-map hit count at zero is a clear sign of a classification mistake.
4. Check both directions. Upstream is usually the constrained one on broadband, and a policy applied on one side only protects one direction of the call.
5. Re-test after every change. New software releases, new applications and new codecs can all shift behaviour.

For ongoing monitoring, track per-path loss, latency and jitter, queue drops in the voice class, and a call quality score such as MOS where your platform provides one. Alert on trends before users notice. Alongside this, a periodic network audit catches drift: a switch port that lost its trust setting, a template that was never applied to a new site.

Common reasons voice still sounds bad

• Markings stripped or remapped by a switch, firewall or carrier, so EF arrives as best effort.
• Priority queue too small after a headcount or codec change.
• No shaping on the outbound interface, so queues form in the carrier’s equipment.
• Overloaded edge device, hitting its packet-per-second limit before the link fills.
• Wi-Fi congestion that no WAN policy can fix.
• Mismatched failover path, with a backup link that has no voice class at all.
• Everything marked EF. When video, backups and softphone updates all claim priority, the priority queue becomes just another best-effort queue.

The common thread is that each fault sits at a boundary between teams, vendors or devices. That is why end-to-end review matters more than any single setting.

Our view: voice QoS is a design discipline, not a feature switch

Across multi-site estates in education, manufacturing, logistics and hospitality, the voice problems we are asked about rarely come from a missing feature. They come from policy that was built on one device and never checked end to end. Cisco SD-WAN gives you the classification, scheduling and path-selection tools; getting value from them means sizing queues from real call volumes, agreeing markings with every carrier and testing failover with live calls.

With more than 35 years of Cisco experience and certified consultants, we approach voice as part of the whole network: LAN, wireless, WAN and security together. A network audit documents what is actually marked and queued today, and a managed service keeps the policy aligned as sites, codecs and headcount change.

Jacob

How Re-Solution can help

If voice quality is a recurring complaint across your sites, the quickest route is to establish what the network is doing today. Our network audits record how traffic is classified and queued across your estate, and our managed services keep Cisco networks monitored and supported once the policy is in place. For organisations that prefer a subscription model, Network as a Service is also available. You can see everything we offer on our services page.

If you are comparing the cost of a wider SD-WAN rollout, our SD-WAN pricing guide breaks budgets down by component for three, 25 and 100 sites.

FAQ

Which DSCP value should voice use in SD-WAN?

Voice media should be marked DSCP EF (46), as set out in RFC 3246 and the Cisco QoS baseline, and given strict-priority servicing at each node. Signalling such as SIP is commonly marked CS3 and given a small guaranteed share of bandwidth. Confirm that your carriers preserve these values.

How much bandwidth does one voice call need?

It depends on the codec and overhead. Planning guides put G.711 at about 87 kbps and G.729 at about 32 kbps per call including headers. Size the priority queue from peak concurrent calls and add 20 to 30% headroom.

Is QoS enough for voice over broadband internet links?

QoS controls queuing on links you manage, but it cannot be enforced across the public internet. That is why SD-WAN adds path measurement and dynamic steering, and, where loss appears, forward error correction or packet duplication, so voice moves to the best available path.

What latency, jitter and loss are acceptable for voice?

The Cisco QoS baseline targets no more than 1% loss, no more than 150 ms one-way latency and average one-way jitter under 30 ms. Use these as the thresholds for your SLA classes and alerts.

Sources

• Implement Quality of Service in Microsoft Teams, Microsoft Learn
• How SD-WAN provides reliable voice and video services over the internet, IEEE SDN Newsletter
• Voice, call-signalling and QoS baseline sample chapter, Pearson
• Cisco Catalyst SD-WAN QoS policy design, implementation guide
• Cisco QoS priority and bandwidth policy discussion, Experts Exchange
• VoIP bandwidth requirements, SIP Symposium
• Design and traffic engineering of VoIP, DePaul University
• Droxy phone agent

Recommended

• Cisco SD-WAN Design: Three Decisions Before Rollout
• SD-WAN failover design: a playbook for network architects
• UK SD-WAN Pilot in Six to Ten Weeks: Architecture and Checklist
• SD-WAN Security: NCSC/ENISA Checklist for Enterprise Architects