Summary:	DAHLIN-00256: ISDN BRI channels hung or down when not in use (particular at night when there is no one in office)
Reporter:	Christopher Debono (ibisgroup)	Labels:
Date Opened:	2011-09-22 01:23:28	Date Closed:	2011-10-17 11:20:58
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	dahdi (the module)
Versions:	2.5.0	Frequency of Occurrence	Frequent
Related Issues:
Environment:	Centos 5 running 2.6.18-194.32.1.el5, asterisk 1.8.6, libpri-1.4.12 & dahdi 2.5.0.1	Attachments:
Description:	The system has been installed and running well for over 6 months but last week, something happened and every morning the customer calls me saying they are without lines. If I restart asterisk, or even do dahdi restart, the channels start working again. Previously I was running 1.6.18 with dahdi 2.4 so I upgraded to the latest but the problem still persisted. I am nearly sure that something from the telco side changed and it is causing the channels to either timeout or get stuck somehow. The only errors I see in the console are [Sep 22 07:55:24] NOTICE[4395]: chan_dahdi.c:3042 my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of span 2 [Sep 22 07:55:52] NOTICE[4396]: chan_dahdi.c:3042 my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of span 3 [Sep 22 07:55:55] NOTICE[4397]: chan_dahdi.c:3042 my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of span 4 Is there anything else I might give you in order to help you to find this bug? Regards Chris
Comments:	By: Shaun Ruffell (sruffell) 2011-09-22 12:34:49.796-0500 Hi Chris, I'm not sure this is a bug. It sounds like it's a configuration / user support issue?  If you agree (as opposed to an error in the drivers) perhaps you want to shoot an email to asterisk-users? By: Christopher Debono (ibisgroup) 2011-09-22 14:15:55.364-0500 It could be, the funny thing is that it worked for 6 months without any problem and I am sure nobody touched the machine because they barely know where the power button is. I am suspecting it is more of a telco issue which changed some parameters. Today I added resetinterval parameter in chan_dahdi.conf to 3600 and will tell you if it made an effect Regards Chris By: Shaun Ruffell (sruffell) 2011-09-22 14:27:37.142-0500 Ok, I'll leave this open for a little while here while you collect more information. By: Christopher Debono (ibisgroup) 2011-09-24 01:35:45.394-0500 Hi Unfortunately the resetinterval=3600 did not work so I set it to 60 and still it did not make any difference. However I noticed by co-incidence that if I do asterisk -r and leave the shell connected to asterisk, it stays ok and isdn channels stay up. I tested it till this morning and it stayed ok. I shall keep it another couple of days open and see if it fixes the issue. if you would like to email me in private, I can give you root access to the server if you would like to test out something Regards chris By: Shaun Ruffell (sruffell) 2011-09-25 17:44:21.766-0500 I'm still thinking this is a configuration problem and not a bug and does not belong in the bug tracker. However, is your provider now bringing layer1 and/or layer 2 down at night?  What BRI card are you using? By: Christopher Debono (ibisgroup) 2011-09-26 00:02:26.581-0500 I asked the provider but they said no. Today I confirmed, the channels remained up with the console open. It has been 2 days now without dropping. The card that I am using is the Digium B410 running dahdi 2.5.1 and asterisk 1.8.6 (compiled from source). If you would like to close this issue, go ahead. Regards Chris By: Christopher Debono (ibisgroup) 2011-09-28 15:54:38.600-0500 Hi Today it happened again. I spoke to the provider and we changed the signalling to point to point instead of point to multipoint so like that the d channels dont go down everytime but still it happened again. my dahdi-channels.conf looks like this ; Span 2: B4/0/1 "B4XXP (PCI) Card 0 Span 1" (MASTER) AMI/CCS group=0,12 context=from-pstn switchtype = euroisdn ;signalling = bri_cpe_ptmp signalling = bri_cpe channel => 5-6 context = default group = 63 resetinterval=60 ; Span 3: B4/0/2 "B4XXP (PCI) Card 0 Span 2" AMI/CCS group=0,13 context=from-pstn switchtype = euroisdn ;signalling = bri_cpe_ptmp signalling = bri_cpe channel => 8-9 context = default group = 63 resetinterval=60 ; Span 4: B4/0/3 "B4XXP (PCI) Card 0 Span 3" AMI/CCS group=0,14 context=from-pstn switchtype = euroisdn ;signalling = bri_cpe_ptmp signalling = bri_cpe channel => 11-12 context = default group = 63 resetinterval=60 ; Span 5: B4/0/4 "B4XXP (PCI) Card 0 Span 4" AMI/CCS RED group=0,15 context=from-pstn switchtype = euroisdn ;signalling = bri_cpe_ptmp signalling = bri_cpe channel => 14-15 context = default group = 63 resetinterval=60 The only way to get it working in the morning is by doing dahdi restart in asterisk or else stopping and restarting asterisk. once it gets going, it remains ok till the evening Regards Chris By: Shaun Ruffell (sruffell) 2011-10-17 09:19:45.092-0500 If to clear this condition all you need to do is restart chan_dahdi / asterisk (and not reload the drivers) then odds are this is a chan_dahdi / libpri issue (or still some configuration issue). Unless you say otherwise I'll move this to the ASTERISK project.  I don't see anything in your configuration that jumps out at me as something that should be wrong. By: Christopher Debono (ibisgroup) 2011-10-17 11:15:46.568-0500 Hi Shaun I managed to find the problem and solve it. It seems that the dahdi module in free pbx was causing the issue. I opened a case with digium and by co-incidence, I did a change in free pbx, applied settings and the lines dropped. So as usual I did dahdi restart to bring them up again. But this time, the fault was reproducible and every time I press reload, the lines go down. After investigating further, I noticed that the dahdi module does not cater for BRI channels as there is no point to point signalling in the free pbx so I removed the dahdi module completely and it is rock stable now. I would like to take the opportunity to thank everybody for all the assistance given and hope that this post helps others who might have got stuck like me. Regards Chris By: Shaun Ruffell (sruffell) 2011-10-17 11:20:58.449-0500 Chris, thanks for closing the loop on this one. I'm glad you were able to resolve the issue!