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.
#68685 by Stuntman
Tue Nov 09, 2010 2:36 pm
The worrisome part is just the fact that the service itself has gotten worse over the last few months.. perhaps they are running thin down there and hoping for a big Christmas so that they can upgrade and improve some of their equipment.. I know I've worked for companies that let the consumer suffer for a few months at a time while we struggled internally to just get to the point we could fix the problem without publicly acknowledging it.. perhaps that is in play here as well...
Hopefully somebody will jump in and throw down some information from Ooma's side of this.
#68686 by Dennis P
Tue Nov 09, 2010 2:55 pm
Our internal testing showed that the roundtrip delay through the Ooma Telo was underperforming the Ooma Hub by 150-200 msec. We have identified one issue that may have contributed to this and are testing a fix right now which should bring it in-line with the Ooma Hub (between 300-350msec).

For users who are experiencing high roundtrip delays on the Ooma Hub (500 msec or more), can you post what state you are calling from and what phone number you are trying to reach (just area code and exchange)? Also try dialing *99 prior to the call to see if the fax codec settings change your roundtrip delay.

Note that Ooma currently has one datacenter in California. If you live on the East coast and call locally, your call needs to be routed to California before going back out to the destination. This may add 80-100 msec of roundtrip delay due the path the call needs to take.
#68691 by geobernd
Tue Nov 09, 2010 4:05 pm
Dennis P wrote:Note that Ooma currently has one datacenter in California. If you live on the East coast and call locally, your call needs to be routed to California before going back out to the destination. This may add 80-100 msec of roundtrip delay due the path the call needs to take.

I am on the east cost.
Delays on calls to/from 845-306, 917-439, 646-484
I understand the California datacenter and that makes sense for the signaling/billing route - I don't understand why the RTP/media stream would need to travel through your datacenter? Routing that directly between the Telo/Hub and the CLEC gateways should speed things up a bit....
#68699 by dschmidt_2000
Tue Nov 09, 2010 5:40 pm
Dennis P wrote:Our internal testing showed that the roundtrip delay through the Ooma Telo was underperforming the Ooma Hub by 150-200 msec. We have identified one issue that may have contributed to this and are testing a fix right now which should bring it in-line with the Ooma Hub (between 300-350msec).


Thanks for popping in and the info. I know I get warm fuzzies knowing that someone on the Ooma team is actually reading and working on this stuff. Silence has very discouraging. Any ideas why only certain calls have the delay? (I'm in So. Cal and it happens with So. Cal #'s)
Dave
#68703 by Stuntman
Tue Nov 09, 2010 5:49 pm
Thank you for the response! That makes us all a little happier for sure!
Would a datacenter on the east coast make sense in addition to the west coast? I assume this would be very expensive and isn't something that can be done without a lot of growth in the company first?? Understandable
#68716 by tfk
Tue Nov 09, 2010 8:08 pm
Yes, thanks a lot for some info and specifics, especially saying what service level has been normal for the Ooma Hubs, and what you would consider excessive. Just knowing that, gives me a little relief that what I am frustrated with, is recognized as a problem worthy of allocating resources to explore the problem in more detail.

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.

My nonscientific (but easy) way to observe the delay is to say the word "Test". A good latency (<500 ms) echoes back with the beginning of the word before I finish saying the word; with a bad latency (>500 ms), my mouth is already closed before the beginning of the word arrives. Not nearly as elegant as Bobby's measurement, but easy to perform!

It would be great if you could share ocassional updates every couple days as more is learned about the problem.

I was getting discouraged about VOIP, then I started messing around with Google Voice on an asterisk server and was encouraged by better latencies to local numbers here than Ooma's....
#68721 by southsound
Tue Nov 09, 2010 10:32 pm
Non-relevant post removed by author.
Last edited by southsound on Wed Nov 10, 2010 7:18 am, edited 1 time in total.
#68722 by Dennis P
Tue Nov 09, 2010 10:47 pm
geobernd wrote:I understand the California datacenter and that makes sense for the signaling/billing route - I don't understand why the RTP/media stream would need to travel through your datacenter? Routing that directly between the Telo/Hub and the CLEC gateways should speed things up a bit....


There are three reasons why the media stream goes through our data center:

1. The codec we use for PureVoice (iLBC) is not widely supported by gateways, which means that we have to transcode to a supported codec (G711). Although transcoding is expensive, we believe it is worth it to get access to a robust, low-bandwidth codec.

2. The adaptive redundancy technology of PureVoice is a proprietary implementation and requires custom code on both the client and server. This adaptive redundancy improves reliability and consistency of voice calls by effectively concealing packet loss rates of up to 40%.

3. We use SRTP which is not widely supported by gateways. Encrypting the media stream improves the privacy and confidentiality of phone calls.

Who is online

Users browsing this forum: Google [Bot] and 7 guests