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.
#68835 by Bill D
Thu Nov 11, 2010 11:02 am
Dennis P wrote:Are you measuring the one-way delay in this test? If so, this is a little higher than I would expect (I would have thought 150-200 msec). Are you connecting your phones directly to the Ooma Hub, or are you going through a Scout?
Hi Dennis - - I think I'm measuring 2-way delay without the Ooma telco gateway delay - - here's exactly what I've done:

Phone #1 has mute and speakerphone on. Phone #2 has it's mike active so the click goes in phone #2's mike through Hub #2 to Ooma and back through Hub #1 to phone #1 to be recorded by Audible. This seems like it would be the same as a round trip delay measurement using one Hub calling 909-930-0003, but without going in and out of any telco gateways at Ooma. This assumes 909-390-0003 is a loopback number outside of Ooma, such that the call goes out of Ooma on a telco gateway and back into Ooma on a telco gateway. (is it outside Ooma?).

When I run the test from one of my Hubs calling 909-390-0003 it measures 420 ms (whether or not I dial *99 first). The fact that it is 110 ms more than my 2-Hub test seems to say the telco gateway(s) adds 110 ms.

Out of curiosity, I also just did a series of pings to www3.ooma.com and measured a solid 100 ms (min max and average).

Answer to your Scout question - - My Uniden 8866 wireless 2-line phone system is connected directly to my two Ooma Hubs. Each Hub has a Scout that I only use for checking VM (nothing plugged into their "phone" jacks).

Bill
#68842 by Dennis P
Thu Nov 11, 2010 12:31 pm
Bill D wrote:Phone #1 has mute and speakerphone on. Phone #2 has it's mike active so the click goes in phone #2's mike through Hub #2 to Ooma and back through Hub #1 to phone #1 to be recorded by Audible. This seems like it would be the same as a round trip delay measurement using one Hub calling 909-930-0003, but without going in and out of any telco gateways at Ooma. This assumes 909-390-0003 is a loopback number outside of Ooma, such that the call goes out of Ooma on a telco gateway and back into Ooma on a telco gateway. (is it outside Ooma?).


Technically you are measuring the one way delay since you are sending a sound input into phone #2 and recording it as it plays out on phone #1. A roundtrip echo measurement would acoustically couple together the mic and earpiece of phone #1 and you would measure the delay from the sound input into phone #2 and the echo heard back also on phone #2.

But maybe this is merely a different in syntax. For your test, yes the packets travel round trip, from one device, to our datacenter and back to a second device. Maybe that is what you were saying.

Bill D wrote:When I run the test from one of my Hubs calling 909-390-0003 it measures 420 ms (whether or not I dial *99 first). The fact that it is 110 ms more than my 2-Hub test seems to say the telco gateway(s) adds 110 ms.
l


I think that would be a logical conclusion.
#68845 by matchorno
Thu Nov 11, 2010 1:05 pm
Dennis P wrote:I see that you are using a Telo. The fix that we are currently testing should be rolling out starting early next week and should reduce your round-trip delay by 150-200 msec.


I too am having terrible audio delay problems. When I talk to someone there is about a 2 second delay. I am calling to a 609-432 number. The fix you are rolling out will not even put a dent in my problem. Is there anything else that is being done to fix this problem? Can I expect a better fix than a 150-200 msec improvement any time soon? I am currently in the process of having my number ported. Once it's ported, do I lose my regular phone service automatically or do I have to cancel it with Verizon. If not, then I need to put a pause on my porting.

I am on the east coast in new jersey. I had no idea it would be worse on the east coast since I am not close to California. This is really something that should be advertised so the consumer can make an informed decision about their purchase.
#68846 by Aveamantium
Thu Nov 11, 2010 1:08 pm
matchorno wrote:
Dennis P wrote:I see that you are using a Telo. The fix that we are currently testing should be rolling out starting early next week and should reduce your round-trip delay by 150-200 msec.


I too am having terrible audio delay problems. When I talk to someone there is about a 2 second delay. I am calling to a 609-432 number. The fix you are rolling out will not even put a dent in my problem. Is there anything else that is being done to fix this problem? Can I expect a better fix than a 150-200 msec improvement any time soon? I am currently in the process of having my number ported. Once it's ported, do I lose my regular phone service automatically or do I have to cancel it with Verizon. If not, then I need to put a pause on my porting.

