Dial 909-390-0003 to test voice quality

[coastalcruiser]

I just found out about this phone number the other day. I had the same issue that snooker reported. Each time I called the number the playback would sharply degrade after a couple of test sentences. Since I am just getting my new ooma set up, and since I was going modem > router > ooma for now, I thought I had some work ahead of me. But last night I used ooma for a 20 minute call and the quality was near flawless (and through a wireless connection between my modem and router, with 4 wireless devices relaying the signal no less).

May I throw in a couple of thoughts regarding full-duplex?

1) When you plug in both ends of an Ethernet cord to a device, two things are negotiated; speed and duplex mode (and something called MTU, but that's another conversation). Speed is set at either 10mbs or 100mbs or 1000mbs (megabits per second), and duplex is set at half or full. By default most networking equipment for years has been set to auto negotiate these settings. The speed and duplex mode are negotiated based on the capabilities of all three devices; the two pieces of network gear being connected, and the cable itself. The least capable device sets the bar for the best possible speed. Most equipment that I've seen is capable of at least 100mbs / full-duplex (I am new to ooma, but assume the telos handle 100mbs and full-duplex based on what's being discussed in this thread).

2) Auto-negotiation does not always work! I have seen fully capable equipment not negotiate full-duplex, or negotiate full-duplex only some of the time. It is OK to force 100/mbs and/or full-duplex IF you are sure the devices and cable are up to it. Again, a cheapo Cat5 cable may be the weakest link. It's the first thing I would swap out of auto-negotiation was failing to establish full duplex.

3) As a general rule, auto negotiation occurs with each cable and the port it plugs on to on each end separately. Establishing full-duplex between your modem and router for example does not infer that the connection between the router and the telo is full-duplex. That's a separate negotiation. Therefore Thunderbird, I am puzzled at how forcing the network card in your computer to full-duplex does anything more than create a full-duplex connection to whatever your computer is plugged into. You mentioned it was plugged into the modem. Did you possibly mean router? Or telo? Either way, I think full-duplex is only assured between your computer and the device the Ethernet cord is plugged into. If you were plugged into the telo, then the full-duplex was only established between your computer and literally whatever port the plug was in on the telo. May I ask how you were able to ascertain that you were set to full-duplex between the modem and the telo, and between the telo and the router (or reversed, depending on how you are configured)? Just asking for my own edification. Can't argue with success if that worked for you. ;>

Regardless, I too think something is goofy with that phone number because results from a real conversation were totally out of sync with what the number played back to me. Full-duplex or no full-duplex.

regards,
jim

ps - I just went through the settings on my telo and did not locate a duplex setting for either of the Ethernet ports. Furthermore, the rather complete status screens did not report the connection speed that I could tell. Too bad

[thunderbird]

Ooma requires a Full-duplex internet signal. As you may know, Half-duplex operation when using Ooma sounds like delay. When talking, if both parties try to talk at the same time, the signal is "stepped on" and interrupted, resulting in breaks in the conversation.

I had been intermittently having Half-duplex conversations, Intermittent One Way Conversations where the other party could hear us, but we couldn't hear them; along with some Robotic voice heard on our end, but not on the other parties’ end. The other party could still hear us talking during these episodes.

Test:
My original test setup was a Modem, a computer with two wired LAN cards installed, an Ooma Telo, with no other equipment involved. I also have a second working Ooma Telo that I use for comparing and testing, but it wasn't used yet for this testing.

Network connections used only one hundred percent shielded CAT6 network cables.

The connections were Modem to one computer wired LAN card. The other computer wired LAN card to the Ooma Telo.

Internet Connection Sharing was setup between the Modem connected LAN card and the Ooma Telo connected computer wired LAN card.

Both computer wired LAN cards were set to 100 MZ Full-Duplex.

I immediately noticed improvement in the Ooma Telo voice Quality, in fact almost perfect, except for a very few DTMF tones heard on our end, when talking to just one loud talking party.


I wanted to test this setup over a period of days, but my wife also wanted to use her computer which was out of commission when using this test setup. So I connected the WAN input of our Router to the computer wired LAN card where the Ooma Telo was connected. I went back to using Wi-Fi to supply the Internet signal to the Ooma Telo. To my surprise, the Ooma Telo voice Quality remained almost perfect.

Eventually I went back to a Modem-Router-Ooma Wi-Fi connection, but left two computers on our LAN set to 100 MZ Full Duplex. I was a little surprised to find that even when the computers are turned off; it appears that they still drive the Internet signal to full duplex.

I am going to do more testing, but can't because I have other things to do right now.

As I said before, the procedure that I put out is not "Tried and True" but has promise.

