| Summary: | ASTERISK-23046: Custom CDR fields set during a GoSUB called from app_queue are not inserted | ||||||
| Reporter: | Denis Pantsyrev (StuxForce) | Labels: | |||||
| Date Opened: | 2013-12-19 23:18:25.000-0600 | Date Closed: | 2014-02-06 17:06:39.000-0600 | ||||
| Priority: | Minor | Regression? | |||||
| Status: | Closed/Complete | Components: | CDR/cdr_custom CDR/General | ||||
| Versions: | 11.7.0 | Frequency of Occurrence | Constant | ||||
| Related Issues: |
| ||||||
| Environment: | CentOS 6.5, MySQL | Attachments: | |||||
| Description: | When I use the dialplan below, the additional field "mambo" and standard field "userfield" are filled with data, but additional field "userfield2" is not!
All additional fields are present in DB. Not only "userfield2" is not filled with data, but all additional fields in GoSUB context. Dialplan I used: {noformat} [test] exten => 400,1,Answer same => n,Set(CDR(mambo)=Mambo) same => n,Queue(test,,,,,,,subEtt) same => n,Hangup [subEtt] exten => s,1,Set(CDR(userfield)=Field_1) same => n,NoOP(${CDR(userfield)}) same => n,Set(CDR(userfield2)=Field_2) same => n,NoOP(${CDR(userfield2)}) same => n,Return() {noformat} My logs show: {noformat} testpc*CLI> core set verbose 9 Set remote console verbosity to 9 == Using SIP RTP CoS mark 5 -- Executing [400@test:1] Answer("SIP/333-00000004", "") in new stack > 0x7f320801cb50 -- Probation passed - setting RTP source address to 192.168.1.49:4008 -- Executing [400@test:2] Set("SIP/333-00000004", "CDR(mambo)=Mambo") in new stack -- Executing [400@test:3] Queue("SIP/333-00000004", "test,,,,,,,subEtt") in new stack -- Started music on hold, class 'default', on SIP/333-00000004 == Using SIP RTP CoS mark 5 -- SIP/333-00000005 is ringing -- SIP/333-00000005 answered SIP/333-00000004 -- Stopped music on hold on SIP/333-00000004 -- SIP/333-00000005 Internal Gosub(subEtt,s,1) start -- Executing [s@subEtt:1] Set("SIP/333-00000005", "CDR(userfield)=Field_1") in new stack -- Executing [s@subEtt:2] NoOp("SIP/333-00000005", "Field_1") in new stack -- Executing [s@subEtt:3] Set("SIP/333-00000005", "CDR(userfield2)=Field_2") in new stack -- Executing [s@subEtt:4] NoOp("SIP/333-00000005", "Field_2") in new stack -- Executing [s@subEtt:5] Return("SIP/333-00000005", "") in new stack == Spawn extension (test, 400, 1) exited non-zero on 'SIP/333-00000005' -- SIP/333-00000005 Internal Gosub(subEtt,s,1) complete GOSUB_RETVAL= -- Remotely bridging SIP/333-00000004 and SIP/333-00000005 > [INSERT INTO cdr (calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,userfield,mambo,uniqueid,linkedid,sequence) VALUES ({ ts '2013-12-18 09:03:50' },'"333" <333>','333','400','test','SIP/333-00000004','SIP/333-00000005','Queue','test,,,,,,,subEtt',1,1,'ANSWERED',3,'Field_1','Mambo','1387343030.4','1387343030.4','6')] == Spawn extension (test, 400, 3) exited non-zero on 'SIP/333-00000004' {noformat} | ||||||
| Comments: | By: Rusty Newton (rnewton) 2013-12-30 19:08:35.277-0600 Additionally it looks like the "gosub" parameter is not documented correctly for the Queue application. {noformat} gosub Will run a gosub on the calling party's channel once they are connected to a queue member. {noformat} As far as I can tell, the gosub is executed on the "called party", which should be the queue member. It looks to be that way in your test and in my test. In your case SIP/333-00000004 calls into the queue, gets connected to SIP/333-00000005 and then the gosub is executed with SIP/333-00000005. By: Rusty Newton (rnewton) 2013-12-30 19:17:15.962-0600 Linking to ASTERISK-23069 as the root issue may be the same. By: Denis Pantsyrev (StuxForce) 2013-12-30 22:46:16.664-0600 Yes, SIP/333 is a calling person and a queue member too. I used the same peer during testing this. But I think it does not affect the result. {quote} Additionally it looks like the "gosub" parameter is not documented correctly for the Queue application. As far as I can tell, the gosub is executed on the "called party", which should be the queue member. It looks to be that way in your test and in my test. {quote} I agree with this. By: Matt Jordan (mjordan) 2014-01-02 16:30:13.248-0600 I will say this much: if there is a problem here, it has nothing to do with CDRs. Putting custom variables on the Party B in a CDR doesn't show up in the CDR for Party A. If you need a custom property set on the Party A, you have to set it on that channel. By: Rusty Newton (rnewton) 2014-01-21 21:10:12.598-0600 [Edit - Also noting here that we fixed the documentation for the GoSUB param, so that it properly says "called" channel] It looks like with both cdr_csv and cdr_custom you can set the CDR variable userfield on both Party A and Party B and it will store both values for the field (semi-colon-delimited), like: "ISetThisOnTheCALLINGChannel;ISetThisOnTheCalledChannel" {noformat} "","6002","602","from-internal","""6002"" <6002>","SIP/6002-00000013","SIP/6001-00000014","Queue","support,,,,30,,my-queue-macro","2014-01-22 01:16:13","2014-01-22 01:16:15","2014-01-22 01:16:17",3,1,"ANSWERED","DOCUMENTATION","1390353373.28","ISetThisOnTheCALLINGChannel;ISetThisOnTheCalledChannel" {noformat} With cdr_custom, in Asterisk 12, if you set newly defined custom fields on Party A and Party B, they'll both show up on the CDR record printed to Master.csv if the mapping includes those fields in cdr_custom.conf. like: {noformat} """6002"" <6002>","6002","602","from-internal","SIP/6002-00000023","SIP/6001-00000024","Queue","support,,,,30,,,submytest","2014-01-21 19:50:50","2014-01-21 19:50:51","2014-01-21 19:50:52","1","0","ANSWERED","DOCUMENTATION","","1390355450.52",";ISetThisOnTheCalledChannel",35,"something1","something2" {noformat} The field holding something1 was set before the macro or gosub was called, and something2 was set after. That is, something1 was set on the calling channel and something2 set on the called channel. I'm not sure why they are not working in Denis' INSERT. @Denis, what database backend and CDR connector module are you using? Are the custom fields printing to your file defined in cdr_custom.conf correctly? By: Denis Pantsyrev (StuxForce) 2014-01-21 23:28:30.608-0600 {quote} @Denis, what database backend and CDR connector module are you using? Are the custom fields printing to your file defined in cdr_custom.conf correctly? {quote} I'm using MySQL (mysql-server.x86_64, 5.1.71-1.el6) and cdr_adaptive_odbc.so module. No, the custom fields are not printing in my file defined in cdr_custom.conf {code} "","333","400","test","""333"" <333>","SIP/333-00000000","SIP/333-00000001","Queue","test,,,,,,,subEtt","2014-01-22 05:23:24","2014-01-22 05:23:24","2014-01-22 05:23:26",2,2,"ANSWERED","DOCUMENTATION","1390368204.0","Field_1" {code} cdr_custom.conf {code} ; ; Mappings for custom config file ; ; To get your CSV output in a format tailored to your liking, uncomment the ; following lines and look for the output in the cdr-custom directory (usually ; in /var/log/asterisk). Depending on which mapping you uncomment, you may see ; Master.csv, Simple.csv, or both. ; [mappings] Master.csv => ${CSV_QUOTE(${CDR(clid)})},${CSV_QUOTE(${CDR(src)})},${CSV_QUOTE(${CDR(dst)})},${CSV_QUOTE(${CDR(dcontext)})},${CSV_QUOTE(${CDR(channel)})},${CSV_QUOTE(${CDR(dstchannel)})},${CSV_QUOTE(${CDR(lastapp)})},${CSV_QUOTE(${CDR(lastdata)})},${CSV_QUOTE(${CDR(start)})},${CSV_QUOTE(${CDR(answer)})},${CSV_QUOTE(${CDR(end)})},${CSV_QUOTE(${CDR(duration)})},${CSV_QUOTE(${CDR(billsec)})},${CSV_QUOTE(${CDR(disposition)})},${CSV_QUOTE(${CDR(amaflags)})},${CSV_QUOTE(${CDR(accountcode)})},${CSV_QUOTE(${CDR(uniqueid)})},${CSV_QUOTE(${CDR(userfield)})},${CDR(sequence)},${CSV_QUOTE(${CDR(mambo)})},${CSV_QUOTE(${CDR(userfield2)})} {code} cdr.conf {code} [general] enable=yes unanswered = yes [csv] usegmtime=yes ; log date/time in GMT. Default is "no" loguniqueid=yes ; log uniqueid. Default is "no" loguserfield=yes ; log user field. Default is "no" accountlogs=yes ; create separate log file for each account code. Default is "yes" {code} /etc/odbc.ini {code} [asterisk-connector] driver=MySQL server=localhost database=asterisk user=asterisk password=password {code} /etc/asterisk/res_odbc.conf {code} [asterisk] enabled => yes dsn => asterisk-connector username => asterisk password => password pre-connect => yes idlecheck => 3600 {code} cdr_adaptive_odbc.conf {code} [first] connection=asterisk table=cdr loguniqueid=yes dispositionstring=yes alias start => calldate {code} odbc show {code} ODBC DSN Settings ----------------- Name: asterisk DSN: asterisk-connector Last connection attempt: 1970-01-01 03:00:00 Pooled: No Connected: Yes {code} By: Matt Jordan (mjordan) 2014-02-06 17:06:36.762-0600 I'm not sure what the bug is here, and it isn't the original issue reported here. As such, I'm going to close this out, as this was resolved as a documentation problem in Queue. If there is an issue with a custom field not being displayed in a CDR record, I'd recommend opening up a separate issue. If you do have such a problem, make sure you attach a full DEBUG log illustrating the problem. Trying to debug such a problem without the dialplan and a log file illustrating it is going to be impossible. | ||||||