"apply configuration changes" drops calls on E1 card but CLI reload does not

gkrawiec · January 29, 2011, 1:47am

Hi, I have two E1 cards with 2 different telecom providers. Whenever i make a change on freepbx and then click on Apply Configuration Changes, all calls on one of the 2 cards (both same Rhino model) get dropped.
A few seconds after the reload of everything, on the CLI I can see something like

– B-channel 0/19 restarted on span 3

once for each channel.

I called rhino and they told me this should not be happening and to try with a CLI reload. So I did. With this command the E1 span stays up through the reload.
This sounds like freepbx reload is restarting something thats causing this.
whats weird is it only happens on one of the cards, and both are configured exactly the same.
is this a bug?
any suggestions? this puts a serious dent on me making changes to configs during business hours…any ideas?
thanks,
-gk

veryxcit · April 18, 2011, 8:57pm

I am having the same issue, with a Rhino T1E1 card. When hitting Apply Settings (essentially reloading everything), one of the last things that pop in the CLI is that the B-Channels are getting reset. Which, if it were just one of the regular “resetinterval” resets, and all active calls would be left alone, it wouldn’t be an issue.

As a sidenote, this same system had a SIP trunk before the DAHDI trunk, and on “apply config” it didn’t react the same, all active calls were left alone.

I am on FreePBX 2.9 (latest) and Asterisk 1.6.2.17.2

gkrawiec · January 30, 2011, 7:06pm

Philippe,
what do you mean with “open up a connection to the manager (you can do that with telnet) and issue a reload and/or module reload” ?
What is “the manager”?
What I did was login to the pbx using SSH and then executing
asterisk -rvvvv
from there I first tried
reload
and it did not cause a E1 card restart
and then i tried
modulde reload
which didnt cause a card restart either.
Finally, while still monitoring the CLI I clicked on “apply config” from the browser and logged the CLI. This is where the restart happened.
If its not this that you are referring to, then please explain to me what “the manager” is and how to log on to it.
As far as the next tests go, i dont know PHP, i know the basics of progamming, but i am definitely not good at it. I will happily test all this but i would need you to be a bit more specific, as far as which files I should look into, where are they located and which section of the code I should concentrate on.
thanks!
-gk

plindheimer · January 30, 2011, 9:19pm

the manager is the Asterisk Manager Interface.

That is what FreePBX uses to communicate inside of Asterisk.

My point is that we are also just doing one of those two commands (depending on your Asterisk version). But, we of course do other things.

To properly test your system to see if there is an Asterisk issue, you need two do a reload through the CLI as you described, then you need to do a reload through the manager, doing NOTHING except the reload so it is an apples to apples comparison.

We do other stuff, re-generate the configurations which of course affects the time stamps (which could remotely be related), we do an moh reload, we run custom scripts if they are configured, etc. You want to NOT do any of that so you can isolate the issue.

You can check the web for information on how to use telnet to connect to the manager, and the format to use to send it commands like this. You can also comment out ALL of the code in FreePBX (around where I put the above patch but extend it) so that the ONLY thing we do is the module reload command, since that would achieve the same thing.

gkrawiec · January 30, 2011, 3:10pm

Philippe, I just tried 3 reloads.

from CLI using command “reload”
from CLI using command “module reload”
from freepbx pressing the “apply configuration changes now” (after pressing submit on an extension having done no changes to it)

the first 2 caused no E1 restart, the last one from freepbx did.
I have the 3 reloads logged, would you like to see them?

thanks,
-gk

plindheimer · January 30, 2011, 3:59pm

gk,

no I don’t need to see them, I believe you.

The ultimate test would be to open up a connection to the manager (you can do that with telnet) and issue a reload and/or module reload (depending on your version of Asterisk). (Or write a super simple application that does that for you). That gets rid of all other possible relics that may be going on when retrieve_conf runs. If it drops calls in that case, then you need to report a bug to Asterisk. If not, then you would need to start instrumenting our code taking out chunks of what we do until you isolate what change keeps it from dropping.

(For example, you can go into the code whee it calls retrieve_conf, which updates the configuration files, and comment out the call and then apply configuration changes so it doesn’t do much more then a reload. You may have to dig a lot deeper then that depending on what you find though.

an example of the above:

Index: functions.inc.php
===================================================================
--- functions.inc.php	(revision 11275)
+++ functions.inc.php	(working copy)
@@ -1550,6 +1550,7 @@
 		}
 	}
 	
+  /*
 	$retrieve = $amp_conf['AMPBIN'].'/retrieve_conf 2>&1';
 	//exec($retrieve.'&>'.$asterisk_conf['astlogdir'].'/freepbx-retrieve.log', $output, $exit_val);
 	exec($retrieve, $output, $exit_val);
@@ -1564,6 +1565,7 @@
 		$notify->add_critical('freepbx','RCONFFAIL', _("retrieve_conf failed, config not applied"), $return['message']);
 		return $return;
 	}
+   */
 	
 	if (!isset($astman) || !$astman) {
 		$return['status'] = false;

You can not the other things that are done in there as well which could have an affect, including configurable scripts that could be customized on your system that you may also want to comment out or check if you have any…

plindheimer · January 29, 2011, 2:56am

Assuming you have not made any configuration changes (e.g. file configurations) then the reloads should be conceptually identical, and this could be an issue with Asterisk.

FreePBX does a reload through the AMI which so the way it is triggered differs from doing it in the CLI.

Here is the code:
[php]

<?php //reload asterisk if (version_compare($version,'1.4','lt')) { $astman->send_request('Command', array('Command'=>'reload')); } else { $astman->send_request('Command', array('Command'=>'module reload')); } [/php] So assuming version 1.4 or above, we are just executing a "module reload" command through the manager, which is the same as you would do in the CLI. If the configuration is unchanged between multiple presses of the reload, then there may be an issue with Asterisk.

ntg · May 29, 2011, 3:21pm

Just installed a Xorcom XR2000:
Elastix 1.6.2-27, Asterisk 1.4.36, FreePBX 2.8.

CLI reload does not drop T1 calls. “Apply Configuration Changes” in GUI does.

Is there a fix?

SkykingOH · May 29, 2011, 3:42pm

Philippe is trying to help you debug this. It is not normal behavior.

Perform the telnet to manager test he suggested and post the results.

ntg · May 30, 2011, 7:01am

found this post:
http://www.freepbx.org/forum/freepbx/general-help/when-applying-settings-in-freepbx-and-b-channels-get-reset-i-drop-all-cal

Turns out the it is the Dahdi Module causing the span 1 reset.

I disabled this module, initiated a call, 'apply configuration changes", no more dropped calls.

izrunas · June 6, 2011, 2:41am

Hi,

I have experienced the same problem reports. Any time I “apply configuration changes” via the orange bar, all calls on DAHDI trunks are disconnected / dropped.

The solution was simply to “disable” the DAHDI module in FreePBX and the problem stopped immediately. We tried re-enabling it and the behavior returned. So, we’ll be leaving the DAHDI module disabled until it is fixed.

Thanks,
Eriks

PS: We’re running the newest possible FreePBX 2.9, Elastix 2.0.4 with Asterisk 1.8.