Outgoing calls through LINE port are dropping

[ChrisThompson]

When I make calls by pressing "#" to get directly to the line port, I'm still getting dropped calls.  Just a moment ago it happened twice in a row, one call dropped after 1 minute and another after 2 minutes.  It makes the familiar clicking sound and drops to a dialtone.

I have the suggest ports forwarded in my router to the IP address of my Obi110. That hasn't seemed to affect the dropped calls, and I'm not sure how that would affect calls on the LINE port.

Here's the log of my last call that dropped:

Code Select Expand

Aug 18 08:56:01  [SLIC]: Slic#0 OFF HOOK
Aug 18 08:56:01  [SLIC] CID to deliver: '(null)' (null)
Aug 18 08:56:01  [CPT] --- FXS h/w tone generator (dial)---
Aug 18 08:56:08  [DSP]: ---- H/W DTMF ON (level:1) : # @ 19656540 ms----
Aug 18 08:56:08  [DSP]: ---- H/W DTMF OFF @ 19656690 ms ----
Aug 18 08:56:10  [DAA]: FXO OFFHOOK
Aug 18 08:56:10  [DAA]: detecting disconnect tone, reinit: 1
Aug 18 08:56:10  FXO: OutboundRinging
Aug 18 08:56:10  [CPT] --- FXS h/w tone generator (ringback)---
Aug 18 08:56:10  FXO: OutboundConnected
Aug 18 08:56:11  PARAM Cache Write Back(256 bytes)
Aug 18 08:56:11  [DSP]: ---- H/W DTMF ON (level:3) : 8 @ 19659980 ms----
Aug 18 08:56:11  [DSP]: ---- H/W DTMF OFF @ 19660110 ms ----
Aug 18 08:56:12  [DSP]: ---- H/W DTMF ON (level:3) : 0 @ 19660391 ms----
Aug 18 08:56:12  [DSP]  ---- S/W DTMF ON (level: 3) : 0, @ 19660441 ----
Aug 18 08:56:12  [DSP]  ---- S/W DTMF OFF @ 19660511 ms----
Aug 18 08:56:12  [DSP]: ---- H/W DTMF OFF @ 19660521 ms ----
Aug 18 08:56:12  [DSP]: ---- H/W DTMF ON (level:3) : 0 @ 19660661 ms----
Aug 18 08:56:12  [DSP]: ---- H/W DTMF OFF @ 19660811 ms ----
Aug 18 08:56:12  [DSP]: ---- H/W DTMF ON (level:3) : 5 @ 19661021 ms----
Aug 18 08:56:12  [DSP]: ---- H/W DTMF OFF @ 19661151 ms ----
Aug 18 08:56:13  [DSP]: ---- H/W DTMF ON (level:3) : 0 @ 19661341 ms----
Aug 18 08:56:13  [DSP]: ---- H/W DTMF OFF @ 19661471 ms ----
Aug 18 08:56:13  [DSP]: ---- H/W DTMF ON (level:3) : 1 @ 19661761 ms----
Aug 18 08:56:13  [DSP]: ---- H/W DTMF OFF @ 19661891 ms ----
Aug 18 08:56:13  [DSP]: ---- H/W DTMF ON (level:3) : 8 @ 19662091 ms----
Aug 18 08:56:13  [DSP]: ---- H/W DTMF OFF @ 19662221 ms ----
Aug 18 08:56:14  [DSP]: ---- H/W DTMF ON (level:3) : 9 @ 19662451 ms----
Aug 18 08:56:14  [DSP]: ---- H/W DTMF OFF @ 19662581 ms ----
Aug 18 08:56:14  [DSP]: ---- H/W DTMF ON (level:3) : 7 @ 19662801 ms----
Aug 18 08:56:14  [DSP]: ---- H/W DTMF OFF @ 19662931 ms ----
Aug 18 08:56:14  [DSP]: ---- H/W DTMF ON (level:3) : 9 @ 19663241 ms----
Aug 18 08:56:15  [DSP]: ---- H/W DTMF OFF @ 19663371 ms ----
Aug 18 08:56:20  [DSP]: ---- H/W DTMF ON (level:3) : 9 @ 19668470 ms----
Aug 18 08:56:20  [DSP]: ---- H/W DTMF OFF @ 19668600 ms ----
Aug 18 08:56:20  [DSP]: ---- H/W DTMF ON (level:3) : 3 @ 19669030 ms----
Aug 18 08:56:20  [DSP]: ---- H/W DTMF OFF @ 19669161 ms ----
Aug 18 08:56:21  [DSP]: ---- H/W DTMF ON (level:3) : 5 @ 19669661 ms----
Aug 18 08:56:21  [DSP]: ---- H/W DTMF OFF @ 19669791 ms ----
Aug 18 08:56:22  [DSP]: ---- H/W DTMF ON (level:3) : 2 @ 19670471 ms----
Aug 18 08:56:22  [DSP]: ---- H/W DTMF OFF @ 19670601 ms ----
Aug 18 08:56:22  [DSP]: ---- H/W DTMF ON (level:3) : 7 @ 19670881 ms----
Aug 18 08:56:22  [DSP]: ---- H/W DTMF OFF @ 19671011 ms ----
Aug 18 08:56:23  [DSP]: ---- H/W DTMF ON (level:3) : 8 @ 19671321 ms----
Aug 18 08:56:23  [DSP]: ---- H/W DTMF OFF @ 19671451 ms ----
Aug 18 08:56:23  [DSP]: ---- H/W DTMF ON (level:3) : 1 @ 19671881 ms----
Aug 18 08:56:23  [DSP]: ---- H/W DTMF OFF @ 19672011 ms ----
Aug 18 08:56:24  [DSP]: ---- H/W DTMF ON (level:3) : # @ 19672371 ms----
Aug 18 08:56:24  [DSP]: ---- H/W DTMF OFF @ 19672501 ms ----
Aug 18 08:57:56  [DAA]: FXO ONHOOK MONITOR
Aug 18 08:57:56  [DAA]: FXO ONHOOK MONITOR
Aug 18 08:58:00  [SLIC]: Slic#0 HOOK FLASH
Aug 18 08:58:00  [SLIC] CID to deliver: '(null)' (null)
Aug 18 08:58:00  [CPT] --- FXS h/w tone generator (dial)---
Aug 18 08:58:13  [SLIC]: Slic#0 ONHOOK
Aug 18 08:58:13  [SLIC] CID to deliver: '(null)' (null)
Aug 18 08:58:18  [SLIC]: Slic#0 OFF HOOK
Aug 18 08:58:18  [SLIC] CID to deliver: '(null)' (null)
Aug 18 08:58:18  [CPT] --- FXS h/w tone generator (dial)---
Aug 18 08:58:20  [SLIC]: Slic#0 ONHOOK
Aug 18 08:58:20  [SLIC] CID to deliver: '(null)' (null)


