[asterisk-bugs] [JIRA] (ASTERISK-23046) Custom CDR fields set during a GoSUB called from app_queue are not inserted

Tue Jan 21 23:29:03 CST 2014

    [ https://issues.asterisk.org/jira/browse/ASTERISK-23046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=214293#comment-214293 ] 

Denis Pantsyrev commented on ASTERISK-23046:
--------------------------------------------

{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}

> Custom CDR fields set during a GoSUB called from app_queue are not inserted
> ---------------------------------------------------------------------------
>
>                 Key: ASTERISK-23046
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23046
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CDR/cdr_custom, CDR/General
>    Affects Versions: 11.7.0
>         Environment: CentOS 6.5, MySQL
>            Reporter: Denis Pantsyrev
>            Assignee: Denis Pantsyrev
>            Severity: Minor
>
> 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 at test:1] Answer("SIP/333-00000004", "") in new stack
>        > 0x7f320801cb50 -- Probation passed - setting RTP source address to 192.168.1.49:4008
> -- Executing [400 at test:2] Set("SIP/333-00000004", "CDR(mambo)=Mambo") in new stack
> -- Executing [400 at 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 at subEtt:1] Set("SIP/333-00000005", "CDR(userfield)=Field_1") in new stack
>     -- Executing [s at subEtt:2] NoOp("SIP/333-00000005", "Field_1") in new stack
>     -- Executing [s at subEtt:3] Set("SIP/333-00000005", "CDR(userfield2)=Field_2") in new stack
>     -- Executing [s at subEtt:4] NoOp("SIP/333-00000005", "Field_2") in new stack
>     -- Executing [s at 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} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira