[asterisk-dev] CDR Problem Proposals

[Steve Murphy]

On Fri, 2008-11-21 at 07:42 +0000, Grey Man wrote:
> On Thu, Nov 20, 2008 at 9:49 PM, Leif Madsen
> <leif.madsen at asteriskdocs.org> wrote:
> > 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?
> 
> I'm well past being a broken record on this issue but I'd like to
> point out again that producing CDRs is not that difficult.
> 
> Speaking for SIP (there's probably equivalents for the other channels):
> 
> 1. Create a CDR per SIP dialogue instead of per bridge,
> 2. Start a CDR when a 2xx final response to an INVITE is received or sent,
> 3. Stop a CDR when a BYE is received or sent.
> 
> The rules are incredibly simple it's Asterisk design flaws that are
> making it hard.
> 
> There are lots of examples of other softswitches having absolutely no
> problems with this very very basic and very very fundamental
> requirement.
> 

Greyman--

I tend to agree. It would be simple if there were no interruptions
in the process. But parking, blind/attended xfers complicate it via
the masquerades, etc... just remember that xfer's and parking
do not break the bridge... in existing code, the bridge stays
up through all of that, the channels participating just change.
Josh has been working on a nifty.

There is a notion of channel/peer role in the dial/pbx code,
that is enshrined in the code itself, and parking/xfers mix it
all up. For instance, if we go by bridge alone, then a situation
where say, an incoming call, A, gets routed to B, and they converse,
then B parks A. C picks up A. C transfers A to D. D parks A. E
picks up A. A and E converse, and A/E hangs up.  The amount of 
time that A spent on the phone would have to be calculated from
several discrete bridge CDR's. 

But, the feeling I get is, that A's conversation from the time
it calls in, to the time it hangs up with E, should all have been
recorded in one single CDR, with parks, xfers, etc, recorded in
other CDR's with some sort of cdr 'type' to help identify
billable/informational information.

So, I'm still not sure that an inline approach can/will give us what
we want, but as a thought experiment, I need to clarify just
what *is* expected of CDR's. So, in the RFCs/CDRfix2.rfc.txt,
I'll try to outline both. So, you might want to review that
doc, and let me know if I'm wildly off-track on how I think
things should be working. 
(svn: http://svn.digium.com/svn/asterisk/team/murf/RFCs)

I'm willing to wager that most CDR expectations will flow down
perhaps 2 paths; channel/peer role CDRs, per-bridge CDR's.
In channel/peer role CDR's, A's entire call would be contained
in a single CDR, with other CDR's reporting parking and xfers.
In the per-bridge, A's total time would have to be added up
from all the pieces.

But make no mistake, generalized, useful CDR implementations
are not as easy as you might think. Someone referred me to one
system's CDR documentation, and it was well over 350 pages
long, and outlined almost two dozen CDR record types.

Until someone thoroughly and thoughtfully writes up a spec
that is coherent, and follows it in the implementation, 
we'll never have a true CDR implementation.


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/0bc294f0/attachment-0001.bin