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.
#81559 by nn5i
Tue May 17, 2011 9:39 am
thunderbird wrote:According [to] the Article [quoted] above, "Route processing is happening at the device--not the core".

The Chronic Audio Delay that a few people have, could be caused by a defective Ooma device?

If the Ooma device consistently chooses "Lousy Carrier Routes" from less reputable low end carrier providers, [then] the call quality is always going to be bad for the user with a defective Ooma device.

Gee, if it was in print somewhere, or on the Web, it must be Gospel.

But if a device is making choices, it is doing so through programming, not through hardwired logic, n'est-ce pas? If the hardware is working well enough to run the firmware, then replacing the hardware wouldn't make any sense.
Last edited by nn5i on Tue May 17, 2011 10:57 am, edited 1 time in total.
#81560 by EA PA
Tue May 17, 2011 9:47 am
I have measured delay on 2 separate loop back numbers while using my handset / Telo Dect 6.0 / Telo combination as previously posted. Numbers used and described below.

Quote Bill D:
909-390-0003 is outside of Ooma and can be called by any phone (Ooma or not) to test round-trip delay.
925-259-0082 is inside of Ooma and tests round-trip delay without going out of Ooma over a carrier.


The 909 number was 760 mSec. The 925 number was 340 mSec. Both tests are repeatable. Tests performed with the OOMA Telo & handset and also with Dect 6.0 phone.

If I can call one loopback to OOMA only, and then call another loopback outside of OOMA and get an increase of 420 mSec, this would suggest that the problem would either be;

1. Outside of the Telo, or
2. Telo is smart enough to mess up only specific numbers.

I pick number 1.
#81561 by tomcat
Tue May 17, 2011 10:04 am
thunderbird wrote:http://www.fiercevoip.com/story/ooma-conspiracy-or-why-vonage-ultimately-doomed/2009-03-19

Article Quote: The current Ooma device has a 450 MHz ARM processor onboard running Linux, a derivative version of Asterisk and a routing algorithm to pick the least-cost route for the phone call, be it another Ooma (free), a regional carrier, or the best national carrier rate of the day. Route processing is happening at the device--not the core--so there's no need for big iron and expensive solutions.

According the Article quote above, "Route processing is happening at the device--not the core".

The Chronic Audio Delay that a few people have, could be caused by a defective Ooma device?

If the Ooma device consistently chooses "Lousy Carrier Routes" from less reputable low end carrier providers, than the call quality is always going to be bad for the user with a defective Ooma device.

Just wanted to point out that the article is over two years old and the "current hardware" referenced by the article doesn't pertain to the telo.

