[Asterisk-Dev] extensions.conf limitations, and how to overcome them

[asterisk at funkspiel.org]

On Mon, Nov 07, 2005 at 11:56:16AM -0600, Steven Critchfield wrote:
> On Mon, 2005-11-07 at 02:31 -0800, Quinn Weaver wrote:
> > Hi,
> > 
> > I'm a relative newcomer to Asterisk, and I have some questions about
> > the dialplan.  Before jumping in, I want to thank Mark, Digium, and
> > everyone on this list for making Asterisk what it is.  Thanks for
> > giving us such an awesome toy to play with. :)
> > 
> > 1) Has anyone thought about opening up programmatic access to
> > Asterisk's internal representation of the dialplan?  With this, there
> > would be no need to munge and reload extensions.conf.
> > 
> > Basically, I want to be able to reorder menus (extensions, priorities)
> > from within a call via an AGI or res_perl script[1].  I'd also like to do
> > the same thing between calls.
> > 
> > My understanding is that this is not possible in the Asterisk API.
> > Do you think it's desirable?  How easily could I hack Asterisk to
> > make it happen?  Where would I start?
> 
> Maybe if you described your needs better, there would be a better
> solution to this problem.

Thanks for the suggestions so far. :)

Let me see if I can be clearer:

Suppose I have an IVR where the order of items within a menu can
change.  I record the choices users make.  (This part I know how to
do.)  If 80% of users choose option 5 on my main menu, I have some
program that notices this and makes option 5 into option 1.  This
translates into changing a priority in the dialplan.

Going further, I could reorder deeply nested menu items.  For
instance, suppose users most often end their calls with Accounts
Payable, and they get there by pressing 2 at the first menu prompt,
then 3 at the second, then 5 at the third.  My program could take that
nested "option 5" and make it into option 1 in menu 1.  This makes
life easier for users.

I hope this makes sense.  I realize these menus don't really map onto
extensions directly.  However, this is part of the problem I want to
solve!

> Then again, if you are needing that much
> flexibility, maybe you need to write your own AGI app that essentially
> handles the equivalent of your morphing dialplan needs.

Right, you mean make all calls enter a single AGI and then do all the
menus within that AGI?  I was thinking of that as one possibility.
At this point I'm just weighing the different options.

> > 2) Apart from question 1, has anyone given thought to the monolithic
> > nature of extensions.conf?

> > [...]

> First, the dialplan can be split many ways via the context tags. Next
> #include in extensions.conf should help break it down into easier to
> manage files.

Thanks for pointing that out.  I didn't know about #include. :)
In this case, you still have to reload extensions.conf all at once,
right?  Or is there a way to reload only one of the included files?