VoIP Mailing List Archives

[venefax at gmail.com]

We should merge this changes immediately. At least, fix NoCDR(), which
really affects the business. Maybe you can do that meanwhile. I know your
changes work.

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Steve Murphy
Sent: Tuesday, June 24, 2008 11:28 AM
To: asterisk-users
Cc: Asterisk Developers Mailing List
Subject: [asterisk-dev] Warning: CDRfix branches about to be merged into
1.4, 1.6.0, trunk!

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