Summary:ASTERISK-23260: [patch]ForkCDR v option does not keep CDR variables for subsequent records
Reporter:zvision (zvision)Labels:
Date Opened:2014-02-07 04:45:11.000-0600Date Closed:2014-02-21 14:29:01.000-0600
Versions:11.8.0 Frequency of
Environment:Attachments:( 0) app_forkcdr.diff
Description:When the 'v' option is specified to ForkCDR application, AST_CDR_FLAG_KEEP_VARS flag is set only for the first CDR in the chain. So ForkCDR works fine with this option only once. After the second and further calls to ForkCDR, CDR variables get cleared on all CDRs besides the first one and moved to the newly forked CDR.
The problematic code is in the forkcdr_exec function:

 ast_set2_flag(ast_channel_cdr(chan), keepvars, AST_CDR_FLAG_KEEP_VARS);

It always sets the KEEP_VARS flag on the first CDR in the chain, instead of the most recent CDR which is used as a base to fork a new CDR.
Sample dialplan sequence that does not work:


The first CDR will get the 'one' variable set and KEEP_VARS flag set.
The second CDR will get no variables and KEEP_VARS cleared.
The third CDR will get one, two, three variables.
Comments:By: Matt Jordan (mjordan) 2014-02-07 06:33:27.491-0600

Thanks for the analysis on the issue. Since you've already found where the problem occurs, do you want to try and provide a patch that fixes the issue?

By: zvision (zvision) 2014-02-07 06:57:14.440-0600

Sure, I will test and provide a patch. Just wanted to confirm whether this is an intended behavior or not.
Thanks for formatting the code:)

By: zvision (zvision) 2014-02-07 09:59:28.309-0600

This patch sets KEEP_VARS flag on the most recent CDR on the stack (the CDR used for forking). In general, keeping this flag in CDR records is a bit redundant, as this flag is examined by the ForkCDR application only. In other places (ResetCDR), this flag is used for application parameters only.

By: Matt Jordan (mjordan) 2014-02-13 15:34:10.373-0600

Thanks for the patch!