[RonR]

Chris,

Try a different telephone (as well as its connecting cable) on the OBi's PHONE Port.  It appears the OBi is detecting a Hook Flash and OnHook condition from your telephone.

When you press # to get a direct connection to the LINE Port, the OBi isn't using your Internet connection.

[M105]

I recently diagnosed a dropped call problem with a friend's Obi110.  This has probably been discussed here before somewhere but I will mention it again.

He was running a 2.4 GHz cordless telephone and a 2.4 GHz wireless router.  The telephone base was hooked to the Obi and sitting right beside the router.  It was causing the phone to randomly go on-hook and drop the call with times from 1 to 20 minutes.  We moved the phone base away from the router as a temporary fix and it cleared up the dropped call problem and fuzzy audio... I sent him shopping for a 5.8 GHz phone.

Moral of the story:  Don't run your cordless phone and router on the same frequency band!  If you are determined to ignore this rule, put the phone base as far away from the router as possible and choose a wifi channel on the router that reduces the problem.  You will likely lose performance on the wifi as well as the phone even if they don't totally zap each other.

[RonR]

And test using a corded telephone with the cordless phone unplugged from the power outlet off before deciding it's the OBi that's dropping the calls.

[infin8loop]

Chris,

If the other suggestions don't work out for you then you might try increasing the Physical interface -> LINE port -> DetectFarEndLongSilence / SilenceTimeThreshold value from the default 60 seconds.
See thread http://www.obitalk.com/forum/index.php?topic=1164.msg7364#msg7364 where it was suggested to me.
If it's dropping while you're talking and the other party hasn't said much then this might be the problem since this parameter monitors the other side of the line for silence.  In my case the wife was most likely going on, and on, talking to her sister.  Since I increased the value to 180 seconds I don't think we've had the dropped calls. I figure if she doesn't stop and take a breath in 3 minutes then she'll pass out anyway and it won't matter.  But then again I think she just got pissed off at the whole idea of Obi and google voice and started using her cell phone more.  Marriage or damned if you do and damned if you don't.

To clarify, we have an AT&T regular old phone line connected to the LINE port of the Obi110 and a 5.8Ghz cordless base station connected to the PHONE port.  GV is on SP1.    Any calls placed on the cordless go out by default on GV.  Most everyone but my daughter calls us on the AT&T old phone line.  It was those AT&T old phone line calls that were being dropped (some of my wife's calls, I never experienced the issue myself).  Anyway, I still have the AT&T old phone line because of the spousal reluctance to get rid of the regular phone line and embrace GV or another voip carrier (I was thinking about getting voip.ms in addition to gv).  I planned on porting the old AT&T phone line to voip.ms and getting rid of the AT&T line and the $40+ monthly bill (and that's with no long distance calls).  I have another AT&T line for my home office to plug into the LINE port giving us a back up.  Everytime something goes wrong with a call the wife immediately says "it's that damned google voice"  even though in most instances it's not. Me trying to explain to her the Obi and gv and voip is like someone familiar with brain surgery trying to explain that to me.  All I get is a blank look followed by get rid of it.  Perhaps I just need to get rid of her.  (grin)

