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
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
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
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.
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.
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…
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.
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.