Summary: | ASTERISK-16892: [patch] Asterisk gets killed during the live calling | ||
Reporter: | destiny6628 (destiny6628) | Labels: | |
Date Opened: | 2010-10-29 08:13:39 | Date Closed: | 2011-04-04 11:18:02 |
Priority: | Critical | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_dahdi |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) backtrace.txt ( 1) bt_full_all.txt ( 2) jira_ast_437_fixup_reentrancy_v1.4.patch | |
Description: | We are using Asterisk 1.4.36 / Dahdi 1.4.0 / Dahdi-tool as 1.4.0 / Libpri as 1.4.11.4 and Wanpipe Drivers as wanpipe-3.5.17. We are using Sangoma 2 Port E1 Card with hardware echo cancellation supported. Problem which is being faced during the calls twice in a day every day asterisk gets stopped and due to which all our calls gets disconnected which has been a daily issues. ****** ADDITIONAL INFORMATION ****** Attached are the BT logs. In case some thing relevant is found do let update so that further resolution can be done. | ||
Comments: | By: Paul Belanger (pabelanger) 2010-10-29 08:33:07 Your backtrace is optimized (see below). --- Thank you for your bug report. In order to move your issue forward, we require a backtrace from the core file produced after the crash. Please see the doc/backtrace.txt file in your Asterisk source directory. Also, be sure you have DONT_OPTIMIZE enabled in menuselect within the Compiler Flags section, then: make install after enabling, reproduce the crash, and then execute the instructions in doc/backtrace.txt. When complete, attach that file to this issue report. Thanks! By: Richard Mudgett (rmudgett) 2010-10-29 21:46:45 You might also try SVN libpri 1.4. I added code to check for stale call pointers. By: destiny6628 (destiny6628) 2010-11-09 07:51:47.000-0600 Hi, I have downgraded the dahdi and libpri version to dahdi-2.3.0 and libpri to 1.4.10 and did not had a disconnection as of now. However i am facing one issue since a long time on asterisk cli and whenever these error comes we dont get the audio at all and instead of same its a complete silence call. Please find the mentioned error below -- Hungup 'DAHDI/0:30-1' -- DAHDI/35-1 is ringing [Nov 9 13:33:15] WARNING[17733]: chan_dahdi.c:8800 pri_fixup_principle: Call specified, but not found? [Nov 9 13:33:15] WARNING[17733]: chan_dahdi.c:9962 pri_dchannel: Hangup on bad channel 0/30 on span 1 -- Executing [9107588121967@default:1] Dial("Local/9107588121967@default-ba1f,2", "DAHDI/r1/127107588121967|21|oj") in new stack -- Requested transfer capability: 0x00 - SPEECH -- Called r1/127107588121967 -- Executing [9107897154943@default:1] Dial("Local/9107897154943@default-a0dc,2", "DAHDI/r1/127107897154943|21|oj") in new stack -- Requested transfer capability: 0x00 - SPEECH -- Called r1/127107897154943 -- Channel 0/30, span 1 got hangup, cause 34 -- DAHDI/30-1 is circuit-busy -- Hungup 'DAHDI/30-1' == Everyone is busy/congested at this time (1:0/1/0) -- Executing [9107897154943@default:102] Dial("Local/9107897154943@default-a0dc,2", "DAHDI/r2/127107897154943|21|o") in new stack -- Requested transfer capability: 0x00 - SPEECH -- Called r2/127107897154943 -- B-channel 0/14 restarted on span 1 -- DAHDI/38-1 is proceeding passing it to Local/9107897154943@default-a0dc,2 -- Moving call from channel 17 to channel 5 [Nov 9 13:33:16] WARNING[17733]: chan_dahdi.c:8749 pri_fixup_principle: Can't fix up channel from 17 to 5 because 5 is already in use [Nov 9 13:33:16] WARNING[17733]: chan_dahdi.c:9691 pri_dchannel: Ringing requested on channel 0/5 not in use on span 1 -- Channel 0/27, span 2 got hangup request, cause 16 == Spawn extension (default, 108, 1) exited non-zero on 'DAHDI/58-1' -- Executing [h@default:1] DeadAGI("DAHDI/58-1", "hangup|192.168.20.174|192.168.20.10|16|ANSWER|n") in new stack -- Launched AGI Script /var/lib/asterisk/agi-bin/hangup -- AGI Script hangup completed, returning 0 -- Hungup 'DAHDI/58-1' == Done Spying on channel SIP/108-00001a5d -- Moving call from channel 17 to channel 5 [Nov 9 13:33:17] WARNING[17733]: chan_dahdi.c:8749 pri_fixup_principle: Can't fix up channel from 17 to 5 because 5 is already in use [Nov 9 13:33:17] WARNING[17733]: chan_dahdi.c:9837 pri_dchannel: Answer requested on channel 0/5 not in use on span 1 -- B-channel 0/6 restarted on span 1 -- Moving call from channel 13 to channel 17 [Nov 9 13:33:17] WARNING[17733]: chan_dahdi.c:8749 pri_fixup_principle: Can't fix up channel from 13 to 17 because 17 is already in use [Nov 9 13:33:17] WARNING[17733]: chan_dahdi.c:9837 pri_dchannel: Answer requested on channel 0/17 not in use on span 1 -- DAHDI/37-1 is ringing Whenever these error comes like Hang up on bad channel or moving call from X channel to Y then only we start getting silent calls else till the time there are no errors things works pretty smooth. Kindly suggests something on same so that this can be resolved. By: destiny6628 (destiny6628) 2010-11-10 07:23:34.000-0600 This is a very major issue which is being faced and troubling a lot during the calls. Any help would be highly appreciated. By: Paul Belanger (pabelanger) 2010-11-10 10:29:54.000-0600 We are still waiting for an unoptimized backtrace [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace By: destiny6628 (destiny6628) 2010-11-11 01:27:34.000-0600 Hi, Please find attached the back trace as required. Let me know in case any other trace is required as well. By: Abhay Gupta (agupta) 2010-11-11 01:56:40.000-0600 It seems that pri_fixup_principle and memory corruption/segmentation fault are related . By: destiny6628 (destiny6628) 2010-11-15 14:08:22.000-0600 Hi Kindly have a look at the issue where B channels are shifting from time to time during the complete day of calling causing no audio on most of the calls at all. By: Abhay Gupta (agupta) 2010-11-16 01:24:02.000-0600 My view is from your logs and code is that while on any message say during ringing if the channel asked is 5 instead of 17 as you see in log and it is found busy , asterisk is not sending the hangup. The call proceeds receives a ANSWER and again the same message moving call from 17 to 5 and 5 is busy . So certainly the call is not going in BUSY state and is proceeding though structures are neither cleared nor locked . This seems to be a sure bug which needs to be resolved . By: destiny6628 (destiny6628) 2010-11-24 08:33:40.000-0600 Hi any feedback would highly appreciable. By: destiny6628 (destiny6628) 2010-11-25 06:02:41.000-0600 Any update for me? By: Paul Belanger (pabelanger) 2010-11-25 11:26:47.000-0600 Your issue is in queue, please be patient. We will get to it as time permits and developer resources become available. By: destiny6628 (destiny6628) 2010-12-06 02:16:17.000-0600 Thanks!!! will wait for the issue to be attended. By: Richard Mudgett (rmudgett) 2011-01-18 10:49:49.000-0600 The jira_ast_437_fixup_reentrancy_v1.4.patch file may help. It fixes a reentrancy problem when the channel negotiation selects a different channel than the originally requested channel. By: Digium Subversion (svnbot) 2011-04-04 10:49:34 Repository: asterisk Revision: 312573 U branches/1.4/channels/chan_dahdi.c U branches/1.4/configure U branches/1.4/configure.ac U branches/1.4/include/asterisk/autoconfig.h.in ------------------------------------------------------------------------ r312573 | rmudgett | 2011-04-04 10:49:32 -0500 (Mon, 04 Apr 2011) | 38 lines Issues with ISDN calls changing B channels during call negotiations. The handling of the PROCEEDING message was not using the correct call structure if the B channel was changed. (The same for PROGRESS.) The call was also not hungup if the new B channel is not provisioned or is busy. * Made all call connection messages (SETUP_ACKNOWLEDGE, PROCEEDING, PROGRESS, ALERTING, CONNECT, CONNECT_ACKNOWLEDGE) ensure that they are using the correct structure and B channel. If there is any problem with the operations then the call is now hungup with an appropriate cause code. * Made miscellaneous messages (INFORMATION, FACILITY, NOTIFY) find the correct structure by looking for the call and not using the channel ID. NOTIFY is an exception with versions of libpri before v1.4.11 because a call pointer is not available for Asterisk to use. * Made all hangup messages (DISCONNECT, RELEASE, RELEASE_COMPLETE) find the correct structure by looking for the call and not using the channel ID. (closes issue ASTERISK-16964) Reported by: destiny6628 Tested by: rmudgett JIRA SWP-2620 (closes issue ASTERISK-16892) Reported by: destiny6628 Tested by: rmudgett JIRA SWP-2924 (closes issue ASTERISK-17120) Reported by: jpokorny JIRA SWP-2929 JIRA AST-437 (The issues fixed here are most likely causing this JIRA issue.) JIRA DAHDI-406 JIRA LIBPRI-33 (Stuck resetting flag likely fixed) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=312573 By: Digium Subversion (svnbot) 2011-04-04 11:00:05 Repository: asterisk Revision: 312574 _U branches/1.6.2/ U branches/1.6.2/channels/chan_dahdi.c U branches/1.6.2/configure U branches/1.6.2/configure.ac U branches/1.6.2/include/asterisk/autoconfig.h.in ------------------------------------------------------------------------ r312574 | rmudgett | 2011-04-04 11:00:04 -0500 (Mon, 04 Apr 2011) | 45 lines Merged revisions 312573 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r312573 | rmudgett | 2011-04-04 10:49:30 -0500 (Mon, 04 Apr 2011) | 38 lines Issues with ISDN calls changing B channels during call negotiations. The handling of the PROCEEDING message was not using the correct call structure if the B channel was changed. (The same for PROGRESS.) The call was also not hungup if the new B channel is not provisioned or is busy. * Made all call connection messages (SETUP_ACKNOWLEDGE, PROCEEDING, PROGRESS, ALERTING, CONNECT, CONNECT_ACKNOWLEDGE) ensure that they are using the correct structure and B channel. If there is any problem with the operations then the call is now hungup with an appropriate cause code. * Made miscellaneous messages (INFORMATION, FACILITY, NOTIFY) find the correct structure by looking for the call and not using the channel ID. NOTIFY is an exception with versions of libpri before v1.4.11 because a call pointer is not available for Asterisk to use. * Made all hangup messages (DISCONNECT, RELEASE, RELEASE_COMPLETE) find the correct structure by looking for the call and not using the channel ID. (closes issue ASTERISK-16964) Reported by: destiny6628 Tested by: rmudgett JIRA SWP-2620 (closes issue ASTERISK-16892) Reported by: destiny6628 Tested by: rmudgett JIRA SWP-2924 (closes issue ASTERISK-17120) Reported by: jpokorny JIRA SWP-2929 JIRA AST-437 (The issues fixed here are most likely causing this JIRA issue.) JIRA DAHDI-406 JIRA LIBPRI-33 (Stuck resetting flag likely fixed) ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=312574 By: Digium Subversion (svnbot) 2011-04-04 11:10:52 Repository: asterisk Revision: 312575 _U branches/1.8/ U branches/1.8/channels/chan_dahdi.c U branches/1.8/channels/sig_pri.c U branches/1.8/channels/sig_pri.h ------------------------------------------------------------------------ r312575 | rmudgett | 2011-04-04 11:10:51 -0500 (Mon, 04 Apr 2011) | 52 lines Merged revisions 312574 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r312574 | rmudgett | 2011-04-04 11:00:02 -0500 (Mon, 04 Apr 2011) | 45 lines Merged revisions 312573 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r312573 | rmudgett | 2011-04-04 10:49:30 -0500 (Mon, 04 Apr 2011) | 38 lines Issues with ISDN calls changing B channels during call negotiations. The handling of the PROCEEDING message was not using the correct call structure if the B channel was changed. (The same for PROGRESS.) The call was also not hungup if the new B channel is not provisioned or is busy. * Made all call connection messages (SETUP_ACKNOWLEDGE, PROCEEDING, PROGRESS, ALERTING, CONNECT, CONNECT_ACKNOWLEDGE) ensure that they are using the correct structure and B channel. If there is any problem with the operations then the call is now hungup with an appropriate cause code. * Made miscellaneous messages (INFORMATION, FACILITY, NOTIFY) find the correct structure by looking for the call and not using the channel ID. NOTIFY is an exception with versions of libpri before v1.4.11 because a call pointer is not available for Asterisk to use. * Made all hangup messages (DISCONNECT, RELEASE, RELEASE_COMPLETE) find the correct structure by looking for the call and not using the channel ID. (closes issue ASTERISK-16964) Reported by: destiny6628 Tested by: rmudgett JIRA SWP-2620 (closes issue ASTERISK-16892) Reported by: destiny6628 Tested by: rmudgett JIRA SWP-2924 (closes issue ASTERISK-17120) Reported by: jpokorny JIRA SWP-2929 JIRA AST-437 (The issues fixed here are most likely causing this JIRA issue.) JIRA DAHDI-406 JIRA LIBPRI-33 (Stuck resetting flag likely fixed) ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=312575 By: Digium Subversion (svnbot) 2011-04-04 11:18:01 Repository: asterisk Revision: 312579 _U trunk/ U trunk/channels/chan_dahdi.c U trunk/channels/sig_pri.c U trunk/channels/sig_pri.h ------------------------------------------------------------------------ r312579 | rmudgett | 2011-04-04 11:18:00 -0500 (Mon, 04 Apr 2011) | 59 lines Merged revisions 312575 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r312575 | rmudgett | 2011-04-04 11:10:50 -0500 (Mon, 04 Apr 2011) | 52 lines Merged revisions 312574 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r312574 | rmudgett | 2011-04-04 11:00:02 -0500 (Mon, 04 Apr 2011) | 45 lines Merged revisions 312573 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r312573 | rmudgett | 2011-04-04 10:49:30 -0500 (Mon, 04 Apr 2011) | 38 lines Issues with ISDN calls changing B channels during call negotiations. The handling of the PROCEEDING message was not using the correct call structure if the B channel was changed. (The same for PROGRESS.) The call was also not hungup if the new B channel is not provisioned or is busy. * Made all call connection messages (SETUP_ACKNOWLEDGE, PROCEEDING, PROGRESS, ALERTING, CONNECT, CONNECT_ACKNOWLEDGE) ensure that they are using the correct structure and B channel. If there is any problem with the operations then the call is now hungup with an appropriate cause code. * Made miscellaneous messages (INFORMATION, FACILITY, NOTIFY) find the correct structure by looking for the call and not using the channel ID. NOTIFY is an exception with versions of libpri before v1.4.11 because a call pointer is not available for Asterisk to use. * Made all hangup messages (DISCONNECT, RELEASE, RELEASE_COMPLETE) find the correct structure by looking for the call and not using the channel ID. (closes issue ASTERISK-16964) Reported by: destiny6628 Tested by: rmudgett JIRA SWP-2620 (closes issue ASTERISK-16892) Reported by: destiny6628 Tested by: rmudgett JIRA SWP-2924 (closes issue ASTERISK-17120) Reported by: jpokorny JIRA SWP-2929 JIRA AST-437 (The issues fixed here are most likely causing this JIRA issue.) JIRA DAHDI-406 JIRA LIBPRI-33 (Stuck resetting flag likely fixed) ........ ................ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=312579 |