[asterisk-dev] CDR variables

[Steve Murphy]

On Wed, Nov 25, 2009 at 1:33 AM, Olle E. Johansson <oej at edvina.net> wrote:

>
> 24 nov 2009 kl. 23.17 skrev Matthew Nicholson:
>
> > On Sat, 2009-11-21 at 11:26 +0100, Olle E. Johansson wrote:
> >> I was looking into adding the RTPAUDIOQOS variables directly to the
> cdr's from chan_sip as a cdr variable. I notice that there are no other
> modules that does add cdr variables directly.
> >>
> >> Is this because developers hasn't noticed this feature or because it
> will fail miserably and cause disruptions in the Asterisk space/time
> relationship?
> >>
> >> If this works, is it safe to add variables to the cdr as long as I have
> an AST_CHANNEL available? We have two closures of cdr - after or before "h"
> processing - but when will the CDR be stored - at destruction of the
> ast_channel or when we freeze it?
> >>
> >> /O
> >
> > Adding the variable should not cause a problem, but it may not actually
> > be stored to disk if it is added while the channel is bridged.
>
> That sounds like  a bug to me. So I can only add CDR variables before the
> first bridge or any time when I'm not in a bridge?
>
> /O
>

Pardon if I inject something here, I just have one general thread for all of
this. It is roughly this: the CDR
system as currently implemented, has several large problems, the largest
being the fact that the CDR data
is stored on a channel. The next is that the masquerading operation, done in
several code paths to make
things like transfers possible, tends to do things like swap the "channel"
and "peer" relationships, and replace
the current channel with a duplicate of itself. A third is the use of things
like Local channels. And a fourth is
the fact that the dialplan can only influence the CDR system at the points
where it gets executed by the
PBX engine. Put all this together and you are trying to tweak a wild and
ferocious beast to get it to do what
you want it to do. Good Luck.

I advise that you read up on the CEL (channel event logging) system, and
explore how you might use it to
generate the CDR stream you are truly wanting, or forgetting CDR's entirely,
directly use CEL to harvest the
data you need to harvest. It would be more productive for you to use CEL
than try to get people to fix
the CDR system. CEL does not try to merge multiple events on multiple
channels into a record on a
channel. It reports single events to whatever backend you desire. You can
store and capture such events
in real time, or process the events post mortem. Or both. It's nice. Better
to report bugs and shortcomings
against CEL, than the fundamentally flawed and troubled current CDR system.
Your "creative juice"
as to how to improve the current CDR system would be better invested in CEL,
imho!

I have, many many months ago, proposed to write a CEL->CDR converter that
would convert a stream of
CEL events into CDRs, with "Simple" CDRs at the start. I have received some
feedback from a very few
people who looked it over and *one* didn't think the Simple system would
give them the data they needed.
Since I have so little input, I found it impossible to take a group of
different requirements (one or two!), and
come up with a more general algorithm for generating the CDRs of your
dreams. So stands the effort with me,
until I get some funding to push the effort along.


-- 
Steve Murphy
ParseTree Corp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20091125/49096c32/attachment.htm