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

[John Todd]

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


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