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

[critch at basesys.com]

On Mon, Nov 07, 2005 at 04:47:43PM -0800, asterisk at funkspiel.org wrote:
> 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!

I wouldn't expect your menu's to change very often. If they did you will
frustrate your callers more than traversing a few menu entries. Any half
inteligent person will quickly learn what menu entries they need to
traverse and start keying in as soon as they hear audio as long as the
menu doesn't change. Take that as a change shouldn't happen often, but
on occasion fixing your menus helps. Having an app rearrange menus on
the fly is probably a quick way to get the people to hit whatever key
gets them to a human quickest.

> > 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?

Still have to reload it all, but it isn't that long of a process.

Steven