I am on the east coast in new jersey. I had no idea it would be worse on the east coast since I am not close to California. This is really something that should be advertised so the consumer can make an informed decision about their purchase.

Have you run this test outlined here viewtopic.php?f=4&t=9569&start=30#p67874
#68849 by Dennis P
Thu Nov 11, 2010 2:24 pm
matchorno wrote:I too am having terrible audio delay problems. When I talk to someone there is about a 2 second delay. I am calling to a 609-432 number. The fix you are rolling out will not even put a dent in my problem. Is there anything else that is being done to fix this problem? Can I expect a better fix than a 150-200 msec improvement any time soon? I am currently in the process of having my number ported. Once it's ported, do I lose my regular phone service automatically or do I have to cancel it with Verizon. If not, then I need to put a pause on my porting.


A 2 second delay is highly unusual. How are you measuring this? Please use the method that Aveamantium links to and post the date/time of your test call. I will look at the traces to see what I can find. You can also PM me and we can setup a time to do some testing and get to the bottom of this.
#68850 by matchorno
Thu Nov 11, 2010 2:37 pm
Dennis P wrote:
matchorno wrote:A 2 second delay is highly unusual. How are you measuring this? Please use the method that Aveamantium links to and post the date/time of your test call. I will look at the traces to see what I can find. You can also PM me and we can setup a time to do some testing and get to the bottom of this.


I will do the test, but no matter what the test results are, to me the best test is the real world test...i.e, what happens when you are on a conversation. I told the person on the other end to say 4 as soon/right after they hear me count to 3. After waiting at least 2-3 seconds (maybe more), I finally hear them say "4". So perhaps the one way delay is 1 - 1.5 seconds (maybe more), but it makes a conversation arduous. I could use a stop watch while I'm talking to see how long it really takes in this real world application...that would seem to be just about as accurate and much more useful. But I will go ahead and do this other test anyway.

I sent an email to support already as I am worried since I am in the porting phase. I don't want to lose my phone carrier and/or phone number if the ooma isn't going to work out. A summary of our email exchange is below

Code: Select allMay we know if this is happening to all of your calls inbound and outbound?
- I can only make outbound calls right now.  My number is in the process of being ported so I can’t receive calls yet.

Are you using the Telo Handset? What type of phone are you using, corded or cordless?
- I am using a vTech (Dect 6.0) cordless phone.

Since you are already familiar on how to configure the QoS, kindly change the value of your upstream to "0". Make sure that the downstream is also set to "0" and then click update. Kindly reboot your Ooma device by unplugging the power adapter. Leave it unplugged for at least 2-3 minutes and plug it back again for changes to take effect.
- I tried this to no avail.  Still have the same issue.

You may also check this site, mailto:www.myvoipspeed@visualware.com so that we can test the disturbance on the line. Please provide us jitter sample, packet loss and the ping. Jitter and packet loss causes delay on the line. A good jitter should not be more than 4.9 ms. For packet loss, it should always be at 0% range.

I did the test you recommended from www.myvoipspeed.  There were numerous tests for MyVoip (G.711 | G.729 | G.723.1 | G.726 | G.728 | Multiple Lines | Concise)
I tried all of them and got the results listed below:

The jitter: you—>server was always 0.0 ms
The jitter: server—>you ranged between 1.7 – 2.9 ms
The Packet loss was always 0.0 %.

I didn’t see any results numbers for “ping”.  I didn’t know how to test for that (there are multiple tests available), so I ran one for “Application Speed”

The results for the MyVoip tests and Application Speed test are shown below.
(By the way, the website you referred me to was an email address: mailto:www.myvoipspeed@visualware.com )  I figured you meant the website (www.myvoipspeed.com)

Please let me know how to proceed to remedy this problem.

Thanks
___________________________________________________________________________

VoIP test statistics
--------------------
Jitter: you --> server: 0.0 ms
Jitter: server --> you: 1.9 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.2

Speed test statistics
---------------------
Download speed: 251617544 bps
Upload speed: 262778960 bps
Download consistency of service: 91 %
Upload consistency of service: 95 %
Download test type: socket
Upload test type: socket
Maximum TCP delay: 15 ms
Average download pause: 1 ms
Minimum round trip time to server: 1 ms
Average round trip time to server: 1 ms
Estimated download bandwidth: 312000000bps
Route concurrency: 1.2399771
Download TCP forced idle: 0 %
Maximum route speed: 524280000bps
#68860 by jhphone
Thu Nov 11, 2010 4:59 pm
Dennis P wrote:
Bill D wrote:
jhphone wrote:I called from one Ooma line to the other Ooma line between two handsets, put one handset on mute and speakerphone while holding it near the PC microphone and I clicked the two handsets together while recording on Audible. The results were consistent for dozens of clicks - 310 ms.

