[Home]

Summary:DAHLIN-00254: 44 isdn cause after 1-4 weeks of work.
Reporter:Badalian Vyacheslav (slavon)Labels:
Date Opened:2011-09-06 03:33:42Date Closed:2012-04-05 10:45:32
Priority:CriticalRegression?Yes
Status:Closed/CompleteComponents:wct4xxp
Versions:2.5.0.1 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:pci:0000:0c:08.0 wct4xxp+ d161:0420 Wildcard TE420 (4th Gen) CentOS 5.6Attachments:( 0) dah.txt
( 1) full.0.gz
( 2) traceview.txt
Description:After update server software to last release (server not updated about 3 month) we have bug.

Asterisk work normal abount 1-4 weeks.
After this uplink PBX get 44 isdn cause code in 80% of calls! (Call direction PBX -> ASTERISK)
In asterisk log we does not see any problem calls.
Restart asterisk software does not help.
Reboot server is help.
E1 load about 1-5 SL.
Comments:By: Shaun Ruffell (sruffell) 2011-09-06 09:47:50.812-0500

What version were you running before the update?  Did you only update DAHDI or Asterisk and DAHDI?
By: Badalian Vyacheslav (slavon) 2011-09-06 13:13:38.444-0500

I don't know what version was :(

I was update all packages.

Now:
[root@asterisk ~]# rpm -qa | egrep "dahdi|asterisk"
dahdi-firmware-oct6114-064-1.05.01-1_centos5
dahdi-firmware-tc400m-MR6.12-1_centos5
kmod-dahdi-linux-fwload-vpmadt032-2.4.1-1_centos5.2.6.18_194.32.1.el5
kmod-dahdi-linux-fwload-vpmadt032-2.4.1.2-1_centos5.2.6.18_238.9.1.el5
kmod-dahdi-linux-2.5.0-1_centos5.2.6.18_238.19.1.el5
asterisk16-dahdi-1.6.2.20-1_centos5
asterisk16-addons-core-1.6.2.3-1_centos5
kmod-dahdi-linux-2.4.1-1_centos5.2.6.18_194.32.1.el5
asterisk-sounds-core-en-gsm-1.4.21-1_centos5
asterisk16-core-1.6.2.20-1_centos5
dahdi-firmware-hx8-2.06-1_centos5
dahdi-firmware-oct6114-128-1.05.01-1_centos5
asterisk16-addons-ooh323-1.6.2.3-1_centos5
asterisk16-voicemail-1.6.2.20-1_centos5
dahdi-tools-2.5.0-1_centos5
asterisk16-doc-1.6.2.20-1_centos5
asterisk16-1.6.2.20-1_centos5
dahdi-firmware-2.0.2-1_centos5
kmod-dahdi-linux-2.4.1.2-1_centos5.2.6.18_238.9.1.el5
kmod-dahdi-linux-2.4.1.2-1_centos5.2.6.18_238.12.1.el5
kmod-dahdi-linux-fwload-vpmadt032-2.4.1.2-1_centos5.2.6.18_238.12.1.el5
dahdi-linux-2.5.0-1_centos5
kmod-dahdi-linux-fwload-vpmadt032-2.5.0-1_centos5.2.6.18_238.19.1.el5

now i try add dahdi-linux-2.5.0-1_centos5 to blacklist and look thats happens  
By: Shaun Ruffell (sruffell) 2011-09-06 15:12:15.647-0500

Are you able to isolate the problem to either just the Asterisk update or the DAHDI update?
By: Badalian Vyacheslav (slavon) 2011-09-07 05:40:45.685-0500

Now i downgrade to "dahdi: Version: 2.4.1.2" and look few days.
Asterisk is 1.6.2.20.

I think its dahdi driver becouse restart asterisk software does not help. Only hardware reboot help (and dahdi card is reinit).


By: Shaun Ruffell (sruffell) 2011-09-07 11:43:12.025-0500

Is the span going into and out of alarm at this time? Are there any messages in the kernel logs when you were seeing the ISDN cause codes 44?
By: Badalian Vyacheslav (slavon) 2011-09-08 02:43:05.213-0500

>Is the span going into and out of alarm at this time?

I not see any problems in asterisk.
"dahdi show channels" show only 5 SL with CallerID.

