[Asterisk-Dev] Making a variable available to a dialplan

David Filion dfilion at dotality.com
Thu Oct 21 11:11:02 MST 2004


Steven Critchfield wrote:

>On Thu, 2004-10-21 at 11:46 -0400, David Filion wrote:
>  
>
>>Hi,
>>
>>I need to create a variable in an app "global" so that I can refer to 
>>its value in a dial plan.  What functions should I look at to do this?  
>>Searching the archives didn't turn anything up.
>>    
>>
>
>PArt of asking an effective question is to state why you are at that
>problem. It may well be that you are going the wrong way about solving
>the bigger problem.
>
>Short answer to you would be to use the ast_db functions and then use
>the dbget dialplan logic to get at the variable. It has the benefit of
>being persistent over asterisk restarts or reboots.
>  
>
OK, the situation.  Our company is sharing * with multiple small 
companies. Our dial plan makes heavy use of patterns and DB look ups 
(postgresql) to avoid having to hard code values, especially since a lot 
of the dial plan is common to all the different companies.  The problem 
we're run into to with the employee directories.  The directory reads 
its values from voicemail.conf, using the context in voicemail.conf as 
the context to jump to in extensions. conf.  This means that we need to 
create a context in extensions.conf for every company,  duplicating a 
lot of code.  Now, we've found a way to still divide each company into 
separate contexts in voicemail.conf and have them all just to the same 
context in extensions.conf.  However, we need access to the actual 
extension number, which does not appear to be passed when the jump to 
extensions is made. This appears to result from forcing the context to 
jump to in extensions.  Confused yet? I know I am.

So, the idea is to store the values somewhere before the jump to 
extensions is made and then query the stored value one in extensions.  
Now, if this can be done with out changing any code, great. If not, then 
tips/pointers are welcome as I'm not real familiar with the inner 
workings of Asterisk yet.

David







More information about the asterisk-dev mailing list