Including proper contexts for feature codes in custom contexts

I was testing a bit of code that is executed on every outbound call from internal sip peers. I have set the peers to the test context.

The last line of my code is:

It works great and I can call out any trunk and reach any other internal peer. What does not work are feature codes.

Can I include another context in order to allow access to the feature codes? I would want my code executed first before passing control to that context. Then the call would need to return so it can be sent to from-internal. Or perhaps there is an easier way to accomplish what I am trying to do.

change _. to _x. (which im sure now that im mentioned it, you realize it yourself :slight_smile: )

Or, use an include

include => from-internal

I wondered about the include. What I am not sure of is the order of precedence.

Does my contexts digit matching take precedence over from-internal with the include?


To my knowledge it does. It was explained to me that the first occurance of a match is the read and all others are ignored. That is why contexts like from-internal-custom work. It processes them first.

You can add some insurance if you like.


exten => 911,1,Noop(Remote extension cannot dial 911)
exten => 911,n,system(echo You may not dial 9 1 1 from this extension. > /tmp/out.txt)
exten => 911,n,system(echo Please use a land based phone >> /tmp/out.txt)
exten => 911,n,system(cat /tmp/out.txt | text2wave -o /tmp/my_new_sound.ulaw -otype ulaw)
exten => 911,n,Playback(/tmp/my_new_sound)
exten => 911,n,zapateller()
exten => 911,n,hangup()
include => from-internal

Note the last line before the include at the bottom. It hangs up, thus terminating the call.

Simpler than my goto method. Thanks for clarifying this, it’s much simpler than my goto method.

I can’t wait for the October training with Philippe and Ethan - should patch a bunch of gaps.

Have a great weekend…


You need to be a little careful using an include. If you pre-process something using custom code, then send it on to from-internal using an include, it may not start at the top. If you have 3 lines in your custom code for that pattern match, when it gets to from-internal, it will start with the fourth line for that patternmatch or the first “n”.

To illustrate this, run this code snippet while watching the CLI. Philippe provided me with this explanation in this post.

So if you completely process the call in the custom code, you can use the include to get the rest of the calls into the normal dial plan. If you are preprocessing some special thing, like adding steering digits, you should probably use a goto statement because you can specify where it starts.

exten => 9123,1,Noop(tst-1 - 1)
exten => 9123,n,Noop(tst-1 - 2)

exten => 9123,1,Noop(tst-2 - 1)
exten => 9123,n,Noop(tst-2 - 2)
exten => 9123,n,Noop(tst-2 - 3)

exten => 9123,1,Noop(tst-3 - 1)
exten => 9123,n,Noop(tst-3 - 2)
exten => 9123,n,Noop(tst-3 - 3)
exten => 9123,n,Noop(tst-3 - 4)

include => tst-1
include => tst-2
include => tst-3

I will try these examples this evening.

My tests where not completely passing the call so this timely information.

My practice does not have any particular application, it is academic. I am trying to be able to ‘touch’ calls arriving in from-pstn and from-internal to make sure I know how to ‘hook’ into FreePBX without breaking it.