Summary:	ASTERISK-03292: [patch] Allow mailbox lookups into astdb (compile-time option)
Reporter:	Tilghman Lesher (tilghman)	Labels:
Date Opened:	2005-01-17 17:41:24.000-0600	Date Closed:	2011-06-07 14:04:41
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20050117__zap_mailbox_lookup.diff.txt
Description:	Our extensions are all configured via astdb, which keeps our dialplan logic complex, yet short.  This compile time option allows our mailbox lookup to use the same storage location as the dialplan, which simplifies configuration. Corresponding patches for other channels may be forthcoming, implementing the same lookup, depending on whether this one gets accepted. ****** ADDITIONAL INFORMATION ****** Disclaimer on file.
Comments:	By: twisted (twisted) 2005-01-17 17:57:44.000-0600 Is there any way to provide an example of the use of this?  I'm currently not understanding it's purpose, as this can be done: exten => _XXXX,1,Macro(extensions,${EXTEN}) [macro-extensions] exten => s,1,DBGet(VMBOX=VMBOX/${ARG1}) exten => s,2,DBGet(DEVICE=DEVICE/${ARG1}) exten => s,3,DBGet(TIMEOUT=TIMEOUT/${ARG1}) exten => s,4,Dial(${DEVICE},${TIMEOUT},tr) exten => s,5,VoiceMail(u${VMBOX}) exten => s,105,VoiceMail(b${VMBOX}) Maybe I'm not getting what it's for, so please, elaborate :) By: Tilghman Lesher (tilghman) 2005-01-17 18:19:41.000-0600 Think stutter tone. By: Mark Spencer (markster) 2005-01-17 21:13:22.000-0600 What about just having a realtime config that runs off astdb?  That would seem to be substantially simpler and more consistant than adding one particular setting that can be pulled from astdb, no? By: Tilghman Lesher (tilghman) 2005-01-17 22:56:00.000-0600 Could you give an example on how that would work? By: Mark Spencer (markster) 2005-01-30 01:37:50.000-0600 In otherwords, a way to say "grab entity foo from db" e.g.  today we have res_config_odbc and res_config_mysql, so we could have a res_config_astdb right? By: Tilghman Lesher (tilghman) 2005-01-30 14:26:53.000-0600 It's an interesting idea, but how does that unify getting the voicemailbox number both in the dialplan, as well as in the config?  It seems the format would have to be incredibly convoluted (to store it in astdb), that you could not guess at the right key in astdb for dialplan purposes. I suppose an alternate way to do this would be a special variable that looks into a channel config and retrieves the right value, but that entails the use of bugset ASTERISK-2248 (since pbx.c cannot look into a channel's private structures, and we cannot currently hook into the special variables from within a channel module). Example of how this might work: SetVar(mailbox=${CHAN_ZAP(${tochannel},mailbox)}) or it could be done by creating a special channel-specific application: SetVarFromZap(mailbox=${tochannel},mailbox) but that would require a special channel-specific application for each channel.  I think the universal variable code would be much cleaner. By: Brian West (bkw918) 2005-01-30 20:58:52.000-0600 I think astdb need to be replaced... or res_config_astdb needs to be written. bkw By: Tilghman Lesher (tilghman) 2005-01-30 22:49:41.000-0600 And while we're eliminating and/or replacing astdb, we should also replace ODBC, as it's too slow, and we should eliminate callerid and callwaiting on analog lines, as they're too big of hacks.</sarcasm> By: Mark Spencer (markster) 2005-02-04 01:13:14.000-0600 Would Realtime work for you here as well, since voicemail can be pulled from Realtime and the "Realtime" application can also pull from it? By: Mark Spencer (markster) 2005-03-09 00:12:37.000-0600 How about creating a zap mailbox function with the new function variables from anthm, e.g. $(zapmailbox 1) ? By: Mark Spencer (markster) 2005-03-09 00:13:19.000-0600 (this would allow you to learn what is already there, without having to store it in a different way) By: Brian West (bkw918) 2005-03-17 21:38:51.000-0600 any update?  would a function var be the right answer? /b By: Tilghman Lesher (tilghman) 2005-03-17 22:31:45.000-0600 I'm not sure how functions would be a relevent substitute for this patch.  Remember, this lookup occurs at FXS pickup time, to know whether or not to send a stutter tone, before the dialplan even starts. By: Kevin P. Fleming (kpfleming) 2005-06-07 15:06:53 OK, so this one's been sitting idle for a while... Am I understanding this properly, that you want chan_zap to do this lookup into astdb every time the channel goes off-hook? If that's not important, but retrieving the data from astdb is (but not dynamically, only on 'reload'), then I think we can possibly make a more general solution. Thoughts? By: Tilghman Lesher (tilghman) 2005-06-07 15:40:46 Unfortunately, 'reload' doesn't do anything on Zap channels, and certain signalling (e.g. PRI) prevents that from being coded easily.  You're talking about a very complex write of a large amount of code, when doing a lookup into the astdb is quite simple and quite fast. There doesn't seem to be any good technical reason why not to do it the way that it has been coded here. By: Brian West (bkw918) 2005-06-07 16:57:55 Ok this way seems fine since its a compile option.. /b By: Kevin P. Fleming (kpfleming) 2005-06-07 17:33:32 Well, actually, I've been thinking of an expression syntax for config files... So, you'd be able to do something like this in zapata.conf: mailbox=$[${DB(mailboxes/${ZAPCHANNEL})}] Obviously this would require the module hosting the expressions to feed some variables into the parser, so that the 'context' of the expression could be referenced. I think this would be fairly reasonable to implement, and generic enough to be useful for many different things. The biggest issue is whether the expression evaluation would be done at config load time or at runtime (which would obviously be more expensive). By: Tilghman Lesher (tilghman) 2005-06-07 17:48:12 Let's try this again.  The code executes BEFORE THE BLOODY DIALPLAN STARTS.  You CANNOT, repeat CANNOT, repeat CANNOT, repeat CANNOT use dialplan logic to do what this patch does. Are we clear, or are you going to mention dialplan functions again? By: Tilghman Lesher (tilghman) 2005-06-07 17:49:27 And NOTHING HAPPENS with zapata.conf WHEN YOU RELOAD. By: Tilghman Lesher (tilghman) 2005-06-07 17:59:02 And while I'm at it, why don't I point out that pbx_ stuff loads AFTER chan_ stuff, which means functions won't even be available at load time until after chan_ stuff is already loaded? By: Kevin P. Fleming (kpfleming) 2005-06-07 18:13:18 Did you read what I wrote? I did not say anything about the dialplan at all, I mentioned using an expression parser that could leverage the existing functions to do this stuff. While those functions do get a 'channel' argument, nearly all of them do not care under what circumstances they get run, they just do their job and return a result. An modified version of the existing expression parser that accepted a predefined list of variables (name/value pairs) and didn't care about channels would be able to parse these expressions at _any_ time; that could be at config load time, or it could be every single time the module wants to make use of the expression. In this particular case, chan_zap could remember that it was given an expression for 'mailbox' instead of a string value, and make a call into the parser to get a result value to use for the mailbox name/context. It could do that whenever it wanted to do so. By: Brian West (bkw918) 2005-06-07 20:32:08 I thought you could reload zapata.conf on everything but signalling? /b By: Anthony Minessale (anthm) 2005-06-09 15:06:12 How bout a compromise? Say you can make a new construct in the config parser. something => #DB(myfam/mykey) '#' tells you ++ the pointer to the value string and feed it to the function parser before adding the result. # also serves as a menomonic that it's a preprocess So then all the functions can have a bit that says "I am safe to call in a preprocess fashion as well as one for a runtime one. then you could have "preprocess only" funcs and "runtime only" funcs or both at once. If you took it a step back and actually honored the $[] and ${} and allowed an environment you would be stepping on the toes of the pbx_config.c and would be a paradox.  the DB func alone as the original patch proports gives you some pretty good power. By: Michael Jerris (mikej) 2005-06-27 22:42:51 Closed due to no response from OP.  If you would like to continue with this bug, please re-open with updates.