1

I have the privilege of trying to optimize our network at work to help improve the quality of the voip system we have. The general setup is:

  • Bandwidth is 18 Mbps down, 3 Mbps up.
  • ~10 people in office with max ~5 tje on phone at any time.
  • One consumer grade router in place between us and the cable modem: Asus RT-AC66U.

Without QoS enabled the phones work "ok", but when the network gets busy, call quality degrades. Enabling QoS seems to be the obvious solution. That's where the problem comes up.

I've enabled QoS on this router to give highest priority to destination TCP and UDP ports in the range of 10000 - 20000 and 5000 - 8999. These were the ports given to me by our voip provider as the ones to prioritize. No other traffic gets this level of priority in the QoS setup.

With this enabled, the voip quality is much worse. It's now significantly more sensitive to other network traffic. I'm at a loss. Can someone shed some light on what is going on here?

QoS settings below...

Screenshot of QoS Settings

Cristian Ciupitu
  • 6,396
  • 2
  • 42
  • 56
CJ F
  • 119
  • 3
  • 2
    `consumer grade router` <-- I would suspect your problem lies deep in the dark, unknowable heart of this device. "consumer grade" hardware tends to be pretty lousy at things like this. That said, if you want us to try to help you you'll need to (a) show us your QoS settings, and (b) show us your traffic statistics (both when things are working well and when the quality drops off). – voretaq7 May 15 '14 at 15:34
  • How can I show traffic statistics? Basically when the upload traffic approaches the bandwidth limit (~3Mb), it goes to crap. The garbling is less intelligible with QoS on. – CJ F May 15 '14 at 15:41
  • 2
    The biggest problem with VoIP is that you can't control the whole path. QoS only goes as far as your router and then the packets do as they will along the rest of the journey to their intended destination. I did a pretty thorough write-up on SU: http://superuser.com/questions/80580/how-to-improve-voip-sound-quality/323593#323593 – MaQleod May 15 '14 at 15:54
  • 1
    @CJF You will need to consult the documentation for your router for information on how to view traffic statistics. (Frankly if you don't have them already you don't *know* if your link is being saturated, though it's probably a good guess...) – voretaq7 May 15 '14 at 15:55
  • @voretaq7 Not exactly. I can watch the traffic monitor which just gives me a graph of incoming and outgoing traffic. I just watch that and correlate it with call quality. – CJ F May 15 '14 at 16:21
  • @CJF Bleh.... I guess a screenshot of that is about the best you can do then. I'm pretty sure [Mark is on the right track](http://serverfault.com/a/595340/32986) though - Your QoS probably isn't "reserving" bandwidth, so the VoIP traffic is getting jammed up in a queue. – voretaq7 May 15 '14 at 17:00

1 Answers1

4

Problem is with high contention, packets begin to queue up and VOIP packets cannot sit and wait. Are you sure you configured destination ports appropriately for traffic exiting your site? You can't packet shape ingress, only egress. Maybe you configured those destination ports for your LAN side which might include a lot of non-VOIP traffic as well

Ideally, you'd allocate a slice of bandwidth that your traffic class (VOIP) will always get no matter how congested the line is, at the expense of your other traffic (bulk, e.g.). So say, a typical VOIP call requires 88Kb/s (depending on codec), multiply that by the number of connected calls (you said 5), then round up and set that as the guaranteed minimum for your high priority class - that would guarantee VOIP ~500Kb/s of bandwidth for VOIP calls.

Honestly, for good workable QoS, you're getting into enterprise networking territory. I've had good experience with Tomato Shibby and the QoS framework/configuration built into that firmware on my ASUS routers.

Mark
  • 41
  • 2
  • For what it's worth, I do my VoIP QoS/Traffic Shaping with [`pf`](http://www.openbsd.org/faq/pf/) *pretty* successfully (we still have occasional quality issues, mostly attributable to upstream congestion). You could probably put [pfsense](http://pfsense.org) in place of your current router/firewall and get reasonable results without too much expense. – voretaq7 May 15 '14 at 17:02