Custom-Contexts Module Upgrade - Updated Info

I know “OPEN SOURCE” means free software but nothing is really free in business. I would urge all users to contribute to the community from time to time, e.g. FreePBX, trixbox, a2billing as all these projects are important to VoIP users and money does help the development process. Just because a project is open source does not mean the development cycle did not cost anything.

Our goal of $4,000 has been met. Many thanks to all who dug deep to give what they could. Stay tuned for more information on how the module upgrade is going.

Again, thanks to both individuals and resellers who put up the funding to keep this module alive!

A programmer is currently working on the rewrite of the custom-contexts module. The new module will not be backwards compatible with 2.7 and below. The existing v0.3.6 module will work for those versions of FreePBX.

I’m told to expect an alpha version of the rewrite for select people to begin testing (with FreePBX 2.8) as early as sometime next week. I’m happy to hear this since I can’t do serious testing of 2.8 under load until I can utilize the new custom-contexts module.

So in short, work has begun on the upgrade and we should see preliminary results shortly. With luck, this module will be completed in time for an official release of FreePBX 2.8.

Many thanks to Philippe for coordinating a programmer to get this done!

I am sorry I have been out of this… As I have mentioned before to those involved, I simply haven’t had time. I understand it may be rude of me to do the work now.

That said, I mistakenly pulled up this link http://geekhut.org/2010/02/freepbx-custom-context-module-delegating-outbound-routes/ on the first page of a Google search yesterday, and got the impression from there that it was worth the effort to make time, if people are still finding it that useful.

It took me longer to get a virtual machine set up and install FreePBX 2.8 than to fix the module to bring it up to date. I understand that there was a bounty collected, that I passed on the offer, and that someone else apparently is already working on a rewrite. I don’t mean to step on anyone’s toes (or collect someone else’s bounty), and I am sure that the rewrite (for $4000!!) will likely be far superior to the original module. This was partly to patch it for the interim just to fix what was broken (I didn’t even integrate into the TimeGroups module even though that was the purpose of the TimeGroups module originally), and partly because I guess I bumped into one too many people upset that it will soon be gone.

For now, I updated the source at contributed_modules/modules/customcontexts/ (r9817) and I will let phillipe package a new release if he approves.

naftali5

P.S. I should have made the time a long time ago to look at it. I was told that outbound routing was changed quite drastically, which would break my module, but little did I figure that it actually was changed to remove a serious flaw in design which had cost me dozens of extra lines of code originally. Most of the change was deleting now obsolete code!

Nafteli5 -

I’m happy you have returned to the foreground and looked at the module. Philippe has been handling the rewrite and I’m not sure where it stands now. The update of the module is only a temporary fix for the new architecture of FreePBX 2.8 and will still need to be ported to the FreePBX v3 framework as that version of the product is finalized and rolled out.

I have been active in the FreePBX, PBXinaFlash, Trixbox and Elastix forums and there remains terrific demand for the Custom-Contexts module. Many consider it a vital part of FreePBX for multi-site installations on a core system. The biggest plus is the ability to route 911 or other calls to the trunk at the particular location.

I hope you are conversing with Philippe to discuss your latest updates with whomever is working on the module.

If you are able to make time, it would be fantastic if you could take the module back “under your wing.” Once the v2.8 updates are done, we need someone to work with the module so it can be integrated into FreePBX v3. Since multi-tenant capability will be more readily programmable in the FreePBX v3 architecture, this module should be able to flourish with more features and flexibility in that framework.

Thanks for the note. I have not had a chance to look at your patched version yet. Philippe had fixed a couple of issues and thus Custom-Contexts v0.3.5 and v0.3.6 were released as updates for FreePBX 2.7 and below.

The community will look forward to hearing from Philippe and you on how this will be worked out.

Just a quick note (and sorry for the delay, I just got off a plane…)

I’ve had Moshe working on the changes and he has been doing such for a couple weeks. I was glad to be able to convince Moshe to do the work as opposed to some random developer somewhere that does nothing otherwise for the FreePBX community. (For those who don’t know, Moshe has donated hundreds of hours (if not thousands) to FreePBX over the last few years and continues to do such now). Moshe was my second choice after Naftali who, as he pointed out above, I had contacted when all of this kicked off but had no time to work on custom context, for pay or free.

