Posted: Tue Apr 15, 2003 4:38 am Post subject: [Asterisk-Dev] Feature request: reading in parts of config f
I was working with some global configurations today, and was
wondering how difficult it would be to include the contents of files
(or, heck, URLs) to set variables or extensions. I am pretty sure
that using the prefix of "local =>" is a bad idea, so I substituted
"read =>" instead. It might even be possible that extension logic
could be read in via the same method, so perhaps using "include =>"
is not so outrageous if this gets expanded in concept...
In other words, something like these two examples:
In the first example, we're simply reading in global variable names
which might be site specific. This would help a lot for
configuration files that are the same between individual offices as
far as their logic goes, but there might be different settings for
each specific site as far as variables go.
The second example includes a small snippet of actual dial plan
pulled in from the URL (or file, or whatever) specified. This would
allow some central admin to change and keep dial plans between
multiple offices in one repository. Even using IAX, you still need
to go twiddle each server remotely. Perhaps this is just a more
centralized way of administering Asterisk servers, but I'm already
running into the "ten million ssh sessions" clutter when doing three
or four way configuration changes.
PS: A side note on this would be an application that could be called
to reload Asterisk's dial plan. In that way, a central administrator
could cause reloads simply by dialing a number. This is potentially a
very dangerous tool, but probably pretty useful.
Posted: Tue Apr 15, 2003 1:04 pm Post subject: [Asterisk-Dev] Feature request: reading in parts of config f
I believe you can use "#include" statements in asteirsk config files.
Mark
On Mon, 14 Apr 2003, John Todd wrote:
Quote:
I was working with some global configurations today, and was
wondering how difficult it would be to include the contents of files
(or, heck, URLs) to set variables or extensions. I am pretty sure
that using the prefix of "local =>" is a bad idea, so I substituted
"read =>" instead. It might even be possible that extension logic
could be read in via the same method, so perhaps using "include =>"
is not so outrageous if this gets expanded in concept...
In other words, something like these two examples:
In the first example, we're simply reading in global variable names
which might be site specific. This would help a lot for
configuration files that are the same between individual offices as
far as their logic goes, but there might be different settings for
each specific site as far as variables go.
The second example includes a small snippet of actual dial plan
pulled in from the URL (or file, or whatever) specified. This would
allow some central admin to change and keep dial plans between
multiple offices in one repository. Even using IAX, you still need
to go twiddle each server remotely. Perhaps this is just a more
centralized way of administering Asterisk servers, but I'm already
running into the "ten million ssh sessions" clutter when doing three
or four way configuration changes.
PS: A side note on this would be an application that could be called
to reload Asterisk's dial plan. In that way, a central administrator
could cause reloads simply by dialing a number. This is potentially a
very dangerous tool, but probably pretty useful.
Posted: Wed Apr 16, 2003 1:49 am Post subject: [Asterisk-Dev] Feature request: reading in parts of config f
Great! That's what I needed. It's easy enough to prod wget into
fetching the appropriate files from cron or something, so URL based
fetching is simply "nice" but not required.
JT
Quote:
I believe you can use "#include" statements in asteirsk config files.
Mark
On Mon, 14 Apr 2003, John Todd wrote:
>
>
> I was working with some global configurations today, and was
> wondering how difficult it would be to include the contents of files
> (or, heck, URLs) to set variables or extensions. I am pretty sure
> that using the prefix of "local =>" is a bad idea, so I substituted
> "read =>" instead. It might even be possible that extension logic
> could be read in via the same method, so perhaps using "include =>"
> is not so outrageous if this gets expanded in concept...
>
> In other words, something like these two examples:
>
>
> [global]
> read => file:/etc/asterisk/sitespecific/stuff
> .
> .
> .
>
> [default]
> read => http://www.mybigfatserver/companystuff.txt
> .
> .
> .
>
>
> where /etc/asterisk/sitespecific/stuff looks like this:
>
> PHONE1=SIP/9393
> PHONE2=SIP/3111
> OUTSIDELINE1=Zap/1
> OUTSIDELINE2=Zap/2
> ANALOG911=Zap/1
>
>
>
> and where http://www.mybigfatserver/companystuff.txt looks like this:
>
>
> 1234 => _1.,1,Dial(Zap/1,${EXTEN})
> 1234 => _1.,2,Hangup
>
>
> In the first example, we're simply reading in global variable names
> which might be site specific. This would help a lot for
> configuration files that are the same between individual offices as
> far as their logic goes, but there might be different settings for
> each specific site as far as variables go.
>
> The second example includes a small snippet of actual dial plan
> pulled in from the URL (or file, or whatever) specified. This would
> allow some central admin to change and keep dial plans between
> multiple offices in one repository. Even using IAX, you still need
> to go twiddle each server remotely. Perhaps this is just a more
> centralized way of administering Asterisk servers, but I'm already
> running into the "ten million ssh sessions" clutter when doing three
> or four way configuration changes.
>
>
> PS: A side note on this would be an application that could be called
> to reload Asterisk's dial plan. In that way, a central administrator
> could cause reloads simply by dialing a number. This is potentially a
> very dangerous tool, but probably pretty useful.
>
> JT
>
>
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum