[asterisk-bugs] [JIRA] (ASTERISK-22983) DAHDI channel gets stuck in 'Pre-rin' state

Tue Jun 17 10:31:56 CDT 2014

    [ https://issues.asterisk.org/jira/browse/ASTERISK-22983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219547#comment-219547 ] 

Alex Loh edited comment on ASTERISK-22983 at 6/17/14 10:31 AM:
---------------------------------------------------------------

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 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.

was (Author: alex728):
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 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 (no battery, thus in alarm condition). 

In the UK there is also an automated line test in many areas 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 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.

> DAHDI channel gets stuck in 'Pre-rin' state
> -------------------------------------------
>
>                 Key: ASTERISK-22983
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22983
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 11.4.0
>         Environment: Asterisk 11.4.0 (32 bit) with DAHDI 2.7.0 
>            Reporter: Peter Jolly
>            Assignee: Rusty Newton
>
> 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 at 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 at from-analog:2] Ringing("DAHDI/1-1", "") in new stack
> [2013-11-06 15:15:31] VERBOSE[3874][C-000000c7] pbx.c: – Executing [s at 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 at 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 at 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 at 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 at 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 at 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 at from-analog:12] Macro("DAHDI/1-1", "from-dahdi-1,s,1") in new stack

--
This message was sent by Atlassian JIRA
(v6.2#6252)