[Home]

Summary:ASTERISK-12085: ForkCDR application fails to set duration
Reporter:Binu Nair (binuvb)Labels:
Date Opened:2008-05-27 01:51:01Date Closed:2008-05-28 23:05:35
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_forkcdr
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Thanks in advance.

I have made a call back system using the callfiles. So when clients call up some access number (which will come to asterisk), asterisk would disconnect, call them back and plays an IVR, where the clients can dial international numbers and speak.

Here i used to generate 2 CDRs , one calling from asterisk to the client's number and then from client's number to the number he/she dials. Both these will be charged under the client's account(which is done by separate program  made by me).
I was using ForkCDR to generate the extra CDR
All these happened without any trouble in ast - 1.4.4. But of late, I changed to ast-1.4.18. Now i get only one CDR.

I did some googling and found out that in ast-1.4.18 , there were some changes made which caused this. Will this feature be restored or can I revert to an old version of forkcdr (within 1.4.18 itself)
=============================================================
I got the below solution from the net which appeared to solve my problem. I tried it , but failed
====================================================================
# svn co http://svn.digium.com/svn/asterisk/tags/1.4.18 asterisk-1.4.18
# cd asterisk-1.4.18
# svn diff -c 82444 > m10668.patch
# patch -R -p0 < m10668.patch

that should give you version with that specific patch reverted, then
you can just upgrade to next version by
# svn switch http://svn.digium.com/svn/asterisk/tags/1.4.19
and re- make, make install
==========================================================================

Please do reply me and solve this.


Thanks once again
Comments:By: Tilghman Lesher (tilghman) 2008-05-27 08:28:41

Please check your settings in cdr.conf.  The production of an additional record is now controlled from there.
By: Steve Murphy (murf) 2008-05-27 13:31:08

binuvb-- The moment you mentioned forkCDR(), I shuddered.
But your solution (reverting the changes submitted via bug
10668) is not going to fly. The fact that forkCDR introduced
the "CDR stack", and marked the current entry as "LOCKED",
was not uniformly enforced in the other CDR functions,
a problem that 10668 pointed out, and we fixed.

IF 10668 was not appropriate, there is no documentation
to explain how and why NOT enforcing locking on the stack
would be desirable and necessary. Indeed, I viewed the
whole thing as an oversight and enforced locking. The guy
who submitted the bug didn't compain about it since it was
done back in Sept.

I'm going to tie this bug to 10668, and also to 11721. Please
see if you can refer to my posting that i just did on the
asterisk-users mailing list subject "ForkCDR". I'm proposing
a set of suggested options to add to forkCDR, and using one
or more of them may just solve your problem.
By: Binu Nair (binuvb) 2008-05-28 02:41:40

just applied arkadia's patch(http://bugs.digium.com/file_download.php?file_id=15457&type=bug).

got things working.

Thanks everybuddy
By: Digium Subversion (svnbot) 2008-05-28 19:19:07

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:24:05

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:35

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