I still have a test system running trixbox and custom contexts v0.3.6 and there the default internal context and internal dial plan both get priority 50 when a custom context is created. Outbound routes start at 51 so the internal calls have priority over the outbound dial plan. I also never experienced this problem prior to switching to the new version of custom contexts but it was difficult to debug because we had also changed to Asterisk 1.6, PIAF 1.755, etc…
With v0.3.6 when I click “allow all” the priorities stay the same, i.e. internal context and internal dial plan all = 50 and outbound routes go from 51 to 71
I am curious as to why you won’t even validate my loop around trunk suggestion.
It solves the problem you have, solves another problem (internal users calling each other) and is generally a cleaner way that does not get “in the way” of the custom context module.
I apologize for not commenting on your suggestion earlier but you blasted my setup and biz practices in an earlier post so much that I did not think it’s wise to put myself in the line of fire again.
You make of course a valid point with the loop around trunks but I only use them when needed and don’t believe in fixing what is not broken. When users dial an internal extension correctly (in my case 10-digit telephone numbers) then a properly designed system should process these calls as internal and not use outside trunks.
However, if a user dials the 10 digit extension as 11 digits then the use of a loop around trunk would make sense if it happens often but personally I find it cumbersome to create an outbound route for all extensions in a system that changes users all the time and it’s not really a big problem for us.
If we’d really need it (and I know you’ll hate this too I would put a loop around trunk into every outbound route so that every call is first looped back into the system and then fails over to the outbound trunk. I find it does not cause much overhead and needs zero upkeep. We use the same system for enum and it works quite well. I know it’s not clean but it works and we set it and forget it.
giving it a test shot I see what you are saying, it does by default make for a bit of a mess when you simply create a brand new context setting everything to allow at first.
For those of you who used this prior to the port from 2.7 to 2.8, is this how it always acted or was it previously a bit better behaved? In other words, on earlier releases, if you were to create a new custom context, and did nothing more then choose allow all, did you end up with your outbound routes all at the end or were they all intermixed like it does now since it starts the priority numbering at 50 for each section?
I am afraid I lack the understanding to write the documentation. Anyways the default internal context is is set at priority 50. The internal dialplan starts by default at priority 51 and the outbound routes also start at priority 51 so the ext-local context is not prioritized over outbound routes by default. Setting it to 50 fixes the problem.
While ultimately you make me getting what you want with custom contexts you would be far better off with the loop around trunk. It solves this problem and insures your subscriber-subscriber call stay on net.
Simply move the loop around route to the top of the outbound router.
turns out you need to assign priority 50 to ext-local which is not done by default. While not a real bug I consider this a problem since no documentation exists for the module.
the custom-context module is a very powerful but yet very confusing module that is hard to use without really understanding what it does.
Ultimately, the way to understand it is to have a look at the dialplan that is generated and more than anything, to really understand how Asterisk processes information.
There are multiple reasons why it is not part of the FreePBX core and remains a third party module, the complexity and difficulty to understand it being one of them, the fact that it ultimately presents a ‘false sense’ of the context separation being another.
As far as the priorities though, I thought that when you created a new custom context, by default it still put the outbound routes at the end so if you didn’t manually change things, all the internal contexts would come before. Is that not the case?
Anahow, if you feel like sprucing up the documentation that does exist for this module on the website, just let me know and I’ll be glad to change your user type so you are able to edit the page and add what you think might help others.
BTW I do have the new custom contexts module installed and all “internal calls” i.e. extension to extension use external outbound routes and trunks. Did I configure this wrong or is there a problem?
the errors look like they are coming from core functionality (the TARTET_FLP42=… stuff is generated by core to address trunk dial patterns).
So … first off, please upgrade core and make sure it is up-to-date as I do recall some syntax errors occurring some time ago in that part of the code.
Once you have done that, if you are still getting a syntax error, please file a bug ticket and make sure you include the Asterisk version you are using.
If possible, please try to paste in the subroutine that is being called, it will be called sub-flp-[trunk_id] where [trunk_id] is the trunk id number. If that subroutine is really really long (like you have dozens to hundreds of trunk patterns (not route patterns but trunk patterns) then try to locate the specific dialplan segment that is generating that error and include that section so we can identify it.
And of course, if you want to have a look at what the syntax pattern is and find the issue, that’s also welcome
Lastly, the following error:
[2010-10-05 13:25:05] WARNING[4174] app_exec.c: Deprecated syntax found. Please upgrade to using ExecIf(?(null)((null)))
leads me to be suspicious that FreePBX is mi-intgerpreting your version number and thus generating the wrong syntax for ExecIf. If that is the case, then for some reason it is not detecting your version number properly. Can you type “show version” at the CLI as well as “asterisk -V” at the command line and let us see how the version is being presented so can see if it is mis-interpreting the version number. (Since - there is no reason in any of auto-generated code that ExecIf should be formatted wrong if it is properly detecting the version).
Thanks for the comments. We’ll look into that. I uninstalled custom contexts and the errors are still there so I was wrong there. I think we may have copied some settings over from trixbox during the migration which are causing the errors. I’ll post a seperate messg in the forum once we know more.
I originally reported a problem where you had to assign priority 50 to ext-local so that internal calls would not use outbound trunks. I now have another issue with custom contexts and “*2 attended transfers” which looks a lot the same. Using NO loopback trunk, if we do a ## blind transfer to an internal extension it works. If we do a “*2” attended transfer to the same internal extension it fails.
ext-local is set to priority 50 in custom contexts
Does anyone know which parameters in custom contexts control
blind transfer
attended transfer
If I know the parameter I can check the priority of both and understand why one works and the other one doesn’t.
OK. It’s not a bug. I “allowed” a couple of extra modules in the custom contexts dial plan and now *2 is working. I think it’s “app_pickup” but I am not 100% sure which one triggered the change. At least it works now.
Trying to clean up some of my FreePBX third-party code and noticed CustomContext causing the extensions class to barf up a few warnings (one per context). The offending code is on line 372 of v0.3.7:
$ext->_exts[$context.’_bad-number’][] = null;
For obvious reasons, it causes a foreach(_exts[][]) in the generateConf() method to sputter. Can’t say I’m fully up to speed with the extensions class, but the purpose of this line alludes me. If I comment it out, I can find no difference in the resulting dialplan. Can anyone shed light on the purpose of this line?
I would put a loop around trunk into every outbound route so that every call is first looped back into the system and then fails over to the outbound trunk. I find it does not cause much overhead and needs zero upkeep. We use the same system for enum and it works quite well. I know it’s not clean but it works and we set it and forget it.