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.
#69070 by sfhub
Mon Nov 15, 2010 11:59 am
jhphone wrote:Good points. But Internet cannot be causing this amount of delay. Lets discuss your point "...one server hop of 1ms bufferi[s] 10KB before sending anything and that could account for 400ms…"
... (followed by discussion of buffering)

My point is that delays can come from many different areas, some you might not be aware of because they are in the backend. To be clear, I'm not saying the problem is on your end.

All that matters is you get the sum total of the delays to something reasonable.

Looking at it from a black box, you can determine the network delays you are directly exposed to, but cannot see into the back-end at Ooma.

I gave you fictional examples at the extreme end just to illustrate a point, not to suggest that is exactly what is happening. Don't assume the problem must be buffering, as in it was (poorly) designed to work this way. There are other possibilities, especially since it was working reasonably at some point in the past.

For example another fictional example could be their transcoding server was working fine, but switched some network pathway or equipment resulting in periodic packet loss (which you can't see because it isn't your stream losing packets). Yes the transcoding server is "buffering" to do the transcoding, but buffering wouldn't be the issue in this case, rather it would be the packet loss causing retransmissions, which could be detected at the transcoding server, but at your end would just result in delays in your stream. Maybe somewhere some stream got configured to use TCP instead of UDP and that is interacting with packet loss to delay packets. Perhaps it is something else entirely. On my DSL connection, if they use fastpath, the latency is 40ms less than if they choose interleave. There is no explicit buffering going on in the network equipment, but the TCP protocols handle the delays or UDP protocols have designs to deal with it.

My point again is to triangulate on the delays first, and don't assume the cause. My examples are not meant to be bulletproof explanations, just to illustrate points. Your voice call is not simply a stream of packets from your ooma to the ooma servers and back. There's a whole other set of network and servers happening behind the scenes on the back-end.
#69173 by subguy
Tue Nov 16, 2010 6:55 pm
What do you all think I should do? I have until this weekend to take back my Ooma (30 days from purchase at BB). If you all had the flexibility to return yours for full purchase price, would you do it?

I was 100% sold on Ooma until this delay issue in the last couple weeks. And the slow response/inability to diagnose and/or remedy the problem has me seriously worried. I don't want to be stuck with a $200 lag-laden device...

Any thoughts/opinions on how I should proceed?
#69176 by Bill D
Tue Nov 16, 2010 7:26 pm
subguy wrote:...........how I should proceed?

You didn't say if you had a Hub or Telo, but it appears the Telo has a unique delay problem that Ooma says they are fixing. The posted Telo delays are longer.

I've had 3 Hubs for a year (2 in Florida and one in California) and I've generally been pleased until these recent on-and-off delay problems. I believe Ooma will get this delay problem fixed (but there's no guarantee), but you could play it safe and return it and follow this forum to see if the problem gets fixed and then buy another Ooma.

Initially I had trouble with Scout voice quality, which I've learned is unfixable, so I don't use my Scouts for calls (only checking VM). Even so, I've still been generally pleased and the value is excellent (I don't have premier).
#69177 by irish0818
Tue Nov 16, 2010 7:30 pm
I have noticed that this is a major problem for me. Especailly when talking with someone on a cell phone. Really frustrating!

Has any resolution been found for this? I have the latest update on my Telo.

I have also noticed people with "Premier for life"? How the heck do you get that?
#69179 by tommies
Tue Nov 16, 2010 8:05 pm
Delay is part of voip. For me, 500ms or less is ok, preferably 300ms or less.

Few day ago, when the measured delay is 700ms for my telo, I only did it out of curiosity and post the result here for comparison. During normal phone conversation, I don't have any idea of the delay or any of it effect. The call quality is still good to my ear.

What is the difference if you hear the other person voice 0.3s or 0.5s after, or even 0.7s after. I usually make some test calls between my (ATT) cell phone and the Telo hand set. I just place one in front of the TV and take the other to another room and listen to the TV through the phone. The sound is very clear with the volume a bit lower compare to the TV volume. In this situation, even with 1sec delay, I would not know it.

Sound choppiness is another issue, which is usually involved packets lost.
#69193 by Bill D
Wed Nov 17, 2010 4:22 am
tommies wrote:During normal phone conversation, I don't have any idea of the delay or any of it effect. The call quality is still good to my ear.

I agree the Ooma sound quality is good but I notice the increased delay results in both the other party and I stepping on each other repeatedly unless we continuously pause longer and stretch our response times. When the other party has non-Ooma Voip, it seems much worse. Its probably double delay.

Who is online

Users browsing this forum: No registered users and 6 guests