we have a multi tennent/trunk pbx (with custom contexts module).
we can route extensions to specific trunks using custom contexts but when using call forwarding it seems to default to the first trunk in the list of trunks.
we want call forwarding from an extension to be routed through the trunk as specified in the context for that extension.
how do we do this?
Well you could fund the dev team to make Freepbx multi tennent, the custom contexts module does not give you a multi tennent box…far from it, that will take a few bucks tossed at the dev team (and some time)
Or I would guess you need to stop using the GUI and get to writing out the custom dail plan.
Thank you for correcting my description of the box we are running.
Your suggestion of tossing a few bucks at the dev team is something I’ve passed on to the owner of this project.
If I’ve got to get my hands dirty under the hood then so be it. I would like to point out that I’m not a programmer but can generally follow well structured instructions in English (as opposed to jargon) that make no assumptions as to my abilities. No disrespect intended to any of the contributers here.
Does anyone have, or aware of, an example of a custom dial plan that would help me achieve the goal outlined in the above post?
Look at this how-to:
How to give a particular extension different or restricted trunk access for outgoing calls
Scroll down to the sub-heading “Different Routes for Different Extensions” - there’s now a few paragraphs that addresses the call-forwarding issue, though probably not in as elegant a manner as you might like. Note this was a little buggy when I first posted it, so if you looked at it before 3:15 P.M. eastern (U.S.) time today you may want to go back and look again, as there have been several edits.
Much of what happens in FreePBX is based on the originating extension number, which is stored in the system variable CALLERID(num). The problem (for you) is that on a forwarded call, I am pretty sure that CALLERID(num) retains the original number - that’s so that whoever receives the forwarded call gets the correct originator caller ID, assuming the trunk supports it (not all providers will allow you to set the outgoing caller ID, in order to prevent Caller ID spoofing, but if the trunk allows it the party that gets the forwarded call will get the original Caller ID - I think).
I know this is true if you have a follow-me set up and it goes to a different extension than the one originally called - it will get the true originating phone number, not the number of the extension that was called. The Custom Contexts module has no way to deal with this. The method described in the above document does, sort of (as of today), but it’s kind of an ugly hack. I don’t know if the new routepermissions module that Rob Thomas is working on will address this at all.
Many thanks for your input wiseoldowl. I will go through this and report back as to my success (or otherwise).
If anyone else has any ideas then please feel free to post them and I will come back to you.
I’ve completely rewritten the part about Call Forwarding about three times since this morning… I finally figured out that it was just easier to pull the dialplan contexts from extensions_additional.conf and make the modifications myself and put the modified contexts on the page, than to try and do a “change this line, change that line” type of thing - I quickly discovered that to really do it right there were more than just a couple of lines that had to be tweaked. Biggest problem was getting it to store the forwarding number with restriction prefix in the database but NOT say the restriction code to the user (as it would almost certainly confuse him/her). In one way it’s trival code, but if you only try to do this sort of thing about twice a year you tend to miss things that only become obvious AFTER you’ve published it (at least that seems to be how it always works with me - I can go over something a dozen times and not see a thing wrong with it, but I can almost guarantee that ten minutes after I commit it to the page I’ll think of some condition under which it will fail).
Anyway I THINK it’s okay now and I also HOPE the instructions are easier to follow - it’s a much longer cut-and-paste, but no “copy this replace that.” It might also break (at least the Call Forwarding part) next time there’s a FreePBX update, but then again maybe Rob Thomas’ module will obliterate the need for this sort of thing anyway.
After I’d worked out how to edit the modules, I expanded your code slightly to increase the number of custom-trunk-selector options and it appears to be working on a test box I set up. Thank you.
The next thing for me to do is set up the live box, which I ALWAYS back-up before making changes, and see it working in the ‘real’ world.
Thanks again for your input, wiseoldowl, a great work around. I’ll keep you updated.