This 310 ms seems to encompass one Hub output delay, one Hub input delay and the Ooma VOIP server delay with no telco gateways involved. I repeated the test again dialing *99 first and the delay dropped to 280 ms.


Are you measuring the one-way delay in this test? If so, this is a little higher than I would expect (I would have thought 150-200 msec). Are you connecting your phones directly to the Ooma Hub, or are you going through a Scout?


Sorry for not being clear. This is the total -- or round trip -- delay. IOW, while recording with my MP3 player, I tap the phone handset (speakerphone mode), which sounds like a sharp click and then hear the return sound from the echo-back number. I did this about a dozen times, allowing at least a few seconds between the echo and my next tap so as not to confuse them. I used audacity to measure the time elapsed between the click and its "echo." It was 500-520 ms consistently.

My belief that the problem -- the delay -- must be in the software design or a setting is because this approx 400 ms of audio is being buffered somewhere. This stream of digital data obviously does not simply disappear for 400 ms and then somehow magically reappear at the other end. There must be buffering going on.

The Internet is not doing the buffering, as testified by the many VoIP test results shown on this forum. Very seldom do you see a total TCP round trip delay of more than 50-100 ms. The handset does not store or buffer audio, ruling it out. Thus some component of the Ooma system must be the buffering element.

I roughly calculated that 400 ms of audio would take about 10KB of buffer (RAM). But where is the buffering happening? The Telo unit certainly has enough RAM for many seconds of audio. So it is potentially the cause of the delay by "waiting too long" (buffering) before transmitting the packet. OTOH, the Ooma server software is obviously much more complex than the Telo. So as a retired programmer I guessed that some setting/parameter in this "big" software would more likely be the cause.

But it looks like the Telo is the cause. I'm very pleased to hear that will soon be an upgrade to it addressing this issue.

Thanks, guys.
#68945 by sfhub
Fri Nov 12, 2010 11:30 pm
jhphone wrote:My belief that the problem -- the delay -- must be in the software design or a setting is because this approx 400 ms of audio is being buffered somewhere. This stream of digital data obviously does not simply disappear for 400 ms and then somehow magically reappear at the other end. There must be buffering going on.

The Internet is not doing the buffering, as testified by the many VoIP test results shown on this forum. Very seldom do you see a total TCP round trip delay of more than 50-100 ms. The handset does not store or buffer audio, ruling it out. Thus some component of the Ooma system must be the buffering element.

I roughly calculated that 400 ms of audio would take about 10KB of buffer (RAM). But where is the buffering happening? The Telo unit certainly has enough RAM for many seconds of audio. So it is potentially the cause of the delay by "waiting too long" (buffering) before transmitting the packet. OTOH, the Ooma server software is obviously much more complex than the Telo. So as a retired programmer I guessed that some setting/parameter in this "big" software would more likely be the cause.

Buffering and/or delay are just two sides of the same coin w/r/t your phone call. There could be network delays, delays in the transcoding servers, delays in the backend providers, delays in the telo, etc. Some of these delays might involve buffering while others might involve very little, if any buffering. The key is to isolate where the delays are happening and get the sum total within a range that is usable.

Using your numbers, you could have one server hop of 1ms buffering 10KB before sending anything and that could account for 400ms (1way) or you could have no buffering with 400 hops of 1ms each accounting 400ms delay. More likely you have some combination of buffering and network delays. In the end, it only matters that you get the sum total down to something reasonable by isolating the delays that are not normal. Clearly the design itself is capable of reasonable performance because at some point it was usable.
#68962 by jhphone
Sat Nov 13, 2010 11:42 am
sfhub wrote:...
Buffering and/or delay are just two sides of the same coin w/r/t your phone call. There could be network delays, delays in the transcoding servers, delays in the backend providers, delays in the telo, etc. Some of these delays might involve buffering while others might involve very little, if any buffering. The key is to isolate where the delays are happening and get the sum total within a range that is usable.

