<br><br><div class="gmail_quote">On Wed, Nov 25, 2009 at 1:33 AM, Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net">oej@edvina.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
24 nov 2009 kl. 23.17 skrev Matthew Nicholson:<br>
<br>
> On Sat, 2009-11-21 at 11:26 +0100, Olle E. Johansson wrote:<br>
>> 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.<br>
>><br>
>> Is this because developers hasn't noticed this feature or because it will fail miserably and cause disruptions in the Asterisk space/time relationship?<br>
>><br>
>> 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?<br>
>><br>
>> /O<br>
><br>
> Adding the variable should not cause a problem, but it may not actually<br>
> be stored to disk if it is added while the channel is bridged.<br>
<br>
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?<br>
<br>
/O<br></blockquote><div><br>Pardon if I inject something here, I just have one general thread for all of this. It is roughly this: the CDR <br>system as currently implemented, has several large problems, the largest being the fact that the CDR data<br>
is stored on a channel. The next is that the masquerading operation, done in several code paths to make<br>things like transfers possible, tends to do things like swap the "channel" and "peer" relationships, and replace<br>
the current channel with a duplicate of itself. A third is the use of things like Local channels. And a fourth is <br>the fact that the dialplan can only influence the CDR system at the points where it gets executed by the<br>
PBX engine. Put all this together and you are trying to tweak a wild and ferocious beast to get it to do what<br>you want it to do. Good Luck.<br><br>I advise that you read up on the CEL (channel event logging) system, and explore how you might use it to <br>
generate the CDR stream you are truly wanting, or forgetting CDR's entirely, directly use CEL to harvest the <br>data you need to harvest. It would be more productive for you to use CEL than try to get people to fix<br>
the CDR system. CEL does not try to merge multiple events on multiple channels into a record on a<br>channel. It reports single events to whatever backend you desire. You can store and capture such events<br>in real time, or process the events post mortem. Or both. It's nice. Better to report bugs and shortcomings<br>
against CEL, than the fundamentally flawed and troubled current CDR system. Your "creative juice" <br>as to how to improve the current CDR system would be better invested in CEL, imho!<br><br>I have, many many months ago, proposed to write a CEL->CDR converter that would convert a stream of <br>
CEL events into CDRs, with "Simple" CDRs at the start. I have received some feedback from a very few<br>people who looked it over and <b>one</b> didn't think the Simple system would give them the data they needed.<br>
Since I have so little input, I found it impossible to take a group of different requirements (one or two!), and<br>come up with a more general algorithm for generating the CDRs of your dreams. So stands the effort with me,<br>
until I get some funding to push the effort along.<br><br><br></div></div>-- <br>Steve Murphy<br>ParseTree Corp<br><br>