Around two years ago there was a huge Ooma voice delay problem for many Ooma users, mostly caused on Ooma's side, but a small part was the Half-duplex problem. Since then I have been looking for a fairly simple way to test and correct this problem, without having an Ooma customer go to extra expenses.

Info only:
The two numbers that are used for delay testing are:
909-390-0003 is outside of Ooma and can be called by any phone (Ooma or not) to test round-trip delay.
925-259-0082 is inside of Ooma and tests round-trip delay without going out of Ooma over a carrier.
Ping www3.ooma.com to see your round-trip Internet delay to Ooma.

The test procedure is at: viewtopic.php?f=4&t=9569&start=30#p67874

It's reported that the pencil tap method on using Audacity is best.

[coastalcruiser]

Aha. So you have what they call a "multi-homed" computer rigged up. Cool. And rare. That explains how you could control the duplex mode. On the other hand, with your current rig, computer on or off, there may be another reason your quality has maintained in the modem > router > ooma config.

Thanx for all that other background info too. I ate it up.

jim

[Cyberchat]

Ooma requires a Full-duplex internet signal. As you may know, Half-duplex operation when using Ooma sounds like delay. When talking, if both parties try to talk at the same time, the signal is "stepped on" and interrupted, resulting in breaks in the conversation.

I had been intermittently having Half-duplex conversations, Intermittent One Way Conversations where the other party could hear us, but we couldn't hear them; along with some Robotic voice heard on our end, but not on the other parties’ end. The other party could still hear us talking during these episodes.

Thunderbird,

The recommended approach with modern LAN equipment is to have all LAN devices set for "autonegotiation". The only exception to this would be when a User Interface exists for both ends of a connection where you can force the same settings on both ends of the connection. If you change one end of a connection from "AutoNegotiation" to "Full Duplex" along with a selected speed setting, while the other end has no User Interface and it is set to "AutoNegotiation" because its built into the product, it is likely that you wil have forced a "Duplex Mismatch". When a "Duplex Mismatch" occurs the connection will most likely work but much more slowly than even a "Half-Duplex" because of induced collisions in the connection from the "Duplex Mismatch".

The best way to avoid duplex mismatches is to use autonegotiation and to replace any legacy equipment that does not use autonegotiation or does not autonegotiate correctly.

Here's an explanation of "Duplex Mismatch" from Wikipedia:

"Duplex mismatch
Main article: Duplex mismatch
A duplex mismatch occurs when two connected devices are configured in different duplex modes. This may happen for example if one is configured for autonegotiation while the other one has a fixed mode of operation that is full duplex (no autonegotiation). In such conditions, the autonegotiation device correctly detects the speed of operation, but is unable to correctly detect the duplex mode. As a result, it sets the correct speed but starts using the half duplex mode.
When a device is operating in full duplex while the other one operates in half duplex, the connection works at a very low speed if both devices attempt to send frames at the same time. This is because data can be sent in both directions at the same time in full duplex mode, but only in one direction at a time in half duplex mode. As a result, a full duplex device may transmit data while it is receiving. However, if the other device is working in half duplex, it does not expect to receive data (because it is currently sending); therefore, it senses a collision and attempts to resend the frame it was sending. Depending on timing the half duplex device may sense a late collision, which it will interpret as a hard error rather than a normal consequence of CSMA/CD and will not attempt to resend the frame. On the other hand, the full duplex device does not detect any collision and does not resend the frame, even if the other device has discarded it as corrupted by collision. Still, the full duplex device, not expecting incoming frames to be truncated by collision detection, will report frame check sequence errors. This combination of late collisions reported at the half-duplex end and FCS errors reported by the full duplex end can be used as an indication that a duplex mismatch is present.
This packet loss happens when both devices are transmitting at the same time. This may happen even when the link is used, from the user's perspective, in one direction only. A TCP stream requires all packets sent to be acknowledged by the receiving device. As a result, even if actual data is sent in one direction only, collision may be generated with acknowledgement packets traveling in the other direction."

[thunderbird]

Cyberchat:
Actually it was a your direction, suggesting that I go to the VOIP Mechanic site, that lead me to look at Half-duplex as my problem again.

I have a gigabyte LAN, with almost all new equipment on the network, except for one old Half-duplex network printer, that hasn't been connected to the network for many months.

Since I made the changes to 100 MZ Full-duplex, to the three wired LAN cards contained in two of our computers, the initial wired LAN card startup connection is slow, but after that, the Internet speed seems to be, and remains, very steady and fast.

Our Ooma phone service, this last past weekend, was so good that my wife spent hours on the phone talking to China. She ran out of the 500 International Bundle call minute plan for this month, but luckily the Prepaid Account auto kicked in.

I am planning on doing more testing later, especially trying to pull down my LAN to Half-duplex, using the old network half duplex printer, which was easily done so in the past, and then test to see if the previous Ooma Telo problems that we were having, come back. I have some other testing in mind also, but these tests take time and a little money.

But for right now, I'm going to leave the settings as they are and just see what happens over a period of time.

As always, I'm not going to hold my breath.

[Cyberchat]

Like you, I've found the VOIP Mechanic site has some really helpful information, especially when troubleshooting. I hope the thoughts I shared with you didn't aggravate your situation.

When the AutoNegotiate functionality first came out, decades ago, it was somewhat flakey, especially across vendors. It steadily improved, however, to the point for the past many years it has become pretty much the standard. Its required for gigabit speeds.

I remember when the Enterprise LAN communications for a server or workstation really slowed down (we usually detected it from the time it took to do the nightly backups) the first thing we changed was the Duplex and Speed LAN settings. Manually setting each end of the server's connection almost always fixed the problem.

Today, most of the LAN equipment (modems, routers, switches, ...) which we as consumers use don't have a User Interface to set the duplex and speed settings.

Its good to hear that your OOMA VOIP environment is working very well for you now. My wife was really skeptical about it when we switched to OOMA a couple of years ago and she had minimum tolerance for my brief periods of testing and cycling components as I was checking it out. Fortunately, I have an ISP with consistently good service and our OOMA environment has coorespondingly been consistently good. So, the OOMA VOIP quickly became transparent to us. Other than the unusual dial tone we hardly notice its there.

Good luck!

[Cyberchat]

Thunderfird,

One more thought! When a device is functioning under AutoNegotiation, any disruption event to a point-to-point connection can cause a new AutoNegotiation sequence between connected devices. Unplugging a cable, a power-off of one of the devices, ..., can trigger the AutoNegotiation.

I mention this because if in your testing there is a mismatch between the Duplex settings between two connected devices then each triggered AutoNegotiation has the potential to change things from their state prior to the new AutoNegotiation. If there is a mismatch between the two devices' duplex settings, however, the most likely outcome of the new AutoNegotiation will be the "Duplex Mismatch" problem described earlier in this thread.

If only one device on one end of a LAN connection has a User Interface for changing the Duplex and Speed settings, then the only good choice is to set to "AutoNegotiation".

An easy check to see the state of setting for AutoNegotiation for all of a PC's adapters is to use the "ipconfig /all" command at a Windows Command Prompt.

[thunderbird]

Cyberchat:
I did the ipconfig/all for both wired LAN cards. One card is almost new, the other is an older card.

The settings for both wired LAN cards are set to 100 MZ Full-duplex.

Both cards show the following:
Autoconfiguration Enabled.... : Yes

[Cyberchat]

Thunderbird,

I was mistaken. The IPCONFIG report on "AutoConfiguration" isn't the same as the "AutoNegotiation" setting related to the Duplex/Speed settings.

There is a free Network Testing tool I occasionally use which may be of some help to you. It attempts to check for "Duplex Mismatch" problems.

Go to: http://www.measurementlab.net/run-ndt

Scroll down to the "NDT (Network Diagnostic Tool)" and run the test.

The test results page has three tabs, Summary, Details and Advanced. If you click Details, along with a lot of other information it provides information as to whether Duplex Mismatch Conditions were detected.

..... No duplex mismatch condition was detected.
The test did not detect a cable fault. .....

I can't speak to this tools accuracy, overall. Obviously since it doesn't install any agents on your LAN its test results probably would be limited to the path between your PC and its servers. Just consider it as another datapoint.

There is another tool, a commercial tool - Speedupe, which is supposed to be releasing a trial version on Friday, May 11, 2012. The trial version is supposed to handle up to ten computers. I'll check it out when it becomes available. Its focused on automating the maintenance of an Enterprises' PC's adapters settings for Duplex and Speed. It lists the adapter settings but I don't believe it reports the actual results connection by connection.

In fact, as I've dug deeper into the search for a tool which will show "actual usage" of Half or Full Duplex within a LAN, there seems to be a void for PC oriented tools which do this. Most solutions I've found were related to Registry scripts which attempt to report Duplex/Speed settings (not an easy task because of the differences across vendors of how they organize their registry settings) but not actual usage on the LAN.

So, the NDT tool, above, at least provides some help toward the "Duplex Mismatch" problem.

[rojama]

Something else to try if you have time and feel like experimenting a little:
... helps or don't help.

Tried it after many complaints about the call quality from my cordless. The corded is better apparently.
But the point I was trying to make was you mentioned we should have all connected computers at that setting, problem is these days we have multiple gadgets apart from computers connecting, I have a TiVO, Mi casa verde, garage door stuff etc...how can we ensure all these comm. at 100MBps ?

Also, whenever I call these test #s, or test VOIP quality, quality is always good.