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

noreply at bugs.digium.com noreply at bugs.digium.com
Wed Sep 12 03:50:32 CDT 2007


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:                     assigned
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:              09-12-2007 03:50 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.
====================================================================== 

---------------------------------------------------------------------- 
 arkadia - 09-12-07 03:50  
---------------------------------------------------------------------- 
I understand your concerns about ForkCDR. But we may save its original
behavior adding extra LOCK flag (e.g. AST_CDR_FLAG_FORKLOCK) in
ast_cdr_setvar(), ast_cdr_answer(), ast_cdr_end(). This flag will be set by
ForkCDR and will keep CDR unlocked in mentioned functions.

Standard AST_CDR_FLAG_LOCKED will be treated in every ast_cdr_* function
as its done in this patch and according our initial assumption what lock
should do. I assume these changes compatible with your cdr work in
res/res_features.c.


This open possibilities for another 'fork' application. Here is possible
description (I'm working on it right now for my own purpose):

[Synopsis]
Forks the Call Data Record

[Description]
  ForkCDRext([options]):  Causes the Call Data Record to fork an
additional
cdr record starting from the time of the fork call.
  Options:
    d - clear dstchannel on new CDR
    e - end original CDR. Without this option original CDR not ended.
    R - don't reset new CDR. By default reset new CDR.
    s(name=val) - set CDR variable in original CDR
    v - all cdr variables will be passed along also. Keep all CDR vars.

  Example: we need status of previous Dial attempt,
we don't want duplicate CDRs with the same dstchan and its error,
previous CDRs will be marked with additional variable 'cdridx'.
  ForkCDRext(deRvs(cdridx=${ROUTENUM}))


It may be implemented compatible with current ForkCDR() or ForkCDR(v)
calls if required. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-12-07 03:50  arkadia        Note Added: 0070379                          
======================================================================




More information about the asterisk-bugs mailing list