The problem QoS solves
Voice is unusually demanding of a network, not because it needs much bandwidth but because it needs timely bandwidth. A file transfer that stalls for 200 ms is invisible. Two hundred milliseconds of delayed audio is a gap in a sentence.
On an idle network this never matters. The moment the link saturates — someone uploads a large file, a backup starts — packets queue, and if voice packets wait their turn behind bulk data, calls break up. Quality of Service is the mechanism for saying "this traffic goes first."
DSCP: marking the traffic
The practical foundation is DiffServ, which uses six bits in the IP header — the DSCP field — to label each packet's desired treatment. Routers then apply per-hop behaviour based on that label.
The recommended markings are set out in RFC 4594, and two matter for telephony:
- Voice media (RTP): EF — Expedited Forwarding, DSCP 46. RFC 4594 recommends EF for the Telephony service class, which includes VoIP.
- Signalling (SIP): CS5, DSCP 40. RFC 4594 states that all flows in the Signaling service class are marked CS5.
Marking media EF and signalling CS5 puts you on the standard, which matters when traffic crosses equipment you do not control. Some vendors and enterprise designs use CS3 (24) for signalling instead — a common convention, but not what RFC 4594 specifies. If you are matching an existing network's policy, follow that policy; if you are starting fresh, follow the RFC.
Marking in Asterisk
Asterisk sets these itself, configured in /etc/asterisk/asterisk.conf under the options section:
[options]
tos_sip=cs5
tos_audio=ef
cos_sip=3
cos_audio=5The tos_* values write the DSCP field; the cos_* values set the layer-2 802.1p priority used inside a VLAN. Setting both covers you whether prioritisation happens at layer 2 or layer 3.
Restart Asterisk after changing these, then confirm the markings are actually on the wire rather than trusting the config:
tcpdump -i any -v -n udp portrange 10000-20000 | grep -i tosThe part people miss: marking alone does nothing
A DSCP value is a request, not an instruction. It only has an effect if a device along the path is configured to act on it — to place EF-marked packets in a priority queue and service that queue first.
This is why so many QoS projects produce no improvement. The PBX marks correctly, and then the packets hit a switch and a router with no matching policy, where the marking is ignored or, worse, rewritten to zero at a trust boundary.
So the work is threefold: mark at the source, configure each device in the path to honour the marking, and ensure nothing along the way clears it.
Where QoS works, and where it cannot
QoS works on links you control. Your LAN, your switches, your router's outbound queue toward the internet. This covers the most common real-world cause of bad calls: your own upload link saturating.
QoS does not work across the public internet. Once your packets leave your router, no provider honours your DSCP markings — they are typically ignored or stripped. There is no mechanism for prioritising your voice traffic across networks you do not own.
This is the honest limit of the technology, and it matters when choosing where to spend effort. If calls degrade only when your office is busy, QoS on your own gateway will fix it. If they degrade at random times with an otherwise idle link, the congestion is upstream, and no amount of local QoS configuration will help. That case needs a different answer — a better ISP, a dedicated circuit, or an SD-WAN product that can steer traffic across multiple paths.
A working configuration
The most valuable single change is usually prioritising the upstream queue on the office router, because home and small-business upload bandwidth is small and saturates easily. A practical order of work:
- Mark at the source — Asterisk and the handsets, EF for media, CS5 for signalling.
- Put voice on its own VLAN. It makes classification trivial and isolates voice from broadcast traffic.
- Configure the router's outbound queue to prioritise EF, and set a bandwidth ceiling slightly below the real link rate so the queue forms on your router, where you control it, rather than in the ISP's equipment where you do not.
- Trust markings on access ports where phones connect, and re-mark or clear them on untrusted ports so nobody's workstation can claim EF for a download.
Measure before and after
QoS work is easy to do and hard to verify by ear. Check whether the numbers actually moved: RTCP reports carry jitter and packet-loss statistics, and Asterisk exposes them per channel. Generate real congestion, place a call, and compare.
If loss and jitter are unchanged with the link saturated, your markings are being ignored somewhere — go back and find the device that is not honouring them.
Frequently asked questions
What DSCP value should VoIP use?
EF (DSCP 46) for the audio itself, which RFC 4594 recommends for telephony, and CS5 (DSCP 40) for SIP signalling. Some networks use CS3 for signalling by convention; match whatever your network already enforces.
Will QoS fix call quality over the internet?
Only for congestion on your own links. Providers do not honour your markings once traffic leaves your network, so QoS cannot help with congestion in the middle of the internet.
Do I need a separate voice VLAN?
Not strictly, but it makes classification simple and reliable, and keeps voice away from broadcast-heavy data traffic. On any network beyond a handful of phones it is worth doing.
Why did marking change nothing?
Almost always because no device in the path is configured to act on the marking, or a trust boundary is resetting it to zero. Marking is only half the job.