>Are there any messages in the kernel logs when you were seeing the ISDN cause codes 44?
dmesg is clean. Only card init.
I see it (44 cause code) on uplink PBX. PBX have 128xE1 links. To asterisk going 4xE1 - all in one group.
All E1 links (but not to asterisk) in PBX is was work normal.
By: Shaun Ruffell (sruffell) 2011-09-10 22:16:01.902-0500

This issue is a little hard for me to follow so my apologies if I'm asking the same questions again.

My current understanding is that you've downgraded only DAHDI to 2.4.1.2 and you're waiting to see if the same problem occurs?
By: Badalian Vyacheslav (slavon) 2011-09-11 07:23:11.213-0500

Yes, you are absolutely right.
By: Shaun Ruffell (sruffell) 2011-09-13 13:20:56.395-0500

Moving this back to waiting for feedback pending the results of your test.
By: Badalian Vyacheslav (slavon) 2011-10-02 11:51:41.890-0500

DAHDI 2.4.1.2 work without this bug.
By: Shaun Ruffell (sruffell) 2011-10-12 12:50:58.020-0500

Badalian, if you have a VPM module on your card, would you be willing to try the current tip of the 2.5 branch? I'm not sure, but I could imagine how [r10221|http://svnview.digium.com/svn/dahdi?view=revision&revision=10221] might be related.
By: Badalian Vyacheslav (slavon) 2011-10-13 06:49:22.858-0500

Sorry, i can't try not rpm packages (test builds) on our system.

Also i can say:
dahdi 2.4 also have this bug. After 3 weeks system drop 80% calls with 44 error. Channals are free. Help only reboot (reinit card)
By: Shaun Ruffell (sruffell) 2011-10-13 09:56:47.242-0500

Is it possible that when you say 2.4 doesn't work that 2.4.0 did work for you but 2.4.1+ does not?  If so, I could see how that commit is related and I guess you'll need to wait for it to trickle through the system.

If not, do you have a version that believe is "good"?
By: Shaun Ruffell (sruffell) 2011-10-13 10:28:49.137-0500

Also....to try and encourage you to try the tip below is the current diffs in dahdi-base and the wct4xxp driver between 2.5.0.1 which you tried and the current tip of the 2.5 branch. It's very conservative only fixing known issues.

But I can understand if you have a policy against doing so.

{noformat}
diff --git a/drivers/dahdi/dahdi-base.c b/drivers/dahdi/dahdi-base.c
index f8c0ae1..f01074e 100644
--- a/drivers/dahdi/dahdi-base.c
+++ b/drivers/dahdi/dahdi-base.c
@@ -4797,6 +4797,10 @@ static int dahdi_ioctl_startup(struct file *file, unsigned long data)
                        */
                       s->chans[x]->rxhooksig = DAHDI_RXSIG_INITIAL;
               }
+
+               /* Now that this span is running, it might be selected as the
+                * master span */
+               __dahdi_find_master_span();
       }
       put_span(s);
       return 0;
@@ -9227,12 +9231,12 @@ static void coretimer_init(void)
       init_timer(&core_timer.timer);
       core_timer.timer.function = coretimer_func;
       core_timer.start_interval = current_kernel_time();
-       core_timer.timer.expires = jiffies + HZ;
       atomic_set(&core_timer.count, 0);
       atomic_set(&core_timer.shutdown, 0);
       core_timer.interval = max(msecs_to_jiffies(DAHDI_MSECS_PER_CHUNK), 1UL);
       if (core_timer.interval < (HZ/250))
               core_timer.interval = (HZ/250);
+       core_timer.timer.expires = jiffies + core_timer.interval;
       add_timer(&core_timer.timer);
}

