[asterisk-dev] Time for a bug fix phase?
john at johnlange.ca
Thu May 29 16:50:49 CDT 2008
Murf, I assume the features you are working on will be for a future
version of Asterisk?
Is there any chance of a simple non-controversial fix for 1.4.20 so that
transfers can be logged again?
I would be happy to patch and test and the diff would shed some light on
the whole CDR thing so I might be able to make better progress on the
code. I looked at it today but didn't get to far because I don't
understand the mechanics behind how it works.
On Thu, 2008-05-29 at 15:01 -0600, Steve Murphy wrote:
> On Thu, 2008-05-29 at 08:53 +0100, Grey Man wrote:
> > If the CDR coding starts again without coming up with a proper design
> > AND getting it agreed to by the couple of Digium employees that have
> > veto power on the Asterisk code contributions then it's likely to be a
> > wasted effort again.
> > The biggest problem here isn't developer resources it's getting a
> > design agreed on that will be incorporated into Asterisk. I could code
> > up a solution myself but it defeats the purpose if I then need to
> > maintain it separately and have to patch every subsequent Asterisk
> > release.
> > It still seems like a mountain is being made out of a molehill as
> > well. Blind and attended transfers are not complex operations and the
> > CDRs they generate are pretty simple. They are the two types of calls
> > that by all accounts are causing people the most pain. Rather then
> > solving 20 esoteric cases why not solve the two simple ones first and
> > make 90% or more of the people following the bug happy. To date I
> > haven't even seen any comments on the two CDR bug reports on calls for
> > cases other then transfers.
> > Regards,
> > Greyman.
> A valid point. My first plan is to review my CDRfix5 branch; I am in
> process now. This morning, I updated it, and resolved the conflicts.
> I have a number of updates mixed together for different purposes:
> 1. I got rid of ForkCDR(). To me, it's a dinosaur. Mainly because I
> grasp all the particulars of ForkCDR. I've come to some
> but all the affects of the CHILD, and LOCK flags and why they are
> used as they are still escape me. Instead, I provide a func instead,
> CDR_CONTROL. You can create CDR's on your own, and put whatever
> in whatever fields you want. They are malloc'd in memory, and you
> store their handles in the dialplan, either in the channel or
> This way you have more complete control over CDR's via the dialplan.
> For some, this sort of thing would be an abomination. For others,
> a delight. We'll see...
> 2. xfers and 3-ways: some of this is done via features, some in the
> channel drivers. I made a few fixes to better track these.
> 3. CDR "Glue". I introduced a new CDR field, "linkedid". It's a bit like
> "uniqueid", but when two channels are bridged, the older of the two
> linkedid fields is copied to the other channel. This allows you to
> track xfers a little easier: one predictable field can be used to
> link multiple CDR's together.
> I'll be looking for the stuff in category (2) and seeing if they cover
> reported problems. I have some work in another branch as well I need
> to filter.
> We've also got CEL running, in the which we've merged the linkedid
> into the code in that branch, and Brian is busy playing and extending
> Brian has pointed out that databasing CEL events is pretty useless. He
> plans to write a CEL->CDR interface that will generate cdr's from the
> CEL events, rather than let the existing CDR do the compiling. We'll see
> how it
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
More information about the asterisk-dev