[Asterisk-Dev] Feature request: reading in parts of config files via URI

[Mark Spencer]

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 at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>