[Home]

Summary:ASTERISK-16892: [patch] Asterisk gets killed during the live calling
Reporter:destiny6628 (destiny6628)Labels:
Date Opened:2010-10-29 08:13:39Date Closed:2011-04-04 11:18:02
Priority:CriticalRegression?No
Status:Closed/CompleteComponents: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