[asterisk-users] ForkCDR

[Michael Collins]

> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-
> bounces at lists.digium.com] On Behalf Of Steve Murphy
> Sent: Tuesday, May 27, 2008 11:12 AM
> To: asterisk-users
> Subject: [asterisk-users] ForkCDR
> 
> Hello, CDR fans!

I guess not too many CDR fans out there! :)

> 
> I'm looking at some issues brought forward over time:
> 
> 12726/10668: someone wants me to revert the changes I made via
>             bug 10668, last Sept; (that's
>             they are messing him up. And I didn't do the change
>             suggested in ForkCDR, for fear of lousing up
>             folks depending on current behavior. Which probably
sparked:
> 11721 : ForkCDR's not yielding CDR with proper duration/billsec.
> 
> Add to that some calls I've gotten recently from "dude" on forkCDR
> messing up the answer() times.
> 
> My thoughts: Whatever ForkCDR was really, really meant to do, since
> not well documented, I have fear of touching, but, I do have
suggestions
> to fix various clearly erroneous behaviors, and in order to suppress
> the number of complaints, I propose this:
> 
> Adding ALL suggested changes in behavior to ForkCDR, but each
> with a controlling option. By Default, ForkCDR() will behave the
> way it always has.
> 
> Right now, ForkCDR() has the v option, which carries forward the
> variables on the old CDR.
> 
> I propose adding:
> 
> a - update the answer time on the NEW CDR just after it's been inited.
>     The new CDR may have been answered already, the reset that forkcdr
>     does will erase the answer time. This will bring it back, but
>     the answer time will be a copy of the fork/start time. It will
>     only do this if the initial cdr was indeed already answered.
> D - Copy the disposition forward from the old cdr, after the
>     init.
> d - Clear the dstchannel on the new CDR after reset.
> e - end the original CDR. Do this after all the necc. data
>     is copied from the original CDR to the new forked CDR.
> R - do NOT reset the new cdr.
> s(name=val) - Set the CDR var 'name' in the original CDR, with value
> 'val'.
>               (you can do the same thing on the new cdr with the CDR()
> func.)
> (the current 'v' option will not change)
> 
> 
> Most of these came from "arkadia" via the bug tracker,
> with a and D being points from "dude". Using R may make
> a and D useless; but there may be reasons to not use R
> instead...
> 
> The complaints about billsec/duration not being set are
> because one of the necessary times aren't in the CDR,
> either start, answer or end.
> 
> All this will be done in trunk; but my real question is:
> 
> Can I apply this fix to 1.4 and 1.6.0 also? It may be an enhancement,
> but it does *fix* problems folks are having in 1.4 etc!
> Things that make this a little easier to swallow:
> a. forkCDR behavior for existing users WILL NOT CHANGE. Users
>    have to add options to the call to get the new behavior.
> b. No existing users should be hurt by the enhancement. If they
>    found a magic way to make it do what needed to be done,
>    they will not be inconvenienced, unless they have stray
>    accidental options in their forkcdr() calls in their dialplan,
>    that just happen to line up with an option that will be added.
>    I don't see this as a major problem.
> 
> My best explanation for all this is that forkCDR, and how it was
> *meant* to be used, was never documented. If it had been, folks
> would have been spared a lot of grief. Because I never could quite
> picture the intended flow of usage and events from the dialplan,
> I couldn't preserve it, and users were left to try to decode
> for themselves  how to make it work considering the other
> constraints the CDR system places on them.
> 
> For instance, in 1.2, forkCDR didn't end the previous CDR,
> or have any options for that. The 1.4 (and trunk version
> for that matter) are pretty faithful to the 1.2 version of
> forkCDR.
> 
> I think the usage of ForkCDR has far surpassed its original
intentions,
> and the things it did by default are not the best for all the
> scenarios folks want to use it in, so I think the time has come to
> try to put enough options into it so that 1.4 and 1.6.x users
> can get what they need out of it.
> 
> So, give me your opinions. Is it OK with the community to backport
> this enhancement into 1.4 and 1.6.0?

If you *PROMISE* that the change won't affect the default behavior then
I can't see any real reason not to implement in both 1.4 and 1.6.

-MC

> 
> And, are the above options enough for you all? Any you'd like to see
> added/removed from the above list?
> 
> BTW, CEL is moving along as well.
> 
> murf
> 
> --
> Steve Murphy
> Software Developer
> Digium