[asterisk-dev] CEL userfield not storing

[Steve Murphy]

On Mon, Dec 27, 2010 at 3:58 PM, Bryant Zimmerman <BryantZ at zktech.com>wrote:

> Ok I figured out how to store the userfield. It only worked when I did a
> Set(CHANNEL(userfield)=value) I was doing a single underscore and it was not
> working.
>

Yes, the CEL code is written to store away only channel fields (not CDR
fields).  Userfield is stored on the channel directly (ignoring CDR stuff).


> So now this brings me to my other two questions with CEL.
>
> 1. Is there some way to store the extradata info in the odbc_database.  I
> can get userdeftype but I can't store the data supplied with it in a
> standalone field? This seems inconsistent at best as I can store it in a
> field in the cel-custom csv files. Am I just missing the correct field name.
> I can not find one in the documentation?
>

2. Is there some way to store custom channel variables to the CEL record in
> either the cel-custom csv or the database. What I am looking to do is to set
> a custom channel variable and have it stored when a CEL event is logged in
> either the database or csv. Is it currently possible to do?
>


When I originally wrote the CEL stuff, I knew people would want something
like this. But the first implementor didn't need this.
I remember playing with code to store channel vars beginning with CEL_ along
with the event;
whether it was a mental exercise, or whether I threw in some comments that
were later removed, I
cannot tell. I just looked at the current code, and I don't see anything to
do this sort of thing.
At any rate, it wouldn't be just this simple. We'd have to have some API
funcs to fetch those vars from the
event record. Some machinery in the backends to allow columns with such
names to be matched against
those vars, etc. And, I'd have to review the AST_EVENT stuff to see it could
handle multiple prop decls.
I'd bet that it could, and if not, we could just put them all in one record.

If this kind of thing isn't handled in the underlying layer of the CEL
stuff, then the cool stuff in the odbc
layer can't take advantage of it.

murf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20101228/dbdee4f9/attachment.htm>