DSCP EF for VoIP on a Router: Marking and Queue Setup

Why does DSCP EF not fix choppy VoIP calls by itself?

DSCP is only a 6-bit label in the IP header. It does not speed up, reserve or protect anything. Priority exists only at a point where packets wait in a queue and a scheduler chooses which one leaves first.

Take a 1 Gbps LAN feeding a 20 Mbps uplink. A backup job pushes data at LAN speed into the router, the uplink drains it 50 times slower, and a queue builds in whichever device first meets the slow link. If that device is your router with a priority queue, a voice packet jumps the line. If it is the ISP modem with one dumb FIFO buffer, the voice packet waits behind hundreds of milliseconds of bulk data, whatever its label says.

That standing delay is bufferbloat, and it is the usual cause of choppy, robotic or one-way audio when someone saturates the link. The fix has two parts: move the queue into a device you control by shaping slightly below line rate, then give EF a priority class in that queue. If no queue ever builds, nothing is reordered and marking is irrelevant.

Which DSCP values should RTP and SIP use?

The ToS byte is the DSCP value shifted left two bits (DSCP x 4), because the low two bits carry ECN. Tools differ on which form they want: Asterisk accepts names like ef, iptables and nft use decimal or names, and some phone UIs want the DSCP number. The classic mistake is entering 0xB8 where 46 is expected, or 0x2e (which is DSCP 46 written in hex) where a ToS byte is expected, which produces DSCP 11 instead.

Where do I set the marking: phones, PBX or router?

Mark as close to the source as possible, then decide at the LAN edge whether to trust or rewrite. In a small office, trusting only the voice VLAN or the PBX and re-marking everything else to 0 stops a PC application from claiming EF.

On Asterisk with PJSIP, set it on the transport and endpoint. Older chan_sip used tos_sip, tos_audio, tos_video and cos_* settings. In FreePBX the equivalents sit under Settings, Asterisk SIP Settings, and per-trunk or extension advanced options.

; pjsip.conf
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060
tos=cs3
cos=3

[office-phone]
type=endpoint
tos_audio=ef
tos_video=af41
cos_audio=5
cos_video=4

; legacy chan_sip.conf [general]
tos_sip=cs3
tos_audio=ef
tos_video=af41

What if my phones or hosted provider cannot mark traffic?

Classify at the router instead. Match by source IP or voice VLAN, or by port: SIP on UDP/TCP 5060 and TLS 5061, RTP on UDP 10000-20000 (the Asterisk default in rtp.conf). Set the DSCP there, before the packet enters the WAN queue.

The rules below live in their own nftables table on the postrouting hook, so they mark IPv4 packets just before they leave the router. If your phones use a different RTP range, adjust the port range to match.

For hosted VoIP, remember that providers and ISPs commonly bleach or rewrite DSCP on the public internet. Your marking mainly helps your own egress queue. It does not guarantee anything downstream, and you cannot control the inbound direction with markings at all.

# nftables: mark voice leaving the router (own table, postrouting hook)
nft add table inet qos
nft add chain inet qos post '{ type filter hook postrouting priority 0; }'
nft add rule inet qos post udp sport 10000-20000 ip dscp set ef
nft add rule inet qos post udp dport 5060 ip dscp set cs3
nft add rule inet qos post tcp dport '{ 5060, 5061 }' ip dscp set cs3

How do I build a shaped WAN egress with a priority queue?

Measure the real uplink first, using a wired test at a quiet time. Set the shaper to 85 to 95 percent of that figure so the queue forms in your router. Shaping above the real line rate is the most common reason QoS appears to do nothing.

Then define classes: EF in a priority (LLQ) class with a cap, CS3 with a small guaranteed share, and everything else fair-queued. Size the EF cap as concurrent calls x per-call bandwidth plus headroom, or around 30 percent of the shaped rate, whichever is smaller. Never give strict priority unlimited bandwidth: a misbehaving stream marked EF would starve every other class.

On the inbound side, CAKE accepts only one diffserv mode, so the ingress qdisc uses diffserv4 with the ingress keyword. Do not append besteffort, because it would override diffserv4 and discard tin priority. Inbound EF is prioritised only if the marks actually arrive from your provider. Many ISPs bleach them, in which case inbound voice lands in the best-effort tin and is protected by flow fairness and the shaped, short queue rather than by priority.

# Linux CAKE on a 20 Mbps uplink (measured), shaped to 18 Mbps
tc qdisc replace dev eth0 root cake bandwidth 18Mbit diffserv4 nat wash
# Inbound: ingress shaping through an ifb device at ~90% of 200 Mbps
ip link add ifb0 type ifb && ip link set ifb0 up
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: matchall action mirred egress redirect dev ifb0
tc qdisc replace dev ifb0 root cake bandwidth 180Mbit diffserv4 ingress

# Cisco IOS
class-map match-all VOICE
 match dscp ef
class-map match-all SIG
 match dscp cs3 af31
policy-map WAN-OUT
 class VOICE
  priority percent 30
 class SIG
  bandwidth percent 5
 class class-default
  fair-queue
policy-map SHAPE
 class class-default
  shape average 18000000
  service-policy WAN-OUT
interface GigabitEthernet0/1
 service-policy output SHAPE

How do I configure this on pfSense, MikroTik and UniFi?

The principle is identical everywhere: shape below line rate, prioritise EF, fair-queue the rest. Only the vocabulary changes.

How do I verify DSCP EF is working, and what usually goes wrong?

Verification has three layers: the marking is present, the queue counts it, and a loaded call stays clean. Aim for added latency under about 30 ms under load, jitter under 30 ms and loss under 1 percent. A loaded-latency test such as Waveform's bufferbloat test, or a continuous ping to the gateway during an upload, shows whether the queue is controlled.

1. Capture on the phone side: tcpdump -i eth0 -v -n 'udp portrange 10000-20000' and read the tos 0xb8 field on each packet.
2. Repeat the capture on the WAN interface (or Wireshark filter ip.dsfield.dscp == 46) to see whether the mark survives the router.
3. Read queue counters: tc -s qdisc show dev eth0 on Linux, or show policy-map interface on Cisco, and confirm the priority class counter increases during a call.
4. Saturate the uplink with a large upload, place a test call, and check for clean audio and stable ping to the gateway.

tcpdump -i eth0 -v -n 'ip and udp portrange 10000-20000' | grep -m5 'tos 0xb8'
tc -s qdisc show dev eth0
asterisk -rx 'pjsip show endpoints'
sngrep