Mark RTP media as DSCP EF (46), mark SIP signalling as CS3 (24) or AF31 (26), and put that EF traffic into a strict-priority queue at the WAN egress. That single combination fixes the majority of choppy-call complaints network administrators chase for weeks.
Here’s the 10-minute check before you touch anything else:
- Confirm your phones are actually marking RTP as EF and SIP as CS3, not sending everything as best-effort.
- Trust those markings on the access switch port the phone plugs into, rather than letting the switch strip or rewrite them.
- Apply a low-latency or strict-priority queue on the WAN interface, sized to your concurrent call count.
The numbers behind this aren’t arbitrary. ITU G.114 sets one-way delay under 150 milliseconds as the threshold for high-quality voice, and codecs like G.729 codec start producing audible artefacts once packet loss creeps above roughly 1%. Everything below builds out from that baseline.
Key Takeaways
Reliable VoIP call quality depends on marking RTP as DSCP EF 46, marking SIP as CS3 or AF31, and enforcing that priority through strict queuing at the WAN egress.
| Point | Details |
|---|---|
| Mark correctly | Use DSCP EF (46) for RTP and CS3 (24) or AF31 (26) for SIP signalling on every device. |
| Fix the WAN first | Shape to 85 to 90% of measured throughput, not the ISP’s advertised speed, so your router controls the queue. |
| Audit switch trust | Untrusted access ports silently strip DSCP; set phone ports to trust and verify CoS mapping to 5. |
| Verify hop-by-hop | Capture packets at the WAN egress; if DSCP shows 0 instead of EF46, trace back to find the rewriting device. |
| Get expert help when it crosses boundaries | TechBug’s managed IT services diagnose VPN, SD-WAN and multi-vendor QoS issues that in-house teams often can’t isolate alone. |
Table of Contents
- What QoS for VoIP actually does to your network traffic
- How much bandwidth does a VoIP call actually need?
- Classification, marking and queueing: the three jobs QoS does
- Which DSCP values should you actually use for VoIP?
- Step-by-step: deploying QoS for VoIP end to end
- How do you verify QoS is actually working?
- Does encryption break QoS for VoIP?
- Common QoS mistakes that quietly wreck call quality
- What standards and field experience back this guidance
- What we see most often when a client’s calls start dropping
- Getting QoS right without doing it all yourself
- Frequently asked questions
- Sources
What QoS for VoIP actually does to your network traffic
QoS for VoIP isn’t a bandwidth increase. It’s traffic triage: telling every router and switch on the path which packets get served first when the link is momentarily full. Voice needs that triage because it can’t buffer the way a file download can. A dropped or delayed video frame is invisible; a 200-millisecond gap in someone’s sentence is not.
Three things ruin a call, and they don’t always show up together:
- Latency — delay above roughly 150ms one-way starts to feel like a satellite call, with people talking over each other.
- Jitter — inconsistent packet arrival times force the jitter buffer to stretch or drop audio to keep pace.
- Packet loss — codecs like G.729 codec tolerate almost none before you hear clicks, robotic syllables, or dropped words.
The frustrating part is that a link can show plenty of free bandwidth on a graph and still butcher calls, because the problem is queuing delay, not capacity. This is bufferbloat: a router holds onto packets in an oversized buffer rather than dropping them, and voice sits behind a queue of bulk downloads for half a second at a time.
Pro Tip: Fix the WAN egress first, not the office switch. A perfectly configured LAN can’t rescue a call that’s already queued behind someone’s cloud backup at the internet edge.
How much bandwidth does a VoIP call actually need?
Not much, but the answer depends entirely on codec and overhead, which most bandwidth calculators ignore. A G.711 codec call, uncompressed and the default on many desk phones, runs close to 87kbps once you add RTP, UDP, IP and Ethernet headers. G.729 codec, which compresses more aggressively, uses significantly less bandwidth for the same conversation.
Your quality targets, per Cisco’s VoIP QoS guidance and ITU G.114, look like this:
| Codec | Payload rate | Typical total bandwidth (with overhead) | Packet loss tolerance |
|---|---|---|---|
| G.711 codec | 87 kbps | ~87 kbps | Well under 1% |
| G.729 codec | 8 kbps | ~32 kbps | Well under 1% |
| Opus (typical VoIP setting) | 24 to 32 kbps | significantly less bandwidth | Slightly more tolerant, still low |
For example, multiple concurrent G.711 codec calls require planning for sufficient bandwidth plus additional headroom for SIP overhead, retransmissions and other real-time traffic sharing the queue to ensure guaranteed priority bandwidth on a link.
Classification, marking and queueing: the three jobs QoS does
Every QoS design does three separate jobs, and conflating them is where most misconfigurations start.
- Classification identifies which traffic is voice, usually by DSCP value, UDP port range (commonly 16384 to 32767 for RTP), or an access list matching the phone’s IP range.
- Marking stamps that decision onto the packet, typically as a DSCP value in the IP header, so downstream devices don’t have to re-identify it.
- Queueing and scheduling decides what happens when the link is congested, giving marked voice packets a dedicated, low-latency path ahead of everything else.
Marking only works if every hop respects it. This is the trust boundary problem: a switch port set to “untrusted” will often strip or zero out incoming DSCP values by default, silently undoing all your work upstream. Cisco’s Catalyst 9300 QoS documentation makes this explicit, and it’s one of the first things to audit on any network inheriting someone else’s configuration.
For queueing, you have a few real choices. Low-latency queuing (LLQ) or strict-priority queuing gives voice a genuinely reserved slot ahead of the line, which Cisco recommends specifically for EF traffic. Class-based weighted fair queuing (CBWFQ) is a softer alternative for mixed traffic classes. On smaller edge routers, particularly Linux-based ones, SQM with fq_codel manages bufferbloat directly without you hand-building queue classes, and it’s a genuinely good starting point for SMB networks that don’t need enterprise-grade CLI QoS.
Which DSCP values should you actually use for VoIP?
Use DSCP EF, decimal value 46, for RTP media. Use DSCP CS3 (24) or AF31 (26) for SIP signalling. This isn’t a preference; it’s the standard Cisco marking scheme that most phone vendors and carriers already expect, so deviating from it just creates interoperability headaches down the track.
Layer 3 marking (DSCP) is what survives routed hops, but inside a VLAN, switches also use Layer 2 CoS (802.1p) to prioritise frames before they ever reach a router. Map DSCP EF (46) to CoS 5 at the switch boundary, so voice gets priority treatment on the switch fabric itself, not just once it hits the WAN router.
Practical trust settings that matter:
- Set phone-facing access ports to trust DSCP or CoS, so the phone’s own markings pass through untouched.
- Leave PC and server ports untrusted or explicitly remark them, so a misconfigured desktop can’t fake EF traffic and jump the queue.
- Police or remark at any network edge where traffic crosses from an untrusted zone, including guest Wi-Fi and third-party circuits.
Step-by-step: deploying QoS for VoIP end to end
Work outward from the phone to the WAN, checking trust and preservation at every hop.
- Audit phone markings. Confirm handsets or softphones tag RTP as EF and SIP as CS3/AF31 in their own configuration, not relying on downstream remarking.
- Configure voice VLANs. Separate voice traffic onto its own VLAN using LLDP-MED or CDP where your switches support auto-provisioning, so phones self-configure without manual VLAN tagging on each port.
- Set switch port trust. Trust DSCP or CoS on phone-facing ports; map DSCP EF to CoS 5 at every switch in the path, per Cisco’s Catalyst QoS guidance.
- Preserve markings through the core. Verify DSCP survives across routed segments; check that firewall rules and NAT policies aren’t rewriting the ToS byte.
- Handle VPN and SD-WAN tunnels separately. Confirm the tunnel encapsulation copies or maps the inner DSCP value to the outer header rather than discarding it.
- Shape the WAN interface below actual throughput. Set shaping to roughly 85 to 90% of your measured real-world speed, not the ISP’s advertised figure, so your router controls the queue instead of the ISP’s equipment.
- Create a strict-priority (LLQ) class for EF traffic. Size it for your expected concurrent call count using the per-call bandwidth figures above, and police it so voice can’t starve other traffic during an unusual spike.
- Test under real load. Run a call while saturating the link with a large download and watch for queue drops, latency spikes, or dropped RTP packets.
Pro Tip: *If you shape exactly to the number your ISP quotes, you’ve handed queue control to their equipment, not yours.
How do you verify QoS is actually working?
Configuration without verification is a guess. Capture packets at the WAN egress and confirm RTP still carries DSCP EF46 by the time it leaves your network. If you see DSCP 0 instead, trace back hop-by-hop, because the culprit is usually an unmanaged switch, a firewall rule, or a VPN endpoint that silently rewrites the ToS byte.
What to actually measure:
- MOS or R-Factor scores where your platform supports them, giving a single quality number instead of raw packet stats.
- One-way latency, jitter, and packet loss at the WAN egress, not just at the LAN switch.
- Queue drop counters on the router (
show policy-map interfaceon Cisco gear,tc qdisc showon Linux) to see if the priority class is actually being used. - DSCP values in a live capture (tcpdump or Wireshark) to confirm marking survives the full path.
For troubleshooting, the split matters: “choppy but connected” usually points to jitter or intermittent loss, so check queue drops and jitter buffer stats first. Calls dropping entirely usually means a capacity or routing failure, so check for saturated links or a device silently rejecting the priority queue’s bandwidth reservation.
Does encryption break QoS for VoIP?
Not on its own. RFC 8862’s SIPBRANDY profile requires DTLS-SRTP for comprehensive media protection, and neither SRTP nor SIP over TLS touches the outer IP header where DSCP lives, so encrypted calls can be classified and marked exactly like unencrypted ones.
The real risk sits with VPNs and some firewalls, which build a new outer IP header during encapsulation and don’t always copy the inner DSCP value across. Test inside the tunnel and again at the physical egress interface to catch this.
- Mark traffic inside your trust boundary, before it hits any tunnel or NAT device.
- Verify your VPN or SD-WAN platform maps inner DSCP to the outer header rather than defaulting to best-effort.
- Avoid blanket firewall or NAT policies that rewrite or zero the ToS byte for convenience.
Common QoS mistakes that quietly wreck call quality
Most VoIP quality tickets trace back to one of a small handful of repeat offenders.
- Applying QoS only on the LAN while the actual congestion happens at the WAN egress.
- Shaping the WAN to the ISP’s advertised speed instead of 85 to 90% of measured throughput.
- Leaving access switch ports untrusted, so DSCP gets stripped before it ever reaches the router.
- Giving the priority queue no bandwidth cap, letting a voice traffic surge starve every other application on the link.
Rule of thumb: fix the WAN first, reserve bandwidth based on real concurrent call counts, cap your priority queue, and test everything under a genuine load, not an idle network.
What standards and field experience back this guidance
This isn’t guesswork stitched together from forum threads. The core numbers come from ITU G.114 on latency thresholds, RFC 8862 on SIP/SRTP media security, and Cisco’s own DSCP and LLQ configuration guides, which remain the closest thing the industry has to a shared VoIP QoS standard.
- ITU G.114 sets the latency target every other recommendation in this guide is built around.
- Cisco’s LLQ and DSCP marking documentation defines the practical configuration syntax used across most enterprise gear.
- RFC 8862 governs how encrypted media interacts with the network path, which matters as more SIP trunks move to TLS by default.
Most VoIP quality failures aren’t exotic. They’re a WAN link shaped to the wrong speed, or a switch port that quietly strips DSCP the moment it leaves the phone.
TechBug’s field work across small and medium business networks backs this pattern consistently: the fix is rarely a new codec or a bigger circuit, it’s correcting where the queue actually sits. The approach stays vendor-agnostic, drawing on Cisco IOS examples where the client runs Cisco gear, and SQM/fq_codel on Linux-based edge devices where a lighter-touch fix does the job just as well.
What we see most often when a client’s calls start dropping
The most common outage isn’t exotic. It’s a WAN link shaped to the ISP’s advertised speed instead of what the circuit actually delivers, combined with a switch somewhere in the path quietly rewriting DSCP to zero. TechBug’s triage process starts at the WAN egress every time, because that’s where the queue actually forms, then works backwards hop by hop until markings check out.
In-house teams can usually handle the switch trust audit and phone configuration themselves with the checklist above. Where it’s worth bringing in a managed-services engagement is when the problem crosses a VPN or SD-WAN boundary you don’t fully control, or when call quality varies by time of day in a way that points to shared, congested infrastructure rather than a single misconfigured device.
Getting QoS right without doing it all yourself
Most of what’s above is entirely doable in-house with the right checklist and a few hours of testing. Where it gets genuinely time-consuming is the hop-by-hop verification across VPNs, firewalls and mixed vendor gear, especially when the fault only shows up under load or at specific times of day.
TechBug runs on-site network assessments that map exactly where DSCP is being dropped or rewritten, design WAN shaping and priority queue policies sized to your real call volume, and configure voice VLANs and switch trust settings so markings survive the whole path. Beyond deployment, ongoing monitoring catches queue drops and shaping drift before staff start noticing choppy calls. If you’d rather have someone else own this end to end, TechBug’s managed IT services cover exactly this kind of network tuning alongside broader support, and pairing it with the right VoIP phone system deployment or SIP trunk package from a partner like Yakho Telecoms rounds out the whole voice stack. Get in touch for a network assessment and find out exactly where your call quality is leaking.
Frequently asked questions
What DSCP value should I use for VoIP?
Use DSCP EF, decimal 46, for RTP media traffic. Use DSCP CS3 (24) or AF31 (26) for SIP signalling, following the standard Cisco marking scheme most vendors already expect.
Why does my VoIP quality still suffer when I have plenty of bandwidth?
Available bandwidth doesn’t fix bufferbloat. If your router queues packets instead of prioritising voice, calls degrade even on an otherwise idle link, which is why WAN shaping and a dedicated priority queue matter more than raw capacity.
Do I need QoS if all my calls use SRTP encryption?
Yes. SRTP and SIP over TLS protect the payload but leave the outer IP header, where DSCP lives, untouched. QoS marking and encryption solve different problems and both remain necessary.
How much bandwidth does one VoIP call need?
A G.711 codec call needs roughly 87kbps including overhead; G.729 codec needs around 32kbps.
What’s the difference between LLQ and SQM for VoIP QoS?
LLQ is a manually configured strict-priority queue typical on enterprise routers, offering precise control over reserved bandwidth. SQM with fq_codel is a simpler, automatic approach to bufferbloat that suits smaller networks without dedicated CLI QoS expertise.
Sources
Save these alongside your configuration notes: