[asterisk-dev] CDR variables

[Olle E. Johansson]

25 nov 2009 kl. 15.26 skrev 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.

I understand you loud and clear. So basically for old releases, I need to create a realtime family to store what I need to store, which is RTCP stats.
For trunk and into the glorious future, it's CEL.

Thanks for the feedback, Steve!

/O

PS. For the funding, try again on the asterisk-biz list. I succeeded in getting some funding for a small project there.