Customizing the generated dialplan for an extension?

1

Hello,

Is there a facility for customizing the template which generates the dialplan for extensions?

When extensions are dialed, I need to run an AGI shell script, to send a push notification then wait(3) seconds to give the mobile app a chance to register to asterisk from an asleep state before the invite is passed on.

This snippet works for me, but if I put it in extensions_additional.conf it is overwritten as expected when apply config is presssed.

exten => 1337,1,Ringing
exten => 1337,n,AGI(/usr/bin/shellscrip.sh)
exten => 1337,n,Wait(3)
exten => 1337,n,Set(__RINGTIMER=${IF($["${DB(AMPUSER/1337/ringtimer)}" > "0"]?${DB(AMPUSER/1337/ringtimer)}:${RINGTIMER_DEFAULT})})
exten => 1337,n,Macro(exten-vm,novm,1337,0,0,0)
exten => 1337,n(dest),Set(__PICKUPMARK=)
exten => 1337,n,Goto(${IVR_CONTEXT},return,1)
exten => 1337,hint,SIP/1337,CustomPresence:1337

This is the ā€œstockā€ generated dialplan (so basically I am just inserting 3 lines at the beginning above)

exten => 1338,1,Set(__RINGTIMER=${IF($["${DB(AMPUSER/1338/ringtimer)}" > "0"]?${DB(AMPUSER/1338/ringtimer)}:${RINGTIMER_DEFAULT})})
exten => 1338,n,Macro(exten-vm,novm,1338,0,0,0)
exten => 1338,n(dest),Set(__PICKUPMARK=)
exten => 1338,n,Goto(${IVR_CONTEXT},return,1)
exten => 1338,hint,SIP/1338,CustomPresence:1338
2

Thatā€™s what the /etc/asterisk/extensions_override_freepbx.conf is designed to do, just copy your working [1337] context into it and from bash

rasterisk -x ā€˜dialplan reloadā€™ā€™

3

OK, but is there any way to template this so that it works for every new created extension in the webUI without neededing to edit that file each time?

4

Only by editing the FreePBX code, which will then throw an ā€œunsignedā€ error/warning.

5

or creating a module and hooking in to the dialplanā€¦

2 Likes
6

Is there a recommended way of finding someone competent and relatively affordable to create a module like this? Iā€™m in one of those ā€œneed to get it doneā€ situations

7

FYI, there wouldnā€™t be a working [1337] or [1338] context. The dialplan snippet that he showed is from [ext-local] which generates the local extension dialplan such as direct dial, voicemail handling if voicemail is enabled, direct paging, etc. It also handles exten to exten dialing.

So this is just more than shoving three lines of dialplan into individual contexts, this is modifying how a core internal dialplan context is written out.

8

How about this, create a prefix that you can add to ext numbers that calls the wakeup script prior to proceeding with the dial. Then you can add the prefixed ext number as an fmdm destination for the extension.

If this could work for you, open a support ticket to explore. Link above.

9

Good point, though I wonā€™t say I fully understand.

Now Iā€™m wondering ā€¦ could I somehow just change the default context for extensions to ā€œcustom-internalā€ , have that run my 3 lines then jump to from-internal ?

hmm

10

You could, but I think you will break more than you will fix. Easy enough to try with a single extension.

1 Like
11

Iā€™m not sure why this is a huge deal.

In extensions_custom.conf you do:

#include extensions_extpush_custom.conf
[from-internal-custom]
include => ext-local-push

Create extensions_extpush_custom.conf and do:

[ext-local-push]
exten => 1337,1,Ringing
exten => 1337,n,AGI(/usr/bin/shellscrip.sh)
exten => 1337,n,Wait(3)
exten => 1337,n,Goto(ext-local,1337,1)

exten => 1338,1,Ringing
exten => 1338,n,AGI(/usr/bin/shellscrip.sh)
exten => 1338,n,Wait(3)
exten => 1338,n,Goto(ext-local,1338,1)

;; Continue as needed

You can do all this in extensions_custom.conf but having extensions_extpush_custom.conf allows you to generate that file as needed.

12

This solution requires manually adding||deleting a block for each extension which would be obnoxious for anything more that a few extensions

13

Yup, I agree. That is why I said ā€œallows you to generate that file as neededā€, meaning it can be updated on the fly when extensions are removed/added. Is it the most optimal solution for what is needed? No. Does it stop the @klong from editing extensions_additional.conf when trying to implement these changes? Yes.

Honestly, this should be a module. Something that has been said to @klong on IRC when this was discussed there. Since this is to facilitate the new push feature in Bria 5 and Counterpath has a partnership with FreePBX I guess the question is: Should @klong look to make this module internally or is this a Bria feature that will be added to FreePBX overall in the future? If yes, then is there a time frame of its availability?

So my solution may not be elegant but so far itā€™s one of the better options on the table save the whole doing this right via module integration.

14

Iā€™ve just tested BlazeStudios suggestion and it seem to be working and is a great help to me in my current situation, so thanks Tom!

I think a bash/python script via cron, which selects extensions from the mysql database which have the custom context, then templates the file and reloads the dialplan if there is a change will be very simple to write (simpler than learning the module system).

That way my coworkers can just create a new extension, set the custom context and the cron job will take care of the rest.

Indeed we have discussed my situation on IRC a few times ā€¦ My situation is am using the AGI script to make an API call to our Bria provisioning server on-prem ā€¦ if Counterpath is opening up their API for *their off-the-shelf bria mobile/stretto clients, then sure it could be useful to manyā€¦

Their push implementation that is apparent to normal users in Bria is totally different though, it actually registers on your behalf to your PBX as a SIP client like Groundwire does ā€¦ whereas in my case I am just sending an Apple Push Notification to wake up the client for it to register back to SIP.