[asterisk-dev] CDR Problem Proposals

[Martin Smith]

We're putting millions of calls through Asterisk and the upgrade to
1.4.22 caused some loss of information in our CDR databases to the tune
of about 600 fewer call records per day of one of our most important
kinds of calls :(.

I'd love to see some of the CDR code moved/refactored, and maybe even in
a separate module. I think part of the problem is that people use the
CDRs to do some funky stuff --  I was recently helping a user try to do
callfile success/failure tracking before calls were hungup, and the user
was bent on using the CDRs to do it (and finding they don't write+flush
immediately to disk).

Thanks all for your hard work on them :)

Martin Smith, Systems Developer
martins at bebr.ufl.edu
Bureau of Economic and Business Research
University of Florida
(352) 392-0171 Ext. 221 

 

> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com 
> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of 
> Mark Michelson
> Sent: Thursday, November 13, 2008 6:41 PM
> To: murf at digium.com; Asterisk Developers Mailing List
> Subject: Re: [asterisk-dev] CDR Problem Proposals
> 
> Steve Murphy wrote:
> > Hello--
> > 
> > When I did it, catching CDR xfers, etc, in the
> > bridge routine seemed such a good idea. After all,
> > if we cut a CDR there, we were guaranteed to never
> > miss a call leg! But the further I go down that road,
> > the worse the decision appears.
> > 
> > To add fuel to the fire, the recent attempt to 
> > get rid of the usage of the KEEPALIVE and NO_HANGUP_PEER
> > by using the masq_park_ routines, and Mark's brilliant
> > fix for the end_bridge crash, just really highlight
> > how wrong this whole pursuit has been/is getting... I was hopeful
> > that I could make tweaks to make the whole thing work,
> > but I've given up hope of that now, as we hit problems
> > that are logically inconsistent with the current system,
> > or extremely impractical to solve, and as regressions
> > start piling up.
> > 
> > I've been thinking about how to turn it all around and
> > have a few proposals:
> > 
> > 1. Back out all the changes to 1.4 back to the beginning,
> > or at least back to the point where I started with the
> > ast_cdr_merge stuff, and toss it all out, and begin anew
> > with what we had in the 1.2 stuff. 1.2 had its problems, 
> > but not *this* many. But, before committing, try a 
> > different approach: instead of catching xfers post-mortem,
> > try to take care of CDR issues directly in the xfer related 
> > code, when the xfer is happening. This happens in the
> > res/res_features.c (or, main/features.c), and in a small
> > set of channel drivers that handle xfers/3ways (dahdi, sip,
> > etc.).
> > 
> > Now, I cannot see the end of this, either, and maybe some
> > of the CDR problems are just not practically possible to
> > solve, but this is the only other path I can perceive that
> > could be taken (as far as CDR/h-exten).
> > 
> > The Park, and xfer code introduces some really interesting
> > channel manipulations, and they are not completely
> > compatible with the current channel-peer philosophy that
> > dial, queue, bridge, the CDR system, and the hangup-exten
> > stuff depends on. For instance, if someone (A) calls into
> > Asterisk, and then dials an internal extension, they are
> > the "channel". But, if the person they call Parks() them,
> > and an internal extension connects to them via the parking
> > lot, then the first caller loses that "channel" role, and
> > becomes the peer. Unfortunately, that makes a mess of who
> > gets the h-exten run, what channel the CDR is stored on,
> > etc. I haven't thoroughly thought it out yet, but preserving
> > the chan/peer role in xfers/parks might be a viable way
> > of getting the h-exten and CDR's to do what most folks
> > think they should. Ideally, the h-exten gets run on A
> > when A hangs up, no matter how many parks or xfers it's
> > been through. But manipulating who's "Channel" and who's
> > "Peer" through xfers and parks (and who knows what other
> > operations) is no simple task: what if they both say
> > they are "Channel"? What if neither?
> > 
> > Some or all of the above role-keeping idea may or may not
> > pan out, but might be worth an experiment.
> > 
> > In the meantime, in 1.4, only work-arounds will be implemented,
> > like attaching BLINDTRANSFER info during blind and attended
> > xfers, so users can tie CDR's together, etc. I'd think
> > I could open a group branch to explore this avenue, and toss
> > if it's no better than what we have, or if it just plain
> > won't work.
> > 
> > 2. Another approach to the problem is more incremental,
> > where we first move the CDR specialized reset code out of the
> > bridge and into the xfer routines, and if that can be made
> > to work, then pull the bridge_cdr concept entirely back out
> > of the bridge, and see if that can be made to work...
> > 
> > Am I crazy? Insane? Stupid? I need your 
> > ideas/feedback/Counter-proposals.
> > 
> > Thanks
> > 
> > murf
> > 
> 
> Whatever route you decide to go, I definitely agree that 
> handling CDR's in the 
> transfer code itself is the best way to go. The functions 
> that facilitate 
> transfers are the only places that you have full access to 
> all channels and call 
> legs involved, which minimizes the chances of accidentally 
> referring to a 
> channel which has been masqueraded away or something of that nature.
> 
> Mark Michelson
> 
> _______________________________________________
> --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
>