Something on your mind? Want to give us feedback on something in particular or everything in general? Tell us how we are doing!
#4947 by koehn
Wed Mar 18, 2009 12:01 pm
Based on posts seen on this forum, many Ooma users don't seem to understand the QOS and how important it is to Ooma functioning correctly. The default setting (384kpbs) is really low for many users, and results in terrible internet performance and seems to result in echos during their calls.

At the end of the day, the whole static QOS number is a bit foolish, given the dynamic nature of internet routing. If the route to Ooma's VOIP service isn't allowing enough packets through, any network segment along the way could be choked with traffic, and Ooma throttling non-VOIP traffic on my router won't necessarily improve quality at all. Other customers flooding my ISP with traffic could impact service easily.

Ideally the Ooma router should shape bandwidth on the fly based on the number of packets that are not making it across the network, zeroing in on the optimum setting based on current network usage and conditions. If the packet loss is too great, Ooma should temporarily throttle other traffic to see if that helps. If it does, it should open the throttle until packet loss increases again, until it finds the optimum balance for that moment. If it doesn't, it should open the floodgates again, since the segment it's shaping isn't the bottleneck.
#4981 by Bobby B
Wed Mar 18, 2009 5:38 pm
You're absolutely right -- another user pointed out the same thing. There's a "dynamic QoS" feature in the planning stages right now, but I'm not too sure when we'll see it out in the field.

koehn wrote:Ideally the Ooma router should shape bandwidth on the fly based on the number of packets that are not making it across the network, zeroing in on the optimum setting based on current network usage and conditions. If the packet loss is too great, Ooma should temporarily throttle other traffic to see if that helps. If it does, it should open the throttle until packet loss increases again, until it finds the optimum balance for that moment. If it doesn't, it should open the floodgates again, since the segment it's shaping isn't the bottleneck.
#4989 by koehn
Wed Mar 18, 2009 6:16 pm
Bobby B wrote:You're absolutely right -- another user pointed out the same thing. There's a "dynamic QoS" feature in the planning stages right now, but I'm not too sure when we'll see it out in the field.


The other user's post wasn't quite the same thing, since I'm not advocating consuming bandwidth for determining the throttling point, only for dynamically detecting when a bandwidth constraint might be alleviated by bandwidth shaping.

In any case, programming the functionality is pretty straightforward, assuming you're running Linux on the Ooma, which is what I've read online. I'd be happy to help you build and test the system.

Who is online

Users browsing this forum: No registered users and 4 guests