| Summary: | ASTERISK-18405: PRI channel becomes unavailable | ||||||
| Reporter: | Kris Shaw (shawkris) | Labels: | |||||
| Date Opened: | 2011-09-01 08:28:26 | Date Closed: | 2011-10-21 22:40:08 | ||||
| Priority: | Minor | Regression? | Yes | ||||
| Status: | Closed/Complete | Components: | Channels/chan_dahdi | ||||
| Versions: | 1.4.42 | Frequency of Occurrence | Occasional | ||||
| Related Issues: |
| ||||||
| Environment: | Kernel 2.6.25.10 LibPRI 1.4.12 DAHDI 2.3.0.1 | Attachments: | ( 0) err_2011_09_01.txt ( 1) log-aug-22.txt ( 2) stuck-channel-2011-10-19.txt ( 3) stuck-channels-187.txt | ||||
| Description: | Channel between Asterisk and PBX becomes blocked. Error log suggests duplicate call ptr, but error seems to appear on first instance of call reference | ||||||
| Comments: | By: Richard Mudgett (rmudgett) 2011-09-01 13:00:00.098-0500 What is the dialplan extension processing these calls? A debug trace of the call through the dialplan would help. From the pri debug output, it looks like the call is dialing though your dialplan using the '!' pattern match to pass subsequent overlap digits to the next hop. The number dialed is then found to be invalid/unassigned. Intense pri debug output is not needed for call control issues. Intense pri debug output is only needed if there is a link layer problem. Otherwise, the debug output is cluttered with irrelevant data. By: Kris Shaw (shawkris) 2011-09-05 04:14:18.478-0500 [globals] TRUNK=DAHDI/G1 INTTRUNK=DAHDI/g2 INTTRUNKPRIV=DAHDI/g3 [out-to-bt] ;National Calls exten => _0[1237]XXXXXXXXX,1,Dial(${GLOBAL(TRUNK)}/${EXTEN}) exten => _0[1237]XXXXXXXXX,n,Hangup ;National Calls exten => _0[1237]XXXXXXXX,1,Dial(${GLOBAL(TRUNK)}/${EXTEN}) exten => _0[1237]XXXXXXXX,n,Hangup ;Other calls, such as 0800 and international exten => _0[0568]X.,1,Dial(${GLOBAL(TRUNK)}/${EXTEN}) exten => _0[0568]X.,n,Hangup ;Special calls (118500 and local) exten => _ZX.,1,Dial(${GLOBAL(TRUNK)}/${EXTEN}) exten => _ZX.,n,Hangup [out-to-pbx] ;This handles incoming calls from the BT network exten => _12XX,1,Macro(dialpbx,${EXTEN},INTTRUNK,) [macro-dialpbx] ;Dials the extension on the trunk name specified in ARG2 ;If ARG3 is present then we know we are using Asterisk VM ;We need to set ARG3 to a variable, otherwise the value is lost on the h extension exten => s,1,Set(CALLERID(num)=${FILTER(0123456789,"${CALLERID(num)}")}) exten => s,2,Set(DB(lastcaller/${ARG1})=${CALLERID(num)}) exten => s,3,Set(DB(lastcallertime/${ARG1})=${STRFTIME(${EPOCH},,%s)}) exten => s,4,Set(ExtenEmail=${ARG3}) exten => s,5,GotoIf($["${ARG3}" = ""]?9:6) exten => s,6,Dial(${GLOBAL(${ARG2})}/${ARG1},20) exten => s,7,GotoIf($["${DIALSTATUS}"="BUSY"]?vm-BUSY|1) exten => s,8,Goto(vm-NOANSWER,1) exten => s,9,Dial(${GLOBAL(${ARG2})}/${ARG1}) exten => s,10,Hangup exten => h,1,GotoIf($["${ExtenEmail}" != ""]?h-email,1) exten => h-email,1,System(/var/lib/asterisk/agi-bin/processCallEmail.sh "${ExtenEmail}" "${CALLERID(num)}" "${CALLERID(name) }" "${DIALSTATUS}" "${VMSTATUS}") exten => t,1,Hangup exten => vm-BUSY,1,VoiceMail(${ARG1:-4}@corp|b) exten => vm-BUSY,n,Hangup exten => vm-NOANSWER,1,VoiceMail(${ARG1:-4}@corp|u) exten => vm-NOANSWER,n,Hangup By: Kris Shaw (shawkris) 2011-09-06 05:45:19.485-0500 Hello, Looks like a similar problem on a different PBX. Span1 Logical channels 1-15 - Context: in-from-bt - 15 channels from ISDN30e Asterisk had been idle for a long time after logs had been rotated but with no calls in progress. There should be no reason for channel 0/1 not to be available? [Sep 4 04:40:03] VERBOSE[20240] logger.c: Asterisk Event Logger restarted [Sep 4 04:40:03] VERBOSE[20240] logger.c: Asterisk Queue Logger restarted [Sep 4 04:40:04] VERBOSE[20240] logger.c: -- Remote UNIX connection disconnected [Sep 4 15:41:54] DEBUG[30151] chan_dahdi.c: Span 1: SETUP requested unavailable channel 0/1. Attempting to renegotiate. [Sep 4 15:41:54] DEBUG[30151] chan_dahdi.c: Found empty available channel 0/15 Span2 Logical channels 1-15 - Context: in-from-pbx-ext - PBX Hunt group 1 Logical channels 16-30 - Context: in-from-pbx-int - PBX Hunt group 2 [Sep 6 11:35:00] DEBUG[30152] chan_dahdi.c: Span 2: SETUP requested unavailable channel 0/4. Attempting to renegotiate. [Sep 6 11:35:00] DEBUG[30152] chan_dahdi.c: Found empty available channel 0/31 [Sep 6 11:35:00] VERBOSE[30152] logger.c: -- Span 2: Extension 07@in-from-pbx-int does not exist. Rejecting call from '558xxx'. Here the problem is slightly different - the channel is rengotiated but in this case the new channel is in a different context so the call fails anyway (although it's the same PRI). We didn't experience these SETUP channel selection errors in the previous version we were running, 1.4.35. By: Richard Mudgett (rmudgett) 2011-09-06 13:22:50.004-0500 1) Use the Proceeding application on your PRI extensions that do not use the '!' wildcard matching. exten => _12XX,1,Proceeding exten => _12XX,n,Macro(dialpbx,${EXTEN},INTTRUNK,) The Proceeding application was backported to v1.4 when an attempted fix to automatically generate the PROCEEDING message was reverted. (Overlap dial through was broken.) Your issue has pointed out a problem with overlap dial through that has been around a long time. Namely dialing a wrong number using overlap dial through will fail to free a B channel completely. Unfortunately, it will not be fixed in v1.4 because it is no longer receiving regular maintenance. 2) Chan_dahdi does not have a way to configure channel selection for incoming calls the way it does for outgoing calls. It *always* selects the highest channel number of a span available if it has to pick a channel. By: Kris Shaw (shawkris) 2011-09-06 17:17:27.579-0500 1. If B channel lock-ups are resolved by an upgrade to a newer version then this is something that I'll look at doing. 2. In our environment, selecting the highest B channel of the span is not desired behaviour, instead the highest B channel in the same group as the unavailable channel would be better. Otherwise, it effectively means than in chan_dahdi that a span must exist only in a single group/context? By: David Woolley (davidw) 2011-09-07 05:18:31.817-0500 For information, I've seen two or three postings on forums.digium.com recently reporting an invalid call ptr error. I would have added this comment earlier, but, unlike Mantis, JIRA is locking third party comments out when in the Feedback state. By: Richard Mudgett (rmudgett) 2011-09-07 12:20:50.278-0500 1) Asterisk v1.8 should not have this unavailable channel issue. It enables a fix in libpri v1.4.11+ that I could not enable in earlier versions of Asterisk because of backward compatibility issues. 2) Incoming calls do not necessarily have to have a B channel assigned in the SETUP message so chan_dahdi would not know which group to search for a B channel in that case. If it did, then restricting the search to the same group or groups as the requested B channel would be a new feature and must go into trunk. 3) When an issue is in the feedback state, the "comment" button intentionally disappears because you have to use the "enter feedback" button at the top instead. When entering feedback you have an option to indicate that feedback is complete or more feedback will be entered later. By: David Woolley (davidw) 2011-09-08 04:37:37.601-0500 "enter feedback" is not available to third parties. By: Leif Madsen (lmadsen) 2011-09-08 13:14:38.258-0500 After speaking with Richard, he states this is not a bug in 1.8, and because 1.4 and 1.6.x are no longer in maintenance mode, there isn't anything further to do with this issue. Closing. By: Kris Shaw (shawkris) 2011-10-17 08:02:58.027-0500 We are still seeing this behaviour in 1.8.7. What information would you need to further troubleshoot this? I have changed the dialplan so that calls made from Asterisk to the PSTN on span 1 are not overlap dialled, but the attached PBX will still overlap dial into Asterisk on span 2. By: Kris Shaw (shawkris) 2011-10-19 04:49:12.129-0500 This is a call to a pre-paid dialing card provider. After this call was hung-up, channel 0/15 on span 2 was stuck. By: Kris Shaw (shawkris) 2011-10-19 11:16:30.566-0500 I can replicate the problem with a single extension in the dialplan: {code} exten => 8697,1,Hangup(34) {code} Dialing the extension from an attached PBX using overlap dialing will cause whatever channel was selected to become stuck. {noformat} PRI B Chan Call PRI Channel Span Chan Chan Idle Level Call Name 2 62 Yes No Idle Yes {noformat} This is with Asterisk 1.8.7, LibPRI 1.4.12 and DAHDI 2.5.0.1. By: Richard Mudgett (rmudgett) 2011-10-19 11:28:26.910-0500 Please attach "pri set debug on span x" capture of channel getting stuck. By: Kris Shaw (shawkris) 2011-10-19 12:22:28.666-0500 I have found a potential fix/workaround for our environment. If I put this back into sig_pri.h, I don't see the stuck channels anymore. #define HAVE_PRI_HANGUP_FIX 1 I remember this being required because of a change to LibPRI's hangup that couldn't be fully fixed in 1.4, so the #define was used to enable the new behaviour in later versions. By: Richard Mudgett (rmudgett) 2011-10-19 12:51:08.558-0500 Since Asterisk is dependent upon what version of libpri is installed, rerunning ./configure on Asterisk v1.8.x should define HAVE_PRI_HANGUP_FIX for you. By: Kris Shaw (shawkris) 2011-10-19 13:06:50.330-0500 I've just checked on a new machine that has only ever had libpri 1.4.12 and Asterisk 1.8.6 then 1.8.7 installed, and I can't see HAVE_PRI_HANGUP_FIX included anywhere. Which header file should I expect to see it in? By: Richard Mudgett (rmudgett) 2011-10-19 13:22:23.478-0500 It is defined in the ./configure generated file include/asterisk/autoconfig.h By: Kris Shaw (shawkris) 2011-10-19 13:29:14.796-0500 For the three systems I have here, the include is missing from autoconfig.h. Libpri was installed before Asterisk was compiled. Running configure again doesn't make any difference. By: Richard Mudgett (rmudgett) 2011-10-19 13:34:15.306-0500 Actually a regression introduced in v1.8.7 broke the ability of the ./configure script to generate the HAVE_PRI_xxx defines. Fix committed to v1.8 branch with -r339719. It is fixed in v1.8.8-rc2. You could simply use the ./configure script from v1.8.6. This regression also explains why you were still seeing the problem in v1.8.7. By: Richard Mudgett (rmudgett) 2011-10-21 22:40:08.386-0500 Closing because the regression in v1.8.7 causing the problem to still be present has already been fixed. By: Richard Mudgett (rmudgett) 2011-11-22 17:40:41.009-0600 A dialplan Hangup with these cause codes will result in stuck channels for v1.4.x and v1.6.x (From AST-681): PRI_CAUSE_NORMAL_CIRCUIT_CONGESTION(34) PRI_CAUSE_REQUESTED_CHAN_UNAVAIL(44) PRI_CAUSE_IDENTIFIED_CHANNEL_NOTEXIST(82) PRI_CAUSE_UNALLOCATED(1) | ||||||