[asterisk-dev] CDR Problem Proposals

[Steve Murphy]

On Fri, 2008-11-14 at 10:36 -0600, John Lange wrote:
> Hey Murf, its good to see you are still plugging away at this.
> 
> IMHO, in order for Asterisk to begin to be considered "Enterprise" ready
> it absolutely needs to do a few things right and high on that list is
> accurate call detail records.
> 
> Asterisk has gotten away with shoddy call tracking until now because
> this was a feature only available in very expensive high-end PBX systems
> and so most SMBs (Asterisk's primary market) didn't expect it.
> 
> No longer. Pretty much all of the digital and VOIP systems have detailed
> reporting either as a standard feature or as an add-on.
> 
> The clients that I have who have requested call reporting have no
> problem paying extra for a nice interface but are surprised when I have
> to tell them it isn't available at any price. Their reaction is often
> along the lines of "you mean this is a brand new system and we can't
> even tell how many calls were transferred from our receptionist to our
> sales department?"
> 
> We also use Asterisk to provide hosted VOIP solutions and I don't have a
> lot of confidence that this information can be relied on for billing
> purposes though thankfully outbound calls do seem to get logged
> accurately.
> 
> >From a code perspective I'm hardly qualified to make a meaningful
> comment but that has never stopped me in the past so here goes ;)
> 
> My gut feeling is the bridging routine _IS_ the correct place to do
> CDRs. Not only is it the correct place but it is the _ONLY_ place it
> should be done.
> 
> After all, everything that happens in Asterisk that needs to be logged
> involves tearing down two ends of a "bridge". If a log was cut every
> time that happened then all bases are covered.

Well, it made perfect sense to me when I started, but in effect,
I ended up painting myself into a corner, generating a lot of
regressions -- in short-- the nightmare of any software developer.
If you take the *right* path, things should get easier; options
get broader, unexpected cases are already covered, etc. etc.
Well, this way isn't presenting any such.


> 
> Calls that involve parking & transfers etc. will generate several log
> messages but that is good. Log messages can be parsed and put back
> together to establish complete call chains.
> 
> Given your comments on how hard this has turned out to be the only other
> suggestion I would make would be, that in order to preserve backwards
> compatibility, the existing system should be left in place and a new
> system implemented in parallel which logs to its own location.
> 

Of course. I kinda visualize a make-menuselect option for 
REWORKED_CDR or somesuch that is off by default.

But like I said, it will be a sort of experiment; we can,
when we are making the xfer/park/whatever, manipulate the
CDR's so that they'll be where we need them and contain
what we want them to contain, but, like I said, the whole
'role' relationship will either aid us in getting us the
results we want, or it will present an impenetrable road block.
The devil's in the details.

murf

> -- 
> John Lange
> www.johnlange.ca
> 
> 
> On Thu, 2008-11-13 at 15:23 -0700, 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
-- 
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/20081114/64f0525b/attachment.bin