And I forgot one of the best parts. One night the wife made two calls to her sister.  The calls went out on GV.  GV delivers the number but apparently her sister's phone shows it as "OUT OF AREA" because GV doesn't deliver a CNAME.  Anyway her sister was in a bad mood and thought the calls were a telemarketer and just hung up immediately after picking up the phone. So the wife had to use her cell phone to call her sister. Yes, yes, I've told her about **8 or # to use the AT&T phone line but again, I get that deer in the headlights look.  So basically for $49.99 the Obi110 is not much more than a toy for me to play with.  Ohmygawd, I have to remember to press an extra digit, *abend*, *reboot*.  I'm lovin it!        

[ChrisThompson]

Try a different telephone (as well as its connecting cable) on the OBi's PHONE Port.  It appears the OBi is detecting a Hook Flash and OnHook condition from your telephone.

When you press # to get a direct connection to the LINE Port, the OBi isn't using your Internet connection.

Sorry, I meant the calls were dropping when using the LINE port; I mixed up PHONE and LINE.  The call dropping sounds like a dead silence for about two-three seconds, then a low frequency "CLICK" or "CLUNK" then a dial-tone.

I understand it's not using the internet, so that leads me to believe it's something weird going on in the OBI. When I connect my cordless phone directly to the LINE, I never have a problem.

I noticed the FLASH thing there to, and I have no clue why that would show up. My phone is a DECT 6.0. I have a wireless router running at 2.4ghz and 5ghz (dual band). My OBI is in the basement, two floors away from my phone, and one floor away from the base station.  Again, I've never had any issues with calls in the same setup but with the phone base plugged directly in to the LINE without the OBI.

[ChrisThompson]

If the other suggestions don't work out for you then you might try increasing the Physical interface -> LINE port -> DetectFarEndLongSilence / SilenceTimeThreshold value from the default 60 seconds.
See thread http://www.obitalk.com/forum/index.php?topic=1164.msg7364#msg7364 where it was suggested to me.

I'll give that a shot. The dropped calls do happen most of the time during conference calls. Is the silence detection just for the MIC (i.e., my voice) or does it also listen to the incoming audio, because I get drops when other people are talking but I may not be talking. I'm often on MUTE during conference calls for long periods of time, certainly more than a minute.

[RonR]

Try a different telephone (as well as its connecting cable) on the OBi's PHONE Port.  It appears the OBi is detecting a Hook Flash and OnHook condition from your telephone.

Sorry, I meant the calls were dropping when using the LINE port; I mixed up PHONE and LINE.  The call dropping sounds like a dead silence for about two-three seconds, then a low frequency "CLICK" or "CLUNK" then a dial-tone.

I understood how you're calling and I still think you should plug in a simple corded telephone and disconnect and remove power from the cordless phone to see if the problem goes away.

[infin8loop]

The dropped calls do happen most of the time during conference calls. Is the silence detection just for the MIC (i.e., my voice) or does it also listen to the incoming audio, because I get drops when other people are talking but I may not be talking. I'm often on MUTE during conference calls for long periods of time, certainly more than a minute.

My understanding is the silence detection is for the other side of the conversation (what you are hearing), not your voice.
I wonder if maybe the volume coming in from the other side of your conference calls is too low to consistently exceed the threshold that is considered "not silence".  If that doesn't make your head hurt, as it does mine, then maybe it's just me.

To adjust the silence detection:
Physical interface -> LINE port -> PSTN Disconnect Detection ->
1. DetectFarEndLongSilence  (checked = on, unchecked = off, default = on)
if the above is "on" then:
1.a SilenceDetectSensitivity (low, medium or high, default = medium)
1.b SilenceTimeThreshold (a value in seconds, default = 60)

So, what does all this mean?  Here's my guess.  Either turn DetectFarEndLongSilence off, or leave it on and adjust one or both of the other two.  The manual indicates SilenceDetectSensitivity "Low" means harder to detect silence and "High" means easier to detect silence.  I'm not positive if you'd want "High" or "Low" because the voices in my head are arguing with each other as to what this really means. I've fall'in into an infiniteloop and can't get up (notice I did not include the word it). It's like chosing between the blue pill and the red pill (the obvious blue pill jokes aside). I'd pick blue, er, I mean I'd pick SilenceDetectSensitivity "Low" harder to detect silence (chuckle, "harder").  Geez, it's after 11 am and I've not had any coffee.  So your actual mileage may vary.  I love when people say that (YAMMV) when they aren't really sure what they're talking about.  It's like "Well, it worked for me. I don't know what your problem is."