[Home]

Summary:ASTERISK-11191: When using ForkCDR Asterisk does not set the duration and billsec correcty
Reporter:Loic Didelot (voipgate)Labels:
Date Opened:2008-01-09 19:46:34.000-0600Date Closed:2008-05-28 23:05:33
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_forkcdr
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_forkcdr.c
Description:When using ForkCDR and the call has not been answered, Asterisk creates 2 cdr's but one of them lacks the data for billsec and duration. The purpose of a fork is to create 2 cdrs but with different variables (accountcode, userfield) but the duration and bill seconds as well as the disposition must be set.
Comments:By: Mark Berry (markab21) 2008-01-24 14:41:05.000-0600

I've been able to replicate this issue and have tracked down the issue to the flag being set on forkcdr:

ast_set_flag(cdr, AST_CDR_FLAG_CHILD | AST_CDR_FLAG_LOCKED);


The CDR record is being locked, but never cleared.  I've not figured out why this is the case, but by simply changing the line of code to:


ast_set_flag(cdr, AST_CDR_FLAG_CHILD);

(removing the flag of AST_CDR_FLAG_LOCKED )

Resolved the issue.

I've tested the change on both 1.4.14 and 1.6 beta 1 and this issue didn't have any negative impact on the CDR postings.  


I've attached a new app_forkcdr.c with the fixes in it.
By: Julien Thomas (jthomas) 2008-02-27 14:43:38.000-0600

I experience definitely the same problem.
Tested on version 1.4.14, 1.4.17.

CDR duration and billsec fields are set to zero value (in my tries even if the disposition is ANSWERED).

ForkCDR is working as it should on a 1.2.24.

But 1.2.24 has also the line:

ast_set_flag(cdr, AST_CDR_FLAG_CHILD | AST_CDR_FLAG_LOCKED);

So I think there is something else to look at.
By: Damian Adamski (sh0t) 2008-03-19 07:04:52

I have the same problem with ForkCDR on 1.4.18 and 1.4.19-rc3
both values (billsec and duration) are zero after ForkCDR

It was working with 1.4.11

log from the cli:
[Mar 19 12:19:20]   == Spawn extension (info800-2, s, 2) exited non-zero on 'SIP/48525514155-b790c8a8'
[Mar 19 12:19:20]   == End MixMonitor Recording SIP/48525514155-b790c8a8
[Mar 19 12:19:20] WARNING[3121]: cdr.c:993 post_cdr: CDR on channel 'SIP/48525514155-b790c8a8' lacks end
[Mar 19 12:19:20] NOTICE[3121]: cdr.c:437 ast_cdr_free: CDR on channel 'SIP/48525514155-b790c8a8' lacks end

Removing AST_CDR_FLAG_LOCKED as mentioned above makes my CDR record not to fork (I have only one record per call)
By: Julien Thomas (jthomas) 2008-03-19 12:23:09

No one seams to be concerned about that bug but fixing it would be very good in the design of that billing application we are planning to write. At the moment I don't have the time to investigate deeply, but anyway it would be painful since I do not really know about Asterisk coding.
By: Damian Adamski (sh0t) 2008-04-22 08:13:24

I found that this problem can have something with this issue:

http://bugs.digium.com/view.php?id=10668

I'll try to compile it later without this patch.

http://svn.digium.com/view/asterisk/branches/1.4/main/cdr.c?r1=82444&r2=82443&pathrev=82444
By: Digium Subversion (svnbot) 2008-05-28 19:19:05

Repository: asterisk
Revision: 118858

U   branches/1.4/apps/app_forkcdr.c
U   branches/1.4/main/cdr.c

------------------------------------------------------------------------
r118858 | murf | 2008-05-28 19:19:02 -0500 (Wed, 28 May 2008) | 46 lines

(closes issue ASTERISK-10252)
(closes issue ASTERISK-11191)
(closes issue ASTERISK-12085)
Reported by: arkadia
Tested by: murf

These changes:

1. revert the changes made via bug 10668;
  I should have known that such changes,
  even tho they made sense at the time,
  seemed like an omission, etc, were actually
  integral to the CDR system via forkCDR.
  It makes sense to me now that forkCDR didn't
  natively end any CDR's, but rather depended
  on natively closing them all at hangup time
  via traversing and closing them all, whether
  locked or not. I still don't completely
  understand the benefits of setvar and answer
  operating on locked cdrs, but I've seen
  enough to revert those changes also, and
  stop messing up users who depended on that
  behavior. bug 12726 found reverting the changes
  fixed his changes, and after a long review
  and working on forkCDR, I can see why.
2. Apply the suggested enhancements proposed
  in 10668, but in a completely compatible
  way. ForkCDR will behave exactly as before,
  but now has new options that will allow some
  actions to be taken that will slightly
  modify the outcome and side-effects of
  forkCDR. Based on conversations I've had
  with various people, these small tweaks
  will allow some users to get the behavior
  they need. For instance, users executing
  forkCDR in an AGI script will find the
  answer time set, and DISPOSITION set,
  a situation not covered when the routines
 were first written.
3. A small problem in the cdr serializer
  would output answer and end times even
  when they were not set. This is now
  fixed.



------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=118858
By: Digium Subversion (svnbot) 2008-05-28 20:23:26

Repository: asterisk
Revision: 118880

_U  trunk/
U   trunk/apps/app_forkcdr.c
U   trunk/main/cdr.c

------------------------------------------------------------------------
r118880 | murf | 2008-05-28 20:22:59 -0500 (Wed, 28 May 2008) | 54 lines

Merged revisions 118858 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r118858 | murf | 2008-05-28 18:25:28 -0600 (Wed, 28 May 2008) | 46 lines

(closes issue ASTERISK-10252)
(closes issue ASTERISK-11191)
(closes issue ASTERISK-12085)
Reported by: arkadia
Tested by: murf

These changes:

1. revert the changes made via bug 10668;
  I should have known that such changes,
  even tho they made sense at the time,
  seemed like an omission, etc, were actually
  integral to the CDR system via forkCDR.
  It makes sense to me now that forkCDR didn't
  natively end any CDR's, but rather depended
  on natively closing them all at hangup time
  via traversing and closing them all, whether
  locked or not. I still don't completely
  understand the benefits of setvar and answer
  operating on locked cdrs, but I've seen
  enough to revert those changes also, and
  stop messing up users who depended on that
  behavior. bug 12726 found reverting the changes
  fixed his changes, and after a long review
  and working on forkCDR, I can see why.
2. Apply the suggested enhancements proposed
  in 10668, but in a completely compatible
  way. ForkCDR will behave exactly as before,
  but now has new options that will allow some
  actions to be taken that will slightly
  modify the outcome and side-effects of
  forkCDR. Based on conversations I've had
  with various people, these small tweaks
  will allow some users to get the behavior
  they need. For instance, users executing
  forkCDR in an AGI script will find the
  answer time set, and DISPOSITION set,
  a situation not covered when the routines
 were first written.
3. A small problem in the cdr serializer
  would output answer and end times even
  when they were not set. This is now
  fixed.



........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=118880
By: Digium Subversion (svnbot) 2008-05-28 23:05:33

Repository: asterisk
Revision: 118909

_U  branches/1.6.0/
U   branches/1.6.0/apps/app_forkcdr.c
U   branches/1.6.0/main/cdr.c

------------------------------------------------------------------------
r118909 | murf | 2008-05-28 23:05:27 -0500 (Wed, 28 May 2008) | 62 lines

Merged revisions 118880 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r118880 | murf | 2008-05-28 19:29:09 -0600 (Wed, 28 May 2008) | 54 lines

Merged revisions 118858 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r118858 | murf | 2008-05-28 18:25:28 -0600 (Wed, 28 May 2008) | 46 lines

(closes issue ASTERISK-10252)
(closes issue ASTERISK-11191)
(closes issue ASTERISK-12085)
Reported by: arkadia
Tested by: murf

These changes:

1. revert the changes made via bug 10668;
  I should have known that such changes,
  even tho they made sense at the time,
  seemed like an omission, etc, were actually
  integral to the CDR system via forkCDR.
  It makes sense to me now that forkCDR didn't
  natively end any CDR's, but rather depended
  on natively closing them all at hangup time
  via traversing and closing them all, whether
  locked or not. I still don't completely
  understand the benefits of setvar and answer
  operating on locked cdrs, but I've seen
  enough to revert those changes also, and
  stop messing up users who depended on that
  behavior. bug 12726 found reverting the changes
  fixed his changes, and after a long review
  and working on forkCDR, I can see why.
2. Apply the suggested enhancements proposed
  in 10668, but in a completely compatible
  way. ForkCDR will behave exactly as before,
  but now has new options that will allow some
  actions to be taken that will slightly
  modify the outcome and side-effects of
  forkCDR. Based on conversations I've had
  with various people, these small tweaks
  will allow some users to get the behavior
  they need. For instance, users executing
  forkCDR in an AGI script will find the
  answer time set, and DISPOSITION set,
  a situation not covered when the routines
 were first written.
3. A small problem in the cdr serializer
  would output answer and end times even
  when they were not set. This is now
  fixed.



........

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=118909