[asterisk-dev] CDR Problem Proposals

[Steve Murphy]

On Thu, 2008-11-20 at 19:34 -0800, John Todd wrote:
> On Nov 20, 2008, at 1:49 PM, Leif Madsen wrote:
> 
> > 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.
> >
> > Perhaps building CDRs into Asterisk is the wrong approach, and maybe  
> > we
> > need to take the course of allowing people to build their own CDRs via
> > the dialplan; and that just means providing them the tools to do it,  
> > and
> > some examples of the most common scenarios (this is what CEL is  
> > supposed
> > to be right?)
> >
> > It seems everyone has a different idea about what CDRs are supposed to
> > be, and how they are supposed to be represented, and perhaps no route
> > you take is ever going to succeed at solving the underlying issue.
> >
> > Just a thought, but I'd hate to see spend another round of trying,  
> > just
> > to realize that perhaps there is no route to success using the current
> > methodology?
> 
> 
> 
> Well, the most obvious problem with that solution is that the Dial()  
> command doesn't allow for much visibility into what's going on with  
> the call.
> 
> So it may be that CEL or something like it is the answer, but call  
> events probably need to be recorded in a way that is outside the  
> dialplan since there are many "invisible" parts of calls that the  
> dialplan is typically executed during those events.  One could argue  
> that the dialplan maybe SHOULD be called during those events - but  
> that's a different architectural issue.   Plus, other API-ish things  
> would then have to push CDR entries of their own instead of relying on  
> Asterisk to do it "without thinking."   Despite being complex today, I  
> would suggest that removing CDR functionality from the core would make  
> programming Asterisk _more_ difficult.  I won't argue that perhaps  
> there are better ways it could be done in the "core", but I'm not well  
> positioned right now to make a case one way or the other as to what is  
> the best method.

I don't think it's the Dial() app's transparency that's the cause
of the current complexity. Dial is just doing what it was designed
to do. It sets up a call (rings possibly several extens, grabs the
first pickup, and bridges the caller to the callee with several
options, 
sets some vars when the bridge closes, and returns.

It's the asynchronous activities of the bridged channels that's
the juicy part. Dahdi hookflashes, Features (one touch park,
blind xfer, attended xfers, etc), and the masquerades that are
performed to make the actions possible within the confines of Asterisk
that make it all so.... interesting!

I think we've reached a point where we actually have to sit down
and truly think and agree on what to do to get to where we want to
be, which includes defining exactly where we want to 'be'.

We can take this anywhere we want. I've seen/heard of folks
that have used nothing but the dialplan to accomplish working
billing systems; others use manager events; others use a mix;
others use the existing CDR system, with really inventive
use of ForkCDR, etc.

But I think most folks don't want to spend a couple man-months
of labor/expense to get a minimally working CDR system running.

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/20081121/f22d735b/attachment.bin