This forum includes tips for maintaining the best audio quality possible with the Ooma System. If your Ooma system is having issues with dropped calls, static audio or echo, look here for assistance.
#11771 by Aveamantium
Sat Jun 20, 2009 6:45 pm
scottlindner wrote:Isn't that due to typical settings that would lead to that?

Scott


Not sure what you meant by this? But like you said, if you wern't doing anything on your network at the time of the call issue it is probably not related to the inbound bandwidth. I only mention this is I've noticed some voice quality issues when downloads are taking place on my network and it is difficult to get Qos to adjust for this.

Anyway, just a thought... Since I just started test driving ooma I'd be curious if you continue to see (or hear) this issue.
#11773 by scottlindner
Sun Jun 21, 2009 4:06 am
Aveamantium wrote:
scottlindner wrote:Isn't that due to typical settings that would lead to that?

Scott


Not sure what you meant by this? But like you said, if you wern't doing anything on your network at the time of the call issue it is probably not related to the inbound bandwidth. I only mention this is I've noticed some voice quality issues when downloads are taking place on my network and it is difficult to get Qos to adjust for this.

Anyway, just a thought... Since I just started test driving ooma I'd be curious if you continue to see (or hear) this issue.


I was a little vague, huh? I was trying to say that it isn't universal that QoS is not applied for downstream. Although it does appear that most consumer routers only focus on the upstream.

Scott
#12088 by scottlindner
Fri Jun 26, 2009 2:30 am
Aveamantium wrote:Is there any chance that your inbound bandwidth happened to be saturated at the time of the call? Not sure what you're using for Qos but Qos really only works "efficiently" in the outbound direction and not the inbound.


I was thinking about this comment more. My Tomato router has both upstream and downstream QoS settings but the other firmware I tried using only had upstream QoS. Could this be why you are saying downstream QoS doesn't work, since most routers do not implement it?

That being said, I didn't realize I have not implemented downstream QoS on my router's configuration. I'll need to come up with some good tests to break my Ooma quality with downstream traffic so I can test a configuration for it. Any thoughts?

Cheers,
Scott
#12099 by Aveamantium
Fri Jun 26, 2009 5:52 am
The reason that Qos for the inbound direction doesn’t really work that well is that you are on the receiving end of the data stream so: a) you can't prioritize what is sent to you; and b) you can only control the speed at which things are sent to you by either dropping packets or slowing ACK receipts. This is why most Qos in routers don't even bother with trying to shape inbound traffic.

With Tomato you can set your inbound limit and then set the corresponding percent of the max limit based on class (keep in mind all classifications are based on outbound connections, which makes inbound control even more difficult). So you can set Maximum (assuming you have this for VoIP) at 100 percent or None (which has no limit) and set High at 90 percent, Medium at 80 percent and so on. What happens is if you get a data stream that is classified as medium the router should only allow 80 percent of the set Max Limit, theoretically leaving 20 percent for higher classifications.
#12102 by scottlindner
Fri Jun 26, 2009 6:02 am
Aveamantium wrote:The reason that Qos for the inbound direction doesn’t really work that well is that you are on the receiving end of the data stream so: a) you can't prioritize what is sent to you; and b) you can only control the speed at which things are sent to you by either dropping packets or slowing ACK receipts. This is why most Qos in routers don't even bother with trying to shape inbound traffic.

With Tomato you can set your inbound limit and then set the corresponding percent of the max limit based on class (keep in mind all classifications are based on outbound connections, which makes inbound control even more difficult). So you can set Maximum (assuming you have this for VoIP) at 100 percent or None (which has no limit) and set High at 90 percent, Medium at 80 percent and so on. What happens is if you get a data stream that is classified as medium the router should only allow 80 percent of the set Max Limit, theoretically leaving 20 percent for higher classifications.


I see. So it is a bandwidth reservation only, not prioritization on the downstream. Interesting. I wonder why that is?

Scott
#12103 by Aveamantium
Fri Jun 26, 2009 6:07 am
You got it... It would be wonderful to be able to prioritize incoming data but since you're at the mercy of what the net/isp sends you after requesting it, this is just not possible. However, if you limit all other classes (including your default class) to somehthing less than 100 percent of the set max, the idea is that the router will try to leave room for those incoming voice packets.
#12104 by scottlindner
Fri Jun 26, 2009 6:33 am
Aveamantium wrote:You got it... It would be wonderful to be able to prioritize incoming data but since you're at the mercy of what the net/isp sends you after requesting it, this is just not possible. However, if you limit all other classes (including your default class) to somehthing less than 100 percent of the set max, the idea is that the router will try to leave room for those incoming voice packets.


Duh... that makes painfully obvious sense now. I don't care about prioritizing my downstream because my network is faster than my ISP. If that wasn't the case, then I would want to prioritize the downstream. It wasn't obvious at first, but now it makes perfect sense. Thanks for clearly that up!

Cheers,
Scott

Who is online

Users browsing this forum: No registered users and 6 guests