Custom context -- help needed

as per phillipe’s suggestion, i am opening a fresh thread for assistance with my custom context issue, as a result of upgrading from 2.7 to 2.8.

the original thread is here:

i have the following outbound setup:
trunk1 + route1 serves extension 101
trunk2 + route2 serves extensions 201-203
trunk3 + route3 serves extensions 401-404
all trunks are sip/voip trunks

prior to upgrading from 2.7 to 2.8 everything worked fantastically with no issues. upon upgrading to 2.8, somehow my custom contexts got broken and i am no longer able to dial out from any extensions.

as per phillipe’s troubleshooting suggestions, i can confirm that a context of ‘from-internal’ tagged with extension 101 will, indeed, execute a call. but when i switch that context back to ‘from-route1’, it no longer works.

the specific log message is:
[Sep 29 11:41:19] NOTICE[14758] chan_sip.c: Call from ‘101’ to extension ‘4095551212’ rejected because extension not found.

additionally, as i mentioned in my previous thread, there are now links in my FreePBX 2.8 under the Tools menu that say Custom Extensions and Custom Destinations. there are no entries in either of these. not sure if there should be or not.

lastly, i seem to remember once-upon-a-time that there was a module called ‘custom contexts’, but perhaps it was ‘custom extensions’. regardless, i cannot locate a module called ‘custom contexts’ or anything related to ‘contexts’.

just to reiterate:
this worked GREAT in 2.7 but no longer works in 2.8. i have made NO changes to my config from 2.7 before upgrading to 2.8. but apparently this isn’t related to the upgrade and is the result of me having a bad configuration somewhere along the way from 1.x to 2.7 which was apparently forgiven/kosher until whatever happened under-the-hood with 2.8 that caused my system to cease working outbound.

does anyone out there have a clue what’s what? any ideas? any suggestions? any additional info i can provide?

thanks in advance,

rested and rejuvenated … i clicked on custom contexts in freepbx this a.m. and was surprised to realize that there are no entries in the UI for these modules.

that said, my extensions_custom.conf file does, indeed, have entries for from-route1, from-route2, from-route3 … is there any reasons you can think of that the 2.8 default install would not read/recognize this conf file? perhaps it’s deprecated and i should move this custom code over to another file?

just thinking out loud here this a.m. would really love to help get to the bottom of this issue, since it’s such an incredibly cool feature.

one more thing … i have not (yet) tried to uninstall/disable the custom context module to see if everything still works. my hunch is that it would work, even without that module installed. and that perhaps, all along, my issue has been some custom code in extensions_customer.conf and not incompatibility with a module.

and so … let the testing/troubleshooting/theorizing continue.

i look forward to your response :slight_smile: as always, thanks again for your efforts. they are truly appreciated.


After upgrading to 2.8, outbound dialing failed. Our outbound route “callout” that had had a context of “outrt-003-callout” somehow changed and must now be referenced with the context “outrt-3”.


ok, here is your issue.

First, I don’t think you were ever using the module.

On 2.7, your extensions_custom.conf contexts are named "from-route1’ and so forth. With the custom contexts module, you managed to set the context for the extension to that (or you did it without the module).

That works because the extensions_custom.conf outbound routes are properly formatted for 2.7.

When you migrated to 2.8, you did not change your extensions_custom.conf outbound route. They were referring to the old naming convention of outbound routes. Note the new convention when you look at extensions_addition.conf. Basically, you are now referring to routes that used to be in extensions_additional.conf that are no longer there.

So … assuming you are still in 2.7, get rid of your extnesions_custom.conf routes. Use the custom context module to setup the same thing and confirm it works. Then migrate and it should migrate your settings. (or just go straight to 2.8 and set it up there).

configured 2.7 with the custom contexts for one of the trunks … took a little massaging, but i got that to work exactly like my work-around in extensions_custom.conf

then blanked out the old context stuff in the _custom file and reloaded the config … still worked!

upgraded to 2.8 as suggested, using the latest/greatest rc1 for custom contexts … works like a champ!

woo-hoo :slight_smile: and there was much rejoicing!!!

in the process of researching custom contexts to get it working properly, i came across this link:

