I don't have a Telo, but its interesting how much more delay you measure on your Telo.
Your measurements/observations about delay and mine have been in sync since late 2010 when our Hubs consistently enjoyed cellphone-like delays around 400 ms.
Being forced to use Skype for my long complex calls lately has reminded me how comfortable it used to be throughout 2010 using Ooma at 400 ms of delay. Hopefully Ooma engineering can nail this problem and get us back there.
If any moderators are lurking here - Thanks much for focusing attention on this audio delay problem - I'll be staying tuned to this thread and sharing my measurements and observations.
My ping roundtrip time to www3.ooma.com is around 85ms avg, with max around 93 ms which is well below the 300ms max standard.
Also from multiple speedtest sites using G.711 and G.729 codec simulations to destinations all over CA I did not get past 0.3% in Jitter or any packet loss.
I too hope they can fix this quick as it will become hard to convice my wife that it is only temporary when it happens on every VOIP call considering using previous VOIP providers & GV the delay was minimal at mutiple SIP gateways all over the country.
Some things to try:
Correct Modem/Router conflict with Ooma device using MAC address Spoofing.
Turn off MAC address spoofing by selecting "Use Built-IN" MAC Address by accessing your Ooma Setup pages with a computer connected to your Ooma device's Home port with a network cable, and to the computer's wired LAN port. Type in http://172.27.35.1 in you computer's brower's window. Your Ooma Setup pages open. Click on Internet Setting, than go down to INTERNET port MAC Address: and click on "Use Built-IN. Than hit "Update".
Test using a (hopefully older) corded phone with your cordless phone base(s) unpowered. Sometimes there has been conflicts between a cordless phone system and the Ooma device, even if the cordless phone cord was disconnected from the base unit. The cordless phones have to be unpowered for this test. I had this problem with a GE cordless phone system and ended up purchasing DECT 6 plus phones.
Test with every other electrical/electronic device (like router, modem, cordless phone base(s) answering machine, etc.) is at least three to four feet away from your Ooma device. Some people have reported problems with echo and delay when other devices are located to close to the Ooma device.
Test with Wi-Fi turned off in your router. Some people have had to change the router’s Wi-Fi frequency to correct this problem, using their router’s Wi-Fi frequency pull-down menu...
Check and make sure that some other device on your home LAN network isn’t Half-Duplexing. Sometimes another device on your home’s LAN will cause the whole system to Half-Duplex. Ooma needs Full-Duplex to prevent echo and delay. The best way to test is to turn off and unplug all other LAN connected devices in your home. Connect the Ooma device directly to the Modem. Reboot the Modem, than the Ooma device and test. If you still have echo and delay, reboot the modem, thatn Omma device again. Sometimes you have to reboot the modem/Ooma several times to get it to return to Full-Duplex mod. Note: some modems contain batteries, which have to be removed to achieve a proper reboot. If so, be sure to reinstall the batteries when done testing. I have an old networked printer that will reduce my home’s LAN to Half-Duplex. I liked the printer and used to use the printer a lot, but I always had to reboot everything to get rid of the echo and delay. So since I have other printers that don’t cause this problem, I hardly ever use it any more.
Test making a call to someone else that has Ooma phone service. If your don't have echo/delay when talking to another Ooma device phone, This tells you your problem is a routing issue, caused by the handoff between Ooma and the legacy carriers. Ooma Customer Service has to have/get this problem corrected.
Test and Get a different Internet Provider IP address:
Some Internet provider's connections are teribble.
Click on the Advanced tab in the lower left side.
Jitter should be 5ms or less.
There should be no lost/discard packets.
The download and upload Quality of Service should be around 80% or more.
Maximum TCP delay should be and is usually much less than 100ms.
Run http://whatismyipaddress.com/ and record the Internet provider's IP address that was dynamically sent to your modem.
If you find that your readings are out of limits, reboot your modem, than Ooma device.
Note: Some modems have batteries installed, that have to be removed for a successful reboot. If batteries are removed, be sure to reinstall batteries.
Run http://whatismyipaddress.com/ and record the Internet provider's IP address that was dynamically sent to you again, to make sure that the IP address has changed.
Run http://speedtest.phonepower.com/ again.
Repeat this process until you receive an IP address that is satisfactory.
I have had to repeat this procedure up to almost twenty times before I received an IP address that was satisfactory for VoIP use.
If you Internet provider issued you a Static IP address, get them to change the Static IP address that your modem is using and is assigned to your account.
You will probably have to reboot your router each time you reboot your modem.
Test your phone system
I was still unable to find any major issues that would cause a constant delay.
Test done from NC to CA.
Test Type: VOIP
Upstream jitter 1.7 ms
Downstream jitter 3.7 ms
Upstream packet loss 0.0 %
Downstream packet loss 0.0 %
Upstream packet order 100.0 %
Downstream packet order 100.0 %
Packet discards 0.4 %
REGISTER ms 778 ms
INVITE ms 792 ms
BYE ms 4 ms
Test Type: Quality
Location: San Jose, CA
Download Speed: 4921 kbps
Upload Speed: 366 kbps
Speed Consistency: 99 %
Round Trip Time: 96 ms
Max Delay: 14 ms
Max Delay: 14 ms
Average Delay: 2 ms
Bandwidth: 4960 kbps
Max Route Speed: 5461 kbps
Test Type: s / s
Round Trip Time Consistency: 97 %
TCP Receive Stats
Packets not in order: 0
Bytes out of order: 0
Packets outside TCP Window: 0
Bytes after rec. window: 0
Bytes Lost: 0
Duplicate Packets: 0
Bytes rec. in duplicate packets: 0
Partially duplicate packets: 0
Bytes rec. in partially dup. pkts: 0
Pkts rec. w/ bad offset to data segment: 0
Pkts rec. w/ bad checksum: 0
Pkts rec. which are too short: 0
Window probes received: 0
Zero Window Updates Sent: 0
TCP Send Stats
Packets Retransmitted: 0
Bytes Retransmitted: 0
Retransmit Timeouts: 0
Fast Transmits: 0
Duplicate acks received: 9
Persist timer timeouts: 0
Acks received for unsent data: 0
Pure window upd pkts: 0
Windows probes sent: 0
Send window close events: 0
Receive overruns: 0
Frames Received w/ bad checksum: 0
Frames Received Too Large: 0
Frames rec. not octet-aligned: 0
Frames rec. too short: 0
Frames received truncated: 0
Network down time: 0 secs
Network up time: 16716 secs
Network downtime in current 24 hour period: 0.0%
HTTP 3XX Error: 0
HTTP 4XX Error: 0
HTTP 5XX Error: 0
unknown HTTP Error: 0
Run the Phonepower test http://speedtest.phonepower.com/ two ways and post here.
First run the http://speedtest.phonepower.com/ test without going through you Ooma device.
Next rut the http://speedtest.phonepower.com/ test with your same computer connected with a network cable, connected to the Ooma device's Home Port.
Click on lower left Advanced tab, than lower right "view text", highlight, copy, and Post both results.
I believe you may be measuring one-way delay between your Ooma and your Pots line and measuring round-trip delay when using the 909 loop-back number, so doubling the Pots-measured delay may be needed.kdawgud wrote:I have been worried about the delay as well after trying that 909 echo line. However, in my own tests between ooma and my land line, cell phone, google voice, etc. I have not experienced anywhere close to the delay of the echo line. I would say I'm seeing ~800ms on the echo line and less than ~500ms between ooma and everything else (and often less than 400ms - unscientifically measured). Is there some reason to expect the 909 echo line to be worse than other connections?
Quote From Another VoIP Provider Site:
reply to buckeyered
I tried 909-390-0003 with CC, VP, and F9 but with F9 I could only hear part of the first word I say and then nothing. CC and VP was crystal clear.
said by nitzan:
Give it another try now. I switched it to our main termination carrier. (it was going through CA CLEC before and for some reason they apparently don't play well with it)
This is actually a good point to consider- just because 909-390-0003 sounds good (or bad) means absolutely nothing. Most providers have many carriers they work with and just because the carrier that services this number works well doesn't mean other carriers will too.
Call an echo number. Speak and listen to yourself echo back. This is helpful to diagnose audio quality issues. One number known to work as a VoIP echo test is 909-390-0003. Nobody says hello, but if you wait a few seconds, you can talk and listen to yourself echo back.
How are you doing these tests?kdawgud wrote:I have been worried about the delay as well after trying that 909 echo line. However, in my own tests between ooma and my land line, cell phone, google voice, etc. I have not experienced anywhere close to the delay of the echo line. I would say I'm seeing ~800ms on the echo line and less than ~500ms between ooma and everything else (and often less than 400ms - unscientifically measured). Is there some reason to expect the 909 echo line to be worse than other connections?
Good point. That may explain most of the difference. It seems I got the shortest delays when my POTS line called the ooma (as opposed to vice versa).Bill D wrote:I believe you may be measuring one-way delay between your Ooma and your Pots line and measuring round-trip delay when using the 909 loop-back number, so doubling the Pots-measured delay may be needed.kdawgud wrote:I have been worried about the delay as well after trying that 909 echo line. However, in my own tests between ooma and my land line, cell phone, google voice, etc. I have not experienced anywhere close to the delay of the echo line. I would say I'm seeing ~800ms on the echo line and less than ~500ms between ooma and everything else (and often less than 400ms - unscientifically measured). Is there some reason to expect the 909 echo line to be worse than other connections?