[Home]

Summary:ASTERISK-19316: Asterisk cannot detect canceled calls on analog lines
Reporter:Jeremy Pepper (jpepper)Labels:
Date Opened:2012-02-08 16:39:20.000-0600Date Closed:2012-03-05 20:01:19.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:If a call comes in on an analog line, but the caller hangs up, and then Asterisk answers the line, Asterisk believes there's a call on the line until a busy signal is generated.
Comments:By: David Woolley (davidw) 2012-02-09 05:03:16.446-0600

I presume you are asking for it to time out the lack of ringing current (I haven't checked whether or not it tries to do this).  However how an incoming call is indicated will depend on the type of analogue line, but you haven't said what type you have, or what your dahdi configuration for the line is.
By: Matt Jordan (mjordan) 2012-02-09 17:47:21.428-0600

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information


By: Jeremy Pepper (jpepper) 2012-02-13 12:37:06.754-0600

My test environment is two Asterisk boxes with an analog phone line connecting them. One box simulates an upstream carrier. Here's the relevant DAHDI configuration:

# Span 1: WCTDM/4 "Wildcard TDM400P REV E/F Board 5" (MASTER)
fxsks=1
echocanceller=mg2,1
fxoks=2
echocanceller=mg2,2
# channel 3, WCTDM/4/2, no module.
# channel 4, WCTDM/4/3, no module.

# Global data

loadzone = us
defaultzone = us

Port 2 is linked to port 1 on the test box, which is configured like this:


# Span 1: WCTDM/0 "Wildcard AEX800" (MASTER)
fxsks=1
echocanceller=mg2,1
fxsks=2
echocanceller=mg2,2
fxsks=3
echocanceller=mg2,3
fxsks=4
echocanceller=mg2,4
fxoks=5
echocanceller=mg2,5
# channel 6, WCTDM/0/5, no module.
# channel 7, WCTDM/0/6, no module.
# channel 8, WCTDM/0/7, no module.

# Global data

loadzone = us
defaultzone = us

Both systems were configured by dahdi_genconf.
By: Jeremy Pepper (jpepper) 2012-02-13 13:44:11.983-0600

I've actually built a patch that hangs up DAHDI channels when an inbound call picks up only to see dialtone on the line. That patch is on reviewboard here: https://reviewboard.asterisk.org/r/1737/

Of course, I'm definitely willing to gather more debug information if you still need it.
By: Matt Jordan (mjordan) 2012-02-16 16:19:38.338-0600

Looks like you've already gotten it through the review process - so nope, nothing more needed.  Do you need someone to commit it?
By: Jeremy Pepper (jpepper) 2012-02-16 16:23:11.285-0600

Yes, please.
By: Alec Davis (alecdavis) 2012-02-18 02:11:28.933-0600

Jeremy, https://reviewboard.asterisk.org/r/1747/ has now been commited, you should be able to use p->outgoing now instead of ast_test_flag(ast, AST_FLAG_OUTGOING).

By: Jeremy Pepper (jpepper) 2012-02-18 19:48:10.759-0600

Thanks!

As soon as I'm back near my test hardware (Monday morning, most likely), I'll retest with p->outgoing.
By: Jeremy Pepper (jpepper) 2012-02-22 16:01:19.844-0600

After updating to the latest revision for svn, something's broken. Inbound calls to my test box show a hangup before the call's answered, even though the call's still ringing in. I'm still investigating.
By: Jeremy Pepper (jpepper) 2012-02-22 18:13:39.010-0600

r356042 appears to have introduced a regression that prevents me from testing Alec's proposed change. Please see ASTERISK-19424 for more info.
By: Alec Davis (alecdavis) 2012-02-22 20:27:49.640-0600

jeremy
On a TDM400P I've seen similar, in a voicemail only application, where the dialplan waits a predetermined time 'wait(10)' before answering the call.
It was the hanguponpolarityswitch=yes in chan_dahdi.conf

However, with limited testing, I was unable to create the same at a different site with a TDM800P.
The TDM800P had hanguponpolarityswitch=yes, and the dialplan stayed in the wait(10) before moving on the answer the call.

By: Richard Mudgett (rmudgett) 2012-02-28 19:46:56.402-0600

Is using p->outgoing working now?  I'd like to commit this patch soon.
By: Alec Davis (alecdavis) 2012-03-04 18:09:01.446-0600

I'm seeing the same as Jeremy reported on the 22 Feb.
Incoming calls repeatedly hangup immediately after app-echo, meanwhile the caller still hears ringing.
{code}
[pstn]
exten => s,1,NoOp()
exten => s,n,Wait(5)
exten => s,n,Answer()
;exten => s,n,Playback(silence/1)
exten => s,n,Echo()
{code}

If I enable the line to send some audio, the call is connected.


By: Richard Mudgett (rmudgett) 2012-03-05 10:19:32.142-0600

Alec
Is this happening with the ASTERISK-19424 patch provided by Michael Young that I committed?
By: Jeremy Pepper (jpepper) 2012-03-05 13:58:52.822-0600

The latest Asterisk from subversion is working for me now, as is using the 'outgoing' flag. I've updated the patch at https://reviewboard.asterisk.org/r/1737/.
By: Alec Davis (alecdavis) 2012-03-05 15:03:12.061-0600

Richard
I should have documented that this is ringing into a TDM400P FXO port on a test box, with r354459 with no patches applied (jeremy's version) it repeatedly hangs up, while caller has ringing throughout. Same also with SVN-trunk-r358216.

   -- Starting simple switch on 'DAHDI/32-1'
   -- Executing [s@pstn:1] NoOp("DAHDI/32-1", "") in new stack
   -- Executing [s@pstn:2] Wait("DAHDI/32-1", "5") in new stack
   -- Executing [s@pstn:3] Answer("DAHDI/32-1", "") in new stack
   -- Executing [s@pstn:4] Echo("DAHDI/32-1", "") in new stack
 == Spawn extension (pstn, s, 4) exited non-zero on 'DAHDI/32-1'
   -- Hanging up on 'DAHDI/32-1'
   -- Hungup 'DAHDI/32-1'
   -- Starting simple switch on 'DAHDI/32-1'
   -- Executing [s@pstn:1] NoOp("DAHDI/32-1", "") in new stack
   -- Executing [s@pstn:2] Wait("DAHDI/32-1", "5") in new stack
   -- Executing [s@pstn:3] Answer("DAHDI/32-1", "") in new stack
   -- Executing [s@pstn:4] Echo("DAHDI/32-1", "") in new stack
 == Spawn extension (pstn, s, 4) exited non-zero on 'DAHDI/32-1'
   -- Hanging up on 'DAHDI/32-1'
   -- Hungup 'DAHDI/32-1'
.

By: Richard Mudgett (rmudgett) 2012-03-05 15:12:05.131-0600

Alec sounds like you have a similar but not the same issue.  Please open another issue.  I am going to commit Jeremy's patch today.
By: Alec Davis (alecdavis) 2012-03-05 18:22:03.832-0600

Agreed, the hangup bug is not related.

Seems as though this method for detecting dialtone relies on call_progress, PROG_MODE_NZ doesn't exist :(
I can however see the use for this.