[asterisk-dev] CDR Problem Proposals

Mark Michelson mmichelson at digium.com
Thu Nov 13 17:41:29 CST 2008


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



More information about the asterisk-dev mailing list