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

[Steve McMahon]

Spoken like a true asshole once again...

----- Original Message ----- 
From: <critch at basesys.com>
To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Sent: Monday, November 07, 2005 9:18 PM
Subject: Re: [Asterisk-Dev] extensions.conf limitations,and how to overcome
them


> 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
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev