● SIP/2.0 200 OK  |  RTP: flowing  |  New guides added weekly

Fundamentals

QoS and DSCP for VoIP: What Actually Protects Calls

By the VoIP Cost Guide Editorial Team  |  Last updated: October 2026

Quality of Service is the most configured and least verified technology in VoIP. Offices swear they 'have QoS' while their markings are stripped at the first hop and their queues sit on a device the voice never crosses. Real QoS is a chain — mark correctly, trust carefully, queue at the bottleneck, and verify in captures — and it only protects you at the points of congestion, which is almost always the WAN edge.

This guide gives the values, the placement and the verification, and explains the limits (QoS cannot create bandwidth or fix a provider-side problem) so expectations stay honest.

The markings that matter

TrafficDSCPValue (decimal)Treatment
Voice media (RTP)EF (Expedited Forwarding)46Strict priority / low-latency queue, policed to a sane ceiling
Call signaling (SIP)CS324Assured bandwidth, protected from drops (some carrier standards use AF31 — follow your provider's spec)
Video (if any)AF4134High-priority assured class below voice
Everything elseDF / scavenger classes0 / CS1Bulk classes explicitly de-prioritized at congestion

Where QoS works — and where it's theater

QoS only matters where a queue can form: the WAN uplink first (your smallest pipe and the usual bottleneck), then congested LAN uplinks and Wi-Fi airtime. Configuration on a gigabit LAN switch with 3% utilization is decoration. The chain that works: mark at the source (phones mark their own RTP EF and SIP CS3 out of the box in most business models — verify), trust at the access edge (switches trust phone markings, ideally only on phone ports/VLANs so users cannot self-promote their traffic), queue at the bottleneck (the router shapes to slightly below the real uplink rate so the queue forms in your priority-aware device, not in the ISP's dumb buffer — this shaping step is the one most often missing), and verify markings end-to-end in captures, including whether your provider honors or re-marks them for the return path. Policing the priority queue to ~30–40% of the link protects data from voice storms and voice from a mis-marked bulk flow.

Implement QoS in the right order

  1. Find the bottleneck: measure busiest-hour utilization on the WAN uplink (see peak-hours guide). If peaks sit under ~50%, your quality problem is probably not queueing — diagnose elsewhere first.
  2. Verify phone markings in a LAN capture (DSCP column): RTP should already be EF, SIP CS3. Fix endpoint templates if not.
  3. Configure the WAN edge: shape egress to ~90–95% of measured uplink, priority queue for EF with a policer, assured class for CS3, fair queueing for the rest.
  4. Align LAN trust: access switches trust DSCP from phone ports/VLAN only; uplinks carry markings untouched.
  5. Verify three ways: markings visible in a WAN-side capture; voice quality statistics stable through a deliberately induced bulk upload; markings (or a documented provider policy) on return traffic.
  6. Document the policy in the run-book with the shaper rate tied to the circuit — when the circuit changes speed, the shaper must change too (a classic silent regression).

Frequently asked questions

Will QoS fix our choppy calls on its own?
Only if the cause is queueing at a bottleneck you control — which the measurement step establishes. QoS does nothing for loss on the provider's network, bad Wi-Fi airtime, or an undersized circuit that's saturated even by voice alone (rare). It is a scalpel for congestion, not a tonic.
Our ISP says they 'support QoS'. What does that usually mean?
Typically that they don't strip DSCP on their network, or they honor markings within a business-class product — with specifics that matter. Get the behavior in writing (which classes, on which product, ingress and egress) and verify in captures rather than assuming end-to-end treatment.
Should everything from the phone VLAN be marked EF?
No — only the RTP stream is latency-critical; the phone's other traffic (provisioning, web UI) is not. Phones mark per-flow correctly by default; blanket VLAN marking invites abuse and misdiagnosis.

Sources and further reading

Related guides

Disclaimer: This guide is educational information based on published VoIP standards and professional practice, not engineering advice for your specific system. VoIP pricing, taxes and fees change and vary by provider and location — verify current figures with providers before purchasing. If your phone system supports emergency calling, work with your provider or a qualified VoIP engineer for changes that affect E911.