am lobbying to get a little thank-you donation from my company; any objections to using that page to make the contribution?

thanks again for all the assistance … much appreciated.

Why don’t you post the extensions_custom.conf so we can put this to rest?


he shouldn’t post the extensions_custom.conf file, he should make a backup up of it then delete everything in it.

That would be the “proper” starting point.

Also … this should be done on the “working” 2.7 version first, to see if it still works, then move on to the upgrade…

here 'tis …


; These are all the applications that you will require
include => app-cf-busy-off
include => app-cf-busy-off-any
include => app-cf-busy-on
include => app-cf-off
include => app-cf-off-any
include => app-cf-on
include => app-cf-unavailable-off
include => app-cf-unavailable-on
include => app-calltrace
include => app-callwaiting-cwoff
include => app-callwaiting-cwon
include => app-dialvm
include => app-directory
include => app-dnd-off
include => app-dnd-on
include => app-echo-test
include => app-recordings
include => app-speakextennum
include => app-speakingclock
include => app-userlogonoff
include => app-zapbarge
include => app-vmmain
include => ext-group
include => ext-fax
include => ext-meetme
include => ext-findmefollow
include => ext-paging
include => ext-queues
include => ext-test
include => ext-local
include => parkedcalls
;include => outbound-allroutes-custom
include => outrt-001-route1
exten => foo,1,Noop(bar)
exten => h,1,Hangup
exten => s,1,Macro(hangupcall)
exten => h,1,Macro(hangupcall)
; end of [from-route1]

; …
; same setup/config for route2 & route3 …
; …

and here is the extensions_additional.conf – two snippets:

; …
; snip
; …

include => from-trunk-sip-route1-custom
exten => _.,1,Set(GROUP()=OUT_2)
exten => _.,n,Goto(from-trunk,${EXTEN},1)

; end of [from-trunk-sip-route1]

; …
; same for from-trunk-sip-route2 & from-trunk-sip-route2
; …

; …
; snip
; …

include => outbound-allroutes-custom
include => outrt-001-route1
include => outrt-002-route2
include => outrt-003-route3
exten => foo,1,Noop(bar)

; end of [outbound-allroutes]

include => outrt-001-route1-custom
exten => 311,1,Macro(user-callerid,SKIPTTL,)
exten => 311,n,Set(_NODEST=)
exten => 311,n,Macro(record-enable,${AMPUSER},OUT,)
exten => 311,n,Macro(dialout-trunk,2,${EXTEN},)
exten => 311,n,Macro(outisbusy,)
exten => 411,1,Macro(user-callerid,SKIPTTL,)
exten => 411,n,Set(_NODEST=)
exten => 411,n,Macro(record-enable,${AMPUSER},OUT,)
exten => 411,n,Macro(dialout-trunk,2,${EXTEN},)
exten => 411,n,Macro(outisbusy,)
exten => 911,1,Macro(user-callerid,SKIPTTL,)
exten => 911,n,Set(_NODEST=)
exten => 911,n,Macro(record-enable,${AMPUSER},OUT,)
exten => 911,n,Macro(dialout-trunk,2,${EXTEN},)
exten => 911,n,Macro(outisbusy,)
exten => _1800NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _1800NXXXXXX,n,Set(_NODEST=)
exten => _1800NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _1800NXXXXXX,n,Macro(dialout-trunk,2,${EXTEN},)
exten => _1800NXXXXXX,n,Macro(outisbusy,)
exten => _1866NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _1866NXXXXXX,n,Set(_NODEST=)
exten => _1866NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _1866NXXXXXX,n,Macro(dialout-trunk,2,${EXTEN},)
exten => _1866NXXXXXX,n,Macro(outisbusy,)
exten => _1877NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _1877NXXXXXX,n,Set(_NODEST=)
exten => _1877NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _1877NXXXXXX,n,Macro(dialout-trunk,2,${EXTEN},)
exten => _1877NXXXXXX,n,Macro(outisbusy,)
exten => _1888NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _1888NXXXXXX,n,Set(_NODEST=)
exten => _1888NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _1888NXXXXXX,n,Macro(dialout-trunk,2,${EXTEN},)
exten => _1888NXXXXXX,n,Macro(outisbusy,)
exten => _1NXXNXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _1NXXNXXXXXX,n,Set(_NODEST=)
exten => _1NXXNXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _1NXXNXXXXXX,n,Macro(dialout-trunk,2,${EXTEN},)
exten => _1NXXNXXXXXX,n,Macro(outisbusy,)
exten => _NXXNXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _NXXNXXXXXX,n,Set(_NODEST=)
exten => _NXXNXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _NXXNXXXXXX,n,Macro(dialout-trunk,2,${EXTEN},)
exten => _NXXNXXXXXX,n,Macro(outisbusy,)
exten => _NXXXXXX,1,Macro(user-callerid,SKIPTTL,)
exten => _NXXXXXX,n,Set(_NODEST=)
exten => _NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _NXXXXXX,n,Macro(dialout-trunk,2,${EXTEN},)
exten => _NXXXXXX,n,Macro(outisbusy,)

