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.
#68785 by jerrygno
Wed Nov 10, 2010 3:04 pm
Calling from 847-934 to anywhere produces a horrable delay, 1sec. My wife wont use the phone any more. Been like this for many months. I would strongly suggest turning off the reasons why we need to have our calls routed through California until such time that youall have servers in the Mid-West and East coast. (I have run the VOIP/speed tests and its not my network). My Telo worked great when I bought it 8-10 months ago.
#68788 by jhphone
Wed Nov 10, 2010 3:21 pm
I called the 909-390-0003 echo number, tapped on the speakerphone with a pencil and recorded about a dozen clicks on my MP3 player. Audacity shows a consistent 500-520 ms delay. This delay is what I have experienced since my first use of the Ooma Telo.

I'm calling from the 650 area code, same as the Ooma corporate office. This means there can't be any East Coast to West Coast server delay.

For the record, here's the VoIP test I just ran.

VoIP test statistics
--------------------
Jitter: you --> server: 0.5 ms
Jitter: server --> you: 3.6 ms
Packet loss: you --> server: 0.0 %
Packet loss: server --> you: 0.0 %
Packet discards: 0.0 %
Packets out of order: 0.0 %
Estimated MOS score: 4.0

Speed test statistics
---------------------
Download speed: 12242024 bps
Upload speed: 3216096 bps
Download quality of service: 94 %
Upload quality of service: 99 %
Download test type: socket
Upload test type: socket
Maximum TCP delay: 37 ms
Average download pause: 1 ms
Minimum round trip time to server: 24 ms
Average round trip time to server: 25 ms

Estimated download bandwidth: 17600000bps
Route concurrency: 1.4376707
Download TCP forced idle: 0 %
Maximum route speed: 21845000bps


OK, there is the actual delay of 500 ms, which is much more than accounted for above: 2 times 25 ms, or 50 ms max. These are the total of delays in routers and switches all along the round-trip path. Let's double that to 100 ms and blame that portion on the Internet. So now the pertinent question is: Where is the remaining 400 ms of audio being buffered?

There are not many candidates:
    Ooma servers that connect to the Internet
    The Ooma base unit -- Hub or Telo,
    My Panasonic cordless handset.

Let's take them in reverse order.

The Panasonic must be ruled out because (1) it's a mostly-analog system that does not create buffered packets, and (2) there's no delay when connected to the POTS. Furthermore, I get the accursed 500 ms delay using a decades-old Western Electric push button phone. It's not the phone that delaying the audio.

The Ooma Telo system -- If the Telo (or Hub) was causing the delay, it would have to buffer 400 ms of audio. I don't know the average data rate, but from the QOS discussions here, assume at least 200,000 bits/second times 400 ms. This means 80,000 bits, or 10K bytes, is stored in Telo buffers. If so, this is very strange. Why the heck would you store 10KB of audio? It makes no sense at all. BUT...

But, around 10KB of packets (per conversation) ARE being held somewhere. The only system I can think of that would have sufficient memory would be the Ooma servers. I think the buffering is done here.

Other evidence is that the 500 ms that I experience is very consistent with other reports here. This consistent delay indicates that the problem is in one place, one common denominator for everyone affected: the central Ooma VOIP system.

Another piece of circumstantial evidence is that a complex system -- the Ooma VOIP software -- is the most likely component to be so screwed up that it inadvertently buffers the packets. We don't know much about the VOIP system design or implementation, but it's a fact that users are experiencing 500 ms delays. This audio is in the form of digital packets, and they have to be buffered somewhere.

My guess is that the VOIP software is the problem.
#68798 by Bill D
Wed Nov 10, 2010 5:21 pm
jhphone wrote:My guess is that the VOIP software is the problem.

To help with a few data points, I ran some tests from South Florida (954-384), far from the Ooma data center. I have 2 Hubs and a 2-line wireless Uniden 8866. Dennis P said above that Ooma had a Telo-only problem, so my Hub test results may be helpful for comparison.

I called from one Ooma line to the other Ooma line between two handsets, put one handset on mute and speakerphone while holding it near the PC microphone and I clicked the two handsets together while recording on Audible. The results were consistent for dozens of clicks - 310 ms.

