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.
#72595 by bmccollum
Sun Jan 09, 2011 1:33 pm
I agree... put your money where your mouth is and give the individuals on this forum some sort of pertinent response on this horrible delay issue. I know the cost per monthly is only $3.47 per month, but come on, even for $3.47 per month, the latency / lag time in calls that a lot of users are experiencing is beyond atrocious.
#72623 by ajw522
Mon Jan 10, 2011 12:45 am
Please Ooma! Give us some sort of update, and as many people have said, this delay is getting worse and worse. We need to know what's going on! 800ms is CRAZY!
#72630 by thunderbird
Mon Jan 10, 2011 6:35 am
Information taken from: http://www.voiptroubleshooter.com/indepth/index.html

Some interesting information.

Problem: Excessive Delay
High levels of delay (generally over 200 milliseconds round trip) can cause problems with conversational interaction. This may be due to the routing of the IP stream, mis-configuration of the jitter buffer (i.e. too large) at either end of the connection or high levels of jitter which are causing an adaptive jitter buffer to grow excessively large

Impact
In the presence of high levels of delay the normal "protocol" of conversation breaks down. In addition, delay can make echo problems more obvious and annoying.

Resolution
Use traceroute to verify the IP path delay. Check the jitter level for the call and verify the configuration of the jitter buffer. The problem can occasionally be due to VoIP Gateways using excessively large voice packets or aggregating voice frames from many calls into one packet.

Tools: Network Analyzer, Traceroute, VQmon

Problem: Access Link Congestion
Access links are typically the bottleneck between a high bandwidth LAN and a high bandwidth IP network. An increase in traffic can cause the queue in the edge/access router to fill, which increases jitter and causes a short term increase in delay. High levels of congestion can also introduce packet loss due to buffer overflow or Random Early Detection (RED).
As an example, it takes 8 milliseconds to send a typical data packet over a T1 connection. If two data packets arrive at the access router ahead of a voice packet, then the voice packet would be delayed by 16 milliseconds. If the access link speed is slower than T1 then the delay would be greater - for a 512 kilobit/sec link the delay would be 24 milliseconds per packet.
Access link congestion can be a particular problem for ADSL and Cable Modem connections.
Impact:
High levels of jitter resulting from access link congestion cause excessive numbers of packets to be discarded by the receiving Voice over IP end system's jitter buffer, which leads to degraded voice quality. As the level of congestion varies with traffic then the jitter level will vary, hence users may report that the call becomes garbled intermittently.
Resolution:
Access link problems can be reduced by
1. Using priority queuing for delay sensitive voice and video traffic
2. Reducing the maximum MTU size on low speed links (512 kbits/s or less)
3. Increasing the capacity of the access link
4. If multiple links are used, then applying load sharing to maximize use of capacity
5. Applying call admission control to limit the number of calls
6. Using fragmentation and interleaving.
Tools: Traceroute, VQmon

Problem: Jitter
Excessive jitter can result from congestion on LANs, Access Links, low bandwidth WAN links/trunks or the use of load sharing.
In depth discussion of jitter sources
Impact
High levels of jitter cause large numbers of packets to be discarded by the jitter buffer in the receiving IP phone or gateway. This may result in severe degradation in call quality or large increases in delay.
(Go to voiptroubleshooter address at top of this post to be able to play examples below)
Example audio file - 5% packet discard rate:
Example audio file - 10% packet discard rate:
Example audio file - 25% packet discard rate:
Resolution
Jitter measurements can be difficult to interpret. RFC3550 (RTP/RTCP) provides a simple running average of the packet to packet delay variation - this provides useful information about the 500 milliseconds before the RTCP report was sent and hence only reports on about 5-10% of the call. The Jitter Envelope measurement provided by VQmon is more accurate and measures jitter in a way that correlates better with the impact of jitter on VoIP systems.
For jitter levels under 100 milliseconds then it may be acceptable to increase the jitter buffer size in end-systems or to enable adaptive jitter buffer operation.
For jitter levels over 100 milliseconds then increasing the jitter buffer size to avoid packet discards will introduce significant delay and cause conversational problems; in this case it is preferable to take steps to isolate the source of jitter and eliminate the problem at source.
Tools:
Network Analyzer, VQmon
#72640 by Bill D
Mon Jan 10, 2011 8:32 am
Thunderbird -

