[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

The line

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

Should be modified to explicitly say that the CDR would only be available in CDR backends that support custom fields. For example, cdr_csv does not, but cdr_custom does.

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

This should be documented on the wiki as it has always been this way. The behavior was also carried over into 12 to avoid breaking things.

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.

This should be documented on the wiki and mention that you should always expect a ';' if the called party has a userfield.

  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


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

The line

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

Should be modified to explicitly say that the CDR would only be available in CDR backends that support custom fields. For example, cdr_csv does not, but cdr_custom does.

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

This should be documented on the wiki as it has always been this way. The behavior was also carried over into 12 to avoid breaking things.

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.

This should be documented on the wiki and mention that you should always expect a ';' if the called party has a userfield.

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, 1.8.25.0, 11.7.0, 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
> The line
> {noformat}
> 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.
> {noformat}
> Should be modified to explicitly say that the CDR would only be available in CDR backends that support custom fields. For example, cdr_csv does not, but cdr_custom does.
> 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
> This should be documented on the wiki as it has always been this way. The behavior was also carried over into 12 to avoid breaking things.
> 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.
> This should be documented on the wiki and mention that you should always expect a ';' if the called party has a userfield.

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