Forgot your password?
typodupeerror
Communications Networking Hardware

Can Any Router Guarantee Bandwidth For VoIP? 414

Posted by timothy
from the garbly-in-garbly-out dept.
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."
This discussion has been archived. No new comments can be posted.

Can Any Router Guarantee Bandwidth For VoIP?

Comments Filter:
  • Gaming Router (Score:5, Insightful)

    by seanalltogether (1071602) on Thursday June 26, 2008 @07:06PM (#23959145)
    Most gaming routers allow for this kind of functionality. In fact the first search result on google for 'gaming router' brought me to a product from dlink that provided exactly that.
    • Re:Gaming Router (Score:5, Informative)

      by OAB_X (818333) on Thursday June 26, 2008 @07:13PM (#23959297)

      While limiting bandwidth might help, VOIP applications are much more sensitive to ping than BitTorrent, so even if you save bandwidth just for the vonage box, you will still need to customize packet priority. My D-Link gaming router has some ability to do it, but if you want real QoS stuff, a linux firewall box is the way to go.

      • Re:Gaming Router (Score:4, Interesting)

        by timeOday (582209) on Thursday June 26, 2008 @07:40PM (#23959683)
        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 (Score:5, Informative)

      by Telecommando (513768) on Thursday June 26, 2008 @07:15PM (#23959343)

      So don't keep us in suspense submitter, which model do you have?

      You can load software on more than just the WRT54G.

      DD-wrt works on quite a few devices:
      http://www.dd-wrt.com/wiki/index.php/Supported_Devices [dd-wrt.com]

      Used Linksys APs are fairly cheap and available. I bought a used WRT54GS V2.1 last weekend for $30. Loaded DD-wrt on it this afternoon.

      • Re: (Score:3, Informative)

        by bfizzle (836992)

        The problem I have ran into time and time again is the WRT54G just doesn't have enough CPU power and RAM to handle the mess torrents make. Throw VOIP into the mix everything comes to a stand still.

        I used pfSense but several distros as supported by some micro pc manufactures.
        http://www.pfsense.org/index.php?option=com_content&task=view&id=44&Itemid=50 [pfsense.org]

        I'm currently running a NetGate device with a 500MHz AMD Geode processor and 256MB of RAM. $200 is a little bit on the pricey side, but it is tiny

        • Re:Gaming Router (Score:5, Interesting)

          by cciRRus (889392) on Thursday June 26, 2008 @08:55PM (#23960653)
          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:Gaming Router (Score:4, Informative)

            by jimfrost (58153) * <jimf@frostbytes.com> on Friday June 27, 2008 @03:22AM (#23963777) Homepage
            Let me pile on to this as well. I have a WRT54GL acting as my router. While I eventually gave up on Vonage I ran it plus my regular loads (web server, a whole lot of SMTP, bulk downloads, interactive browsing) simultaneously for a couple of years.

            The stock Linksys firmware didn't do it; its QoS features were pretty much worthless IMO and the stock tuning was regularly overloaded due to too-long TCP timeouts and the pounding the thing got from The Bad Guys.

            DD-WRT allowed me to tune the settings to the point that it worked slick-as-you-please. There were a couple of critical settings.

            First, I boosted the number of active connections allowed to the maximum, 4096. Second, I dropped the TCP/UDP timeout to 10 minutes. These two made all the difference in terms of stability; without them the connection count would rise to saturate the table and things would fall apart fast.

            With stability in hand the next thing to do was QoS. I chose to cap bandwidth at about 80% of available and then give priority to the Vonage box's port. This worked neat-as-you-please; the phone never had dropouts and everything else kept going smoothly.

      • Re:Gaming Router (Score:5, Informative)

        by duffbeer703 (177751) * on Thursday June 26, 2008 @10:33PM (#23961645)
        To hell with DD-WRT, Tomato is a much, much better firmware with QoS services that work better than the Cisco gear I have at work. You can prioritize traffic to/from hosts, specific ports or even application signatures (note that if you do alot of sig matching it may affect performance)

        I have a RR Pro account, and I can have a torrent box churn away while I play Counterstrike and my wife talks on the VoIP phone with zero problems.
    • Re:Gaming Router (Score:5, Informative)

      by bonehead (6382) on Thursday June 26, 2008 @08:04PM (#23960021)

      Most gaming routers allow for this kind of functionality. In fact the first search result on google for 'gaming router' brought me to a product from dlink that provided exactly that.
      Not exactly true. Sure, it might be a bullet point on their feature list, but in practice it doesn't really work.

      I've installed many VOIP systems in small to medium sized companies, and back when I first started doing it I learned a valuable lesson:

      Your router can only control what it sees.

      Seems obvious, but let's consider the implications.... Your router cannot do anything of meaning about incoming data. By the time your router sees it, it's already traversed your cable or DSL line and the damage has been done. Something like bittorent is throwing a ton of incoming bandwidth at you, and there's not much a consumer grade router can do about it.

      The way I approach it is to use a small, but fully functional Cisco router at the client side, and work with a mom & pop ISP who will also throw some QoS on their router for that link. I won't accept a job installing a VOIP system for a client who isn't willing to go that route.

      You have to give the *incoming* VOIP priority over the incoming torrent traffic, and for good results, this must be done at the ISP, before it has already clogged up your personal "last mile" link.

      If you want to run bittorrent and VOIP on the same connection, you need a *real* router, and a cooperative ISP.

      Torrents kill VOIP. The method I outlined is the only way, after several years of trying every idea and product out there, that actually produces reliably stable results.

      • by IBitOBear (410965) on Thursday June 26, 2008 @09:01PM (#23960719) Homepage Journal

        What most people don't understand about TCP (and therefore bittorrent etc) and Cable Modems could fill a book.

        The thing most people don't understand about cable modem is that it has virtually no buffer for outbound traffic (e.g. the traffic you do control) so subsequently it is almost a given that you will overrun the transmit buffer on your cable modem doing the simplest of things. This in turn will destroy all your throughput because...

        The thing most people don't understand about TCP is that it accelerates linearly and falls back exponentially. So whenever you drop an acknowledgment frame (outgoing) then your incoming data session tends to stumble to a near halt. (that is each successful frame you send increases the transmit window by one frame, but each failure cuts the transmit window in half, and most failures cause at least two drops.)

        This can be seen when you use a "near by" internet speed test (a la speakeasy) and you see the speedometer surge and fall like someone revving their engine. But each "fall" is actually a bunch of trash hitting your system and then getting discarded as the stream colapses back on itself.

        Now for a cable modem provider, they have no interest in throttling data coming to you to your downstream cap. That would be expensive and would just clog up the memory in their routers. your downstream limit is really implemented as an aggregate of your upstream capabilities and how their time division multiplexer is configured to cascade into statistical multiplexing. (See Comcast's "speed boost" as an example of free-wheeling and only cutting back if it must.)

        So anyway, I have posted my firewall and traffic shaper scripts to my slashdot journal. They are drop-in ready for Ubuntu and Slackware, minimal editing may be needed for RedHat or others.

        Try them out. Be particular to tune the top of the shaper file for the upstream speed to match your _advertised_ cable modem rate (INTERFACE_SPEED=768 in the file) and then you can fine tune the numerator part of the fraction in CEILING=... (98 worked best for me).

        I get my full 8M down PLUS whatever speed boost is doing (24M down often) and my VoIP works great, even during peak usage etc, while people are gaming and web surfing in the house (my house is a high usage environment with multiple housemates skyping and gaming etc).

        On top of that, the script is actually _BENEFICIAL_ to my ISP. By shaping my outgoing traffic I waste virtually zero bandwidth on retransmits so I am a great net citizen.

        (If you set your firefox to enable pipelining and set max pipeline requests to a value like eighty (yes 80) you will find that you are a most efficent and therefore quite spunky web citizen.)

        Share and Enjoy...

        • by NormalVisual (565491) on Thursday June 26, 2008 @10:14PM (#23961477)
          What most people don't understand about TCP (and therefore bittorrent etc) and Cable Modems could fill a book.

          Hence the reason one can find books on these subjects. :-)
        • by ciscoguy01 (635963) on Friday June 27, 2008 @01:59AM (#23963261)
          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.
      • Re: (Score:3, Interesting)

        by ACMENEWSLLC (940904)
        >>You have to give the *incoming* VOIP priority over the incoming torrent traffic, and for good results, this must be done at the ISP, before it has already clogged up your personal "last mile" link. I concur. While I use QoS to rate limit incoming connections to many T1 & frame links, there is just so much you can do with an incoming stream which is congested. We have a Packeteer 6Mb/s device at Corp throttling about 10 remote sites. Handles incoming/outgoing pretty well. But when the incom
      • Re: (Score:3, Informative)

        by batemanm (534197)

        Your router can only control what it sees.

        Seems obvious, but let's consider the implications.... Your router cannot do anything of meaning about incoming data. By the time your router sees it, it's already traversed your cable or DSL line and the damage has been done.

        For TCP connections your router could control the window size of the connection by rewriting outgoing packets. If you put a cap on the window size it would keep your throughput low. Your router would need to keep some state on TCP connections, you could probably get away with just the number of active TCP connections. Of course this wouldn't help with anything UDP based.

    • Re:Gaming Router (Score:5, Insightful)

      by Binestar (28861) on Thursday June 26, 2008 @09:59PM (#23961347) Homepage

      You can just get the Vonage Linksys: WRT54GP2. Has built in vonage and QOS for it.

      • Re: (Score:3, Informative)

        by RandyOo (61821)

        You can just get the Vonage Linksys: WRT54GP2. Has built in vonage and QOS for it.

        Yeah, then watch it crash on a daily basis if you try to run bittorrent? No thanks. (speaking from experience here)

        After plenty of trial-and-error, I've found a router with Tomato installed and QOS properly configured to be the best solution.

  • Tomato (Score:2, Interesting)

    by Anonymous Coward

    Perhaps try picking up a WRT54GL and installing Tomato on it.

    • Re: (Score:3, Interesting)

      by ScrewMaster (602015)
      I agree. I was running Smoothwall for a while, but then I got hold of a WRT54GL V4 and started playing around with alternate firmware. I eventually settled on Tomato. I use AT&T's CallVantage VoIP service, and it works great with Tomato. I can have my line maxed out running a bunch of torrents, or playing live video from Netflix, and the phone never stutters.

      Frankly, I think Linksys ought to hire the guy that wrote Tomato. His stuff is light years ahead of the stock firmware.
  • Build one... (Score:5, Informative)

    by kwabbles (259554) on Thursday June 26, 2008 @07:11PM (#23959227)

    www.ipcop.org
    www.endian.com
    www.smoothwall.org

    Full-featured firewalls, will run on old crappy hardware you got laying around the garage. All you need is two NICs. Viola. QoS no problemo.

  • Voip packet queuing (Score:5, Informative)

    by whatmot (756982) on Thursday June 26, 2008 @07:11PM (#23959233)
    I use a Dlink appliance that works well, requires zero configuration and is placed in between the router and the modem - Voip Internet Accelerator Intelligent Packet Priority Engine Manufacturer Part Number: DI-102 Never had a single problem over more than a year of use.
  • by fat_mike (71855) on Thursday June 26, 2008 @07:11PM (#23959235)

    If you're running a business, your first worry should be about servicing your customers not using Bittorent. Get another DSL/Cable/Wifi connection for your business and run your VOIP over that.

    If you only need the limited bandwidth that you are looking for you'd be fine with the lowest speed (read cheapest) connection any ISP offered.

    • by geekoid (135745)

      true, OTOH if there is a solution for this, why not use it?

    • by mollymoo (202721)
      If you're using it for work get work to pay for a second phone line and unplug it after hours.
    • If you're running a business, your first worry should be about servicing your customers not using Bittorent. Get another DSL/Cable/Wifi connection for your business and run your VOIP over that.

      Excellent suggestion! Instead of a one-time cost of $50 for a gadget to salve the problem the submitter can pay $50 every month! That ought to stimulate the economy!
  • bittorrent latency (Score:3, Informative)

    by markjhood2003 (779923) on Thursday June 26, 2008 @07:12PM (#23959249)
    Interesting exploration of the issues here: http://www.formortals.com/Home/tabid/36/EntryID/57/Default.aspx [formortals.com]
  • QOS should work (Score:5, Interesting)

    by corsec67 (627446) on Thursday June 26, 2008 @07:12PM (#23959251) Homepage Journal

    QOS should work if you set it up properly.

    On my WRT-54GL with Tomato [polarcloud.com] (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.

    • Re:QOS should work (Score:5, Informative)

      by pyite (140350) on Thursday June 26, 2008 @07:36PM (#23959631)

      QOS should work if you set it up properly.

      No, it shouldn't. QoS only works on egress. You can't do any meaningful ingress QoS. All you can do is stop packets from coming past the router. That doesn't address the real problem which is that the ISP link is maxed out. In fact, if you start dropping TCP data that's in a lower priority queue than your UDP voice, it will cause even further issues as the sender will retransmit those lost TCP packets.

      • Re: (Score:2, Insightful)

        by wolf12886 (1206182)
        I wish I had mod points today, most people don't understand this, and wonder why even throttled BT kills their connections.
      • It will work if (Score:3, Interesting)

        by addikt10 (461932)
        Actually, yes it should, as long as you also set your bit torrent to use a maximum of download bandwidth, and report as choked to the "supplier".
        • Re: (Score:3, Informative)

          by pyite (140350)

          Actually, yes it should, as long as you also set your bit torrent to use a maximum of download bandwidth, and report as choked to the "supplier".

          My parent was talking about QoS at the router, not at the application. There's a difference. In any event, bit torrent is one protocol. The original question was more general and mentions "other high-bandwidth applications." Most protocols have no BCN (backwards congestion notification) nor is there any link layer method for allocating bandwidth a la fibre channel,

      • Re:QOS should work (Score:5, Informative)

        by ArbitraryConstant (763964) on Thursday June 26, 2008 @10:45PM (#23961755) Homepage

        No, it shouldn't. QoS only works on egress. You can't do any meaningful ingress QoS. All you can do is stop packets from coming past the router. That doesn't address the real problem which is that the ISP link is maxed out. In fact, if you start dropping TCP data that's in a lower priority queue than your UDP voice, it will cause even further issues as the sender will retransmit those lost TCP packets.

        You can indeed do ingress QoS. It's not as good as egress, but it's a very good approximation that provides perfectly adequate results in most situations. In response to packet loss, TCP and other protocols throttle themselves. You're helpless if someone wants to DoS you, but in almost any circumstances short of that, you'll be okay.

        What you do is figure out your real-world downstream speed, then set your downstream speed to somewhat less than that (say 80%) to allow for a bit of overflow from TCP retransmits and higher priority traffic. Give the higher priority traffic a big queue that doesn't drop packets (eg no RED), and you'll get very good results unless someone is really out to get you.

        The inability to QoS ingress traffic is very widely accepted, but what people neglect to consider is that we can use an approximation. A lot of problems never get solved beyond workable approximations. You're not going to get a network suitable for hard realtime data, but it'll be good enough for VoIP.

    • In my experience DD-WRT QoS features don't work in the latest release. You're better off buying a tomato compatible router and flashing it with that firmware. The other option is OpenWRT but after reading the installation guides it doesn't seem so easy to get working.
    • by afidel (530433)
      For VoIP there's really no need for QoS on the downstream. Personally I've found that the best QoS is to simply limit my torrent client to about 1/3rd of my total available (150/500 kbps) upload bandwidth. That works better than the QoS on any low or midrange router/firewall I've ever run.
    • Seconded for Tomato (Score:4, Informative)

      by PCM2 (4486) on Thursday June 26, 2008 @08:02PM (#23959975) Homepage

      I also use the Tomato firmware on a WRT54G, and I have exactly the kind of setup the OP describes. I don't even remember what kind of QoS came with the default firmware, but I never had any kind of luck with it, nor with DD-WRT. Tomato has been great so far.

      Tomato actually offers fairly sophisticated QoS rules. You can set priorities by MAC address, IP address, port, etc. You can even set bandwidth caps for specific protocols/ports; so, for example, you can set the first 512KB of data transferred over port 80 to "Highest" priority, while anything after that drops back down to "Lowest" -- the effect being that regular ol' Web surfing gets a little kick in the pants, but extended transfers are given less priority. The latest release even added the ability to prioritize small packets (ACK, SYN, etc.)

      What's more, Tomato also offers really neat graphing of your traffic. You can actually see, in near real time, what percentage of your outbound traffic falls under which priority category, with a nice pie graph. This is especially helpful when you want to double check that your rules are actually working (and you didn't make a typo when you were entering in a Mac address, for example).

      One thing to remember when you're setting up QoS on a router like this, though, is that you need to reserve a certain amount of upstream bandwidth just to manage to QoS overhead. So, say you have 384KB/sec upstream bandwidth. You'll probably want to tell the router to reserve 40KB/sec or so for QoS. YES, that means your maximum upstream bandwidth will in effect be lower than what your provider advertised; call it the cost of doing business with QoS.

      I have no empirical measurements to offer. All I know is that with the original, official WRT54G firmware and also DD-WRT I saw virtually no difference whatsoever when QoS was enabled. My outbound voice quality on my VoIP line was very choppy, particularly (but not limited to) when I was doing BitTorrent. With Tomato, on the other hand, there seems to be a marked improvement. I can actually hear the difference when I check and uncheck the "enable QoS" checkbox.

      • by PCM2 (4486)
        Incidentally, other posters are correct when they say that QoS can only really manage your upstream bandwidth. When I say the voice quality was bad, I'm talking about the sound of my own voice. The way I check the quality is by calling a different number and leaving a voicemail message. Everything sounds fine to me when I'm speaking, but the voicemail message tends to sound pretty choppy upon playback if there was other traffic on the line at the time and QoS was not enabled.
  • ISP to blame? (Score:3, Insightful)

    by jrronimo (978486) on Thursday June 26, 2008 @07:12PM (#23959253)
    I have heard that most ISPs put VOIP packets on super-low priority anyway, so even your setup at home won't affect it a whole lot. I may have heard wrong, though.
    • by billstewart (78916) on Thursday June 26, 2008 @07:57PM (#23959913) Journal

      There are a few ISPs that have blocked VOIP, mostly (ex-) monopoly telcos in various countries that want to charge you by the minute for voice. But most ISPs, and especially non-telco ISPs, don't care, because voice doesn't use that much bandwidth (especially if you're using compression.) BitTorrent's a different game - it's using something in excess of 1/3 of the bandwidth on the internet, so there are reasons for some ISPs to care about it other than just greed and spite :-)


      The real problem is that ISPs don't put VOIP on high priority, and applications like BitTorrent, ftp, and to some extent http want to suck down all the bandwidth they can get and fill up any network queues they can to keep the data flowing. ISP backbones are fat enough that it doesn't matter that they don't prioritize VOIP, but the link from their last switch or router to your house is a finite size, and BitTorrent can not only crowd out the downstream link, but can queue up enough packets that your VOIP traffic needs to wait a while for its packets to get through, and the gaps kill your audio quality.


      Also, the most critical thing for your router to control is prioritizing VOIP packets on the upstream, but apparently that wasn't enough to keep the article poster's calls working well.


      don't know if you were serious or trolling anyway...

    • I have talked with a number of clients and friends that have had their Vonage service unofficially blocked by Comcast.

      As a side not I have also had plenty of clients have their IPSEC VPN traffic blocked by Comcast as well.
  • One packet at a time (Score:5, Informative)

    by feenberg (201582) on Thursday June 26, 2008 @07:13PM (#23959273)

    Suppose your upload speed is 150Kbps. A single bittorrent packet is 15,000 bits, so it takes a tenth of a second. If there is a bittorrent packet in the router when the VOIP packet arrives, the VOIP packet still has to wait for the bittorrent packet to finish, which means waiting up to a tenth of a second. Even though the VOIP packet always gets priority over other waiting packets, it will often arrive when the router is otherwise engaged, and therefore likely to endure a tenth of a second delay, which is probably noticable. I suppose reducing the MTU might be a help.

    • by afidel (530433)
      Yeah setting my PC MTU to 576 instead of 1500 made a big difference for me, not as much as limiting my upload in the torrent client, but the two together work very well.
  • http://openwrt.org/ [openwrt.org] (extend yourself, open, maybe takes longer to set up)

    http://www.dd-wrt.com/dd-wrtv3/index.php [dd-wrt.com] (web interface like normal, just tons more options)

    both should do the trick and maybe even run on your router

    check:
    http://www.dd-wrt.com/wiki/index.php/Supported_Devices [dd-wrt.com]

    • I have installed DD-WRT on many Linksys WRT54G's like the poster said he has. I find it to be very useful and I find the vpn endpoint capabilities totally amazing. One thing to look out for is the version of the default firmware. Versions 1-5, installing is like a walk in the park. Version 6 needs a bit of voodoo trickery and more 3rd party software. All of that is documented on DD-WRTs Hardware Compatibility List under Linsys [dd-wrt.com]. Version 7 is unsupported altogether so I would recommend fleabay for an older mo
  • by Lord Byron II (671689) on Thursday June 26, 2008 @07:14PM (#23959307)

    I have the Sunrocket "widget" (Linksys voip adapter) plugged directly into my dsl modem, and my router plugged into the widget. The widget is supposed to give its own data priority, but I've never seen any evidence of that.

    But if all you care about is keeping BT from using the last XX amount of bandwidth, just dial your max upload and download speeds down in the BT client.

  • by grandfenwick (31075) on Thursday June 26, 2008 @07:15PM (#23959341)

    Between the modem and the router. Hook the phone into the adapter as usual.

    The adapter is what guarantees bandwidth for your phone.

  • Purchase a WRT54GL (not any other WRT54G, unless you know what you're doing) and install the Tomato firmware on it. Not DD-WRT, not OpenWRT or any of the others. Tomato has better QoS and Traffic shaping functionality than most commercial firewalls I run.
  • You answered your own question, buy a newer Linksys (or other supported brand) router model that you can get one of the many Linux firmwares (dd-wrt, open-wrt, etc.) onto. They all have QoS sections in their web gui's that are somewhat simple to use. The big thing to remember though is that bit torrent uses hundreds of connections that can build up at the ISP side and give you horrible latency and jitter so to avoid that you may have to severely restrain your torrents.

  • by acvolt (241850) on Thursday June 26, 2008 @07:16PM (#23959363)

    The problem is related to the amount of traffic coming to you from the internet. No amount of QoS applied to your router will be able to shape the traffic that is piling up against the provider's side of the link to your house. That leaves you with 2 options:
    1. If your BitTorrent client supports it, set the maximum download rate to less than what your internet connection speed is. I won't guarantee this will completely solve the issue, but it should help.
    2. Don't download big files while you are using your VoIP phone.

    • Most BitTorrent clients allow you to control the upload and download bandwidth consumed by the torrent(s). Limit the total of your torrents to about 1/3 of your measured (as opposed to advertised) available bandwidth in each direction. I had the same issue with VPN connections to remote desktops and found that this was enough to restore performance.

      If the torrents are saturating your bandwidth, there isn't a lot a router can do with QoS to avoid choppiness. And if you keep your torrents to less than hal
    • The built in QoS on all the open linux firmwares only does outbound QoS. You can use iptables on the linux firmware to do prioritization. Slashdot's filter won't let me post the script because of "too many junk characters" so sorry I can't post it. I didn't make the whole script up myself. There is a program called WRT54 Script Generator v1.02. What I've done is prioritize nntp based on ports and gave it 2-5000Kbps and TCP on port 80 and port 443 to something like 90% minimum of my max connection speed
  • ...I called my VOIP provider (PrimusTel) and talked technically to the representative on the other side. I asked him to increase the compression ratio to allow near quality calls. I also used the web interface and "told" my router that trhe maximum available bandwidth available was 50kbs.

    This has worked for me, no regrets.

  • by Ungrounded Lightning (62228) on Thursday June 26, 2008 @07:18PM (#23959381) Journal

    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.

  • BitTorrent Client (Score:2, Interesting)

    by Bobfrankly1 (1043848)
    I know you're looking into the router, but another option is to impose a limit in your BitTorrent client. I know UTorrent has functionality for restricting upstream and downstream speeds. Perhaps the client you are using has the same capabilities. Or perhaps I'm just made a worthless point, let the mods decide!
    -
    Soon to be modded -5 retarded, Bob
  • by DeadBeef (15) on Thursday June 26, 2008 @07:25PM (#23959501) Homepage

    Short answer, not really.

    Longer answer, any circuit where you don't have a predictable amount of bandwidth will be hell to build any QoS with. Pretty well any home user connection will be in this class. Most of the cheap consumer devices that claim to do this are relying on tricks that won't work in a heap of cases or worse are snake oil.

    No device is going to be able to do a good job without a heap of background information on what your connection is an how it behaves, things like when the buffers for outbound traffic on the other end of your DSL line kick in and behave etc.

    If you want to learn a whole bunch of esoteric commands and a bit about networking you should be just fine building something to do it with a Linux box =)

    Alternatively you might get a 95% successful solution if you buy a consumer device and shape the internet facing interface down to a speed that you hope your circuit will never drop below.

  • Bandwidth is important to make sure your data arrives in a timely manner. However, there are other considerations when you are dealing with VOIP- mainly packet order and jitter.

    I would recommend that you do a packet capture (wireshark) and take a look at the time between packets arriving. Also, pay attenation to sequence numbers. One or two every here and there can be compensated with, but if yours or the ISP's router buffer is delivering packets out of order (or even worse, dropped packets), then that's

  • My SpeedTouch 546 will do this, I think all the SpeedTouch routers will. I don't think you can do it with the web interface, but you can with telnet or by editing a config file. You just turn IPQoS on and the default ruleset prioritises VOIP and shares bandwidth fairly between the four ethernet ports. In fact, it might be on by default.

    Speedtouches are very capable little routers under the hood. In addition to the usual 1:many NAT, firewalling and port forwarding, mine is currently also doing proper NAT (I

  • You can shape the outgoing traffic, but not the incomming one. Even if that is bandwidth-limited by the application, different bittorrent senders will create bursts of incomming traffic when their traffic combines. There ia absolutely nothing you can do about this, except haveing more bandwidth available than the combined maximum burst speed of the incomming traffic.

  • It isn't "esoteric". Do some research and you will find it is not that hard, and it does work fine. However, I have to dump Vonage anyways... Even with it being plugged DIRECTLY into the cable modem it doesn't work as well as it should. I've been a Vonage customer for 3 years...and I'm canceling my number this weekend to switch to Skype. I have had zero Skype problems whatsoever, and it is 1/3 the cost for the same features (minus 911, but you can always call the emergency departments directly)
  • VOIP traffic needs to get good bandwidth in both directions - inbound and outbound. Your router can prioritize outbound traffic so that VOIP packets always go first (assuming it can recognize VOIP), but there's it can't control inbound traffic because the bottleneck in that direction is the DSL/cable link from your broadband provider to your router, not the Ethernet from the router to your PC. In theory, your ISP could offer QoS features and if the people you're talking with sent you properly marked packe

    • In theory, your ISP could offer QoS features ... but it practice that never happens with consumer-priced services.

      For good or ill, I bet that will change (at least at the cheap "home" end of the ISP market). At least one ISP in the UK does this - VOIP etc. sits at the top of the table, so-called "interactive" traffic such as web browsing is next, and P2P scratches around on the floor.

      It'd solve your problem, but at the expense of your P2P traffic being slow because everyone else is browsing the web. You pays your money and takes your choice...

    • by mzs (595629)

      This is the finest answer. I would like to add that a simple thing to do regarding the 'messing with queuing and TCP ACKs' is to simply drop the inbound packets over a set limit. Yes this is yucky and it causes the retransmits but each time it happens the sender will halve the transmit window thinking it has detected congestion. It is pretty easy to make some firewall rules this this as well, but the easy rules do not take into account the sending host but an aggregate per type. This ends-up leading to slow

  • by Adeptus_Luminati (634274) on Thursday June 26, 2008 @07:39PM (#23959669)
    Firstly, there are routers out there, or perhaps more specifically, firmware (i.e. DDWRT), which support detailed QoS schemes such as allocating 100Kbits for VoIP at high priority, 512K for http web surfing at medium priority and whatever is left over can be used for torrenting.


    What such routers are doing is only "outbound packet DSCP marking". In English this means that once you configure such routers, only the packets that you send out to the Internet will be marked to exibit the behaviour you desire; however... and this is a BIG however, the fact of the matter is that:


    1) Whilst you have marked some packets high, medium and low pririty, your ISP and every other Telco/ISP on the Internet may completely ignore those markings (preferences) of yours.


    2) In fact, some of them may "remark" all your packets back to the same level, effectively disabling QoS.


    3) Most routers mark packets outbound, and little emphasis is placed on inbound marking. This is because by the time the packet gets to you, unless YOUR router is saturated the packet will get through with low latency.


    In order for QoS to work effectively the following things must be in place:


    1) Every single network device along your network path must support QoS. This is NOT the case with 99% of the Internet. Not because the routers aren't capable of such, but rather because the ISPs disable this function for customer marked traffic.


    2) Even if every network device from your home PC, router, to your ISP, the 6 telcos in the middle of the Internet cloud and your destination website in China supported QoS, chances are they would not all agree on what each marking would mean, and therfore they would interpret them incorrectly (from your perspective).


    3) QoS only comes into effect when a network point is saturated, during all other times of bandwidth being available, QoS has next to no effect.


    Further,


    VoIP is UDP based, and is highly sensitive to latency. The Internet is a place where latency is highly unpredictable and the more network hops (the further geographically) your packets have to travel, the higher the end to end latency will be; as such, VoIP is likely to remain a low quality voice transport for a while. Contrastly, your analogue telephone line, when you make a call from US to China, actually reserves an entire set of *dedicated* DS1 (64Kbits/sec) analogue pipes from one end to the other. In other words, there is zero sharing; hence the guarantee and high quality.


    Perhaps one day, when all the major Telcos and ISPs have more pipe than they know what to do with, long distance VoIP will come close in quality to analogue phones... until then it's a complete crap shoot. You might get amazing quality to some locations on some days, at certain times 99/100 times, and to other locations 80/100 times the VoIP call is utterly useless.


    In resume, you can tweak your home router all you want. It might help slightly since your router would become a saturated network point due to you using bitorrent simultaneously; however, the other 8+ hops to get to "China" are completely out of your control.


    My recommendation is that if you have a say 1Mbit Up/Down pipe for broadband internet; that before you make your VoIP call, that you throttle your bittorent software (in the software itself) to use only 850Kbits up/down. VoIP protocols can suck up anywhere between 8Kbit/sec (highly compressed) to 110 Kbits/sec (uncompressed). So by leaving 150Kbits for VoIP, there's a good chance the VoIP and torrents can co-exist peacefully.


    Cheers, ADeptus

    • Re: (Score:3, Informative)

      by ClownPenis (1315157)

      ....

      3) Most routers mark packets outbound, and little emphasis is placed on inbound marking. This is because by the time the packet gets to you, unless YOUR router is saturated the packet will get through with low latency.

      "outbound" depends on your perspective. "YOUR router is saturated" (If your router is saturated, I would recommend drying if out.) Usually the links that routers are connected to become saturated. Marking the pakets on the way in may or may not happen, but the net result would be the the same. (Unless your WAN (outbound) connection was faster than your LAN (inbound)).

      Further,

      VoIP is UDP based, and is highly sensitive to latency. The Internet is a place where latency is highly unpredictable and the more network hops (the further geographically) your packets have to travel, the higher the end to end latency will be; as such, VoIP is likely to remain a low quality voice transport for a while. Contrastly, your analogue telephone line, when you make a call from US to China, actually reserves an entire set of *dedicated* DS1 (64Kbits/sec) analogue pipes from one end to the other. In other words, there is zero sharing; hence the guarantee and high quality.

      Actually you get less than 64Bbit/second dedicated if your telco is in the US. Google "Robbed Bit Signaling"

      VoIP is UDP based, and is highly sensitive to latency.

      Bad generalization ther

  • Do we really need requests for commercial product recommendations on the front page?
  • by Duncan Blackthorne (1095849) on Thursday June 26, 2008 @07:41PM (#23959699)
    Why not just get your VoIP through Comcast? They'll have no problems throttling your bandwidth for you for no extra charge.
  • If the calls sound choppy to you, then the problem probably is the incoming bandwidth, which a router on your premises is not going to be equipped to solve. By the time the packets come in to your border router, they've already occupied the bandwidth that you would be attempting to reserve.

    • It could also be the processor on the router. If you are using very many firewall rules, etc. on the router, you could be maxing out the processor.

      I used to have a Cisco 801 router that was just fine for HTTP, SMTP, POP3, etc., even with publicly accessible servers on the inside network. However, the minute I added an Asterisk server inside my network, I started seeing performance problems (testing showed about 2-3 seconds latency through the router on an IAX call). In a nutshell, the 801 didn't have
  • See, here's the problem. With QoS on these routers, you only have actual REAL control over what you transmit, not what you receive, and since you're receiving data across the internet, all the QoS bits on your inbound traffic from Vonage are thrown away as soon as they hit a backbone router.

    So, yeah, you can control how much bandwidth on your outbound you allocate to VOIP traffic, but your bottleneck is not on outbound (if Bittorrent is what is causing your problems), but on traffic coming in. The best you

  • Some routers do bandwidth limitation by limiting average bandwidth. That is they send at full speed, pause, send at full speed, pause.

    That's not good for VOIP as it hoses your latency, but it's going to be fine for SMTP. Maybe yours does that.

  • If only there was some way to route analogue sounds signals over some unused bandwidth in those internet wires that you have coming into your house...

    Why not just set up plain old telephone call forwarding, and get calls to your business number routed to your home number?

  • 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,

    Check for firmware updates for your router. Consider purchasing a new router. At most it will help a bit.

    which helps a little, but not enough.

    As you've noticed, evidently.

    Is there a router out there that would allow me to reserve, say, 75-90kbps of bandwidth off the

  • Call up ImageStream (http://www.imagestream.com) and check out a Transport router. They are essentially just a small PC running Linux. I believe they go for about $800, but they are rock solid and extremely beefy.
  • >> 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?"

    Why completely block out bandwidth even when you're not using the service that uses it? that seems kinda silly overkill to me. Packet prioritisation is much better.

    I expect your actual problem is either:
    1) Your bittorrent client doing all it can to make your bittorrent

  • by IBitOBear (410965) on Thursday June 26, 2008 @08:13PM (#23960109) Homepage Journal

    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.

  • You can set a set of bandwidth priorities in rules, which can be protocol and/or IP based, and when that rule is not in use, the bandwidth is available for other apps, but when it is, it gets its guaranteed bandwidth.

    It's even got a topic [vonage-forum.com] in the Vonage Forum (which would have been the right place to ask this question).
  • I've tried a program called cFosSpeed (Windows only I think?) that prioritizes packets quite well. The main point is to keep latency as low as possible, especially during uploads, and I think it would work quite well for VOIP.
  • Most QOS stuff on routers is rubbish, the pfSense system works very well. It needs some understanding and effort to set up (the wizard isn't that good) but you won't find a more effective system.

  • Have you looked into the Sonicwall TZ line? I have a TZ-170 that will do QoS tagging. The TZ-170 is a few years old at this point. They offer a wireless version of it. You're probably looking at ~$500 once you include the advanced firmware. It might be overkill for your situation.
  • Most of the time it works fine, but when I'm using BitTorrent or other high-bandwidth applications ... the call quality gets choppy.

    ... stop downloading (I'm guessing, porn) while you're on the phone.

  • Whenever my phone rings, first thing I do is kill the bit torrent client if I have one running. People come first. Other than that, VOIP totally rocks.

    I wonder how much longer that will be the case. --I seem to recall some companies were getting hit hard with law suit losses.


    -FL

  • by rpp3po (641313) on Friday June 27, 2008 @05:49AM (#23964537)
    Priotizing bandwith with the Linux kernel's de-facto standard shaper HTB is not the correct approach if you care about latency. Nevertheless 95% of the internet's advise points exactly into that direction. What most people don't know, Linux already includes a shaper being able to make realtime scheduling guarantees: HSFC. It is a little bit more complicated to setup, but my box is able to give me 15 ms VoIP delays in parallel on a congested line (2000+ bittorrent peers).

The person who's taking you to lunch has no intention of paying.

Working...