[asterisk-dev] CDR Problem Proposals

[Steve Murphy]

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
-- 
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-dev/attachments/20081113/16d9c77b/attachment-0001.bin