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
> -----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 probablysparked:> 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 havesuggestions> 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 originalintentions,> 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
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 >