Clearglobalvars=no - Asterisk is still losing the values

I have outbound callerID information saved as global vars…which I use to set the callerid oubound on different extension ranges…

This works fine…however…

I often change these values, through the manager interface.(AMI)
I have clearglobalvars=no, but everytime I do a extensions reload or a dialplan reload… these values get set back to their defaults. This is a problem, because I have a “blacklist” conf file, that get’s added too often, and this sends an extension reload command through AMI. So everytime a user adds to the blacklist…the callerID global variables get set back to the defaults.

Running Asterisk version 1.4.22 on Centos4.7
The was an issue in version 1.2xx according to bugtracks, but it was supposedly fixed…and now it’s back !


If you are changing these regularly I would look at using the ASTDB to store them and then just call them from that. It will mean you can update with no need to reload


That is actually something i’m looking into now…
However, we have other things planned for our asterisk implementation that will rely on other global variables…and I can’t think of any reason this should be happening to begin with.

I’m also concerned about the amount of reads on the astdb, because of our outgoing call volume. I would hate to trade one problem for another…especially since this behaviour is not by design.


How often are you reloading the dialplan.? and as to reads we have servers doing 90000+ mins a day and 200 concurrent calls using the astdb with no issues.


I reload the dialplan everytime a number is added to our blacklist.conf file…so that the number not be able to be called immediatly after being added…

Part of my problem is that my blacklist.conf file is HUGE ! has over 20,000 numbers listed.

exten => _5555555555,1,Hangup()

I would rather fix the issue of globals being erased…which would solve my problems altogether… but if I can’t get it working I may look at storing the blacklist numbers in the astdb and doing a lookup before dial. I’m just concerned about putting load on the server for a astdb lookup every time a number is dialed.

your thoughts ?


Are you serious [quote]it has over 20,000 numbers[/quote]

Then that needs to be in mysql and looked up haing a conf file of 20000 lines is not a good idea.


I know… you’re probably right.

I didn’t have any issues until recently we imported about 5000 more names into the file. Now I think we may have reached the limit here.

I think our postings got a bit off-topic though the two issues are intertwined…I can’t find anything to explain why the global vars are being erased. For testing purposes I unlinked the #include blacklist.conf, to see if it had anything to do with it… still no fun here.

anyway…i’m not sure this can be solved on my end, maybe it truly is a REAL bug with version 1.4.22, as opposed to some configuration error on my part (which I doubt because i’m good :smile:, and hopefully i’m not the only one with this problem so it will get some attention.

Which would you say is better …MySQL, or the AstDB ??
I thought about MySQL, except for the fact that it’s just one more server process running, meanwhile the Astdb is being used anyway.

Is there a way for me to connect to the astdb remotely ?..or just the MySQL ?


I think they may be linked. As to astdb or mysql with that number I would go with mysql.

You could even use curl to call another server via http. having a call go through 20000 lines must be slowing things down somewhat.


No, the calls do not slow down.
When you do an extensions reload or dialplan reload… it loads the configuration into asterisk from the static files…so the dial is placed instantly, but the actual reload of the dialplan now takes up to 10 seconds because of the blacklist.conf file,…during which time you can see lot’s of other things being re-registered along with the blacklist file’s contents…

I’m wondering now… is this a limitation of Asterisk, as to how many configuration lines you can have in a static dialplan ?

My blacklist solution works fine and is easy… IF you can keep the list below 10k numbers I guess… though it’s not realistic for a telemarketing company like us.

Back to the drawing board…
MySQL it is.

Thanks for your help.

NOTE: This still hasn’t solved the issue of Globals being removed on reload, with clearglobalvars=no

I TESTED, taking out the blacklist altogether,…and when a global variable is changed from the AMI or CLI, it still get’s reset after extensions reload or dialplan reload. The vars won’t stick !.. :imp:

Hi what version did this work for you ?

and if you set a global that isnt defined in extensions.conf are they still cleared ? also are you using a ael file ?


I’m not using ael at all.

This previously worked in version 1.4.17 - After upgrade to 1.4.22 it no longer works.


It may be worth doing a diff of pbx_config.c between the two versions.

also comment out the clearglobalvars line as it defaults to no. just to see what happens


I tried commenting it out,…was the first thing I tried.

I’m going to do a diff as you suggested.


Ok, Nothing in the release notes to say anything has changed, there is a few bugs in the bugtracker but they are old. It maybe that old code has sneaked in.


So,…i’m abondoning, the clearglobalvars problem.

However, I did manage to get sql up and running, with a working realtime blacklist table.

Thanks for the suggestion.

All… is now good.