QOS settings for VOIP -- how to troubleshoot?

[lighting]

I have been trying to get decent VOIP phone performance on a Comcast cable connection for, well, years. My device of choice is an Obi 202 SIP appliance, which uses IP port 5060. I use both Google Voice and Callcentric.

On the RMerlin firmware I've tried both Adaptive and Traditional QOS, with mixed results. On the traditional QOS, I gave highest priority to all traffic to/from the Obi (selected by IP address). I never knew how to set the priority of the signaling packets, experimented a bit but never settled on a consistently acceptable setup.

When I was using Traditional QOS there also seemed to be no way to figure out whether the traffic was being treated appropriately, and based on the often lousy out-going voice quality I was suffering with it seemed like it wasn't working properly.

Or maybe I'm deluded thinking a cable connection can support reliable VOIP?

I'm currently trying Adaptive QOS, which is working fairly well. I chose "Customize" and moved "VOIP and Instant Messaging" to the highest priority.

But how would I know whether this is actually prioritizing the Obi traffic? (I'm a little worried because the QOS Bandwidth Monitor page shows ALL traffic in light blue. Am I wrong to think that the color key on that page means that traffic should show up in the appropriate colors? Which would mean that the traffic is all "lowest" priority.)

Thank you in advance for any advice!

RT-AC68U w/ Merlin 378.56
Comcast "Blast" ~140/10 Mbps measured

 

[sfatula]

Me too. I used to have cable and never had any issue at all with voice quality. I also use an OBI 202. I assume if you get bad quality, that, during those calls, you have a lot of network traffic coming and going? The bandwidth monitor screen should show you inbound and outbound bandwidth being used. I don't know of anywhere that shows you whether or not data is being prioritized or not.

For me, I tried the traditional QOS, and, never did get it to work well. Had some pretty sophisticated rules. So, went to adaptive, and, even though OBI was the only "highest" priority device, if say an iCloud backup was going on and consuming 100% outbound bandwidth and a phone call at the same time, the phone call suffered badly. I expected more from the adaptive qos.

So, I now am using bandwidth limiter. My biggest offender is offsite backups, whether crashplan or iCloud. So, I bandwidth limit those so they take a little longer but don't use 100% of my uplink.

Sure wish adaptive worked better though. Not sure why it can't.

 

[Nullity]

Assure that your configured QoS bitrate is below your speedtest results. Otherwise, QoS does not work.

So, @lighting, you should have your QoS set to ~135/8.

@sfatula, sophisticated rules are rarely a good idea, especially if you did not confirm that every rule functions as you expect. For VOIP you should have only VOIP traffic prioritized, with everything else defaulted.

 

[sfatula]

Yep, I get that, but it still does not work for me. Configured bitrate is now half of the speedtest results, does not matter, behaves exactly the same. That being said, I am finding the newer bandwidth limiter working fairly well thus far.

I've done many a QOS in the past on different hardware with great results. Maybe something is corrupted somewhere.

Unlike lighting, I have a much slower connection. 8/1. So, for me, much easier to exceed upload bandwidth without a whole lot of effort.

 

[RMerlin]

If using an ATA for VoIP, my recommendation is to simply bump up the priority of that ATA itself rather than fiddle with the protocol itself. Simpler rule, should be more reliable. And Asus's QoS only deals with the WAN to LAN, it doesn't impact LAN to LAN (unlike a managed switch would do).

 

[Nullity]

Yep, I get that, but it still does not work for me. Configured bitrate is now half of the speedtest results, does not matter, behaves exactly the same. That being said, I am finding the newer bandwidth limiter working fairly well thus far.

I've done many a QOS in the past on different hardware with great results. Maybe something is corrupted somewhere.

Unlike lighting, I have a much slower connection. 8/1. So, for me, much easier to exceed upload bandwidth without a whole lot of effort.

AsusWRT QoS seems to be hit-n-miss.

If you are going the bandwidth limiter route, make sure to limit non-VOIP traffic to ~80% or less of your speedtest results. The attached image is from this great QoS tutorial showing that beyond ~80% load, latency climbs exponentially.

 

[sfatula]

Yes, that's what I started with, did not work for me, just fiddled with the device priority, highest, to begin with, and went from there. Never worked for me, and, the configured bitrate never did anything either. But, the limiter *does*! Working for now. Perhaps I need to start over with default settings to see what happens, but, no time for that now. Limiter working good enough for now. One day, likely when some update says I must default the router settings again, I will start over on QOS to see if anything works differently at that time.

I actually limit the upload of the offsite backup machines to 50% of the upload bandwidth. Seems to work great, as you say, latency too high otherwise. And, I don't have lots of machines doing lots of things at the same time typically.

 

[Nullity]

Yes, that's what I started with, did not work for me, just fiddled with the device priority, highest, to begin with, and went from there. Never worked for me, and, the configured bitrate never did anything either. But, the limiter *does*! Working for now. Perhaps I need to start over with default settings to see what happens, but, no time for that now. Limiter working good enough for now. One day, likely when some update says I must default the router settings again, I will start over on QOS to see if anything works differently at that time.

I actually limit the upload of the offsite backup machines to 50% of the upload bandwidth. Seems to work great, as you say, latency too high otherwise. And, I don't have lots of machines doing lots of things at the same time typically.

QoS is hard enough to trouble-shoot when the QoS is properly functioning.

I know pfSense has a easy way of monitoring the data passing through individual queues. There are even ways of using tcpdump to view the raw traffic with artificial (never actually transmitted across the wire) tags showing what queue the packet was assigned to, if you want to 100% confirm your configuration.

Tomato may also have easy ways of monitoring a particular queue's traffic, but I am not sure.

Dunno about AsusWRT.

 

[RMerlin]

QoS is hard enough to trouble-shoot when the QoS is properly functioning.

I know pfSense has a easy way of monitoring the data passing through individual queues. There are even ways of using tcpdump to view the raw traffic with artificial (never actually transmitted across the wire) tags showing what queue the packet was assigned to, if you want to 100% confirm your configuration.

You can also view the queue content using the Linux tc tool, but I don't know how. The Tomato forums had a post on this a few years ago.

 

[Nullity]

You can also view the queue content using the Linux tc tool, but I don't know how. The Tomato forums had a post on this a few years ago.

Possibly "tc -s qdisc".

For anyone confused by "qdisc" (I was), it means "queueing discipline". Nothing to do with discs...

@RMerlin Would it be super hard to make pretty graphs showing queue bandwidth from the "tc" information? Edit: I guess some /dev or /sys file would be a better source of information though.

 

[RMerlin]

@RMerlin Would it be super hard to make pretty graphs showing queue bandwidth from the "tc" information? Edit: I guess some /dev or /sys file would be a better source of information though.

Yes. Any kind of chart/graphic design is very time consuming to implement. I've never developed any in Javascript, for starter.

 

[Etz]

As AsusWRT has SNMP support, why not to graph it via SNMP to outside device, for example Raspberry PI running Cacti?

 

[Nullity]

As AsusWRT has SNMP support, why not to graph it via SNMP to outside device, for example Raspberry PI running Cacti?

Use SNMP to communicate queue stats?

Is such a thing plausible?

(I have no experience with SNMP.)

 

[Etz]

Not sure what OID`s are available on AsusWRT via SNMP, but it is definately plausible...
And as I read this topic, only viable solution.

I have not snmpwalked it, so I cannot comment if that is actually doable ,as I have no idea what data is exactly available via SNMP.