[asterisk-bugs] [Asterisk 0010668]: Incomplete CDR lock

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10668 
====================================================================== 
Reported By:                arkadia
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   10668
Category:                   CDR/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             09-07-2007 08:26 CDT
Last Modified:              06-06-2008 18:16 CDT
====================================================================== 
Summary:                    Incomplete CDR lock
Description: 
This is all about the meaning of AST_CDR_FLAG_LOCKED flag for CDR. 
I assume if CDR has this flag set then it wont be updated anymore by any
ast_cdr_ functions except cases when we force such update. ast_cdr_reset()
is example of function which allows to update locked CDRs if special flag
is given.

Based on this assumption I prepared the patch with such changes:

  ast_cdr_setvar() - not allowed to touch locked CDRs. I don't see any
cases when we need to change locked CDRs too. Not touching locked CDRs is
helpfull when ForkCDR being used and every new CDR may have different
custom variables.

  ast_cdr_answer() - don't change status of locked CDRs. That might be
helpfull when we have a chain of CDRs for one incoming call for which we
perform several tries to make outgoing call. Every outgoing attempt may
finish with its own completion code. And if the final attempt is 'answered'
then we have only one CDR with 'answered' status. All other will keep
connection error codes which is very helpful for error monitoring.

 ast_cdr_end() - don't change locked CDRs by the same reason as
ast_cdr_answer()

As there will be no changes in CDR after lock, app_forkcdr.c should be
updated to end original locked CDR.
Also it'll be great to make optional cdr reset in this application, but
thats a theme for another patch.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0012726 ForkCDR application fails to set duration
====================================================================== 

---------------------------------------------------------------------- 
 murf - 06-06-08 18:16  
---------------------------------------------------------------------- 
OK, that explains it; the patch was against 1.4, as that's the version
you reported in the bug report.

I apologize for my previous inaccuracy; yes, setvar has only the recur
option, and two modes of operation. But the only way to get at setvar
from
the dialplan is to use the CDR func, and that provides the (l for last)
3rd
option. It just advances the cdr ptr to the last in the chain before
calling
the setvar func.

Now, don't get me wrong. I am not proposing the 'u' option. I was
asking if you are proposing it. If you are, you need to explain to
me why you'd need this. I'd rather not include it. 

As to changing the setvar func to make it so it doesn't touch LOCKED
cdrs, well, my reaction is no. The way ForkCDR is constructed,
all CDR's but the last in a chain will be locked. Thus, you get
this behavior without anything needing to be changed, if you 
use the CDR() func with the 'l' option (small-L). (after I commit
the change to make CDR honor the 'l' in writing).
If you can show me a concrete need that is not otherwise 
filled, I would like to leave setvar/CDR() as they are,
with only the 'l' flag fixed/honored on write. I'm not trying
to be contrary, it's just that this is released software, 
and people are using it. I'm trying to be as absolutely
minimal as possible when it comes to changes. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-06-08 18:16  murf           Note Added: 0087919                          
======================================================================