As pointed out here (viewtopic.php?f=9&t=11068&p=77228#p77228) the hub uses Asterisk while the telo uses Freeswitch.

thunderbird wrote:...a derivative version of Asterisk and a routing algorithm to pick the least-cost route for the phone call, be it another Ooma (free), a regional carrier...

And, as noted here (viewtopic.php?f=6&t=710#p3075) other user's ooma devices (hubs & telos) are not used for call termination anymore.
#81562 by vicw
Tue May 17, 2011 10:07 am
thunderbird wrote:http://www.fiercevoip.com/story/ooma-conspiracy-or-why-vonage-ultimately-doomed/2009-03-19

Article Quote: The current Ooma device has a 450 MHz ARM processor onboard running Linux, a derivative version of Asterisk and a routing algorithm to pick the least-cost route for the phone call, be it another Ooma (free), a regional carrier, or the best national carrier rate of the day. Route processing is happening at the device--not the core--so there's no need for big iron and expensive solutions.

According the Article quote above, "Route processing is happening at the device--not the core".

The Chronic Audio Delay that a few people have, could be caused by a defective Ooma device?

If the Ooma device consistently chooses "Lousy Carrier Routes" from less reputable low end carrier providers, than the call quality is always going to be bad for the user with a defective Ooma device.


I don't quite understand how you made the logical leap from the article content to the conclusion that the problem could be caused by a defective Ooma device. I also don't understand how a defective Ooma device would manage to always select a "lousy carrier route", or why you assume that the cheapest route is always the worst choice - but all of that aside, I will allow for the notion that all of that may is possible, even though highly unlikely, IMHO.

That said, I would really just like to know if Ooma, or any customer has seen a clear and repeatable change in echo timing, and presumably performance, between one Telo and another Telo. Ooma has the advantages, as I said above, and a more global view of what they and their customers are experiencing, especially since this is a fairly common complaint, so they should be able to easily answer this question. If they don't know the answer to my question, they can send me a sampling of Telos, the more, the better, and I will be happy to perform that test for them. I promise to send them back - really.
#81563 by EA PA
Tue May 17, 2011 10:15 am
Ah Tomcat, I was just looking for that thread that noted (from OOMA) that this technique was not used any more! I could not find it...thanks
#81564 by lbmofo
Tue May 17, 2011 10:23 am
EA PA wrote:Ah Tomcat, I was just looking for that thread that noted (from OOMA) that this technique was not used any more! I could not find it...thanks

I think tomcat was talking about peer to peer termination model not being used anymore.
But I think thunderbird was talking about call termination ooma to ooma, not talking about peer to peer call termination via peer's landline.
#81567 by nn5i
Tue May 17, 2011 11:27 am
vicw wrote: ... [Ooma] can send me a sampling of Telos, the more, the better, and I will be happy to perform that test for them. I promise to send them back - really.

Now that would be a lot of work to do for free. That, also, would be a most desirable and sensible thing to do, as long as I don't do it. Having a comprehensive set of test results, all from one location with an assortment of Telos of varying provenance, differing manufacture dates, and disparate engineering change levels including firmware, could answer the question once and forever. But, of course, it may be that someone already knows and isn't telling.
#81569 by vicw
Tue May 17, 2011 11:51 am
nn5i wrote:
vicw wrote: ... [Ooma] can send me a sampling of Telos, the more, the better, and I will be happy to perform that test for them. I promise to send them back - really.

Now that would be a lot of work to do for free. That, also, would be a most desirable and sensible thing to do, as long as I don't do it. Having a comprehensive set of test results, all from one location with an assortment of Telos of varying provenance, differing manufacture dates, and disparate engineering change levels including firmware, could answer the question once and forever. But, of course, it may be that someone already knows and isn't telling.


You have a good point. I should have put a realistic cap on the number of units - perhaps 10 would be reasonable, but I'm not seriously expecting a positive response. I WOULD be willing and happy to do it, though.

This discussion reminds me a bit of the recent reports in the press about the new white iPhone being thicker than the black one, and much of the media jumped on it with reports of catastrophe to case users - how they couldn't fit, etc. After much kveching and distress over this gross screwup by Apple, and Apple insisting it really wasn't any thicker, after a couple of weeks or more Consumers Reports took the step of actually measuring it with a vernier caliper, and, as you probably already know, the white and black iphones are the same thickness. Never Mind!!!

Incredible that much time and energy would be expended without taking the time to check the facts.

Like you, I have a hunch that someone probably really knows the true answer to my question, but that's just speculation on my part, and I'll give them the benefit of doubt. They really SHOULD know the answer, but lets assume that they don't.

In any case, my offer remains, with the upper limit of 10 units. I'm retired, so I have plenty of time for this (assuming my telomeres are still long enough :D ).
#81570 by tomcat
Tue May 17, 2011 11:54 am
lbmofo wrote:
EA PA wrote:Ah Tomcat, I was just looking for that thread that noted (from OOMA) that this technique was not used any more! I could not find it...thanks

I think tomcat was talking about peer to peer termination model not being used anymore.
But I think thunderbird was talking about call termination ooma to ooma, not talking about peer to peer call termination via peer's landline.

lbmofo -
You are right. I was thinking call termination using another ooma user's landline was what was being referenced. I stand corrected. :)
#81572 by EA PA
Tue May 17, 2011 12:15 pm
tomcat wrote:
lbmofo wrote:
EA PA wrote:Ah Tomcat, I was just looking for that thread that noted (from OOMA) that this technique was not used any more! I could not find it...thanks

I think tomcat was talking about peer to peer termination model not being used anymore.
But I think thunderbird was talking about call termination ooma to ooma, not talking about peer to peer call termination via peer's landline.

lbmofo -
You are right. I was thinking call termination using another ooma user's landline was what was being referenced. I stand corrected. :)


I was interested in this thread as I had read it before and was curious about the design evolution but could not locate it. Sometimes the past can shed some light on the present or future.

To continue, maybe I am missing something here that I can’t put together (not being a phone guy, as one can plainly see). I cannot put the logic together as to how a defective Telo or Hub hardware device could consistently result in the nearly same delay. I thought I read that it may even be another users device. Is this true? If so, once again, how? (I understand that P-P Distributed Termination does not happen any more.)

Anyway, I cannot put the failure mechanism together for a hardware issue. Can someone please explain the logic behind this theory for me?

Who is online

Users browsing this forum: No registered users and 5 guests