Steve Murphy has posted details of the merging of the CDRfix branch:

This is just a note that the fixes in the CDRfix4 and CDRfix6 branches are getting closer to being merged into 1.4, trunk, and 1.6.x.

If CDR's are important to you, and you ignore this notice, then you deserve what you get!

These branches address various long-standing bugs, most of which are regressions from 1.2. It is hoped that these fixes will solve most of the problems introduced by the various changes made in 1.4 and trunk, without losing the fixes made in those changes.

To test out these branches, you can:

svn co http://svn.digium.com/svn/asterisk/team/murf/CDRfix4

or

svn co http://svn.digium.com/svn/asterisk/team/murf/CDRfix6

The above commands will create a directory called CDRfix4 (or CDRfix6) in the current directory, which contains an entire copy of the asterisk source. You can cd into this dir and do the configure/make menuselect/make/make install thing there to your hearts content.

The CDRfix4 branch is based on 1.4;

The CDRfix6 branch is based on trunk (which is still close enough to 1.6.0 that it won't take much effort to merge it 1.6.0 also.)

The bugs that will hopefully be addressed are:

http://bugs.digium.com/view.php?id=10927
http://bugs.digium.com/view.php?id=11093
http://bugs.digium.com/view.php?id=12724
http://bugs.digium.com/view.php?id=12907

and perhaps others.

The goal was to restore the code roughly to 1.2 behavior when it came to transfers, minus any bad behavior that 1.2 had. So, entire legs missing from transfers, missing or bad times, etc, seem to mostly solved.

The fixes do NOT fulfil requests to further subdivide CDR's in xfer situations, as I'm not warm and fuzzy on a general consensus as to exactly what the new CDR's would say. I haven't been able to engage really anyone in getting details ironed out on these issues. Folks have made suggestions, good ones at that, but everyone seems to be of a mind that before we extend or upgrade the current CDR system, we should produce a specification, and see if the community can come to a consensus on that spec.

So, I think I might make a proposal for enhancement of the existing CDR's to give more details about xfer situations, and we can hash out the details from there. This proposal can then serve as the spec for future enhancements.

Also, keep in mind, that we have a new facility being groomed for merging into trunk:

http://svn.digium.com/svn/asterisk/team/group/newcdr

which will introduce some new concepts that will help in forming billing records; it is single-event based, and introduces a new channel value, linkedid, which is spread between channels that 'interact', thus allowing you to more easily collect events that are related via transfers, conferences, parking, holding, etc.

So, please, please, please, test these branches against your implementations, and report any problems you see, so we can solve problems before they get merged!

Problems and complaints can be added to the bugs mentioned above, choose the one that seems most closely related to the problem you are having.

murf

--
Steve Murphy
Software Developer
Digium

Comments (Click to post)

Name:
Subject:
Website:
Message: