[asterisk-users] CDR changes in 1.4.3?

[Atis]

Hey,

I just found this in ML archives.

I have pretty the same situation - i had very well written CDR
processing engine on asterisk, making use of ResetCDRs, however now
when we're migrating to 1.4, it's a bit pain to deal with extra CDR
records. My engine is built so that MYSQL CDR can be used directly for
reports (imagine - you get whatever report you need immediately). So,
this way i don't have much processing abilities to remove unnecessary
records (i really don't want to delete anything, as that way i can
take something important with it). So from my point of view - extra
records can be there as long as it is possible to control them from
dialplan.

Currently i found a solution - whenever processing fresh CDR part i
move unnecessary records to another table, that should work for some
time, but i still have a hope to see ability to control them in some
future :)

I can confirm - there is extra empty record on NOANSWER (straight SIP
to SIP call). This is not much use, however NOANSWERR from queue is
for us.

Additionally i found extra record with not empty billsec. I'm not sure
is it from 1.4.0 or 1.4.3, but i will try to test it in next days. The
situation is like this.

1) SIP phone calls to queue.

2) Queue callback to SIP agent
Dial(SIP/90003|25|gtM(queue_call_answer^21121))

3) SIP agent answers call, macro queue_call_answer gets executed

In CDR i see additonal record (with lastapp/lastdata set to last line
of queue_call_answer). This record have duration of whole queue call,
and disposition is ANSWERED and dst is "s" - so it certainly don't
match the NOANSWER/duration=0/no src pattern.

It seems like additional channel is made for macro (is there some?)

Regards,
Atis


> On Fri, 2007-04-27 at 11:32 -0400, Scott Lykens wrote:
>> Hello all:
>>
>> I upgraded to 1.4.3 last night and use MySQL for CDR.
>>
>> I have noticed that 1.4.3 seems to log a lot of "crap" to CDR that
>> 1.4.2 did not. I use a few macros in my dialplan to handle outgoing
>> calls (lcr type stuff) and in addition to the proper CDR for the call
>> itself I also have records to 's' in the same dest-context and entries
>> to 's' in the default context. Up to 3 CDRs are generated for one
>> outgoing call (SIP -> Zap channel) with one being the legit CDR and
>> two being the type described above.
>>
>> My dialplan executes a ResetCDR after calling the lcr macro so that
>> the CDR is sane and accurate, however, it appears these "spurious" CDR
>> entries are generated by the call the ResetCDR even though I do not
>> call it with any options.
>>
>> Am I missing something obvious here? I have read the ChangeLog but I
>> didn't see anything that addressed this particular issue.
>>
>> Thanks for the help.
>>
>> sl
>
> Scott--
>
> I'm the guilty party. I've been trying to fix several CDR bugs,
> involving stuff like missing times, missing changes in state (like
> NO_ANSWER when the call was ANSWERED), etc.
>
> CDR's are complicated by the fact that they record 3 events: "start",
> "Answer", and "end" events. Add to that the fact that in most cases at
> least two channels are involved, sometimes 4 or 5, or even more,
> involving bridging, maquerading, parking, transfers, local channels,
> AGI, conferences, and more...
>
> Some cases were impossible to fix unless CDR's were attached to every
> channel,
> and merged to collect the bits and pieces that sometimes were on the
> wrong side of the bridge.
>
> The result is that several more cases are more accurate, but also, that
> rather uninteresting CDR's can be generated. In contemplating what could
> be done to get rid of some of these, I sometimes have to ask, "is this
> truly something we have to get rid of?"... In the meantime,
> uninteresting CDR's with NO_ANSWER and billsec=0, should be easy to
> filter out, right?
>
> I will, in the coming days, look at some of the extraneous CDR's that
> are generated, and see what I can do to get rid of them. It's not always
> that simple.
> If we ring a phone, for instance, and no-one answers it, is that truly,
> really, something that no-one will ever be, could ever be, interested
> in? (just a fer-instance).
>
> I welcome your input. Complain up a storm. I'll try my best to make you
> happy.
>
> murf