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

Tue Dec 17 09:49:03 CST 2013

     [ https://issues.asterisk.org/jira/browse/ASTERISK-22983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-22983:
------------------------------------

    Assignee: Peter Jolly
      Status: Waiting for Feedback  (was: Triage)

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.

> 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: Peter Jolly
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira