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.
#81669 by tomcat
Thu May 19, 2011 10:07 am
EA PA-- I didn't come across any public test numbers this morning. Those that I did see were specific to the provider and most were a SIP address instead of a phone number. If I do see any I will be sure to pass along.
#81676 by EA PA
Thu May 19, 2011 10:55 am
tomcat wrote:EA PA-- I didn't come across any public test numbers this morning. Those that I did see were specific to the provider and most were a SIP address instead of a phone number. If I do see any I will be sure to pass along.


TC - thanks. I spent some time browsing Google for one also, and came up empty handed. I will try and find one of my old buddies in So Cal for a speaker phone shoe test to validate the ~ 800 mSec delay.

One interesting tidbit I came across this AM in a discussion with a cohort; He told me that GV used to, or currently has a loopback. The way it works (described as a "quality test" - peaked my curiosity) is that it waits until after you are speaking before it repeats back to you. That is; speak/delay/repeat. This is kind of what you were describing. I tried the 909 number, but instead of waiting, it repeats everything as you speak, implying a true loopback vs. a quality check.

Thanks - and let us know if you find a better number
#81705 by vicw
Thu May 19, 2011 4:24 pm
tomcat wrote:
EA PA wrote:Moderator link for 909 number:
viewtopic.php?f=4&t=9569&start=30#p67874

Moderator link to 925 number:
viewtopic.php?f=4&t=9569&p=72898&hilit=0082#p72898

Would seem self defeating for OOMA to recommend a number with a built in delay to measure and then report as an issue..!?!? :?

Yes, I agree. But, that server is run by people outside of ooma and ooma may not be aware of any changes to that system.

