[asterisk-users] ForkCDR

[David Backeberg]

I think these are great changes. I have been recently working with
ForkCDR, ResetCDR, trying to get records that make any sense. I think
the best way to make changes is exactly what you propose:
retain the default behaviour, and add flags that make ForkCDR do what
people think it should do.

Thanks for taking a look at this! When these are in, I'll jump all
over getting these into voip-info

On Tue, May 27, 2008 at 2:12 PM, Steve Murphy <murf at digium.com> wrote:
> 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?
>
> 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
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>