Moshe started doing the work a couple weeks ago. He reverted the changes that naftali checked in in preparation for getting the changes he has been working on into the system. I’m guessing that sundown of the Sabath beat him to getting his changes in or they would have been there by now. They should be in later this weekend.

The changes that Moshe has been working on not only include some similar work that Naftali did, but they also include all of the migration code to take you from 2.7 to 2.8, they include some additional work that makes sure the default context sequencing for some of the selections are consistent with the intended default when no priorities are specified (which was not there in the recent check-ins), there are some functions not present in custom context that are being added to help it interact properly with some aspects of the framework. Moshe is also on the hook to follow-up with once this gets out to beta and production making sure that everything works properly and there is quick turn around as issues are identified. There is also work on the module infrastructure. Unlike the ‘core’ modules, the Extended Repository, on the server side, is currently not designed to have different module versions for different FreePBX versions. Since we did not want to break ‘pre-2.8’ systems with the new fixes, this has to also be addressed.

So … you should be seeing this work hitting the system for testing within the next few days, hopefully sooner.

I’ve upgraded my system to FreePBX 2.8 on Asterisk 1.6.2.7 with absolutely no issues. I used the extended repository to update my Custom-Contexts module to the 2.8 version which also upgraded with no issues.

I went to each of my custom contexts and did notice that in the ones where I had used “Deny All Routes” and had selected specific allows, the allows were all turned to “Deny.” I changed the required routes back to “Allow” and all is well.

I will continue testing but it all looks really good right now.

kenn10,

can you file a bug on this migration issue where you had Deny All Routes and then some specific one’s allowed resulting in those denied?

That should be looked into. Thanks.

A couple days ago I pulled the trigger to go to 2.8. Everything seemed to be working fine, until a remote office of ours called to tell me they can’t make any outbound calls. Since I know the people who installed our PBX created a custom context manually for that office, I immediately suspected I knew where to look. I decided to remove all the hard work they had done setting things up manually and instead installed the new custom_contexts module. I recreated the custom context needed and all was well. But on the way I found a couple minor bugs.

I found a couple bugs, or perhaps to be more accurate buglets (actually I would call 1 a bug, and 1 a buglet).

The first buglet, is that ALL OUTBOUND ROUTES is given a priority of 96 which is great. However if you disable that and are selecting specific outbound routes they start at a priority of 50 which is low than most other things including internal extensions. The end result is that internal extensions break. This isn’t really a bug but it seems to me those should be starting at something like 100 say.

The bug, is that if you change the Context of a custom context (not the description), than go and look a the extensions anything that had that context selected is now blank. Presumably if I can change the name, then the name change should carry through everything else (just like if I change the alias).

NSummer -

Thanks for the feedback. Manually entered custom contexts could well be an issue after the upgrade to 2.8 because of the substantial change in the way routing is handled. It isn’t surprising that you encountered a problem. That is the reason the Custom-Contexts module had to be updated.

Please post a bug report in the FreePBX Bug/Feature request section regarding your issue. I’m not sure there are any hours left in the original rewrite for which we collected the bounty, but I’m sure Philippe will at least look at it once a report is posted.

I believe a bug was entered the other day on this.

There is an open question on the ticket system wrt to the priorities. If the behavior is something that worked priornto 2.8 and now has issues then it is a bug and should be fixed as part of the work done. Someone with a pre 2.8 system needs to provide feedback on that ticket.

Concerning the context name change, that behavior remains the same as previously and would be a bit of a hack to try and address.

the final version is in the extended repository.

there was a glitch and it was not showing up but that was reported and corrected this morning. Just use Module Admin to load it from there on 2.8.

A slight issue with the custom-contexts add-on module was found regarding the priority numbering of the outbound routes. I submitted a ticket on this issue and the problem has been resolved. I have tested with FreePBX 2.9 on both Asterisk 1.6.2.17.2 and on Asterisk 1.8.3.2 with success.

A couple of notes:

(1) If you manually changed the priority numbers of items in a custom-context, the upgraded module will not change them. I recommend deleting the context and recreating it unless you made specific modifications for a specialized purpose (or had changed them because you had problems with the module initially.)

(2) Newly created (or recreated) custom-contexts will have the outbound routes numbered in the 1xx priorities which will insure that correctly ordered dial plan execution takes place.

