[asterisk-dev] CDR Problem Proposals

[John Lange]

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.

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.

-- 
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
> _______________________________________________
> --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