[asterisk-users] Warning: CDRfix branches about to be merged into 1.4, 1.6.0, trunk!

[Steve Murphy]

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
-------------- 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-users/attachments/20080624/8752d38a/attachment.bin