Summary:	ASTERISK-22983: DAHDI channel gets stuck in 'Pre-rin' state
Reporter:	Peter Jolly (petej1)	Labels:
Date Opened:	2013-12-13 08:44:06.000-0600	Date Closed:	2014-01-06 20:46:52.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:
Versions:	11.4.0	Frequency of Occurrence	Frequent
Related Issues:	is duplicated by ASTERISK-00364 DAHDI channel gets stuck in 'Pre-rin' state
Environment:	Asterisk 11.4.0 (32 bit) with DAHDI 2.7.0	Attachments:
Description:	This issue has been debated on the Asterisk Forum under the title - ‘DAHDI trunk getting stuck in pre-ring state’ with reports from several users - all seeing the same issue. All in the UK, all with analogue lines, all with UK caller ID. No fix has been found. The problem is that frequently after a call has finished the DAHDI channel stays stuck in ‘pre-rin’ state. This state will remain until a new in-bound call is received on that particular analogue channel. The issue occurs on any of the analogue channels on the line card. Out-bound calls cannot be made on the channel when it is in this state. You cannot clear the condition by using 'channel request hangup DAHDI/x-. Removing the telephone line cable does clear the line. As does stopping the Asterisk service and then starting it again. On our system you see this issue every day. The system runs Asterisk 11.4.0 (32 bit) with DAHDI 2.7.0. It has three analogue exchange lines connected to a TDM410P card. The system is in the UK on BT lines with Caller ID. This problem did not occur on a much old system running Asterisk 1.4 and DAHDI 2.2.0.2-6 Any help would be very much appreciated. This is stopping us deploying any analogue installations at the moment. Thanks, peter. My logs show: At the end of a call: ……… [2013-11-06 13:47:22] VERBOSE[2384][C-000000b3] app_macro.c: == Spawn extension (macro-dialout-trunk, s, 22) exited non-zero on 'SIP/205-0000028d' in macro 'dialout-trunk' [2013-11-06 13:47:22] VERBOSE[2384][C-000000b3] pbx.c: == Spawn extension (from-internal, 01245123456, 5) exited non-zero on 'SIP/205-0000028d' [2013-11-06 13:47:22] VERBOSE[2385][C-000000b3] app_mixmonitor.c: == MixMonitor close filestream (mixed) [2013-11-06 13:47:22] VERBOSE[2385][C-000000b3] app_mixmonitor.c: == End MixMonitor Recording SIP/205-0000028d [2013-11-06 13:47:23] VERBOSE[7557][C-000000b4] sig_analog.c: == Starting post polarity CID detection on channel 1 [2013-11-06 13:47:23] VERBOSE[2386][C-000000b4] sig_analog.c: – Starting simple switch on 'DAHDI/1-1' When the next call comes in on that channel: [2013-11-06 15:15:31] NOTICE[3874][C-000000c7] chan_dahdi.c: Got event 17 (Polarity Reversal)... [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] chan_dahdi.c: – Detected ring pattern: 0,0,0 [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] chan_dahdi.c: – Checking 0,0,0 [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] chan_dahdi.c: – Ring pattern check range: 10 [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] chan_dahdi.c: – Ring pattern matched in range: -10 to 10 [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] chan_dahdi.c: – Ring pattern check range: 10 [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] chan_dahdi.c: – Ring pattern matched in range: -10 to 10 [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] chan_dahdi.c: – Ring pattern check range: 10 [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] chan_dahdi.c: – Ring pattern matched in range: -10 to 10 [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] chan_dahdi.c: – Distinctive Ring matched context from-analog [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] pbx.c: – Executing [s@from-analog:1] NoOp("DAHDI/1-1", "Entering from-dahdi with DID == ") in new stack [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] pbx.c: – Executing [s@from-analog:2] Ringing("DAHDI/1-1", "") in new stack [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] pbx.c: – Executing [s@from-analog:3] Set("DAHDI/1-1", "DID=s") in new stack [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] pbx.c: – Executing [s@from-analog:4] NoOp("DAHDI/1-1", "DID is now s") in new stack [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] pbx.c: – Executing [s@from-analog:5] GotoIf("DAHDI/1-1", "1?dahdiok:checkzap") in new stack [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] pbx.c: – Goto (from-analog,s,9) [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] pbx.c: – Executing [s@from-analog:9] NoOp("DAHDI/1-1", "Is a DAHDi Channel") in new stack [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] pbx.c: – Executing [s@from-analog:10] Set("DAHDI/1-1", "CHAN=1-1") in new stack [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] pbx.c: – Executing [s@from-analog:11] Set("DAHDI/1-1", "CHAN=1") in new stack [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] pbx.c: – Executing [s@from-analog:12] Macro("DAHDI/1-1", "from-dahdi-1,s,1") in new stack
Comments:	By: Rusty Newton (rnewton) 2013-12-17 09:48:56.102-0600 We don't have enough information in this issue to move forward. Peter, I see you are using a Digium board product, are you already in contact with Digium technical support? That really needs to be the first stop for this sort of issue, as they work with chan_dahdi and DAHDI every day, and could likely identify an issue and gather the specific debug needed to track the issue down more quickly than we can when working with those specific components. I think the first step is to extract all relevant information from your forum post and provide it to Digium technical support; they may already be working on a related issue or have a ticket open with Digium engineering regarding this. If not, then they'll get the specific information needed and open an issue with engineering. By: Rusty Newton (rnewton) 2014-01-06 20:47:01.694-0600 Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines By: Alex Loh (alex728) 2014-06-17 10:30:15.532-0500 I have the issue on a different line card (Openvox A400) and have also posted a message on their forum. I can reproduce the issue it by listening in on a ZAP channel, making an inbound call and clearing very quickly (during the time the caller ID detection routine is processed). The channel is then stuck in PRE-RING until the next inbound call. There are also reports of the same happening with other line cards, the common factor being UK caller ID detection. Asterisk treats any polarity reversal on a UK line as a potential caller ID signal (including a reversal sent by some exchanges when a call has completed) - there should be a time out on this pre-ring state; as the line is either in pre-ring state, ringing, on/off hook or dis (i.e plug pulled out, external dropwire cut) - with no battery, thus in alarm condition). In the UK there is also an automated line test that is a sequence of polarity reversals, battery removed and reapplied, and various signals sent to A and B wire (tip and ring) - this used to segfault Zaptel and cause a false red alarm with DAHDI but was fixed at some point. The fix here may be as simple as reactivating the time out of the PRE-RING state and may solve similar issues in other nations which have a polarity reversal before caller ID signal.