[asterisk-bugs] [JIRA] (ASTERISK-23174) CDR and app_queue documentation issues

[Rusty Newton (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-23174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-23174:
------------------------------------

    Status: Open  (was: Triage)
    
> CDR and app_queue documentation issues
> --------------------------------------
>
>                 Key: ASTERISK-23174
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23174
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CDR/cdr_custom, CDR/General
>    Affects Versions: SVN, 12.0.0
>         Environment: Asterisk 12, chan_sip, app_queue, cdr_custom, cdr_csv
>            Reporter: Rusty Newton
>            Severity: Minor
>
> Found a few CDR related documentation issues while looking into ASTERISK-23069 and ASTERISK-23046. 
> Due to the nature of the two issues, the test involved a SIP peer calling into a Queue and being answered by a queue member.
>  * CDR variables are set on the calling channel and the called channel. That is, we are setting CDR before AND after a macro OR gosub is called from app_queue (see macro or gosub params). The macro and gosub are executed on the called channel.
>  * I observed this behavior with both cdr_csv.so and cdr_custom.so
> Description in CDR function help text:
> {noformat}
> All of the CDR field names are read-only, except for 'accountcode', 'user
> field', and 'amaflags'. You may, however, supply a name not on the above list,
> and create your own variable, whose value can be changed with this function,
> and this variable will be stored on the CDR.
> NOTE: CDRs can only be modified before the bridge between two channels is
> torn down. For example, CDRs may not be modified after the 'Dial' application
> has returned.
> Example: exten => 1,1,Set(CDR(userfield)=test)
> {noformat}
> ISSUE 1
> *cdr_csv*:  Setting a new CDR field on the *calling* channel before it is bridged or the *called* channel after they are bridged does not result in a new field being generated in the .csv file.
> *cdr_custom*:  If the new fields are specified in the mapping in cdr_custom.conf, the above works fine and results in CDR showing fields set on the calling and called parties channels.
> CDR function documentation isn't clear about when new user defined fields are pushed out to a backend. That is, which backends will generate CDR with the "create your own variable" from the CDR function. This should be documented in the CDR function, and at least in cdr_custom.conf.sample.
> ISSUE 2
> *cdr_csv and cdr_custom*: Setting the userfield on each channel involved in the call results in the field having two values delimited by a semi-colon. This is not mentioned in documentation anywhere
> ISSUE 3
> *cdr_csv and cdr_custom*: Setting the userfield once, on the called channel, results in a value prefixed with a semi-colon. This is not mentioned in the documentation.
> ISSUE 4
> The app_queue documentation for the "macro" parameter is incorrect. The macro is executed by the called channel (the queue member) and not the calling channel as stated in the help text.
> This was also the same for the "gosub" parameter, which we recently modified.

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