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.
#82539 by CodeMasterG
Tue May 31, 2011 5:45 pm
Current Telephone Company:
NationsLine

Original Telephone Company:
Verizon Maryland Inc.

Original Telephone Company Type:
Regional Bell Operating Company (RBOC)

Noticeable delay, like a half-duplex line at times (two cannot talk at same time wo/ cutting each other off). It's usable, but not the same quality as the plain old telephone service I had.
#82559 by thunderbird
Tue May 31, 2011 9:38 pm
CodeMasterG wrote:Current Telephone Company:
NationsLine

Original Telephone Company:
Verizon Maryland Inc.

Original Telephone Company Type:
Regional Bell Operating Company (RBOC)

Noticeable delay, like a half-duplex line at times (two cannot talk at same time wo/ cutting each other off). It's usable, but not the same quality as the plain old telephone service I had.

Many times half-duplex comes from one piece of the home's equipment. I have an old half-half-duplex printer that I like very much. But when I use the old printer, it will almost always bring my whole home LAN down to half-duplex. But a computer's LAN or Wi-Fi connection "Link Speed/Duplex Mode" setting also may not be set to automatic. Instead it may be set to half duplex or may be malfunctioning.

For my system to return back to full-Duplex, I have to turn off the old printer and then reboot my modem, and router, some times several times.

You could try turning off all of your home's LAN equipment except you Modem, Router and Ooma device, reboot Modem, router and Ooma device and see if you Ooma phone service improves.
#82604 by vicw
Thu Jun 02, 2011 9:53 pm
horsecore wrote:
vicw wrote:Hopefully, they are working furiously and diligently, and will let me know when its all fixed.


LOL.

If they are, please let me know whatever fairy dust or magic potion you used to get them to correct the problem - I'd be very happy to acquire it.


They must really be working hard to fix it - so much so that they haven't had a spare moment to send me a status update in the 11 days since the ticket was escalated. I've been repeating the echo test from time to time, just to see if conditions have changed, but I haven't seen any improvement yet.
#82691 by Dennis P
Fri Jun 03, 2011 3:47 pm
We made a routing change today that should improve latency to the external echo server (the 909 number). Can folks test this and see whether or not it improves their results? If you have tested before, please post "before" and "after" numbers. We are working with one of our vendors to see why the latency is high through the old route and hopefully will be able to use this information to create a more general fix for the issue.
#82694 by vicw
Fri Jun 03, 2011 4:23 pm
Dennis P wrote:We made a routing change today that should improve latency to the external echo server (the 909 number). Can folks test this and see whether or not it improves their results? If you have tested before, please post "before" and "after" numbers. We are working with one of our vendors to see why the latency is high through the old route and hopefully will be able to use this information to create a more general fix for the issue.


I just ran the echo timing test at 8:15 PM EDT

I got readings between 476 ms and 522 ms.

My most recent "before" recorded results from 5/19 were between 789 ms and 824 ms.

During the last couple of weeks I've been making periodic looks at the timing, without recording the results, as recently as this morning, and they consistently had been around 750 ms to 880 ms, or thereabouts. I also did a couple of tests using the *98 & *99 prefixes, but I'm not counting those results. They didn't show any improvement, anyway.

Looks like you may be making some progress. It will be interesting to see what others get.
Last edited by vicw on Fri Jun 03, 2011 4:55 pm, edited 1 time in total.
#82695 by sb06794
Fri Jun 03, 2011 4:32 pm
vicw wrote:
Dennis P wrote:We made a routing change today that should improve latency to the external echo server (the 909 number). Can folks test this and see whether or not it improves their results? If you have tested before, please post "before" and "after" numbers. We are working with one of our vendors to see why the latency is high through the old route and hopefully will be able to use this information to create a more general fix for the issue.


I just ran the echo timing test at 8:15 PM EDT

I got readings between 476 ms and 522 ms.


Does this only mean that the echo test has improved or does it also mean that general calls are improved as well?
#82696 by Tom
Fri Jun 03, 2011 4:47 pm
For now this only means the delay on the echo call has improved. We're working with the vendor to reduce
latency on other calls before switching the echo number back to this vendor.
#82700 by hikerwillie
Fri Jun 03, 2011 8:19 pm
I ran the 909 echo test four times this evening.

The results are rather consistent at 395 to 425 msec. Using prefix *98 made no difference.

Early this week readings varied from 560 to 690. The trend over the last six or seven weeks has been toward noticeably shorter times. :D
#82715 by horsecore
Sat Jun 04, 2011 7:30 am
I don't have a method of measuring actual times but the delay when calling the 909 has most definitely been reduced.

I'm mildly optimistic now!

:P

Please keep up misfits posted if/when further progress is made - thanks for keeping us informed to this point as well!
#82716 by vicw
Sat Jun 04, 2011 7:45 am
hikerwillie wrote:I ran the 909 echo test four times this evening.

The results are rather consistent at 395 to 425 msec. Using prefix *98 made no difference.

Early this week readings varied from 560 to 690. The trend over the last six or seven weeks has been toward noticeably shorter times. :D


I'm glad to see that you are also seeing the echo time reduced. It's interesting, though, that you have seen a trending decline over some weeks, whereas mine was pretty constant until suddenly improving yesterday. I guess there must be differences between our routes, and at least in your case, another variable beyond the change that Ooma made just yesterday.

It's also interesting that the ranges of your timing measurements are significantly lower than any others have posted here. Again, I guess that differences in routes could explain that. Are you using the Audacity program on a PC to make your measurements, or another method?

Who is online

Users browsing this forum: No registered users and 14 guests