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

    Description: 
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.

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


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.

    
> 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