Not sure if your referenced info is aimed at helping Ooma users or at helping the Ooma engineers fix their problem.

My stats are great (see below) and my www3.ooma.com ping time used to be 100 ms back when I always saw the Ooma delay at 400 ms. My ping time has now improved to 75 ms, but Ooma delay (just measured again) is a very ugly 800 ms.

I'm very curious if there any Ooma users actually mesuring low delay times right now.

VoIP test statistics
--------------------
Jitter: you --> server: 0.1 ms
Jitter: server --> you: 1.0 ms
Packet loss: you --> server: 0.0 %
Packet loss: server --> you: 0.0 %
Packet discards: 0.0 %
Packets out of order: 0.0 %
Estimated MOS score: 4.0

Speed test statistics
---------------------
Download speed: 9812536 bps
Upload speed: 1176088 bps
Download quality of service: 96 %
Upload quality of service: 77 %
Download test type: socket
Upload test type: socket
Maximum TCP delay: 55 ms
Average download pause: 3 ms
Minimum round trip time to server: 76 ms
Average round trip time to server: 76 ms
Estimated download bandwidth: 35200000bps
Route concurrency: 3.587248
Download TCP forced idle: 81 %
Maximum route speed: --
#72643 by thunderbird
Mon Jan 10, 2011 9:11 am
Bill D Asked: I'm very curious if there any Ooma users actually mesuring low delay times right now.

Pinging www3.ooma.com
My delay is 157ms not going through my Ooma Telo Home port.
My delay is 433ms going through my Ooma Telo Home port.

My wife called me from her workplace a few minutes ago, and and neighbor called shortly after, the call quality for both calls were next to perfect.

I just can't understand why some people have so much trouble, but other have little or no problems. There has to be some common link, like Internet provider, or Internet speeds or ?????
#72652 by ajw522
Mon Jan 10, 2011 10:55 am
@Bill D: I'm experiencing the same delays as you. What's your ISP?

The thing is, I don't think it has anything to do with my ISP. I've always had the same ISP before I got Ooma and after I got Ooma. Only after I switched to the Telo did I start having delay issues.
#72654 by Bill D
Mon Jan 10, 2011 11:01 am
thunderbird wrote:Pinging www3.ooma.com
My delay is 157ms not going through my Ooma Telo Home port.
My delay is 433ms going through my Ooma Telo Home port.
....I just can't understand why some people have so much trouble, but other have little or no problems. There has to be some common link, like Internet provider, or Internet speeds or ?????

I agree T-bird and I would like to nail that reason. Voice quality on my calls are also "next to perfect" but its only the delay that's my problem.

The ping times you posted above are interesting. My ping times are 75ms either through my Hub's Home port or NOT through my Hub's Home port.

Have you measured your audio delay using the method described earlier in this thread at viewtopic.php?f=4&t=9569&start=30#p67874 - Knowing your delay measurement would help very much to compare to the delay measurements made by me and others on this thread.
#72656 by Bill D
Mon Jan 10, 2011 11:08 am
ajw522 wrote:@Bill D: I'm experiencing the same delays as you. What's your ISP?

The thing is, I don't think it has anything to do with my ISP. I've always had the same ISP before I got Ooma and after I got Ooma. Only after I switched to the Telo did I start having delay issues.

I'm on AT&T U-Verse in Ft Lauderdale Florida.
I've never had a Telo.
I have 3 Hubs in two houses and the delay trouble started a couple months ago.

Who is online

Users browsing this forum: No registered users and 8 guests