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

[Steve Murphy]

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


-- 
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-dev/attachments/20080529/19b142fb/attachment.bin