I’m gonna pipe in here being the guilty party who wrote the original Custom Destinations module. First, a minor history lesson …
Many moons ago there was simply the ability to type in a custom destination as freeform text, no need for a custom destination module or anything of the sort. As FreePBX evolved, we added the destination integrity capability. What this means is, the ability to detect that a module was sending a call to a destination which no longer exists. (e.g. you point to an IVR from your inbound route, and then go delete the IVR). When we added this, it posed a problem because we had no way of knowing if a freeform destination existed or not. As such, I decided to add the Custom Destination module which gave you the ability to ‘register’ a destination that you would normally put into extensions_custom.conf. This is still not invulnerable since, you can go delete it from that file and we won’t know, but it did two things. It gave you some control of putting that destination into FreePBX and then using it as a select box option throughout your call flow.
Adding this module solved two problems. It allowed you to identify these destinations so you didn’t get false triggers about ‘orphan’ destinations, and it allowed you to access these destinations as select box choices. It didn’t solve the problem you are struggling with, which is, how do you get BACK into the module call flow from your custom dialplan without having to know the cryptic format of each destination. Even if you do know that format, what happens if things change … you end up with very fragile code.
It seems to me there is a simple solution to this. In addition to having a Custom Destination, why not add the feature of having a custom Subroutine? The best way to think about this is if you imagine a module like the Language Module. This is a super simple module that you can point to, have it set the channel’s language (in a freeform textbox) and then point to the subsequent destination after it’s done. So effectively, you would give it the name of a subroutine, we would call that subroutine which you would place in extensions_custom.conf, and then in your dialplan, you simply call ‘Return()’ and it comes back to our module and goes on to the subsequent destination that you have chosen just like any other module.
This seems to be the natural solution. It could be either implemented as yet another menu item of "Custom Subroutines’ or alternatively, we could enhance Custom Destinations with a radio button indicating whether this is a Destination or a Subroutine, and if the latter, we would simply present the common destination select boxes that you could choose from, otherwise they would be hidden.
It would seem like that would address your issue of how to get back and in general, provide a much more integrated way of adding custom dialplan. This would largely give you what you are getting from Dialplan Injection with a few differences:
- You will have to use some editor to write your dialplan in extensions_custom.conf as a subroutine vs. doing it in textarea in the module. Some probably consider this a negative, personally, I really appreciate using syntax highlighting in the editor of choice when writing dialplan as it helps catch typos and other errors.
- You get the benefit of proper Destination Registry integrity checking if we did this, since I am pretty sure that Dialplan Injection was written before the days that we had this and was never modified to add this in. (Don’t hold me to this, I haven’t gone and checked the module in a few years, but that is what I recall.)
So … thoughts on this?
