News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Obi110 Dropped calls on landline

Started by infin8loop, July 14, 2011, 07:35:37 PM

Previous topic - Next topic

infin8loop

I have the Obi110 connected to an AT&T landline "POTS" (not u-verse, dsl etc.) via the Obi "line jack" and a 5.8 ghz cordless phone base station connected to the Obi "phone jack".  Never had any issues with the cordless dropping calls when connected directly to the land line absent the Obi110.  Most recent dropped calls:

1. Inbound call to landline answered on cordless phone whose base station is connected to the Obi110 "phone jack" (see above) ie: PHONE1/LINE1 in the Obi110 log.  Call dropped at 2minutes 6seconds after "Call Connected" time in the log.

2. Outbound call via landline on same cordless phone to the same outbound number that was disconnected in #1.  This call was placed on the cordless by dialing a # to get the landline dial tone and then dialing the number. Have seen same result by dialing **8 in the past. The target number dialed is an AT&T landland regular old "POTS". This call was dropped 13minutes 46seconds after "Call Connected" time in the log.

As I typed this while sitting by the Obi110, it has rebooted for no apparent reason.  The wife is pissed because it's her calls being dropped.  So she is using her cell phone instead of the land line to continue the above call.  No calls in progress during this particular reboot.  I don't know if the Obi rebooted during the two dropped calls and caused the disconnects.  I just made a test call to time&temp on the cordless by dialing **8 to get landline and pulled the power cord out of the Obi110.  To my surprise the landline call did NOT drop. So I'm not sure that a spontaneous reboot would cause a lineline call to drop.   Again, all things being equal (I think), the cordless phone and base station never dropped calls before the Obi110 was introduced into the mix. 

SP1 is configured to use GoogleVoice (incidental information).  SP2 is not configured.   Don't see how this would have anything to do with LINE1/PHONE1 landline calls but I mention it just in case. These dropped calls were NOT placed or received through GoogleVoice.  I haven't personally experienced any issues with GoogleVoice but the wife would most likely disagree. My calls tend to be short, hers no so much.

Any ideas?
"This has not only been fun, it's been a major expense." - Gallagher

RonR

Do you have the latest firmware installed? : 1.2.1 (Build: 2384)

Quote from: infin8loop on July 14, 2011, 07:35:37 PM
As I typed this while sitting by the Obi110, it has rebooted for no apparent reason.

An OBi should not unexpectedly reboot.  If you see a pattern of this, you might consider resetting the OBi to factory defaults before restoring your configuration.  If the problem persists, you should contact Obihai for a replacement unit.

Quote from: infin8loop on July 14, 2011, 07:35:37 PM
I don't know if the Obi rebooted during the two dropped calls and caused the disconnects.

You can tell if the last reboot was unexpected.  Status -> System Status -> Uptime normally shows a reboot reason code in parenthesis : 3 Days 2:17:10 (4).  If the last reboot was unexpected, the reason code will usually be omitted.  Reason codes can be found in the OBi Device Administration Guide.

Quote from: infin8loop on July 14, 2011, 07:35:37 PM
I just made a test call to time&temp on the cordless by dialing **8 to get landline and pulled the power cord out of the Obi110.  To my surprise the landline call did NOT drop. So I'm not sure that a spontaneous reboot would cause a lineline call to drop. 

When the OBi loses power, a fail-safe relay disengages which connects the PHONE Port directly to the LINE Port.  The changeover is quick enough that  the call usually isn't dropped.  When the OBi reboots, however, it also disengages the relay for a short time, but then re-engages it shortly thereafter to an OBi with no call in progress, at which time your call will be dropped.

infin8loop

#2
@RonR

Thanks so much for your reply.  Yes, I should have mentioned I have the latest firmware installed 1.2.1 (Build: 2384).   Unfortunately I forced a reboot from the local webpage before I saw your reply so if there was a reason code there from the unexpected reboot, it's not there now. At least now I know what the number in parenthesis means after the uptime. Thanks.  Now it's a "9: Reboot from Webpage - No Change in Configuration" per page 37 of the Admin Guide. Cool.  Sheesh, I didn't even think to look at the uptime number to see if it had indeed rebooted around the time of the dropped calls. Also, thanks for explaining the relay between the Phone and Line ports. Probably explains the rather loud "clicking" sounds when it reboots (I hope that's normal!).

Now that I know what to look for, I will keep an eye on uptime and reason code.  I notice on local webpage under System Management/Device Admin that a Syslog server can be specified. I could try setting up a Syslog server on a machine running Ubuntu (I googled some instructions). Not exactly sure what I'm doing but that's never stopped me before! Do you know if the Syslog data would provide additional debugging information that might indicate why calls are being dropped?   I can understand why the Obi itself probably cannot store much of a log due to limited memory and the data needs to be sent somewhere. Thanks again for your reply!


"This has not only been fun, it's been a major expense." - Gallagher

RonR

It is the relay you hear clicking upon reboot/power cycling.

Setting up a Syslog server couldn't hurt.  The output is undocumented, but maybe you'll see something that offers a clue.

Best of luck with the detective work!

infin8loop


I have the Syslog up and running on an Ubuntu machine. Actually a windows machine running Ubuntu booted off a USB stick.  Wasn't difficult at all.  I see Debug (Level 7) messages coming into the Syslog from the Obi's local IP address.  I made outbound test calls on Google Voice (SP1) and Telco Line and watched the Syslog in real time.  Also made an inbound call from my other telco line to both the telco line connected to the OBI and Google Voice.  The data coming into the log seems to lag quite a bit behind what is actually happening on the Obi.  Now I have a baseline of log messages for future reference.  If anyone at Obi wants to share debug message documentation to aid my spelunking, please share away. I will sign an NDA if needed.  Dang, it's already 2:08 am.  I must be crazy.
"This has not only been fun, it's been a major expense." - Gallagher

LeftRight

#5
One case that I can think of might cause a call drop on LINE port is Long Silence Detection. If the person you talk to remains silence for over a minute (60 seconds by default), OBi will hang up the call. 60 seconds might appear long enough for normal calls, but not for conference type of conversation. The other part might mute the terminal during conference, and that could trigger long silence detection.

You can try to either turn off LINE port long silence detection, or give it a very large number on the time threshold --

Physical interface -> LINE port -> DetectFarEndLongSilence / SilenceTimeThreshold

QBZappy

I think this happened to me today. I was put on hold for what seemed to be a long time, and the call hung up on me. I got another dial tone. I had never considered this.
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

LeftRight

#7
Long silence is considered a very useful feature on calls through LINE port. In the case that other party hangs up the call, and OBi device uses long silence as an indication that the call was actually terminated, and goes on hook FXO port so that next caller can call in.

infin8loop


@LeftRight

Thanks for the heads up. I have changed Physical interface -> LINE port -> DetectFarEndLongSilence / SilenceTimeThreshold to 180.  I think it's plausible this is the issue because the wife said she was cut off in mid sentence during the last disconnect.  Perhaps she was talking more than a minute straight to her sister on the other end (I can imagine that, er I mean can't).  Reading the manual this setting monitors the "far end".  Maybe her sister couldn't get a word in edgewise.  Maybe I'll be in trouble if this message is linked back to me. I don't understand why it doesn't or cannot monitor both  sides of the conversation for silence. 
"This has not only been fun, it's been a major expense." - Gallagher

fix4all

Have been experiencing the same issue on landline calls (Verizon). Firmware 1.2.1 (Build: 2384). Will try increasing the Long Silence Detection.