Recipe: keep phone calls clear when the line is busy

Goal: a call stays intelligible while someone else uploads a large file or a backup is running.

What you need

A router that routes, so not the switch or access point role.
The real speed of your line, measured, not the one on your contract. The upload especially, because that is where calls get stuck.
The address range your phones will get, or the VLAN they will sit on.

Why a call breaks up

Voice is very little traffic, a few tens of kilobits per call, but it is demanding about timing. A packet that arrives half a second late is as good as lost. The moment someone starts an upload, the queue in your modem fills up and those voice packets end up at the back of it. So this is not a bandwidth problem but a queue problem, which is why you fix it with a queue and not with a faster line.

Step 1: a VLAN for the phones

In VLANs, add a VLAN of its own, say 40 with 192.168.40.1/24, DHCP on and internet on. Leave Isolated off if the phones have to reach a PBX inside your own network; switch it on if they only talk to a provider in the cloud.

This is not only tidiness. A VLAN of its own gives you an address range you can point at later in a single rule, and it keeps workstation broadcast away from the handsets. If your phone sits in front of a desk PC on a daisy-chained port, check the handset's manual for which VLAN it tags itself.

See VLANs for the port assignment: ports with phones on them become access ports on this VLAN, cables to switches and access points become trunks.

Step 2: the queue

Switch the QoS / bandwidth section on and enter roughly 90 to 95 percent of your measured speed in Download and Upload. This is the step with the most effect and the one most often skipped: only while your router is the thing braking can it also decide who waits.

Then pick one of two:

Fair share per host with CAKE. One queue, no mangle rules, little CPU. It fixes bufferbloat and gives every host its own share, which in practice already keeps a call standing almost every time. Start here.
Priorities with the queue tree, if fair sharing is not enough. Switch Priority: VoIP/video on. The tool then recognises DSCP EF and AF41, SIP on UDP 5060 and 5061 and small UDP packets in the RTP range, marks those connections and puts them at priority 1 in both the download and the upload tree, with a guaranteed slice of the line.

The queue tree is the heavier option. On a hAP ac, hEX or relatives it shapes in software with a ceiling around 200 to 300 Mbit/s, and the tool warns you if you enter a higher speed. Once you hit that ceiling your priorities stop holding, which is the opposite of what you wanted. On such a router take CAKE instead.

Step 3: slow the rest down, if you know the culprit

If you know exactly which machine is to blame, the backup server for instance, put it in the Limits per host/network table with a maximum and priority 8. That is more direct than hoping the classification gets it right.

Step 4: know that fasttrack goes off

As soon as QoS is active the firewall switches fasttrack off, because fasttracked traffic bypasses the queues. That costs throughput and CPU. The tool tells you, and leaves a line in the script explaining why fasttrack is not there. This is not a fault, it is the price.

Testing

Make a call with the line idle. That should be fine; if it is not, your problem is not in the queue.
Start a large upload and call again. This is the real test.
During that upload, run a /ping to a fixed address outside your network. Without a queue you will see the times climb from 10 ms to hundreds of milliseconds. With a properly set queue they stay close to idle.
Use /queue simple print stats to see whether traffic is going through your queue. A zero there means the traffic is not reaching it.
With the queue tree: /queue tree print stats shows how much went through each branch. If ul-voip stays at zero while you are on a call, your voice is not being recognised.
Watch /system resource print with the line full. If the CPU is against 100 percent, the router has become the bottleneck.

Where it goes wrong

The speeds are set too high. By far the most common mistake. The jam then forms in the modem and your router is shaping thin air.
Voice is not recognised. Not every handset marks with DSCP EF, and some providers use ports other than 5060 or an RTP range outside the usual one. If the call runs encrypted through a tunnel, there is nothing to see from the outside at all. In those cases a per-host limit on the rest of the network works better than trying to spot the voice.
Calls only break up in the evening. And your own graphs are empty. Then the congestion is not yours.

When it is your provider

This is where it stops, and saying so is more honest than inventing another switch. Your router manages the queue on your own line and nothing else. If the knot sits inside your ISP's network, on an oversubscribed aggregation point or somewhere further out on the internet, no setting here changes it. The download you can steer only indirectly, by slowing it so the sender holds back; the upload you control fully. So measure where it goes wrong before you turn more knobs: if latency already climbs at the first hop outside your router while your own line is quiet, that is a conversation with your provider.

Read on

QoS and bandwidth for all the methods, VLANs for the network around it, and When something goes wrong for the rest.