VOIP etc > Voice Over IP - VOIP > VOIP Tech Chat > Best Open Firmware For VOIP QOS

reply to wcweaver

Re: Best Open Firmware For VOIP QOS

reply to christcorp

reply to christcorp

For both your posts. 1st: If you read my entire post instead of just what you thought it said, you'll see that I specifically mentioned that there are bandwidth intensive apps that can have you use enough to even saturate a 30mb connection. But for the overwhelming majority of users, this will not be an issue. So yes, I already said you can saturate large amounts of bandwidth. Please read what I wrote.

Next; no, you can't QOS the incoming packets. You can believe you can all you want, but it's not possible. In an open network, today's internet, "Basically, the whole net-neutrality issue; all packets coming in are in the open. They aren't channelized or sectioned off. Your router has no idea what the "Next" packet is going to be until it's already arrived. It can physically slow down incoming packets once they reach your router, trying to allow voip packets to stream through, but once the packets are at your router, there is absolutely no reason to try and slow certain ones down. You might as well just let them go where they're going. Your router isn't going to be the chokepoint. Again; if you've got a constant download stream going, you can alter the packets once they hit the router, but any QOS on the downstream is basically negated. This discussion has been visited literally thousands of times. You can believe what you want, but as long as the internet is still an open pipe with all traffic having equal priority, then your download isn't going to get QOS'd with any significance at your router.

Now, having said that, depending on the application you are running in the background, you may be able to reduce the bandwidth requirements of the app. Just like voip only uses roughly 90kb up and 90kb down using the G-711 codec. (28kb up and down with the g.729 codec). If you have "X" amount of down bandwidth, and you can limit the amount bandwidth an app uses instead of all it wants, then you can effectively reserve enough bandwidth for voip or any other app. Which takes us back to bandwidth. Until the politics of net-neutrality are removed; and consumers are educated that the internet needs to priority so some apps are given higher priority than others, having more bandwidth than you need, and managing that bandwidth at the application level is the best solution.

And no, my router isn't junk.

You are quite correct. You can slow down the acknowledgement (ACK), for the next packet to come. But the ACK is on the outgoing side. I understand you believe that that in turn will slow down the next packet arriving. And in an elementary school game where you pass a message back and forth you are correct. But at the bandwidth and speed of electrons, "Leaving Bandwidth" for voip is simply not true. Voip only needs 95kb of bandwidth. Plus, it's UDP traffic.

But you can limit bandwidth at the app level. For instance, I can manually use less bandwidth when streaming Netflix or slingbox. I can manually reduce the amount of bandwidth I use in torrents. I can reduce the bandwidth I use on a web/security cam. In those instances, I can in fact reserve enough bandwidth for voip. The key to voip is to not have excessive latency, and to have enough bandwidth that your system isn't trying to buffer too much.

Yes, you can slow the ACK down and thus slow the arrival of the next packet; but you're simply allowing more packets to back up on the WAN side. No big deal. But you're not really helping. But I will give one caveat in agreeing with you. If you're still one of the few that are suffering with 1.5mb/896kb dsl type internet service, then you can provide a little relief by slowing down the tcp ack traffic. But with that little bandwidth, you'd actually be better off going to the g.729 voip codec. It uses 1/3 the bandwidth, and it compresses more bytes into a packet. Not sure if they still do it, but Vonage use to offer a bandwidth saver which did this for the consumer.

But you did try to enlighten, that's cool. But I believe that you and I have taken this thread off track. And that is not good. I simply pointed out that with enough bandwidth, you don't need to use QOS. I stated that "ENOUGH BANDWIDTH" was relative to what you are using it for. And for the average person who isn't streaming 24/7, doing torrents all day, and isn't gaming constantly, my point is correct.

This is a QoS thread, so entirely relevant. I recommend choosing a firmware or router that supports bi-directional QoS. Most aftermarket firmwares do.

There is no 'packing up' on the WAN side, the sending server being QoS'd sends more slowly, relieving congestion in your downlink from the ISP to allow room for VoIP. This is TCP/IP protocol.

Yes, you can limit bandwidth per-application (usually), but I maintain that is an annoying and over-complicated approach given that any application on any PC could demand to saturate your downlink. It is far easier and more robust to let the router handle it. With the right router and firmware this is not a big deal.

Another advantage of incoming QoS is it does not require you 'reserve' bandwidth for VoIP 100% of the time. You can use your full internet bandwidth as the router will dynamically reduce lower-priority traffic when you pick up the phone. Surely you don't believe a feature that doesn't work (incoming QoS) according to TCP/IP is included in all quality routers?

Try it, you'll like it.
--
Lifespeed

reply to lstevens
It seems that the conversation diverged quite significantly from the original question. I use OpenWRT on several routers, and after several years of lull they came up with a new release that is just terrific. QoS could always be managed through configuration file, and now it also has UI. Technically, I am sure DD-WRT is equally powerful (I have DD-WRT on one router as well and have no complains), but administration is much easier in latest version of OpenWRT

reply to lstevens