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
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
