[asterisk-users] ForkCDR

[Steve Murphy]

Hello, CDR fans!

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? 

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20080527/caf4e660/attachment.bin