; end of [outrt-001-route1]

; …
; same for outrt-002-route2 and outrt-003-route3 on the second snip.
; …

; …
; snip
; …


let me know if that helps at all.

… also … confirmed that if _custom is removed, nothing works and it goes back to the aforementioned problem … so i absolutely must have those entries for it to work.

should it be in _additional instead of _custom? perhaps … but is there a freepbx gui way to get it in there? not that i’ve seen (at least in the standard setup)

would it work if i used the custom contexts module? perhaps … will have to play around with that module and see if it does the trick.

i am still really curious to know what happens when i upgrade to 2.8 and whether or not the _custom file gets wiped out or if the order of includes changes, etc.

thanks again, guys. appreciate the assist.


oops – typo on the customer/custom … yes it’s called extensions_custom.conf

in the extensions.conf file, here is the order of includes:
#include extensions_override_freepbx.conf
#include extensions_additional.conf
#include extensions_custom.conf

so yes, _additional comes before _custom (and there is no _customer – lol)

no error messages in main window of dashboard, so we’re safe there. i also didn’t notice any error messages in the dashboard post 2.8 upgrade.

in the _additional there are entries the read like:
from-trunk-sip-trunk1, from-trunk-sip-trunk2, from-trunk-sip-trunk3 which only include the -custom bits of each of those (which doesn’t exist, per se) … i’m not sure if these are even used … have to poke around with some debug later.

there are also outrt-001-route1, outrt-002-route2, outrt-003-route3 entries in _additional which are the includes that _custom points to in each of the from-route1, from-route2, from-route3 contexts. this seems to be fine, since the dialplan info is contained in _additional and then included/referenced once _custom is included in the main extensions.conf file

_override is blank.

as to your last comment, i think you’re 100% correct in your diagnosis … i thought i was using custom contexts (as a module), but in reality it appears that i simply have my custom contexts defined within _custom. my next point of troubleshooting will be to upgrade to 2.8 and see what happens to the entries in _custom (and if they persist), if the order changes in extensions.conf, and if the rest of the freepbx-generated info in _additional is same/similar.

much obliged for the hand-holding here on the troubleshooting. i started playing with freepbx back in the trixbox days (before fonality took over). the custom context example/setup was something straight from kerry’s blog (again, this is going back to 2007/2008). so it appears that i have been successfully able to use custom contexts (possibly even without the 3rd party module?) all along until 2.8.

will try to schedule another maintenance window where i can attempt the 2.8 upgrade once again and at least report back what / why it breaks. sounds like my use case is very, very specialized. and it’s entirely possible that my “solution” is a bit unorthodox, so i’ll be looking into best-practice as well, with the expectation of getting back to a more standard config, so i can enjoy all the new treats that 2.8 has to offer.


well if your conf fie is named extensions_customer.conf then it is something that was never used by FreePBX

If it is named extensions_custom.conf then nothing should have changed.

Look at the order of #includes in the main extensions.conf (which should be sym-linked from the core module. While you are at it, make sure there are no error messages in the notification window on the dashboard…

The order of the includes will determine what gets used if there is a conflict. The auto-generated extensions_additional.conf file comes before the extensions_custom.conf and thus anything in the former will be used if there is a conflict. If there are conflicting contexts in both files, it is possible to end up with some of the extensions from the second conflicting context mixed into your first. You REALLY don’t want conflicting contexts…

