[asterisk-dev] Time for a bug fix phase?

[John Lange]

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.

Regards,
-- 
John Lange
www.johnlange.ca


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.
> 
> Greyman--
> 
> A valid point. My first plan is to review my CDRfix5 branch; I am in
> the 
> 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
> don't
>    grasp all the particulars of ForkCDR. I've come to some
> understanding,
>    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
> values
>    in whatever fields you want. They are malloc'd in memory, and you 
>    store their handles in the dialplan, either in the channel or
> globally.
>    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
> the
> 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
> concept
> into the code in that branch, and Brian is busy playing and extending
> it.
> 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 
> flies.
> 
> murf
> 
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev