Obi 200 spontaneous random disconnects

[Marty.ba.calif.usa]

I've had an Obi 200 for a few years, which has been working very well until somewhat recently. It's possibly related to the firmware update I did a bit over a year ago, but because i don't use it that much, I'm not really sure.  But I just updated to a newer firmware today, and will see if it helps.

I have Anveo for incoming calls, and voip.ms for outgoing, and both services experience a problem with random disconnects in the middle of a call after a few minutes (maybe 2 - 10 minutes, or so).  The log files look totally normal at the time of disconnect.  I've monitored the log while constantly refreshing during test calls.

I asked about it on the dslreports.com forum, and nobody could really help, and suggested contacting one of the providers to possibly help, which I have not done so far.

I've configured everything manually, and considered that perhaps during my learning curve (which I'm still on), things might not be optimal.  Since my needs are not very complex, I thought perhaps it would help if I were to reset the Obi, and use Obitalk to configure the services so I'd at least have some standard setup before going further, if necessary.

My question now is how to best do this. I see there is a "Reset Configuration" option in System Management, Device Update..  Does that reset it to initial default? Is this a good idea?

I don't think I mind using Obitalk, since I'm not really a power user for this device anyway - we mainly use our cell phones, and have unlimited calling, but I don't like to give that number out to businesses.  Plus, Anveo has such a good incoming call flow setup.

[SteveInWA]

Yes, there is a "Reset configuration" option on the device's local web page, under System Management --> Device Update.

You can also use a paper clip to depress the recessed reset switch on the bottom of the unit --look for the raised circular bump with the hole in it.

Log into the OBiTALK portal and if present, delete your device off of your account, then add it back, using the **5 procedure (click "Add device").

Both Anveo and voip.ms can be configured using the pre-defined (wizard-based) settings on the portal.  Note that there are two different places to configure Anveo.   One is for the Anveo / Obi plan (the large Anveo logo), and the other is accessible when you click the Anveo selection in the list of other SIP providers, along with voip.ms

[Marty.ba.calif.usa]

Yes, there is a "Reset configuration" option on the device's local web page, under System Management --> Device Update.

You can also use a paper clip to depress the recessed reset switch on the bottom of the unit --look for the raised circular bump with the hole in it.

Log into the OBiTALK portal and if present, delete your device off of your account, then add it back, using the **5 procedure (click "Add device").

Both Anveo and voip.ms can be configured using the pre-defined (wizard-based) settings on the portal.  Note that there are two different places to configure Anveo.   One is for the Anveo / Obi plan (the large Anveo logo), and the other is accessible when you click the Anveo selection in the list of other SIP providers, along with voip.ms

Thanks a lot.  I have a pretty good idea about how to set it up, as I originally did it that way with no problems, but I didn't think about deleting my device and then adding it back - it might have occurred to me along the way, but your advice is appreciated.

I didn't really know a bout the **5 procedure, so I'll check that out further.  I don't think I did that originally, but it's been a while, so maybe I did.

BTW, I checked it out after updating the firmware, and it disconnected after 3 1/2 minutes, so I guess it's not that simple.  I suppose it could be a bad device.  If push comes to shove, I guess I can try another from Amazon, and return it if it doesn't fix the problem.

[SteveInWA]

BTW, I checked it out after updating the firmware, and it disconnected after 3 1/2 minutes, so I guess it's not that simple.  I suppose it could be a bad device.  If push comes to shove, I guess I can try another from Amazon, and return it if it doesn't fix the problem.

I doubt that firmware is causing the problem, assuming that you are using the current version.  It could be your home network and internet service provider dropping the connection.  It's also possible that the AC adapter is going bad.  But, one step at a time...if it still behaves the same way after re-adding it via the portal, then you've eliminated any configuration issues.

[Marty.ba.calif.usa]

I doubt that firmware is causing the problem, assuming that you are using the current version.  It could be your home network and internet service provider dropping the connection.  It's also possible that the AC adapter is going bad.  But, one step at a time...if it still behaves the same way after re-adding it via the portal, then you've eliminated any configuration issues.

Makes sense. 

So I reset to factory defaults, removed from Obitalk, and deleted the providers, then set it up again using Obitalk. I did some test calls, and it still disconnects, once after 10 1/2 minutes, once after 4 1/2 minutes, and one after 30 seconds.

I'm connected via cable to my router, and I use the internet for TV and radio streaming a lot, normally with no problems.  The internet goes out now and then, but that's usually pretty drastic, and infrequent.  I don't get glitches for music or TV, and I have QOS set for priority to the Obi.  Not much else going on during the test anyway, though.

I think I'll swap the ethernet cable next, and perhaps check the voltage to the Obi with a meter to see if it's solid - or see if I have another power supply that will work.  Eventually, I'm afraid I'll need to try a new Obi.

One thing though... when I test, should I have some minimum level of sound going through the line?  Does the Obi have any detection for silence that might disconnect the line?

Thanks for your help so far.

[SteveInWA]

Well, I guess you can chalk up the delete/re-do exercise as a learning experience.   

My SWAGs still remain either a network issue or a hardware failure.  The OBi devices use a rather common adapter voltage and plug shape, so you might find one in your collection.  If you want to buy a replacement power adapter, jameco.com is a great place to find one, or you could just get one from Obihai.

Silence on the line shouldn't cause disconnects.  That said, VoIP does support a feature that detects silence, and, instead of wasting bandwidth sending background noise, it will suppress sending audio over RTP.  This function is disabled by default (meaning, silence is not detected and suppressed).

My bet is that your ISP connection is unreliable.  VoIP is much more sensitive to this than web browsing and video streaming, since streaming, for example, generally buffers data to mitigate dropouts.

[Marty.ba.calif.usa]

My bet is that your ISP connection is unreliable.  VoIP is much more sensitive to this than web browsing and video streaming, since streaming, for example, generally buffers data to mitigate dropouts.

That's interesting.  And probably hard to pin down. 

So, is there no buffering at all?  Oh, I guess it would be annoying to buffer a real-time conversation. :-(  My connection is fairly fast (55 mb/s), but I really don't know if there might be quality problems.  I can monitor the download speed while downloading a large file, although I haven't done that lately.  Used to be steady, but maybe something's changed.

I suppose I should eliminate as many variables as i can, though, before digging deeper into that hole. :-(

[SteveInWA]

RE:  buffering, your point about it being unacceptable to the callers is correct.  VoIP endpoints do have small (and adjustable) buffers, called jitter buffers, but they're only designed to mitigate very short signal dropouts.  Buffering any more than about a quarter-second becomes noticeable and disconcerting to the callers, since it creates a delay that that messes with the brain's ability to follow the conversation.

This is a tricky problem to isolate.  You can't tell anything by looking at download speed, since the speed measurements are averaged over time.  As for the power supply, you can't tell much with a voltmeter, other than it being completely dead or not.  You'd need to connect an oscilloscope to the power line to watch for distortion or brief dropouts in the voltage, and/or harmonics, caused by some component or electrical connection in the switching power supply starting to fail.

You've already eliminated the service provider (Anveo or voip.ms) as the cause (because it happens with both of them), and you've eliminated the configuration as the cause, because you re-did it.

You could now further isolate this with these two tests:

Use the SIP VoIP quality test at this website, which uses a Java applet to simulate an end-to-end VoIP "conversation", and measures multiple parameters to come up with a MOS (telco industry term for "Mean Opinion Score"). 

http://myspeed.visualware.com/index.php

Repeat the test multiple times, to a few different endpoints, and if you score less than 4.0, you have an internet service issue.  It's really common for cable internet to exhibit these issues, caused by some sort of corrosion or water incursion on the coax cables or connectors.  Occasionally, the cable modems go bad, too.

If you consistently score 4.0 or better (4.2 is the max), then, an easy way to isolate the OBi hardware as the culprit would be to unplug it, and install a SIP VoIP softphone on your computer.  Counterpath X-Lite is free and very easy to set up, but there are others out there.  If calls never disconnect while using the service via the softphone, then you've got a hardware issue (Ethernet cable, power supply and/or OBi box).

[Marty.ba.calif.usa]

...
This is a tricky problem to isolate.  You can't tell anything by looking at download speed, since the speed measurements are averaged over time.  As for the power supply, you can't tell much with a voltmeter, other than it being completely dead or not.  You'd need to connect an oscilloscope to the power line to watch for distortion or brief dropouts in the voltage, and/or harmonics, caused by some component or electrical connection in the switching power supply starting to fail....

Thanks for all the input.  I've run some tests, including a 24 hour smokePing test from http://www.dslreports.com/smokeping, which looked pretty good most of the time.  The one you recommended says I should be good, and the MOS was 4.19 the last time.  I ran it yesterday, and it was OK, but I forgot the exact score.

I tested using a softphone (SFLphone - I'm on Linux, and it was easy to install).  Using the softphone, I did not get a disconnect.  But I didn't disconnect the Obi, fwiw.  I also did a test where I did a continuous ping to the obi while making a test call and constantly refreshing the call status.  There was nothing unusual on the status page a second before it disconnected, and the ping never lost any packets at all.

I don't have a 'scope, but the DC voltage was steady.  I should measure the AC component, perhaps, but I don't really know if my meter would filter high frequency components or not.  I used to have a collection of 12 volt adapters, but I'm not sure where they are now.  So far, they are disappeared (a new verb).

I'm leaning toward just ordering a new ata from Amazon for $45, and if it doesn't fix the problem, I can always return it and only lose a few dollars shipping.

[Marty.ba.calif.usa]

Use the SIP VoIP quality test at this website, which uses a Java applet to simulate an end-to-end VoIP "conversation", and measures multiple parameters to come up with a MOS (telco industry term for "Mean Opinion Score"). 

http://myspeed.visualware.com/index.php

Repeat the test multiple times, to a few different endpoints, and if you score less than 4.0, you have an internet service issue.  It's really common for cable internet to exhibit these issues, caused by some sort of corrosion or water incursion on the coax cables or connectors.  Occasionally, the cable modems go bad, too.

If you consistently score 4.0 or better (4.2 is the max), then, an easy way to isolate the OBi hardware as the culprit would be to unplug it, and install a SIP VoIP softphone on your computer.  Counterpath X-Lite is free and very easy to set up, but there are others out there.  If calls never disconnect while using the service via the softphone, then you've got a hardware issue (Ethernet cable, power supply and/or OBi box).

Did you know that the MOS score is listed at the end of the call status during the call?  I just noticed that.

As an update to my problem, I ordered an OBI 202 on sale at Amazon, and it didn't help.  After replacing everything, including the network cable again, I also connected the phone directly to the ata output, all with no improvement.  So, I put the old OBI 200 back, as I like it better - it's simpler, and does everything I need.  I'll have to decide on whether to return it or just keep it in case me or someone else needs it in the future.

So, it occurred to me that it could very well be the phone itself, a Panasonic set I got at Costco a few years ago.  I tested with the base station, which has a dialpad, and it also disconnected, so I invested $10 on a little wired AT&T phone at Fry's today.  My test call has been going for 45 minutes so far, breaking all recent records for anything going through the ata.  I've never had a phone actually go bad, I don't think.  Usually, they just outlive their usefullness in some way or another.  This one never had any noise or anything to indicate it was going bad.  Guess it could be the power supply.

My call status window had two new buttons appear on one refresh - "Remove" and "Record".  I'm pretty sure they weren't there when I started.  Anyone else ever see them? 

[SteveInWA]

RE:  phone causing the problem - well, that's amusing.  Perhaps it's something as simple as the phone's rechargeable battery going bad, causing momentary voltage drops?  If it's a Panasonic DECT 6.0 model, it probably has two AAA NiMH batteries that can easily be replaced to test that theory.  If it's older (5.8GHz or, gawd forbid, 2.4GHz), it's time to get a new phone.  DECT is far less prone to interference from other wireless signals, since nothing else uses its band.

There have also been reports of people placing the cordless base station right on top of, or right next to the OBi, and somehow causing problems from the radiated RFI.  So, if that's your situation, try moving the base station away.  Otherwise, yah, perhaps the phone is dying.

RE:  the "Remove" and "Record" buttons, they only appear when you are on a call.  See P. 59 of the Admin guide.

http://www.obihai.com/docs/OBiDeviceAdminGuide.pdf

RE:  MOS:  yes, it does appear during a call, but I have no idea how it's being calculated.  I suppose it's useful to view during a call, if you experience poor call quality.  The nice thing about the Visualware test, is that it eliminates your local hardware from the loop, so it gives you a measurement of how your internet service and the path to the far end are or are not impacting call quality.

[Marty.ba.calif.usa]

RE:  phone causing the problem - well, that's amusing.  Perhaps it's something as simple as the phone's rechargeable battery going bad, causing momentary voltage drops?  If it's a Panasonic DECT 6.0 model, it probably has two AAA NiMH batteries that can easily be replaced to test that theory.  If it's older (5.8GHz or, gawd forbid, 2.4GHz), it's time to get a new phone.  DECT is far less prone to interference from other wireless signals, since nothing else uses its band.

The one I have is DECT 6, and uses AAA batteries.  I use NIMH batteries a lot, so I have extra known good ones.  In fact, I never used the original Panasonic ones, and used higher capacity instead.  But my system also has a dialpad on the base station, so I had tested using that.  I don't think the handset batteries would affect it in any way if they were bad, although they still have a long talk time.

However, I was checking out the power supply, and disconnected it from the jack, then reconnected.  Now, I'm testing (using a handset even), and the last test went for an hour using Google voice.  Now, I'm trying again, but using VOIP.ms, to see if there is any difference.  I actually only recently added Google voice, and hadn't tested with it. So, it's possible it may be related to the power supply for the phone.  If so, I just wasted a bunch of time checking out new phones.

[SteveInWA]

Humph.  You're right about the base station ruling out the handset as the cause, but if you haven't already done so, I'd recommend keeping the base station a few feet away from the OBi to reduce the possibility of RFI.  Perhaps it's something as lame as the base station's power supply and its connector.  In the immortal words of Roseanne Roseanadana, "If it isn't one thing, it's another!"  Good luck.

[Marty.ba.calif.usa]

Humph.  You're right about the base station ruling out the handset as the cause, but if you haven't already done so, I'd recommend keeping the base station a few feet away from the OBi to reduce the possibility of RFI.  Perhaps it's something as lame as the base station's power supply and its connector.  In the immortal words of Roseanne Roseanadana, "If it isn't one thing, it's another!"  Good luck.

Sorry for by bad quoting in my previous post - I was in a rush and didn't take time to check it.  Fixed now.

The Obi is not near the phone.  I think you're right about the power supply connector - it has been working well for several tests since messing with it.  And I also noticed that the extensions have the same power supply, so I can switch if I find that it's intermittently bad, and as long as the station works well enough to charge the battery, it'll be fine.

I feel pretty good about the way it turned out, although I do feel a bit lacking in not thinking about the phone earlier.  I was fooled by the complete lack of symptons like noise, etc.

Thanks for your help in this.  I gained a lot of knowledge just from this ordeal.

[SteveInWA]

Yah, it was an "adventure", but a good learning experience, as you said.  Thanks a lot for circling back with the (presumed) solution, as it helps others to remember it's not always rocket science.