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
Happens to me again, SIP->Zap or SIP->SIPProvider with a quite simple dialplan, it generates an 's' record in the context of both sides just like if it was doing a per-channel CDR instead of a per-call... 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 > _______________________________________________ > --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 >-- _________________________ Fran?ois Delawarde Ingeniero de red Tel: 918.03.92.51 E-mail: fdelawarde@wirelessmundi.com <mailto:fdelawarde@wirelessmundi.com> _________________________ WIRELESS MUNDI http://www.wirelessmundi.com/ C/Isaac Newton, 1 - Oficina 26 ? Parque Tecnol?gico de Madrid 28760 TRES CANTOS (Madrid) Tlf./Fax: (+34) 918 03 92 51 ------------------------------------------------------------------------ La informaci?n contenida en este mensaje y en sus archivos adjuntos es CONFIDENCIAL y se dirige exclusivamente a sus destinatarios. Queda expresamente prohibida la utilizaci?n de la misma por cualquier persona distinta de los destinatarios de esta comunicaci?n. Si usted ha recibido este mensaje por error le rogamos que lo comunique inmediatamente a WIRELESS MUNDI y lo borre al igual que todos sus documentos adjuntos. El correo electr?nico no puede asegurar la confidencialidad ni la integridad de sus mensajes por lo que WIRELESS MUNDI no se hace responsable de tales errores u omisiones. ----------0---------- All information in this message and its attachments is confidential and may be legally privileged. Only intended recipients are authorized to use it. If you have received this transmission in error, please notify WIRELESS MUNDI immediately and delete this message and its attachments. E-mail transmissions are not guaranteed to be secure or error free and WIRELESS MUNDI does not accept liability for such errors or omissions. ------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20070427/15ddb97b/attachment.htm
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. > > slScott-- 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