This 310 ms seems to encompass one Hub output delay, one Hub input delay and the Ooma VOIP server delay with no telco gateways involved. I repeated the test again dialing *99 first and the delay dropped to 280 ms.

I've not currently been having delay issues but my wife's Hub had 3 calls dropped (to land lines) in the last two days followed by her hearing a continuous gurgling sound. Prior to this we've had very little trouble in over a year so I suspect something may be amiss lately at Ooma. I rebooted her Hub to see if it helps. She's ready to boot her hub (me) if another call is dropped.

Bill D
#68826 by Dennis P
Thu Nov 11, 2010 9:52 am
tfk wrote:I have been dialing 909-390-0003 from the Midwest: Lansing, Michigan. The area code/exchange here is 517-886. I tried again tonight, dialing with and without *99 and received about the same results. I consistently get ping of 90 ms to https://www.ooma.com, and a proxy site mentioned on these forums, despite being so far from the datacenter.


I see that you are using a Telo. The fix that we are currently testing should be rolling out starting early next week and should reduce your round-trip delay by 150-200 msec.

Also note that www.ooma.com is not hosted at our datacenter. To measure the latency between you and our datacenter, it is better to ping www3.ooma.com (which is hosted in our datacenter).
#68828 by Dennis P
Thu Nov 11, 2010 9:59 am
bmccollum wrote:Calling from the 731-784-xxxx area code / exchange and pretty well most any calls to any number local or otherwise produces terrible delay of I'd guess almost 1-second.


It would be helpful for me if you can measure an exact delay to the echo test number using the method described here: http://www.ooma.com/forums/viewtopic.php?f=4&t=9569&start=30#p67874. Then post the date/time of your test call.

Since you are using a Telo, you should also see an improvement after the upgrade that is scheduled for next week.
#68829 by Dennis P
Thu Nov 11, 2010 10:00 am
subguy wrote:From area code 508, I'm getting ~560 ms delay both with and without pressing *99 first.


Since you are using a Telo, you should also see an improvement of 150-200 msec after the upgrade that is scheduled for next week.
#68830 by Dennis P
Thu Nov 11, 2010 10:05 am
jerrygno wrote:Calling from 847-934 to anywhere produces a horrable delay, 1sec. My wife wont use the phone any more. Been like this for many months. I would strongly suggest turning off the reasons why we need to have our calls routed through California until such time that youall have servers in the Mid-West and East coast. (I have run the VOIP/speed tests and its not my network). My Telo worked great when I bought it 8-10 months ago.


Most providers will not allow calls to be routed directly to them. Also, the extra delay from coming to California should not result in 1 second roundtrip times. There must be something else going on here. It would be helpful for me if you can measure an exact delay to the echo test number using the method described here: http://www.ooma.com/forums/viewtopic.php?f=4&t=9569&start=30#p67874. Then post the date/time of your test call.

Since you are using a Telo, you should also see a reduction in delay of 150-200 msec after the upgrade that is scheduled for next week.
#68831 by Dennis P
Thu Nov 11, 2010 10:07 am
jhphone wrote:My guess is that the VOIP software is the problem.


Since you are using a Telo, you should also see an improvement of 150-200 msec after the upgrade that is scheduled for next week.
#68833 by Dennis P
Thu Nov 11, 2010 10:10 am
Bill D wrote:
jhphone wrote:I called from one Ooma line to the other Ooma line between two handsets, put one handset on mute and speakerphone while holding it near the PC microphone and I clicked the two handsets together while recording on Audible. The results were consistent for dozens of clicks - 310 ms.

This 310 ms seems to encompass one Hub output delay, one Hub input delay and the Ooma VOIP server delay with no telco gateways involved. I repeated the test again dialing *99 first and the delay dropped to 280 ms.


Are you measuring the one-way delay in this test? If so, this is a little higher than I would expect (I would have thought 150-200 msec). Are you connecting your phones directly to the Ooma Hub, or are you going through a Scout?

Who is online

Users browsing this forum: No registered users and 7 guests