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.
#83223 by lbmofo
Wed Jun 15, 2011 11:38 am
jhphone wrote:Voodoo and potatoes, whatever, "have been found to cause echo and delay", blah blah.

Billshit.

This is a user forum where folks try their best to help others. Even if certain things posted don't help you, doesn't mean they are BS.

To me, it is pretty simple, really. When things are not working right, you go through a process of elimination...is it your modem? router? your internet service? your setup? If all is well, then it could be Ooma's carrier support for your area or the Ooma hardware itself.

You look at the forum to gain some help and get possible pointers. Even if no suggestions work for you, no need to be overly critical of a goodwilled forum contributor.
#83535 by EricJRW
Wed Jun 22, 2011 7:33 am
jhphone wrote:
thunderbird wrote:Purds:
I am listing all of the things that have helped others in the past.
...
Electrical/electronic equipment located to close to the Ooma device have been found to cause echo and delay.
Move all electrical/electronic equipment at least three to four feet from the Ooma device.
Test again and see if there is a difference.
...


Voodoo and potatoes, whatever, "have been found to cause echo and delay", blah blah.

Billshit.

Delay requires buffering of digitized packets.

So, in the real world -- not in the Harry Potter world where you get to make things up with your keyboard -- please [b]explain [/b]how "Electrical/electronic equipment located to close ..." can cause this buffering.
You cannot.


If something local, i.e. interference, is causing packets to become corrupt/lost, might there be some retry logic? Typically in UDP I don't think this is the case, but I'm not sure if ooma is UDP or TCP. If ooma uses TCP, then corrupt packets could be retried. Not sure if ooma if going for reduced latency with UDP, or better reliability with TCP.
#83544 by murphy
Wed Jun 22, 2011 8:27 am
Retries would be meaningless for VOIP data. A retried packet would be so far out of sequence that it would be discarded anyway. It's not like a data transfer where the packets can be put back into the correct order before the file is written to the hard disk. If a VOIP packet is not received in the correct sequence it is too late for it to be of any use. Imagime the complaints if the voice data stream was held up until a wayward packet arrived 5 seconds late.
Voice traffic is UDP. It either gets there on time in the right order or it is discarded.
#83553 by EricJRW
Wed Jun 22, 2011 10:51 am
murphy wrote:Retries would be meaningless for VOIP data. A retried packet would be so far out of sequence that it would be discarded anyway. It's not like a data transfer where the packets can be put back into the correct order before the file is written to the hard disk. If a VOIP packet is not received in the correct sequence it is too late for it to be of any use. Imagime the complaints if the voice data stream was held up until a wayward packet arrived 5 seconds late.
Voice traffic is UDP. It either gets there on time in the right order or it is discarded.

Understood. Thanks.
#83604 by thunderbird
Thu Jun 23, 2011 6:04 am
jhphone wrote:
thunderbird wrote:Purds:
I am listing all of the things that have helped others in the past.
...
Electrical/electronic equipment located to close to the Ooma device have been found to cause echo and delay.
Move all electrical/electronic equipment at least three to four feet from the Ooma device.
Test again and see if there is a difference.
...


Voodoo and potatoes, whatever, "have been found to cause echo and delay", blah blah.

Billshit.

Delay requires buffering of digitized packets.

So, in the real world -- not in the Harry Potter world where you get to make things up with your keyboard -- please explain how "Electrical/electronic equipment located to close ..." can cause this buffering.

You cannot.

http://en.wikipedia.org/wiki/Electromag ... terference

http://en.wikipedia.org/wiki/Signal_noise

http://en.wikipedia.org/wiki/Echo_(computing)
#83879 by John Pombrio
Wed Jun 29, 2011 10:51 pm
sigh... A brand new user of Ooma, and a brand new delay in the phone (when calling my cell). I donno if I will keep it or not, it depends on how it works over the next few days. Meantime though, I did find the forums! Heh.
EDIT EDIT EDIT 6-30-2011 Terrific voice quality and no delay noticed at all! A Keeper! Whew..
I agree with the poster who said that any delay is NOT due to RF interference. (This is 25+ years of HP/Agilent Test and Measurement Systems repair and calibration talking. DC power supplies to optical fiber jitter testing, RF/microwave/Antenna, Cable Modem tester for UL labs, ParBERTs, cable testers for Cat5/6, with a specialty of digital analyzers.)
RF noise can cause issues with the voice quality of the phone call but not a delay, period. The analog to digital converters these days are damn near instantaneous. That means that my voice is turned to a digital signal in the Ooma hub with virtually no chance of any delay. The low level conversion of the digital signal into packets is also very quick and has no chance of a delay. Now moving packets on the home network has such a slight chance of collisions that it can be ignored. EDIT One other point is that VoIP is a decidedly low bandwidth application. It barely uses any of the available resources. I would expect that a normal home internet connection could easily handle dozens of calls at once. END EDIT Bottom line? Any delay has to be from the ISP or the cloud.
Now I have a Docsis 3 cable modem. This is tremendously fast, real world fast. 70Mb/s, 5Mb/s fast. I regularly have torrents run at 3MB/s (that is right Megabytes, not Megabits) download speeds. I am pretty sure that any delay issues with my Ooma is not with my ISP. Heh.
Sooo, what is left is the cloud. The cloud is the network packet backbone carriers along with the local VoIP to phone companies that Ooma has contracted with. Here, money counts and delays are a certainty. All packets are prioritized by the carriers, net neutrality be damned. Pay more money and your packets have priority. Pay less and you are low priority to no priority. This is not the case in most places besides the US as there is no government regulation here.
All phone lines have delays, been that way since Mr. Bell's time. However, all phone calls these days are VoIP, including landlines. So what distinguishes the different kinds of service? Money, of course. My phone line with my cable company is superb, with excellent voice and virtually no delay. I also use Google's GMail free calling all the time and that has a slight delay, noticeable at times. The GMail also has occasionally some issues with voice quality.
Ooma is daring company in trying to basically give away what the big companies are charging for. It piqued my interest enough to buy one of their hubs. What Ooma does not have is the money to fully develop a quality experience, as I have immediately found out. Without a bottomless purse like Google has, Ooma will be struggling to balance customer experience with low cost of operations until the premium customers fork over enough income to let Ooma upgrade their carriers. Unfortunately, I am not sure I am willing to wait until Ooma gets it together.
Delays are caused by lack of quality service of the carriers. Not RF interference, not ISPs, not networking woes, not bad signal strength. Calling Ooma customer support will be a fruitless waste of time as they can only bitch to the carriers and the carriers are going to say "you get what you pay for".
And let the discussions begin...
#83884 by lbmofo
Thu Jun 30, 2011 10:01 am
Welcome John. Where I am in the Pacific Northwest, most Ooma users have XO Communications. I think they are excellent.
#83956 by EricJRW
Sat Jul 02, 2011 3:20 am
Interesting read John. Thank you and welcome.

Who is online

Users browsing this forum: No registered users and 6 guests