SOLVED Lenny talks, but he won't hang up.

[visionlogic]

I've installed Lenny Encore and the Lenny Blacklist Mod on my IncrediPi and overall Lenny does his thing without a hiccup. However (you knew that was coming) I have one problem.

First, I've got 4 trunks composed of 2 GV trunks, a VOIP.ms trunk, and a HACKEDTOGETHER trunk.

The HACKEDTOGETHER trunk is composed of a AT&T ZTE WF720 GSM cellular to home phone adapter, with one of its PHONE RJ11 jacks feeding the RJ11 LINE jack of an Obi110, and the Obi110 being a SIP trunk connection to my IncrediPi.

A blacklisted number coming in on the GV trunks or the VOIP.ms trunk can hangup while Lenny is talking and shortly thereafter FreePBX System Status will show that active call dropped. However (there it is again), if a blacklisted call comes in on the HACKEDTOGETHER trunk and the caller hangs up while Lenny is talking the active call will continue to show active for about 10 minutes before it disappears from FreePBX System Status.

In the Obi110 settings I've changed the default setting of Physical Interfaces -> Line Port -> PSTN Disconnect Detection -> SilenceTimeThreshold to 60 seconds, from its default 600 seconds. But this doesn't seem to have any effect.

Any clues or tips anyone may offer will be much appreciated.

Thanks!

 

[wardmundy]

The problem probably is some obscure setting in the GSM adapter which isn't recognizing the disconnect. I see it on the GoIP device although it typically is a 10-15 second delay, not 10 minutes.

 

[visionlogic]

Hmmm... I'll try to get some time to scrounge the net for some further clues an that adapter. In the meantime I dropped into the CLI while the event was in progress and the CLI was just scrolling as fast as it could with this type of output:

Connected to Asterisk 11.3.0-rc1 currently running on incrediblepbx (pid = 2820)
 
      > Got 0ms silence < 700ms required
      > Got 0ms silence < 700ms required
      > Got 20ms silence < 700ms required
      > Got 40ms silence < 700ms required
      > Got 60ms silence < 700ms required
      > Got 80ms silence < 700ms required
      > Got 100ms silence < 700ms required
      > Got 120ms silence < 700ms required
      > Got 140ms silence < 700ms required
      > Got 160ms silence < 700ms required
      > Got 180ms silence < 700ms required

 

[visionlogic]

Something in your setup is messing up the silence intervals so the silence detect won't work. The pattern is interesting, each period of silence is exactly 20ms longer than the previous one, which makes me wonder if it is perhaps being generated as comfort noise or for some other reason. I can't really help beyond that.

Thanks for your input.

The 20ms silence intervals were rolling through the CLI after the caller (me) had already hung up the phone. The intervals indeed would increment by 20ms and increase to 700ms and then immediately start over. While on the phone and speaking to Lenny the silence was apparently being recognized. Lenny was appropriately responding to my speech and would move on to his next statement after I would speak and go silent. If I remained silent after Lenny made a statement he would repeat his statement.

After hanging up I can physically disconnect the line between the WF720 and the Obi110 and the Obi, of course, recognizes the disconnect. So either 1.) the ZTE WF720 is not sending an On-Hook disconnect voltage/tone/CPC change to the Obi110 Line port when I hang up, or 2) a disconnect is being sent but the Obi110 Line port is not recognizing it.

So I'll continue to dig.

Thanks

 

[MGD4me]

I don't own an Obi, but have a Linksys/Sipura ATA, so this may or may not apply.

Some Telcos reverse the 'Talk Battery" polarity, depending on whether the line is idle, or not. In real life, the line never goes "open", electrically speaking. In the Linksys, there is a provision to detect normal or reverse voltage polarity, to signal that the call has ended. Have a look to see if there is an equivalent detection scheme in the Obi. I'd be curious to know as well, for future personal needs.

 

[visionlogic]

I don't own an Obi, but have a Linksys/Sipura ATA, so this may or may not apply.

Some Telcos reverse the 'Talk Battery" polarity, depending on whether the line is idle, or not. In real life, the line never goes "open", electrically speaking. In the Linksys, there is a provision to detect normal or reverse voltage polarity, to signal that the call has ended. Have a look to see if there is an equivalent detection scheme in the Obi. I'd be curious to know as well, for future personal needs.

