[asterisk-users] What do you use? .conf or AEL?

[Tilghman Lesher]

On Wednesday 11 February 2009 13:07:16 Gordon Henderson wrote:
> On Wed, 11 Feb 2009, Tilghman Lesher wrote:
> > On Wednesday 11 February 2009 08:22:39 Gordon Henderson wrote:
> >> For my appication, I get on OK with pure "dialplan". I have a fully
> >> featured PBX system which runs on nothing more than dialplan, and I'm
> >> happy with it. I do have something "higher level" that generates some of
> >> the dialplan for me, but I still had to write that dialplan in the first
> >> place and I was happy to do it in pure "dialplan".
> >
> > My viewpoint is that you should work on separation of your application
> > code versus data, so that other than new development, your dialplan
> > should be completely static and never need changing (other than, like I
> > said, new development).
>
> One mans program is another mans data....
>
> But what would you call "new development"? Say I have a site who has many
> extensions and they then wanted to create a call-group - ie. one new
> extension, ring multiple phones?
>
> In my world, they go to the web interface, create the extension, tick a
> selection of existing extensions and the code then writes out a new
> segment of dialplan to create the new extension, issues an extensions
> reload command to asterisk and off it goes... The dialplan was static
> before, and is static after, it's just that I wrote some php to write
> dialplan based on user input...
>
> How do others do it?

I'd have a range of extensions, when dialled, it goes to the database,
retrieves the list of channels, and dials those channels.  The web frontend
would look exactly the same, but the data would go directly into a database,
not taking an extra step to go into a dialplan, then reload the text file.
The advantage is that I'd never have the possibility of two people colliding
on the regeneration of a text file.  While it is possible for two people to
select the same number when defining new extensions, that can be very
easily worked around, given that database updates are atomic.

-- 
Tilghman