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

[Rusty Newton (JIRA)]

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

Rusty Newton closed ASTERISK-22983.
-----------------------------------

    Resolution: Suspended
    
> 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 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