[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-10-2008 14:25 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-10-08 14:25  
---------------------------------------------------------------------- 
Arkadia--

I like the idea of not affecting the function interfaces. I uploaded the
patch4
file. the function interfaces have been returned to previous, and they
now
rely on the cdr struct containing a DONT_TOUCH flag instead.

The DONT_TOUCH can be set via a new option to forkCDR.

> I'm saying from the beg[inn]ing this bug report is about ast_cdr_... API
only and cdr.c changes.

Sorry if I've been a bit dense, but you **have** expressed interest in
dialplan
app changes:

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

as well as all the discussion over forkCDR and CDR()... 

But, the app/func work I've been pushing is not just for you. I've gotten
phone calls, email, and have been involved in IRC discussions on these
sort of issues for about a year. And while you may only peripherally care
about the dialplan app/func changes, they will be key to folks who are
having
problems in developing billing apps with the current restrictions of the
CDR system. 

Also, I'd prefer to have users developing apps, use the dialplan
app/func interface, rather than coding in C in the source code. Your app
will be much more upwardly compatible and portable than keeping your own
patches up to date against a shifting code tree. Just the fact that you
are mucking around with the ast_cdr_xxx funcs tells me that the dialplan
interface is not sufficient for you. But you can't say I didn't try!

What do you think of the patch4 stuff? Is it OK to commit it? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-10-08 14:25  murf           Note Added: 0088564                          
======================================================================