Thanks for that info. I'll dig through the Obi's LINE settings this evening... seems like I recall seeing something dealing with reverse polarity. Whatever voltage is being sent is being supplied by the ZTE WF720 to the Obi110, and the WF720 has no settings that are accessible as far as I can tell.

I also dropped into the CLI again and observed what was happening after I disconnected a call that had passed from the WF720 to the Obi110 and on to the IncrediPi. I did not pipe the output to a txt file so I can't quote it exactly, but it was showing something like "speaking" (I believe that was the term) was still coming in to Lenny and Lenny was still responding. I'm thinking that the WF720 is producing some kind of noise that's being sent on after disconnecting and that noise is being interpreted by the Lenny routine as speaking. If I make a call from my blacklisted number to one of my GV or VOIP.ms numbers Lenny ceases and a proper hangup occurs when I disconnect my call.

 

[wardmundy]

Whether Lenny is speaking or not, Asterisk will honor a legitimate hangup event. So the polarity issue is certainly worth tracking down. Keep us posted.

 

[visionlogic]

Whether Lenny is speaking or not, Asterisk will honor a legitimate hangup event. So the polarity issue is certainly worth tracking down. Keep us posted.

Thanks. I will post back my findings/testing. At this point a legitimate hangup event is certainly not traversing the entire WF720->Obi110->IncrediPi chain.

 

[visionlogic]

Here is a pic of a portion of the Obi LINE port setup screen showing the PSTN Disconnect Detection settings. If anyone has suggestions as to what possibly to modify please chime in:

 

[TwigsUSAN]

DetectPolarityReversal looks to be set by default. Try unchecking it and see what happens.

 

[visionlogic]

DetectPolarityReversal looks to be set by default. Try unchecking it and see what happens.

Thanks for the tip. But, alas, it doesn't change the behavior. There is no hangup. Lenny continues on his merry way until the 600 second (10 min) built in limit is reached unless I physically unplug the RJ11. I've also tried changing various other parameters, still without a "fix".

For some testing, I did the following:

1. Send the incoming WF720 call to an extension instead of Lenny.
2. Answer the extension. Good two-way sound between extension and incoming caller.
3. Incoming caller hangs up.
4. Asterisk CLI shows no hangup event. There is silence on the extension.
5. After about 15 seconds the extension hears a continuing "beep-beep-beep..." (fast busy signal?). Still no activity in asterisk CLI.
6. Disconnect RJ11 from WF720 to Obi110. Beeping at extensions ceases. Asterisk CLI shows hangup event.

Conclusion? Apparently the WF720 does not send a disconnect/hangup event. It only produces the continuous "beep-beep-beep...".

The Obi110 Line Port has a "DisconnectTonePattern" setting. Could this be used to detect the beeping sent by the WF720? I don't know. But without knowing what the settings should be for the particular "pattern" I'm hearing from the WF720 I have no idea of what to set it to in order to try it out.

 

[visionlogic]

SOLVED!

Everyone is probably tired of my babbling in this thread, so this should wrap it up.

Indeed, it was "DisconnectTonePattern" setting in the Obi110 that made the difference.

I went on a search and after looking and looking I found a thread over at Voiceguide.com ( http://voiceguide.com/forums/index.php?showtopic=599 ) regarding "End Of Call Detection (Dialogic D/4PCI)". Within the thread there was mentioned using Audacity ( http://audacity.sourceforge.net/ ) to analyze the frequencies and cadence of a disconnect tone. So I decided to try it, even though I didn't fully understand it. I set my Incredible Pi to record on demand on the extension I chose, made an incoming call, hung up, initiated the on-demand recording and waited and recorded the disconnect tone. Then downloaded the wav file to my laptop with Audacity installed. Opened the file in Audacity and went to Analyze -> Plot Spectrum. Got back a peak frequency of 426 hz. Then scratched my bald head for a while, and just gave a shot at changing the "DisconnectTonePattern" in the Obi from the default this -> 480-30,620-30;10;(.25+.25) to this -> 425-30;30;(.25+.25) BAM! IT WORKS! Still takes about 15 seconds to hangup, of course. But it beats the hell outta 10 minutes. So, if there's another 62 year old out there like me who's still silly enough to think they'd like to experiment with odds-and-end equipment they come across and they get their hands on a WF720, there's your solution to getting an Obi110 to recognize its hangup.