On Wed, 2007-06-06 at 13:47 +0300, Atis wrote:> 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
>
Atis--
Keep me informed. I've been continuing the effort to improve the CDR
accuracy. Give me specific test cases; and your using the SVN 1.4 branch
head will help me, too, as I may have fixed bugs, and it's a shame to
waste time on stuff I might already have fixed.
I've spent weeks trying to upgrade CDRs to work right. I'm in the middle
of an effort to make CDR's cover transfers (zap, and soon sip), and give
folks enough data that they can successfully bill on any sort of strange
transfer operation.
I've found that if I rebuild CDR generation around bridging, and
eliminate the code that posts CDR based on hangups, I can generate
better CDR's in a transfer environment. No chunk of conversation can be
lost this way. But the philosophy is a little different, and will give
you headaches if you've already put in some work on billing. The main
difficulty with this approach is that the transfer events aren't visible
at a high level in the bridge, but happen within the drivers, so I have
to some dancing between the drivers (sip, zap, etc), and the bridging
code (res_features.c).
Even if I leave the drivers out of it, just generating a CDR every time
a bridge is formed and ended, allows me to make sure a CDR is generated
if a conversation took place, something that right now, in transfer
situations, is not happening.
murf
>
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3239 bytes
Desc: not available
Url :
http://lists.digium.com/pipermail/asterisk-users/attachments/20070607/95443f50/smime.bin