SIP changes made in the gui (ie, add or delete an extention) are not happening in aterisk.
If I run /var/lib/asterisk/bin/retrieve_sip_conf_from_mysql.pl and then a ‘sip reload’ in the asterisk CLI, then it works fine.
This is an ‘unsupported’ configuration I’m sure, but any help or pointers would be appreciated. As always, if I find the answer first, I’ll post it back up here.
Traced to a problem with the paging module, error was being given about a sip header (sorry, didnt write it down, gone from scroll buffer now) so I removed the paging module and restarted asterisk.
That seemed to do it. The bizarre thing is I’ve reinstalled the paging module and the error did not return.
…
While typing this I realised that I’d not added any paging groups so I went ahead and did so and now the problem is back. Changes made in the gui are not being written back to asterisk.
Here’s the output of /var/lib/asterisk/bin/retrieve_conf
[code]Checking for PEAR DB…OK
Checking for PEAR ConsoleGetopt…OK
Checking for /etc/amportal.conf…OK
Bootstrapping /etc/amportal.conf…OK
Parsing /etc/amportal.conf…OK
Parsing /etc/asterisk/asterisk.conf…OK
Connecting to database…OK
Connecting to Asterisk manager interface…OK
Fatal error Class ‘ext_sipaddheader’ not found in /var/www/html/admin/modules/paging/functions.inc.php on line 91[/code]
Yeah, I thought of that as I clicked submit, too late I know.
The thing is, I dont know if it’s the beta of freepbx or the module thats causing the problem? The changelog for the module does mention something about this sip header.
Anyway, if you can move the thread to a more suitable place that’d be great.
Cheers Philipe
it’s the paging module. The short term fix would be to disable paging, hopefully I’ll have the beta out today or tomorrow at the latest, or you can just grab the file I mentioned in the other thread.
there seems to be something broken in the backup restore stuff although I was sure I had it fixed several months ago. The backup tarball has a filed called something like astdb.dump or something similar and there is a function in the AMPBIN directory calls restoreastdb.php that can restore it. The problem is, it was written really badly and expects the file to be in a very specific place that the backup stuff sets up (if you look in the restore script you will see). That script could easily restore all your settings (as it should) if you can get things properly setup, or modify the script so you can just pass in the name of the dump file which you can get out of the backup tarball.
backup is on the list of problematic modules to review again - problem is, it really needs a rewrite…