Can Any Router Guarantee Bandwidth For VoIP?

cartman94501 writes "My wife and I use Vonage for Voice over IP at home, mainly for work-related phone calls so we don't have to give out our home number to clients and colleagues. Most of the time it works fine, but when I'm using BitTorrent or other high-bandwidth applications (purely for legal and non-copyright-violating purposes, of course), the call quality gets choppy. I have used my Linksys (not a WRT54G, so 'upgrading' it to Linux probably won't work) router's QoS feature to assign high priority to the MAC address of the Vonage box, low priority to the BitTorrent box, and medium quality to everything else, which helps a little, but not enough. Is there a router out there that would allow me to reserve, say, 75-90kbps of bandwidth off the top for VoIP and never, ever allow any application to use that, regardless of whether there's a VoIP call going on at the moment or not?" (More below) cartman 94501 continues: "That would solve my problem, but I fear I'd have to build a Linux box and learn all sorts of esoteric commands to really make that work. Are you aware of a commercially-available router that would allow me to accomplish this goal with some sort of ease? While I'm not prepared to pay four figures, I'm certainly not naïve enough to expect such a device to be available in the $50-100 range of your garden-variety wireless router. Wireless would be ideal, but if I could patch it in between my existing wireless router and the cable modem, and turn off QoS entirely on the existing router, that would work, too."

Comments

QOS should work

[corsec67]

QOS should work if you set it up properly.

On my WRT-54GL with Tomato (others might work, Tomato is the easiest of ddwrt, openwrt in my experience), the QOS settings can be limited in just the way you want, with everything except the highest only being allowed only 75% of your upload, or whatever you want.

Downstream is a bit harder to restrict, since the queue is on the Telcom side of things, but you could do some QOS in your router there as well.

Once you're past the router...

[Ungrounded Lightning]

Once you're past the router you'll also have the problem that your ISP may not be honoring the QoS tagging of the VoIP traffic or otherwise identifying it and giving it priority. (In fact they may chose to identify it and give it LOWER priority if it's not theirs.)

So fixing your router may only be half the solution: It may throttle back your BitTorrent traffic to keep from stepping on the VoIP packets on the way to your ISP's first box, only to have it stomped by somebody ELSE's BitTorrent (or whatever) traffic on the next hop.

This, by the way, illustrates both halves of why "network neutrality" can't be just "treat all packets the same". You have to give the VoIP packets priority in scheduling over the BitTorrent packets to get them to work well (which doesn't do anything but slightly slow BitTorrent). But the tools to do that also give an ISP the ability to give the VoIP packets for their high-dollar service priority over BitTorrent while letting their competitors' VoIP packets fight it out, or even be handicapped further. Now try writing legislation to mandate the first while forbidding the second.

Re:Gaming Router

[timeOday]

Since I run a PVR/Webserver at home anyways, I did just that (routed all traffic and ran lartc to prioritize VOIP) for a couple years. But in the end, I stopped because the uptime wasn't good enough for phone service. A fan in the PC fails = no phone until you get a new fan. In my experience a router device with no fans and no hard drives is much more reliable, so I took the PC out of the loop. The downside is now bittorrent messes up the phone again.

PS you don't need to statically reserve upstream for the phone, just set VOIP to have the highest priority, then limit total upstream to about 10% less than your ISP upstream so your modem buffers don't fill up. However, nothing will save you if your ISP isn't delivering reliable upstream bandwidth.

Re:Gaming Router

[c_forq]

Couldn't you do a low heat/low power CPU that doesn't need active cooling, RAM, and a USB thumb-drive to boot off of?

You are Doing it Wrong: you need THROTTLING

[IBitOBear]

I use a reasonably cheap PC setup for my boarder router (used to be just a 486) and have flawless Vonage VoIP service.

The thing you are doing wrong is that you are not _THROTTLING_ the link from your router to your cable modem.

In point of fact, and sadly, there is virtually no buffer for outgoing data on a cable modem. If you are configured for 768kbps upstream then sending data any faster than that will lead to all sorts of misery.

So in a properly configured firewall you want to throttle your _outgoing_ data to about 99% of your rated upstream bandwidth and _then_ use packet shaping to make sure that the right kind of packets get to "go first" in the QOS stack.

This turns your router into the buffer that your boundary modem lacks and will both make your VoIP flawless _AND_ _VASTLY_ improve your TCP/IP (web etc) throughput.

I have six ranks in my QOS gateway:
1) TCP ACKs (actually tcp packets less than 80 chars in length)
2) SSH (for emergencies)
3) VoIP (udp from my vonage device)
4) special occasions (none of your business 8-)
5) Games (udp in general)
6) Everything else.

Doing both of these things together will speed up everything in your house (including bittorrent) and leave you with outstanding voice quality even when gaming and running bittorrent while watching video on demand.

If found the basic rules files searching aroud the net, and then tweaked them with dynamic math and weightings.

Flawless.

Re:Gaming Router

[cciRRus]

I'm not sure how you found your WRT54G lacking in CPU power because on my WRT54G v4, I had actually underclocked it to 183MHz and yet it worked just as well.

I run BitTorrent actively on two separate PCs, and at the same time, we have VoIP and we play delay-sensitive online games.

I did some crucial settings though... like setting the correct upstream and downstream capacities, reducing the TCP and UDP timeouts, and using HFSC as the packet scheduling algorithm (some have reported to try HTB if HFSC fails).

Re:Not actually true, you are doing it wrong... 8-

[ciscoguy01]

The OP doesn't say but probably doesn't have a cable modem, he more likely has ADSL from the phone company.
I have fought those problems with VOIP and a poor DSL line. With a WRT54G and that optional firmware, and it was an abject failure. We couldn't solve the ADSL line problems at our end.
The solution is probably going to be calling his provider and demanding they give him the speed he is paying for, and if he's not paying for enough speed he may have to pay for more line speed.

The trouble with DSL is it is not guaranteed bandwidth. It can completely stop working for more than enough time to screw up VOIP and there is likely nothing he can do about it.
Cable modem service is typically enough faster than ADSL from the phone company he is much less likely to have these sort of problems, unless maybe his provider has installed Sandvine traffic management equipment and that is screwing him up detecting his P2P usage and throttling his circuit. I don't know if Sandvine equipment throttles the whole circuit or not. Does it? Does anyone know?

The funny thing is you would never have these problems on an ISDN circuit, which though slow by todays bursty ADSL standards is guaranteed bandwidth, just like that corporate OC-48 you have at work. You get two FM radio quality voice channels on ISDN and it does work, guaranteed. If not they *have* to fix it.
Whereas on ADSL they just say "sorry bub". Then they maybe say "If you got your VOIP from us I bet it would work". But only because in that case they would *have* to fix it. Evil telcos, to be sure.