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

[Alex Loh (JIRA)]

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

Alex Loh commented on ZAP-364:
------------------------------

Hi Peter, both issues (this original + the duplicate) appear to have been closed (perhaps a mistake?) Unless something has changed recently this remains a problem with Asterisk in the UK


> DAHDI channel gets stuck in 'Pre-rin' state
> -------------------------------------------
>
>                 Key: ZAP-364
>                 URL: https://issues.asterisk.org/jira/browse/ZAP-364
>             Project: Zaptel
>          Issue Type: Bug
>      Security Level: None
>          Components: General
>         Environment: Asterisk 11.4.0 (32 bit) with DAHDI 2.7.0 
>            Reporter: Peter Jolly
>            Assignee: Russ Meyerriecks
>
> 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)