Hi,

I have a remote installation with a central router and many access points managed by Capsman. Staff need to have access to Wifi Calling (VoWiFi?).

Most of the access points are three or more point to point links away, so phone traffic would have to go through multiple routers.

The Staff wifi has local forwarding enabled and their connection will be have a vlan tag assigned by a radius server.

Wifi Calling works fine at the moment, but sometimes the calls get garbled and drop out. Sometimes they come back, but more often the call drops ( is nat timeout something I should be looking at? ). I am not sure if this is due to a internal or external network issues, but it still happens when the access point being used is not on capsman and is basically connected to the wan p2p link.

Anyway, I want to prioritize the traffic from phone calls. Do I need to do this on all routers or can it be managed from Capsman. From what I undertstand, with local forwarding, the traffic from each client finds its own way to its destination. So as I type this, I am starting to think each router needs some queues setup.

Do I need to setup prioritization on each router? This isn't a problem, just thought I would ask.

Also at this point, I am assuming that queues are the way to go and will do my research and testing on this one. If anyone out there has done this sort of thing, any help would be greatly appreciated.

regards

Justin.

You need to prioritize the real time traffic by delaying the other traffic using queues on any device where the egress link bandwidth is lower than the overall traffic requires.

Within a private network, I would recommend to use detailed rules to classify the traffic for prioritization only at the routers which receive the traffic from the endpoint devices directly connected to them, and assign DSCP values to the packets based on these criteria; on both the edge routers and the intermediate routers, you then assign the packet-marks used to choose the queue based on the the DSCP values alone.

And yes, where local forwarding is used at CAPsMAN, you have to use classification rules on the CAP itself. Actually, if you didn't use local forwarding, you'd have to prioritize all the CAPsMAN transport packets on their way to the CAPsMAN because you wouldn't be able to tell which of them would carry the real-time traffic.

Thanks for the reply.

I am learning queues at the moment. I haven't done anything with DSCP yet, but I am sure it will make more sense once I go through the docs and test a bit.

Cheers

I would recommend to use detailed rules to classify the traffic for prioritization only at the routers which receive the traffic from the endpoint devices directly connected to them, and assign DSCP values to the packets based on these criteria;

I think those wifi calling phones already set the correct DSCP value (EF) on their traffic; you merely need to use the packet marks and queues based on that.
(i.e. no classification required, only handling of the priority)

I haven't done anything with DSCP yet, but I am sure it will make more sense once I go through the docs and test a bit.

DSCP is a field of IP header which is intended to carry the information about packet priority. The idea is that, as @pe1chl says, already the source devices set the value of this field for each packet they send, and the routers all the way to the destination just use this information to place the packet into the right queue (or maybe send it via the right physical channel). But this ideal scenario doesn't always happen. Most notably, any DSCP value assigned in a private network is typically carefully ignored by the ISP.

If the sending device itself doesn't set the DSCP value, you may use mangle rules to assign it based on the information available at the router - source and destination IP and/or port, input interface etc.

You can use packet sniffing followed by analysis using Wireshark to check whether the mobile phones do set any particular value of the DSCP field of the IPsec transport packets they send.