There is also an _override.conf file which can be used to override auto-generated dialplan (from the _additional.conf file). This is typically only used if you REALLY know what you are doing and want to block something we are generating when there is no other way to block/override it.

Ultimately, you should be able to use the show dialplan command within the CLI to show what Asterisk sees for specific contexts, if you think something odd is going on. But before that, you should simply check the extensions_additional.conf file to make sure that the dialplan you think should be generated is being generated.

Going back to your comment about the code in extensions_custom.conf… if you really are using custom contexts (in what ever version of FreePBX), then you should be able to remove anything out of that file related to this. The fact that something is in there at all makes be suspect that you really have something very different going on…

custom context works fine on 2.8.

If it still says beta, it is just that we spaced bumping up the release.

The one thing you may want to check though is the actual allow/deny state of the custom context configuration.

There was an earlier bug that migration would end up setting them to deny when they were allow (though that was fixed some time ago).

i used 2.8.0rc1.1 from here:

doesn’t work.

and for anyone else trying to downgrade freepbx, here are the steps i have used – there is likely a much, much easier way, but this is working for me so far:

  • download freepbx 2.7
  • unzip
  • install_amp --force-version=2.7
  • go back to freepbx and apply the changes
  • go to the modules page and notice that some of the stuff is still 2.8.x
  • manually tweak the module.xml for each and every module that is 2.8.x to 2.7.0 (mine are located in /var/www/html/admin/modules; yours may be different)
  • freepbx will tell you the module is disabled and prompt you to download and enable the 2.7.0 version – which is great
  • do that, then go thru and upgrade all the modules to the latest/greatest 2.7.x version

i am still in the process of the last 3 items now, but should be done shortly. :slight_smile: and then i will be queuing up a tasty libation to celebrate.

thanks philippe for all your assistance (and apologies for spelling your name with two Ls instead of 2 Ps)



there are a lot of people using that module (which is the latest one) and it does work.

I don’t know what is going on in you case. (Maybe there is a bug lurking that your specific configuration has uncovered).

You should obviously do what you need to and/or makes most sense to you (downgrading or what not), but I can tell you from both first hand experience and reports from others that it “does work” (quoted, since I can’t conclusively say that there is not a bug that maybe you uncovered…)

i hear you loud and clear.

i’m happy to report that i have just completed my process of manually reverting back to 2.7 … and having done so, i just tested everything and it’s back to working properly.

… and there was much rejoicing …

i’ll stop short of saying i’m confident i have uncovered a bug. it’s entirely possible that my config is just so completely screwed up that even tho it’s worked fine for the past 3 years … lol, you see where i’m going with this, i hope. :wink:

should this issue ever percolate up to your list of things to investigate, feel free to PM me. i’m happy to provide any additional details that would assist in tracing this out further.

thanks again. have a great evening! i am now getting back to the more pressing matter – a tasty libation!


well go have fun with your tasty libation.

If in fact you have custom context working on 2.7 and doing a migration to 2.8 results in it failing, then when you have time and the additional patience you should help try to get to the bottom of things.

The migration could some how be failing for some reason. Problem is, I seem to recall some of the migration code was necessarily in the framework code, meaning you would have to go do the full upgrade again, with the custom context module pulled down and included.

Anyhow … unfortunately we don’t have the information to try and repro your problem for someone to try and determine why its doing that.

well, at least i’m not the only person ever to have this kind of problem … looks like it also reared its ugly head in the 2.3->2.4 days:

anyone out there have any ideas?

ok, so all along the problem is that custom contexts never came out of beta / rc for 2.8.

so the bottom line is that custom contexts are NOT compatible with 2.8 … fair warning to anyone/everyone who uses custom contexts – might want to check and make sure it’s working before you upgrade and waste countless hours of time (and by extension the time of phillipe and the other developers) …

so once again, i’m reverting back to 2.7 …

one final suggestion: just make a sticky somewhere of how to revert back to a previous version. i’ll post a link in here if/when i find one.

i remain tremendously frustrated (and disappointed)