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

Steve Murphy murf at digium.com
Sat May 31 09:00:44 CDT 2008

On Sat, 2008-05-31 at 09:39 +0100, Grey Man wrote:
> On Fri, May 30, 2008 at 3:16 PM, Steve Davies <davies147 at gmail.com> wrote:
> >
> > If you change the format too much, everyone is going to have to
> >
> > a) Rewrite all of their CDR parsers
> > b) Find some way to migrate historical customer data
> >
> > I am all for moving forwards, but do please keep in mind that lots of
> > effort will need to be put into it AFTER the code is changed, so
> > please consider a migration path.
> >
> I agree with that and I don't think many people if any want to see the
> CDR format changed. The problem, at least in the case of transfers, is
> that a CDR is missing not that the format needs to be changed.
> I don't think the fix for this is that difficult. In res_features.c in
> ast_bridge_call there is actually a block of code that takes the two
> CDR's for the channels on either end of the call and merges them
> together to create a new CDR and at the same time deletes the CDRs for
> each individual channel. This is the root of the whole problem. The
> single merged (bridge) CDR is never going to be able to accurately
> record the call details if there are one or more changes on the
> channels making up the bridge.
> I commented out the code that creates the merged CDR and deletes the
> channel CDRs and the results end up being closer to what is required
> for the blind and attended transfer calls!


Believe me, I am *always* looking for an easy fix in the CDR stuff. 
Personally, I'd love to be able to discover a single little thing 
I could do that would clear up the problems.

Which version of Asterisk did you do this in? The stuff I in did 1.4
is different than what I did in trunk.

In general, the CDR merging was necessary to combine info that was
captured in either the channel or peer CDR's.

And also, in general, I find that the CDR system is pretty much smeared
across the entire code base, and innocuous changes in one part can
solve one problem, but create a cascade of problems in other areas.

I have been targeting trunk for changes to the CDR system, mainly
of all the complaints about changes I've made in 1.4. It disturbs apps
worked hard to develop. I've pretty much written off 1.4, for this
There's hardly ANYTHING I can do without mucking somebody up.

Sure, a hemispherectomy will stop seizures.... but...


I have targeted tr
> Regards,
> Greyman.
> _______________________________________________
> --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
Steve Murphy
Software Developer
-------------- 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/20080531/01895bad/attachment-0001.bin 

More information about the asterisk-dev mailing list