[asterisk-users] CDR changes in 1.4.3?
Steve Murphy
murf at digium.com
Fri Apr 27 15:28:04 MST 2007
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
--
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20070427/4798c1a1/smime.bin
More information about the asterisk-users
mailing list