asterisk users - Jun 2008 - 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
-------------- 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

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

On Tue, Jun 24, 2008 at 4:28 PM, Steve Murphy <murf at digium.com>
wrote:
> 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!
>
Hi murf,