[asterisk-bugs] [JIRA] (ASTERISK-23174) CDR and app_queue documentation issues
Rusty Newton (JIRA)
noreply at issues.asterisk.org
Tue Jan 21 20:59:02 CST 2014
[ 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
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).
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
> 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
More information about the asterisk-bugs
mailing list