Summary:	ASTERISK-17190: [patch] CEL logging to ODBC field not being stored.
Reporter:	Bryant Zimmerman (zktech)	Labels:
Date Opened:	2010-12-30 10:35:22.000-0600	Date Closed:	2012-01-13 11:14:01.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	CEL/General
Versions:		Frequency of Occurrence
Related Issues:	is related to ASTERISK-17940 [patch] Peer not recorded on CEL_BRIDGE_START and CEL_BRIDGE_END is related to ASTERISK-17189 [patch] CEL logging to ODBC Eventtype error on userdefined type
Environment:		Attachments:
Description:	CEL fields not being updated in ODBC storage. eventextra field not being stored. peer field not being stored. Documentation is incorrect. https://wiki.asterisk.org/wiki/display/AST/CEL+Events+and+Fields cel_odbc.conf Neither have the eventextra field listed but the cel_custom.conf has it listed. The wiki does not have the userdeftype field listed.
Comments:	By: Steve Murphy (murf) 2010-12-30 14:59:17.000-0600 OK, an inspection of the code says that one problem is because of "misdocumentation" (probably because of ME). The name of the var in the CEL world is not "peer", but rather "BRIDGEPEER". I will update the config files to correct this; I apologize. If I change it back to "peer", then everyone with working s/w will be hurt. The fix involves editing cel_custom.conf.sample by trading ${CHANNEL(peer)} for ${BRIGEPEER}. In configs/cel_sqliste3_custom.conf.sample, the same replacement, but the columns spec can retain the "peer" name. In the case of the cel_odbc config file, I replaced the comment about "peer" with "BRIDGEPEER" instead, and added eventextra to the list of fields. I would think you could call the column "peer" by using some mapping in the cel_odbc config file, right? Similar changes in the cel_pgsql.conf.sample file. Next, the "eventextra". This field was not being copied into the field via the code in cel_odbc.c; I will endeavor to add the missing two lines of code. Can you update the wiki entry when this bug is closed? By: Bryant Zimmerman (zktech) 2010-12-30 15:36:56.000-0600 Ok so if I change the name of the peer field in my database from peer to bridgepeer then will that start to give me the channel being bridged? The other option would be to do an alias in the cel_odbc.conf to map bridgepeer to peer. Is this a correct understanding?  Either option works for me on this as I have not commited any code to the peer field name yet? "eventextra"  Does the error also effect cel_pgsql module as well or just the cel_odbc one? As long as I can log into the wiki entry I will update it once we are done. By: Steve Murphy (murf) 2010-12-30 18:13:37.000-0600 The patch on 18559 fixes this issue as well, so pick it there. In answer to previous questions: > Ok so if I change the name of the peer field in my database from peer to > bridgepeer then will that start to give me the channel being bridged? > >The other option would be to do an alias in the cel_odbc.conf to map bridgepeer >to peer. I believe you can use either option. do caps make a difference? Use BRIDGEPEER if so.  Sheesh, I must have braindead when I invented that name. > Does the error also effect cel_pgsql module as well or just the cel_odbc one? I just changed the comments in the pgsql config file for cel. So, I would assume that you'd have to rename the column there. By: Bryant Zimmerman (zktech) 2011-01-03 08:47:16.000-0600 I tried the alais option in the cel_odbc.conf and did a core reload. The bridgepeer is not mapping to the peer field. I tried both lowercase and uppercase. Any Ideas alias bridgepeer => peer alias BRIDGEPEER => peer By: Bryant Zimmerman (zktech) 2011-01-03 16:29:10.000-0600 I added a bridgepeer field to my database and no joy I still do not get the bridge channel being stored? Any other ideas? I remove all of my alias entries and restared asterisk prior to testing. Bryant By: Steve Murphy (murf) 2011-01-04 17:31:32.000-0600 Sorry, my mistake; the BRIDGEPEER has to be used in the sqlite3 and csv_custom backends; otherwise, it's just "peer".  Now, if you get nothing but empty space, then, the bridged peer slot in the channel is empty, and if this is unexpectedly so, then there's a little deeper debug to go thru. By: Steve Murphy (murf) 2011-01-04 17:34:30.000-0600 I'm going to attach another corrected patch here tonight. Before I do it, would everyone be OK with me renaming the "eventextra" field to just "extra"? iirc, The guys who fixed this previously had named it that, and I hate to muck them up. By: Nic Colledge (nic) 2011-04-28 15:20:45 I just tried this patch against 1.8.4-rc2 on a test machine and it seems it breaks the Peer / BRIDGEPEER fields and cel_pgsql. Basically, on 1.8.4-rc2 with no patch, I used to get the peer field filled in for some events on an attended transfer. With this patch, peer is not used but neither is BRIDGEPEER (no matter what I call it nothing get filled in with the patch). Another question I have is should BRIDGEPEER / peer be used for Event CEL_BRIDGE_START (id 7)? Ive never seen it filled in for this event and IMHO it should be. Nic. By: Nic Colledge (nic) 2011-05-28 12:21:00 Just a quick FYI note, I managed to fix the Peer field thing I was talking about for CEL_BRIDGE_START and CEL_BRIDGE_END myself patches are attached to 0019383 (ASTERISK-17940). Nic.