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.
#81588 by EA PA
Tue May 17, 2011 6:48 pm
No theory I guess.
The latest code made no change for me.

Latest data;
909 number:
Cell - Verizon: 500 mSec
Dect 6.0 : 810 mSec
Handset: 900 mSec

925 Inside Number:
Dect 6.0 : 360 mSec
Handset: 400 mSec
#81594 by thunderbird
Wed May 18, 2011 4:42 am
EA PA wrote:Anyway, I cannot put the failure mechanism together for a hardware issue. Can someone please explain the logic behind this theory for me?

A few months back I was taking to a social acquaintance, who is a software engineer, engineering head, and part owner in a small company that manufactures highly specialized test equipment. He told me a story about production running out of a part, used in the manufacture of one of their pieces of test equipment, which they manufacture and sell. One of the test technicians knew about a similar part that was in stock and wasn’t being used for any other product. He looked up the specifications for both parts and found that both parts were identical, except the stock part didn’t contain one capacitor and one resister that the normal build package part contained. He pointed the part differences out to engineering and it was decided that the stock part could be used as an alternate part, as long as a capacitor and resister of the correct values were also installed in the circuit on the board. Engineering made the necessary paperwork changes to use the alternate part, and production continued. After a period of time calls started coming in from customers that the test equipment wasn’t functioning quite right for one test. A real odd thing was that one of the digital number displays would count backwards during one test. Instead of displaying positive numbers, the digital number display displayed negative numbers. It was found that through a production error, one electronic assembler used the alternate part, but failed to add the capacitor and resistor, in about one hundred test equipment units. The capacitor and resistor provided positive logic. Without the capacitor and resistor there was negative logic.

If the home Ooma device does choose the call routing, positive logic may choose the fastest routes. But if the home Ooma device had some kind of production error, a batch of defective parts, etc. negative logic may be used, which may be choosing the slowest routes. You can also see where certain build number of defective units could be built and malfunction, and all other units built before and after function normally.

Note: This is a highly simplified explanation, and may or may not apply to home Ooma devices.

I would agree that the problem is probably with the Ooma servers, carrier, legacy carrier, or even the Internet provider. But when trying to find solutions for a problem, everything must be looked at, and looked at again, over and over again.

This problem is probably an individual problem like the I/they can’t hear you/me problem was. That means every individual person having this problem has to contact Ooma and keep after Ooma until their Individual delay problem is solved.
#81597 by vicw
Wed May 18, 2011 5:27 am
I'll put the question again. Can Ooma, or any participant here cite an example where a Telo was replaced by another Telo, resulting in a significant change in the echo timing?

I don't want to waste endless amounts of time and energy chasing shadows, when it would be so simple to test a sampling of Telos, and answer the question, rather than fantasize about what might be possible
#81607 by horsecore
Wed May 18, 2011 9:15 am
thunderbird wrote:This problem is probably an individual problem like the I/they can’t hear you/me problem was. That means every individual person having this problem has to contact Ooma and keep after Ooma until their Individual delay problem is solved.

The problem with that thunderbird is I have and I get the same "deer-in-the-headlights" response that goes nowhere and they show an unwillingness to resolve the issue properly.

#81628 by EA PA
Wed May 18, 2011 5:50 pm
OK, thanks I got it. I thought there may be some insider information floating around. It is clear to me that there is lots of speculation. That answers my question.

I understand that designs or design changes that are not properly incorporated can result in unpredictable operating characteristics.

That said, I still cannot put together a credible mechanism that would result in this delay issue that is limited to a combination of a few Telo and also Hubs. I assume that these have different hardware designs that make a common mode hardware issue even more difficult to swallow.

I would argue that the same delay is reported for both Telo and Hub and I assume (but do not know and cannot prove) that these are different hardware designs and therefore would have a low probability of a common mode failure. I would also argue that logic in present day design does not need to incorporate analog components to select different configurations of code as in the example. I have seen dip switches and jumpers used to develop a readable hardware byte to select optional configurations of code, however this was in the ancient days. Also notable is that nobody has reported that this delay is resolved with a replacement box. Finally, I conclude that if I can call one number and get a fast loopback and get a slower loopback for a different number then it is not a box specific issue.

I agree that anything is possible and there have been many head slapping discoveries in the past, however in this case, I still have my doubts and still have not seen a credible argument that a hardware configuration or failure common to both a limited number of Telo and Hub could result in this issue. I can see how a device level algorithm or other software issue common to all, or an external issue common to OOMA infrastructure and beyond could be causing this delay. But, without cracking the box, all of this is mere speculation and opinion that does not resolve anything!

Although I do not agree that this is box specific, I do agree with TB that the best possible avenue for resolution is to call CS and keep posting.
#81630 by vicw
Wed May 18, 2011 6:07 pm
Well said, EA PA. I agree with all that your said. I put in an inquiry to Ooma today, with very little expectation that the echo problem will be resolved soon, on an individual or aggregate basis, and almost zero expectation that a Telo replacement has a ghost of a chance of making a difference, but what can we do?

This thread has become a circular discussion, and unless someone comes up with some actual test data, I don't see any progress. I'll keep checking in here, hoping for something, anything, but we'll see what Ooma itself can offer.
#81635 by marcaronson408
Wed May 18, 2011 7:41 pm
I had several email-based exchanges w/ OOMA support. After a while it was clear that they were asking me to try things based on the assumption that I had a problem at my end and also they were not really fully digesting the information I had supplied. I ran some more experiments, submitted the follow up email outlined below and than called their toll free support line. I spent 10-15 minutes on the phone with a pleasant support agent who acknowledged that some people are having this problem, took down additional information and then escalated the issue. I will report back what happens from here when I have more info...


Lance, I reconfigured so that the OOMA hub was connected directly to the cable modem. I did not connect the router to the home port of the HUB, thus assuring that no other device, including the OBI 110, had access to the network. I then called 909-390-0003 and did the "pencil tap" test. The delay measured 766MS -- a result very consistent with other testing. I then dialed 925-259-0082, which is a number that is inside the OOMA network and the delay was 250MS. If I pull all the data together the only conclusion is that the problem is not with my equipment, network or internet connection -- the problem is somewhere in OOMA's or OOMA's partner network. Here is my logic:

1. Calls completely contained within the OOMA network (the 925 number) do not suffer from delay problems. This means there is no defect in my OOMA hub.

2. Calls initiated on OOMA's network that terminate outside of OOMA's network (the 909 number) do suffer from delay problems. This delay happens even if I configure my network so that the OOMA hub is directly connected to the cable modem and the rest of the network is offline.

3. Calls initiated on GV's network that terminate outside the GV network (the 909 number) do not suffer from delay problems.
#81641 by vicw
Wed May 18, 2011 7:58 pm
Thanks for sharing that, Marc. I like your idea of removing everything except the cable modem from the loop for the timing measurements. That should eliminate a full round of:try this, try that, maybe your router is causing the delay, maybe your QOS is wrong on your router, etc.

I think I'll do that one last step tomorrow before I make and more exchanges with them, fully expecting the results will be identical to what I've already done.

Please do keep this thread posted on any results, especially any actions that improve things. Good luck.

Who is online

Users browsing this forum: No registered users and 5 guests