Like I said, it was just a thought hoping to shed some light on the higher delay with that number. :(


You make a good point, and the possibility that the delay is caused by external factors, or intentional, should be checked out, but since it can only be reached via Ooma, I don't know how that could be done, unless Ooma is willing to step up to the plate and do it. It would also be helpful if they would offer their position of its value as a tool for the echo timing test.

I reran my testing today, based on the suggestion by EA PA, to eliminate all local variables. I ran the echo timing tests with the Telo connected directly to the cable modem and using a wired phone, and all cordless phones off - no other hardware connected.

(909) 390-0003 - 810ms (789-824ms)
(925) 259-0082 - 325ms (302-348ms)


Not significantly different my earlier results, so that should exclude everything have reasonably been able to change here, up until now, other than perhaps the configuration of the Telo.

Ironically, about 1/2 hour after I ran the direct test today, my internet service went down - hard. TWC said there were no other reports of problems in my area, and offered a replacement modem, which I did, and it made no difference. In the end, apparently others actually were down also, and it was repaired in another couple of hours. Bottom line is, I swapped out my Arris modem for a Motorola one, so I will do another timing test tomorrow, just to eliminate the modem as well. I really don't expect any change, but I want to check any possibility, no matter how unlikely it is that I think it will be productive.
#81713 by tomcat
Thu May 19, 2011 6:00 pm
vicw wrote:You make a good point, and the possibility that the delay is caused by external factors, or intentional, should be checked out, but since it can only be reached via Ooma, I don't know how that could be done, unless Ooma is willing to step up to the plate and do it. It would also be helpful if they would offer their position of its value as a tool for the echo timing test.

vicw -- Just to clarify: the number I was referring to was the 909 number which has the higher delay. To my knowledge, this is a public number that can be reached by any carrier and not a service provided by Ooma. The 925 number is only accessible by ooma customers. Sorry for the confusion.


EA PA wrote:I tried the 909 number, but instead of waiting, it repeats everything as you speak, implying a true loopback vs. a quality check.

EA PA -- You are probably right on this.
#81715 by vicw
Thu May 19, 2011 6:26 pm
tomcat wrote:vicw -- Just to clarify: the number I was referring to was the 909 number which has the higher delay. To my knowledge, this is a public number that can be reached by any carrier and not a service provided by Ooma. The 925 number is only accessible by ooma customers. Sorry for the confusion.


Sorry, I messed that up. You didn't create any confusion. Just me.

Since the 909 number is public, maybe someone with a landline phone handy could run the same timing test to it to see if it always has that excessively high echo timing, or if it occurs solely through Ooma. Seems to me that would be very helpful.
#81716 by vicw
Thu May 19, 2011 6:56 pm
I just timed the 909 number using the gmail phone function on my laptop. On the first call, I got RT echo timing of 371-395 ms. On the second call 279-291 ms. That tells to me that Ooma has a problem, I think.

Update: I went back a few minutes later, and reran the tests on the 909 number via Ooma. Echo timing was 883-929 ms.
#81728 by EA PA
Fri May 20, 2011 3:55 am
I previously posted 500 mSec to the 909 number with my cell phone. I don't think I ever got close to this with OOMA. OOMA averages to ~800 mSec for me.

I wonder if there are ANY users out there that can boast and post a ~350 mSec loopback result to the 909 number, or even <500 mSec for that matter? I do not recall any. I have a sneaking suspicion that there are none. Anybody?

Then again, how many people actually buy an OOMA and spend their free time calling some empty number and tap pencils on the phone besides ET. :shock:
#81729 by vicw
Fri May 20, 2011 4:17 am
EA PA wrote:...
I wonder if there are ANY users out there that can boast and post a ~350 mSec loopback result to the 909 number, or even <500 mSec for that matter? I do not recall any. I have a sneaking suspicion that there are none. Anybody?
...


Just to be sure I understand your question, I think you are asking if any users have been able to get a <500 loopback on the 909 number via Ooma, right? I did just report an acceptable timing using the gmail phone function, instead of Ooma..
#81731 by EA PA
Fri May 20, 2011 5:14 am
vicw wrote:
EA PA wrote:...
I wonder if there are ANY users out there that can boast and post a ~350 mSec loopback result to the 909 number, or even <500 mSec for that matter? I do not recall any. I have a sneaking suspicion that there are none. Anybody?
...


Just to be sure I understand your question, I think you are asking if any users have been able to get a <500 loopback on the 909 number via Ooma, right? I did just report an acceptable timing using the gmail phone function, instead of Ooma..


vicw: Yes, I am asking if anyone has placed a call using OOMA to the 909 number that can claim a delay of < 500 mSec. The problem (higher delay) seems to be when you are using the OOMA infrastructure to call a public number (909 loopback) vs. a loopback from the OOMA datacenter only (925 number).

I can call the same public number with my cell and get ~500 mSec, but my OOMA phone is ~ 800 mSec. This seems to be consistent with the other posts that I have seen, and there are some with worse delays. The implication (my opinion) is that the sum of all the delays including internet delay, the OOMA datacenter delay, handoff and phone co delays, are quickly adding up resulting in larger delays as compared to other cell or landline phone calls. At the surface, this would appear to be a VOIP generic issue. However, I believe I have seen other posts (but need to research), that claim other VOIP systems are not experiencing this magnitude of delay (Vonage, GV, even Magic Jack although there are lots of MJ complaints as well). This is part of the controversy.

That said, there are some in the forum that feel that this may be a box specific issue due to routing algorithms or hardware configuration / assembly issues. Bottom line is we (at least I) can't explain the source of the total delay. All we can do is test, post and complain if warranted.

I personally think it’s a larger issue for what it is worth, and we simply do not have a broad enough view of users and their delays. I attribute this to 2 reasons. First, most users don’t hear the delay or it is not bad enough to complain. The 800 mSec delay is really only ½ of that when you are conversing with others. At 400 mSec delay, you can still have a reasonable conversation (with polite folk as nn5i has indicated) unless you are into rapid Yankee speak. Second, most users don’t spend time analyzing gizmos to the extent we are with pencil taps and recording software.
#81733 by sb06794
Fri May 20, 2011 5:36 am
If you go to the "Ooma Telo 45073 Release Notes" (our current Telo firmware version) here:
http://www.ooma.com/forums/viewtopic.php?f=10&t=11265&p=78546&hilit=45073#p78546
you will see the statement:
"reduced latency on PureVoice adaptive redundancy calls (should be about 80-100 msec less then before)"
Also notice that the reduced latency statement is the very first item mentioned in the release notes. That tells me that their technical support people are well aware of the delay problem and are trying to fix it. What's needed for the future firmware upgrades is further reduction in delay of 400 msec or more.
Stu
P.S. This is Ooma's explanation of "Adaptive Redundancy": "Packet loss is the enemy of VoIP – it can cause voice to sound stuttered or garbled. Ooma can detect packet loss on your Internet connection before you even hear it and automatically deploy redundant packets to boost the clarity of your phone call."

Who is online

Users browsing this forum: No registered users and 12 guests