diff --git a/drivers/dahdi/wct4xxp/base.c b/drivers/dahdi/wct4xxp/base.c
index f1c2bed..f412f13 100644
--- a/drivers/dahdi/wct4xxp/base.c
+++ b/drivers/dahdi/wct4xxp/base.c
@@ -766,11 +766,9 @@ static inline unsigned int __t4_raw_oct_in(struct t4 *wc, const unsigned int add
       __t4_pci_out(wc, WC_LADDR, (WC_LWRITE | WC_LALE));
       if (!pedanticpci)
               __t4_pci_in(wc, WC_VERSION);
-#ifdef PEDANTIC_OCTASIC_CHECKING
       __t4_pci_out(wc, WC_LADDR, (WC_LALE));
       if (!pedanticpci)
               __t4_pci_in(wc, WC_VERSION);
-#endif
       if (!octopt) {
               __t4_gpio_setdir(wc, 0xff, 0x00);
               __t4_gpio_set(wc, 0xff, 0x00);
{noformat}
By: Badalian Vyacheslav (slavon) 2011-10-15 05:12:49.504-0500

I don't know that version is "good". May be we faster reboot server than get this bug :)

I can patch module and install it, but i think, you faster add this "clean fix" and release new version of dahdi than i test this bug.

I Think in next time i do
cat /proc/dahdi/*
asterisk -rx "dahdi show status"
asterisk -rx "dahdi show channels"
asterisk -rx "dahdi show channel 1"
...
asterisk -rx "dahdi show channel 128"

and send it to you.  Maybe this help.
Thanks
By: Shaun Ruffell (sruffell) 2011-10-17 09:14:21.076-0500

Ok, I'll leave this open then and you can comment after the next release.  I've been running massive amounts of calls on the current 2.5 branch and haven't noticed anything strange with the exception of the issue I commented on above.
By: Shaun Ruffell (sruffell) 2011-10-22 15:09:57.212-0500

2.5.0.2 is released if you want to upgrade and try that version.
By: Badalian Vyacheslav (slavon) 2011-10-26 02:40:36.869-0500

Debug info from dahdi
By: Badalian Vyacheslav (slavon) 2011-10-26 02:43:40.705-0500

now again.
Many Free Channels. At up PBX 44 cause code. Reboot server was help.

Dahdi 2.5.0.2 we wait. No new rpms in official repo.
By: Badalian Vyacheslav (slavon) 2011-12-05 02:47:29.653-0600

2.5.0.2 Have some problems.
After 3-5 days Asterisk send to Upstream PBX 44 cause code if PBX call to Asterisk.
Help reboot Server or physical trun off and turn on E1 patchcord.
Restart asterisk service does not help.
Have full debug log at bug time, but its not have any info about calls thats dropped.
Echocancelers is off (also try to on) by dahdi/system.conf and  dahdi_chan.conf - its does not help.
Dropped about 70% of incomming calls!
On second server with not so many calls this bug activated after 2-6 weeks.
How to fix this? We drop clients :( Please help.
By: Badalian Vyacheslav (slavon) 2011-12-05 02:50:06.467-0600

Full log at time 44 cause code
By: Badalian Vyacheslav (slavon) 2011-12-05 02:50:47.024-0600

Attached log and comments
By: Badalian Vyacheslav (slavon) 2011-12-05 03:10:01.749-0600

Trace from PBX
By: Shaun Ruffell (sruffell) 2011-12-05 10:34:51.199-0600

And there isn't anything in dmesg or /var/log/messages that corresponds with when the calls start dropping?
By: Badalian Vyacheslav (slavon) 2011-12-06 05:21:52.370-0600

No. All is clean
By: Shaun Ruffell (sruffell) 2011-12-06 10:50:29.996-0600

Richard, does this look like anything you've seen recently?
By: Shaun Ruffell (sruffell) 2011-12-06 13:07:19.656-0600

I spoke with Richard this morning and we would like to rule out chan_dahdi in Asterisk.

Is it possible for you to try either Asterisk 1.8.8-rc5, 1.8.6 (just not 1.8.7) or go back to revision 1.6.2.17.3 (which predates [312574 "Issues with ISDN calls changing B channels during call negotiations." |http://svnview.digium.com/svn/asterisk?view=revision&revision=312574])?  You should be able to keep the same revisions of libpri and DAHDI (just you may need to recompile depending on the direction that you go)

Richard's theory is that chan_dahdi is "wedging" one of the bchannels so it's not available when the remote PBX tries to initiate a call on it, even though the remote PBX doesn't have any idea that chan_dahdi believes it's in use.
By: Badalian Vyacheslav (slavon) 2011-12-06 18:01:40.573-0600

Ok. I compile and start 1.6.2.17.3. Will try...

Strange that * restart does not help and no help reinit channels witch must be (as i think) after restart *
By: Badalian Vyacheslav (slavon) 2011-12-06 18:38:54.468-0600

Asterisk version changes:

Sep 30 11:58:08 Installed: asterisk16-core-1.6.2.12-1_centos5.x86_64
Nov 24 13:03:55 Updated: asterisk16-core-1.6.2.14-1_centos5.x86_64
Dec 20 13:05:56 Updated: asterisk16-core-1.6.2.15-1_centos5.x86_64
Jan 19 18:20:11 Updated: asterisk16-core-1.6.2.16.1-1_centos5.x86_64
Apr 07 00:17:00 Updated: asterisk16-core-1.6.2.17.2-1_centos5.x86_64
Apr 22 21:49:03 Updated: asterisk16-core-1.6.2.17.3-1_centos5.x86_64
Jun 29 12:38:25 Updated: asterisk16-core-1.6.2.18.2-1_centos5.x86_64
Jul 04 12:30:24 Updated: asterisk16-core-1.6.2.19-1_centos5.x86_64
Aug 09 17:41:02 Updated: asterisk16-core-1.6.2.20-1_centos5.x86_64
Oct 13 16:16:01 Updated: asterisk16-core-1.6.2.20-2_centos5.x86_64


44 Cause errors in month 2011:
Month 1: 61 / 115461
Month 2: 91 / 126523
Month 3: 127 / 159270
Month 4: 180 / 208195
Month 5: 103 / 230372
Month 6: 108 / 183704
Month 7: 27505 / 219319
Month 8: 52670 / 188681
Month 9: 20658 / 168802
Month 10: 34266 / 202144
Month 11: 38226 / 209794
Month 12: 5715 / 36264

7 Month by day:
Day 1: 3 / 8914
Day 2: 0 / 4105
Day 3: 0 / 3677
Day 4: 4 / 8499
Day 5: 126 / 8639
Day 6: 270 / 8941
Day 7: 313 / 8756
Day 8: 501 / 8164
Day 9: 238 / 2907
Day 10: 178 / 2181
Day 11: 576 / 7104
Day 12: 617 / 7625
Day 13: 742 / 8389
Day 14: 839 / 8717
Day 15: 886 / 8170
Day 16: 585 / 5485
Day 17: 470 / 4165
Day 18: 1223 / 8724
Day 19: 1677 / 9894
Day 20: 2132 / 10401
Day 21: 2217 / 10331
Day 22: 2030 / 9654
Day 23: 1181 / 5699
Day 24: 950 / 4553
Day 25: 2702 / 12192
Day 26: 1597 / 7939
Day 27: 1408 / 7022
Day 28: 1439 / 6932
Day 29: 1388 / 6386
Day 30: 626 / 2742
Day 31: 587 / 2412


Result:
After update from
asterisk16-core-1.6.2.18.2-1_centos5.x86_64
to
asterisk16-core-1.6.2.19-1_centos5.x86_64
Astertisk get this bug

Dahdi drivers in linux does not updated at "Jul"

Find diff beetwen asterisk16-core-1.6.2.18.2-1_centos5.x86_64 and to
asterisk16-core-1.6.2.19-1_centos5.x86_64 and you find bug i think :)





By: Badalian Vyacheslav (slavon) 2011-12-06 18:43:59.861-0600

Yes - is it (maybe)! ChangeLog-1.6.2.19

All Bugs in dahdi changed:

2011-04-04 16:00 +0000 [r312574]  Richard Mudgett <rmudgett@digium.com>

* channels/chan_dahdi.c, /, configure,
 include/asterisk/autoconfig.h.in, configure.ac: 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 #18313) Reported by: destiny6628 Tested by:
 rmudgett JIRA SWP-2620 (closes issue #18231) Reported by:
 destiny6628 Tested by: rmudgett JIRA SWP-2924 (closes issue
 #18488) 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)
 ........



2011-04-11 15:32 +0000 [r313189]  Richard Mudgett <rmudgett@digium.com>

* channels/chan_dahdi.c, /: Merged revisions 313188 via svnmerge
 from https://origsvn.digium.com/svn/asterisk/branches/1.4
 ........ r313188 | rmudgett | 2011-04-11 10:27:52 -0500 (Mon, 11
 Apr 2011) | 25 lines Stuck channel using FEATD_MF if caller hangs
 up at the right time. The cause was actually a caller hanging up
 just at the end of the Feature Group D DTMF tones that setup the
 call. The reason for this is a "guard timer" that's implemented
 using ast_safe_sleep(100). If the caller happens to hang up AFTER
 the final tone of the DTMF string but BEFORE the end of that
 ast_safe_sleep(), then ast_safe_sleep() will return non-zero.
 This causes the code to bounce to the end of ss_thread(), but it
 does NOT tear down the call properly. This should be a rare
 occurrence because the caller has to hang up at EXACTLY the right
 time. Nonetheless, it was happening quite regularly on the
 reporter's system. It's not easily reproducible, unless you
 purposely increase the guard-time to 2000 or more. Once you do
 that, you can reproduce it every time by watching the DTMF debug
 and hanging up just as it ends. Simply add an ast_hangup() before
 goto quit. (closes issue #15671) Reported by: jcromes Patches:
 issue15671.patch uploaded by pabelanger (license 224) Tested by:
 jcromes ........

* channels/chan_dahdi.c: fixes reload Chan_dahdi memory leak caused
 by variables chan_dahdi reloading with variables set via setvar
 in chan_dahdi.conf would stay in the dahdi_pvt structs for
 individual channels (causing them to just continue adding the new
 ones to the list) and also there was a memory leak causes by the
 conf objects. This patch resolves both of these by using
 ast_variables_destroy during the loading process. (closes issue
 #17450) Reported by: nahuelgreco Patches: patch.diff uploaded by
 jrose (license 1225) Tested by: tilghman, jrose Review:
 https://reviewboard.asterisk.org/r/1170/

* channels/chan_dahdi.c: fixing stupid mistake with putting code
 before variable declaration ........ Merged revisions 313433 via
 svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ........
 r313432 | jrose | 2011-04-12 13:12:29 -0500 (Tue, 12 Apr 2011) |
 14 lines reload Chan_dahdi memory leak caused by variables
 chan_dahdi reloading with variables set via setvar in
 chan_dahdi.conf would stay in the dahdi_pvt structs for
 individual channels (causing them to just continue adding the new
 ones to the list) and also there was a memory leak causes by the
 conf objects. This patch resolves both of these by using
 ast_variables_destroy during the loading process. (closes issue
 #17450) Reported by: nahuelgreco Patches: patch.diff uploaded by
 jrose (license 1225) Tested by: tilghman, jrose Review:
 https://reviewboard.asterisk.org/r/1170/ ........ ........

* channels/chan_dahdi.c: white space change ........ reload
 Chan_dahdi memory leak caused by variables chan_dahdi reloading
 with variables set via setvar in chan_dahdi.conf would stay in
 the dahdi_pvt structs for individual channels (causing them to
 just continue adding the new ones to the list) and also there was
 a memory leak causes by the conf objects. This patch resolves
 both of these by using ast_variables_destroy during the loading
 process. (closes issue #17450) Reported by: nahuelgreco Patches:
 patch.diff uploaded by jrose (license 1225) Tested by: tilghman,
 jrose Review: https://reviewboard.asterisk.org/r/1170/ ........
By: Badalian Vyacheslav (slavon) 2011-12-07 06:52:00.527-0600

Deleted post becouse wrong :)

Now (today) have one 44 cause code.
But we have 4xE1 (120 Connection lines) and use abount 15-30 CL... 1-10 44 cause codes per day is also bug i think. We all time have free CL!
By: Shaun Ruffell (sruffell) 2011-12-07 12:22:54.249-0600

I'm a little confused still. But it sounds like you're back to where you were initially before upgrading in Month 7?
By: Badalian Vyacheslav (slavon) 2011-12-08 03:52:09.154-0600

Again:
After update from
asterisk16-core-1.6.2.18.2-1_centos5.x86_64
to
asterisk16-core-1.6.2.19-1_centos5.x86_64
Astertisk get this bug

Number of 44 cause codes increased hundreds of times

Day of change (Day: count 44 cause codes / calls total)
Day 4: 4 / 8499 // version asterisk16-core-1.6.2.18.2-1_centos5.x86_64
Day 5: 126 / 8639 // version asterisk16-core-1.6.2.19-1_centos5.x86_64
Day 6: 270 / 8941 // version asterisk16-core-1.6.2.19-1_centos5.x86_64

Yes. I back to ver 1.6.2.17.3 and 44 cause codes is go out, but i think your old code also have small bug becouse * send 44 cause codes sometimes (1-5 times in day), but all time we have free Connection Lines.

Statistics on December (Day: count 44 cause codes / calls total):
Day 1: 580 / 6786
Day 2: 1521 / 6460
Day 3: 828 / 2829
Day 4: 565 / 1904
Day 5: 1282 / 5648
Day 6: 939 / 4996
Day 7: 2 / 4440 // go to 1.6.2.17.3
Day 8: 2 / 2237


By: Richard Mudgett (rmudgett) 2011-12-08 09:40:45.869-0600

Cause 44 is also an indication of call collisions.

Do you have it setup so that each end picks channels from the opposite end of the channel range?

i.e. One side picks channels starting with 1 and the other side picks channels starting with 24/30.
By: Badalian Vyacheslav (slavon) 2011-12-09 05:03:14.634-0600

PBX have 128xE1... to * going only 4... all other E1 go to other PBX.
Not anyone 44 cause codes on other channels (in 112xE1).
No side settting on any PBX, all PBX get status of channels normal and don't try call to used channel.
I think you have one bug (small count 44 cause codes) before 1.6.2.19 and get regression of bug in 1.6.2.19.
PBX can't send call to channels that used becouse its see all used channels.
By: Badalian Vyacheslav (slavon) 2011-12-13 07:49:46.550-0600

Any updates?
By: Richard Mudgett (rmudgett) 2011-12-13 11:09:28.238-0600

As I stated earlier, cause 44 is also an indication of call collisions.
Call collisions are normal and can be minimized by Asterisk and the PBX
picking channels from opposite ends of the available channel range.

From Asterisk v1.8 code:
{noformat}
Dial(DAHDI/pseudo[/extension[/options]])
Dial(DAHDI/<channel#>[c|r<cadance#>|d][/extension[/options]])
Dial(DAHDI/<subdir>!<channel#>[c|r<cadance#>|d][/extension[/options]])
Dial(DAHDI/i<span>[/extension[/options]])
Dial(DAHDI/[i<span>-](g|G|r|R)<group#(0-63)>[c|r<cadance#>|d][/extension[/options]])

i - ISDN span channel restriction.
   Used by CC to ensure that the CC recall goes out the same span.
   Also to make ISDN channel names dialable when the sequence number
   is stripped off.  (Used by DTMF attended transfer feature.)

g - channel group allocation search forward
G - channel group allocation search backward
r - channel group allocation round robin search forward
R - channel group allocation round robin search backward

c - Wait for DTMF digit to confirm answer
r<cadance#> - Set distintive ring cadance number
d - Force bearer capability for ISDN/SS7 call to digital.
{noformat}


A "pri set debug on span x" debug output is needed to see what sequence of
events could be causing wedged channels.  The cause 44 is a symptom of the
problem and not the cause.  When you capture a call clearing with cause
44, you need to find out how the previous call using that channel ended.

For Asterisk pre-v1.8, it is known that using the dialplan Hangup()
application with these cause codes will wedge the channel:
PRI_CAUSE_NORMAL_CIRCUIT_CONGESTION(34)
PRI_CAUSE_REQUESTED_CHAN_UNAVAIL(44)
PRI_CAUSE_IDENTIFIED_CHANNEL_NOTEXIST(82)
PRI_CAUSE_UNALLOCATED(1)
From libpri v1.4.12 q931.c:__q931_hangup() line 6604.


In addition, per the Asterisk maintenance timeline page at
http://www.asterisk.org/asterisk-versions maintenance (bug) support for
the 1.4 and 1.6.x branches has ended.  For continued maintenance support
please move to the 1.8 branch which is a long term support (LTS) branch.
For more information about branch support, please see
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions.  After
testing with Asterisk 1.8, if you find this problem has not been resolved,
please open a new issue against Asterisk 1.8.

By: Badalian Vyacheslav (slavon) 2011-12-15 08:59:55.149-0600

Our going to 1.8 is blocked becouse have one posted bug in sip... after fix it we go to 1.8
By: Shaun Ruffell (sruffell) 2011-12-15 12:02:43.389-0600

Putting this issue in Waiting for feedback to hear about after moving to 1.8.
By: Shaun Ruffell (sruffell) 2012-04-04 17:00:09.672-0500

Badalian, any update on this? Have you been able to update to asterisk-18?
By: Badalian Vyacheslav (slavon) 2012-04-05 04:18:14.308-0500

yes. we go to 1.8. have other bugs, but this is done. thanks
By: Shaun Ruffell (sruffell) 2012-04-05 10:45:32.368-0500

Ok, thanks. Closing this one out.