Many thanks to Philippe and the FreePBX team for quickly fixing the issue. Custom-Contexts 2.9.0.0 is now available in the FreePBX extended repository. I encourage users of FreePBX 2.9 who use the module to try it out. It is definitely broken on FreePBX 2.9 prior to this update.

This version simply makes what worked before work on 2.8.

The issue you describe is because you are trying to create a multi-tenant setup on a PBX which is not designed for that.

Although Custom Context can do a lot of things that you might wan to do for a multi-tenant setup, it still comes short in a lot lot of subtle areas of which what you described is one of those areas.

For your specific Directory issue though, you may want to have a look at the 2.8 Directory module, you may be able to get closer to what you want to do with some of it’s flexibility.

I spent some time looking around, and found a way to do it from an old trixbox post related to voicemail stuff, it was easier than I thought it would be. In case anyone else comes looking for a solution, this worked for me in asterisk 1.4: (change Company A context to your appropriate entry and appropriate extension)

Original Code in extensions.conf

[app-directory]
include => app-directory-custom
exten => #,1,Answer
exten => #,n,Wait(1)
exten => #,n,AGI(directory,${DIR-CONTEXT},from-did-direct,${DIRECTORY:0:1}${DIRECTORY_OPTS}o)
exten => #,n,Playback(vm-goodbye)
exten => #,n,Hangup
exten => o,1,Goto(from-internal,${OPERATOR_XTN},1)

; end of [app-directory]

My fix in extensions_override_freepbx.conf

[app-directory]
include => app-directory-custom
exten => #,1,Answer
exten => #,n,ExecIf($[${DIR-CONTEXT} = **Company A context**]|Set|OPERATOR_XTN=399)
exten => #,n,ExecIf($[${DIR-CONTEXT} = **Company B context**]|Set|OPERATOR_XTN=5700)
exten => #,n,Wait(1)
exten => #,n,AGI(directory,${DIR-CONTEXT},from-did-direct,${DIRECTORY:0:1}${DIRECTORY_OPTS}o)
exten => #,n,Playback(vm-goodbye)
exten => #,n,Hangup
exten => o,1,Goto(from-internal,${OPERATOR_XTN},1)

I use the previous version of custom contexts for 3 separate small firms in our building (company A, B & C), all works well, except for 1 issue. All 3 firms use the directory for calls to search by name, and if they don’t know who they are looking for and hit ‘0’, it dumps them to company A’s operator extension, even if they were in company B or C’s directory. Does this version fix that (or have I been using it wrong all along)?

Thanks.

This thread would not be appropriate however an open discussion on FreePBX as a service provider platform and alternatives would be very interesting.

Take care…

dcitelecom,

If creating a new custom context on the pre-2.8 version of custom-context results in a “reasonable” default dialplan choosing “allow all” and doing so in 2.8 is significantly different (e.g. all the outbound routes being inter-mixed with the internal dialplan priorities) then you should file a bug in the trac-er and ask moshe to have a look.

The port to custom-context to 2.8 should be reasonably consistent with the earlier versions and if it is rally this different then I would consider it a bug to be looked at. I suspect is fairly straight forward to address once looked at.

Yes. Thanks. I appreciate your comments and we are always evaluating other platforms. I was going to look at FreeSwitch next but maybe we’ll look now at Kamailio but I don’t want to discuss the advantages of another system over FreePBX in this forum as this would not be fair. I know you do consulting so maybe I’ll contact you about this one day in your professional capacity.

I won’t make any sweeping comments. My only observation is the great lengths that you go to in order to try and make FreePBX conform to something the lead developer admits it is not intended for. I know recreating a system seems like a daunting task.

Kamailio with SIREMIS tames the mystery of SER. It is more flexible than a Nextone switch and almost as good as Sonus ASX.

One of the reasons I am so passionate about this issue is business processes can degrade when the core platform does not support the business mission. I have looked over your website and have an understanding of the offerings, not talking out my a**.

Certainly FreePBX can be used to put together voice products that offer great value to the client.

Philippe was lukewarm to custom contexts because it drives FreePBX further into spaces it was never meant to play in. Custom contexts was meant to fill a feature gap, lack of class of service definitions. It was never designed to create secure dial plans and service offerings.

With your immediate problems solved I would spend the time looking at the next steps in your platform evolution.

As always I am around to comment <>.

A new thread would be in order.