As i was very interested to see the GUI enhancements of FreePBX 2.8, i’ve installed the beta. (Version 2.8 beta upgrade module did not advertise about module incompatibilities).
Previously, updating to a new version had never triged major problems. But here, unfortunately, this version completely broke the Custom contexts module.
I thought that the major concern of the FreePBX team was to not break modules presents in the FreePBX repository.
Advanced routing module has been fully broken as well by version 2.8.
My question is simply : how to come back to version 2.7 ?
I think that FreePBX 2.7 is now mature and should stop development, to concentrate about version 3.0 / Freeswitch development. FreePBX without custom contexts is simply not usable in a lot of situations.
Philippe already warned us in a previous thread that 2.8 will break Custom-Contexts in particular due to drastic changes to routing in the core of FreePBX.
Remember that the modules in the 3rd party respository are unsupported by FreePBX. If a module is not maintained or does not work with FreePBX, I’m sure it will be pulled out of the repository. Currently, Custom-Contexts is orphaned and I’m trying to spearhead its revival. I am not a programmer and can do little more than facilitate and inform. My interest in it is purely selfish as I use the module myself. I’m sure there are many who use the module and I hope they will “put their money where there mouth is” when we need to get the repairs done.
If the community wants to pursue having this unsupported module brought forward, it will require several thousand dollars and a programmer just to make changes to make it compliant with 2.8. Philippe will be contacting some people to get estimates. There will be a donation link posted once a cost to fix it is known.
If the community wants custom-contexts to become a “supported” module, I shudder to think what the expense might be. I also think additional unsupported 3rd party modules may also require a lot of modificaiton for 2.8 and beyond.
Personally, I’m probably going to stick with 2.7 until FreeSwitch and FreePBX 3.0 become a viable alternative. Of course, 3.0 will be much less robust in features than current FreePBX releases because of the total reengineering of the internal plumbing. There is so much more built into the core of FreeSwitch to allow a multitude of features we can’t have in Asterisk. The kind of enrichment of product that happened with the original FreePBX will no doubt bloom as people adopt 3.0 and the community begins giving back.
Have you done anything serious with FreeSWITCH yet that brings you to that conclusion?
I’ve used both FreeSWITCH and Asterisk in big projects. They are both great engines and they also both have their issues and limitations.
The great thing about v3 is that it supports both engines and will therefore give users a choice as to which engine fits their bill. As it develops you will find some features and capabilities are supported on one engine or another and you’ll be able to choose which one fits the bill for any give application.
In the meantime, 2.x will continue to push forward as 3.x evolves. We also hope to see a lot of the features on 2.x quickly ported to 3.x but it’s likely that Asterisk will pull forward pretty quickly due to its feature rich maturity though hopefully FreeSWITCH will make strides as well to move forward quickly.
As far as Custom Contexts, as others have pointed out, I’ve tried to communicate pretty clearly that there would be issues with it until it gets ported. Having looked at it a bit the other day, I’m hoping that the migration to 2.8 won’t be quite as bad as I was thinking it might be, though it will still be reasonably involved.
Bill - if that is all you are doing, you can doing the following. For the route(s) that you don’t want certain extensions to have access to, just make a unique route that has a ‘bogus’ trunk on it and place it before the ‘standard route’ of the same. On that ‘bogus’ route, simply add the CID of the extensions you don’t want to be able to call.
Here’s an example:
where the 011XX. is the match pattern and the 7XX is the CallerID and will catch all extensions in the 7XX range to use that route, which goes to a bogus trunk.
The next route would simply be:
which would allow any other extensions dialing international that does not meet the above pattern to call out.
I must be missing something. It’s 3:30 in the morning and was awakened by the weather radio alarm…Severe Thunderstorm w/quarter size hail and 60 mph winds. Fortunately it passed east of me!..
Anyway…I’m unclear of how to set up the bogus routes that you mention above.
Where is the 011XX. 7XX placed. In my test case it’s 1. 1010 which would restrict LD access to extension 1010, but when I place the 1010 behind the 1. entry in the outbound route and trunk dial pattern boxes, I get an Invalid dial pattern error.
Maybe this will get clearer after the sun comes up and I’ve had a couple of cups of coffee, but for now the storm has passed and I’m going back to bed!
olivier1010, open a shell to your pbx, change directory to /var/lib/asterisk/backups, in that directory you will see a couple of other directories, those are you backups. Go down to the newest created directory and look at the file in there, it should look something like 20091227.05.17.04.tar.gz (my backup done 12/27/09).
Now you have two choices, one is to do a backup from 2.8 so it will create a new directory in /var/lib/asterisk/backups, copy your previously backup into that directory and do a restore, that should bring you back to 2.7.
If that fails (depending on what you backed up) you could extract the asterisk.sql from the backup, install 2.7 and dump back the asterisk.sql into mysql and you should be where you were before the upgrade.
You then have to save each extension to recreate the astdb entries.
here is an example setup where extensions 7XX does not get international access but gets everything else as the rest. I will format it here in the “old” style since it’s hard to type text boxes in the forum
Route 1: E911
Route 2: Local-LongDistance
Route 3: Restrict-International
Route 4: International
Now for trunks, Route 3 should get a bugus trunk. Make a custom trunk, or a non-existent ZAP group, or something similar and assign it to Route 3.
Note, I mentioned old style, if this really was 2.7, the Restrict-International would actually be:
However, with the new text boxes, it is smart enough that you don’t need the “_” (and will complain) as it knows to put it there for anything that is a pattern vs. a number.
In any event, the first part (011XX.) goes in the match pattern as usual, the second part (7XX) goes in the CallerID and will match any extension in the 700 range).