Using your numbers, you could have one server hop of 1ms buffering 10KB before sending anything and that could account for 400ms (1way) or you could have no buffering with 400 hops of 1ms each accounting 400ms delay. More likely you have some combination of buffering and network delays. In the end, it only matters that you get the sum total down to something reasonable by isolating the delays that are not normal. Clearly the design itself is capable of reasonable performance because at some point it was usable.


Good points. But Internet cannot be causing this amount of delay. Lets discuss your point "...one server hop of 1ms bufferi[s] 10KB before sending anything and that could account for 400ms…"

It would actually take much more than 10K to buffer 400ms. Remember, your packets are mixed in with a huge number of other packets. If an Ooma packet is delayed at a hop, so are all the others. Internet switches simply don't have enough memory to buffer 400ms of data. Here's why.

At each hop, an input fiber from a distant hop is connected to an input port on the switch. The input port contains a line card (LC) that converts optical data to electronic data. IOW, an optical packet streaming into an LC fills an electronic ("SRAM") buffer. The LC looks at the header and decides what to do with it, where to forward it, etc. This takes a very short amount of time. Meanwhile, as you state, the packet has to be buffered.

Assume the fiber speed is 2.5 Gbits/sec speed. If packets are held for 400ms, how much memory would the LC need to buffer this traffic: 125 Mbytes! (2,500,000,000 bps x 0.4 sec / 8 bits/byte). Line cards absolutely don't have this much memory for buffering.

Let's look at it from a different angle and assume an LC does have this amount of buffering -- 125 MB. IP packet lengths vary from about 50 bytes to 1,500 bytes, with an average length of about 500 bytes (from Google). It would take 250,000 packets to fill a 125MB buffer! There is absolutely no reason to buffer 250,000 packets before sending them on.

Each LC has to process more than 700,000 packets per second. The LC has to perform a lookup based on the destination IP address in the packet header to determine which output port/fiber to forward it. But this must be done, and is done, in sub-microsecond time.

Each switch wants to get rid of arriving packets as fast as it possibly can. It is very expensive to buffer packets that are arriving a gigabit/sec rates. No more than a handful of packets are buffered at the LC. The average time it's delayed inside a switch is much less than 1ms. It arrives and is gone -- BAM!

Your other point of "400 hops at 1ms each for a total of 400ms" is important. But a packet cannot make that many hops. There is a TTL (time to live) byte in the header. Every time the packet passes through a switch (hop) this value is decremented by one. If it reaches zero the packet is discarded (not forwarded). The max TTL is 255, which sets an absolute upper limit of 255 hops.

But in reality, packets never even go through half that many. Assume 50 hops at 0.5 ms each, that's 25ms total delay caused by the switches.

There is also a speed-of-light delay that has to be added to the switching delay. Assuming 3,000 miles of fiber (worst case!) out and back, I get about 27ms of delay. Adding these, 25ms + 27ms is about 50ms.

But all these calculations are irrelevant. The actual delay can be measured.

The VoIP tests show that actual Internet-related delays are typically less than 50-100 ms. These test results have been reported in the forum many times by many people, at different times and locations. I've run them at least a dozen times and get consistent results. (And they are consistent with the calculated numbers.)

The total delay that we have measured and reported here is 500-550ms. So we have to account for 400-500ms of delay that is external to the Internet: Ooma. We are promised an upgrade to the Telo which addresses this issue.
#68969 by Bill D
Sat Nov 13, 2010 2:28 pm
My delay just got MUCH worse.

Previously my Hub's loop delay regularly measured 410 ms
(calling the 909 loop number from either of my two hubs in Florida 954-384).

Today at 4:10 pm and 5:30 pm EST my loop delay measured 680 ms.
(pings to www3.ooma.com are 100 ms, the same as always).

My further testing indicates the Ooma telco gateway as the sole cause of the 270 ms increase.

Hub1->Ooma->909-390-0003->Ooma->Hub1
(basic loop delay test measured 680 ms)

Hub1->Ooma->Hub2
(calling between my two Hubs, with no telco gateway involved measured 290 ms)

My Hub to Hub (no gateway) delay of 290 ms is the same as it has regularly been, so the 270 ms increase in loop delay was completely caused by the telco gateway at Ooma (the gateway delay went from 110 ms to 380 ms).

Has anyone else seen a big increase in delay?

What's up Ooma?

Bill

Who is online

Users browsing this forum: No registered users and 6 guests