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

[Tony Mountifield]

In article <000501c5e429$b103b750$ee01a8c0 at Steve>,
Steve McMahon <voip at digitaldatabits.net> wrote:
> Spoken like a true asshole once again...

Huh? I thought Steven's comments were perfectly valid and reasonable.
What is your problem?

Cheers
Tony

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


-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org