Thank you very much ! Andrea Atis Lezdins ha scritto: > You have to revert patch for issue http://bugs.digium.com/view.php?id=10659 > > More specific - that is - remove those two lines from main/cdr.c > > if (cdr->disposition < AST_CDR_ANSWERED && > (ast_strlen_zero(cdr->channel) || ast_strlen_zero(cdr->dstchannel))) > continue; /* people don't want to see unanswered single-channel > events */ > > Regards, > Atis > > Andrea Cristofanini -- [GedamEurope] wrote: > >> Hi there ! >> So it is possible to have logged a single unanswered channels ? >> What sould be stted into the cdr.conf ? >> Regards Andrea >> Steve Murphy ha scritto: >> >>> Sorry! >>> >>> I've gotten some complaints on this; I will try this week to >>> mod 1.4 so that you can choose to see the single-channel unanswered >>> CDR's, in a new config file option. I've gotten complaints both ways, >>> tho, so pardon me if I get a little confused about what users out there >>> want from CDR's. >>> >>> My biggest trouble is that by forcing all channels to have a CDR at >>> creation time >>> solves problems with missing CDR's, but creates a problem by generating >>> extra unanswered CDR's that weren't generated before... for instance, >>> when you >>> ring three phones via a dial command, you then get 3 CDR's, including >>> the >>> two phones that were rung, but not answered. >>> >>> Another problem is with Zap-based phones; you take the handset off-hook, >>> and >>> a channel is created and dialtone generated. If you hang up, you get a >>> CDR there, also. >>> >>> I have not found an easy way to detect and drop these kinds of CDR's, as >>> most folks really do not find them very useful. >>> >>> And, I've gotten a complaint that you end up with 'duplicate' CDR's, >>> which is also an artifact of forcing all channels to have a CDR >>> associated. If anybody >>> thinks they have a magic spell that will calm down the CDR's, I will not >>> mind the information at all! I worked all last week to try to iron out >>> the 1.4 zap-transfer CDR issues. I have 12 cases I test with involving >>> hook-flash and #-blindxfers, and so far, I've got 9 of the 12 working OK >>> (as far as I'm concerned.), but I have 3 cases that come up with >>> problems. For instance, if you hookflash, and dial a number, the CDR's >>> will be different, if you hang up before the dialed party answers, >>> versus hanging up afterwards... The diff between a blind xfer and an >>> attended xfer (without the 3 way), I guess, but I lose the calling >>> channel name... I'll try to sort all this out, and then I'll attack this >>> problem. Hopefully, I get it all into svn before the next release of >>> 1.4...! >>> >>> As far as xfers in 1.4 go, I'm trying to make sure that the source and >>> destination channel names reflect the true dialing party, as this makes >>> more sense from a billing perspective, at least to me. So, if A calls >>> B, and B forwards the call to C, then the CDR's need to reflect a call >>> from A to B, and a call from B to C, which you may or may not be seeing >>> right now. AFAICT, transfers pretty much result in confused CDR's. I >>> gave up totally on generating separate CDR's for any 3-ways that might >>> occur. Such 3-ways will end up being billed to the dialing parties. >>> >>> Here's an interesting situation: A calls B, A then hookflashes, and then >>> A calls C, and hookflashes again. It's now a 3-way call, between A, B, >>> and C. A then drops out and B and C converse. My goal with this >>> situation was to have two CDR's, one for A->B and one for A->c. Since A >>> placed both calls, it seems only just that A pay for B's and C's >>> conversation. Especially if A is in the US, for example, and B is in >>> Uganda, and C is in Bangladesh! >>> >>> Getting the right info in the right field from the driver level is >>> pretty tricky, and you can add the fact that there's definite timing >>> issues at play. If I make changes to CDR's in channels A and B, near to >>> the time a hangup occurs (and it's very commonly the case), I can end up >>> with some pretty strange stuff happening! I found that adding debug >>> logging statements to the driver can affect the way the CDR's are >>> generated! I solved some of this by locking channels (which to me is >>> pretty ugly, considering the number of locks involved). >>> >>> So, please, cut me some slack... and keep me informed about your >>> "happiness" levels. I want this stuff to be good, solid, and useful to >>> the majority. But also keep in mind that I fix something, someone out >>> there is going to be unhappy, because they have code/backends/whatever >>> that depends on the borked behavior! >>> 1.4 ***IS**** a release, and I dare not do ANYTHING but fix bugs. But, >>> wow, fixing a bug changes behavior, and my goal is minimal impact, but >>> real and useful fixes. >>> >>> >>> murf >>> >>> >>> >>> >>> >>> >>> >>> On Mon, 2007-10-15 at 10:40 +0200, Andrew Nowrot wrote: >>> >>> >>>> Hi >>>> >>>> Thanks for reply >>>> >>>> Yes, there's a change. For me it's completely unacceptable, so >>>> i >>>> reverted the patch (http://bugs.digium.com/view.php?id=10659). >>>> >>>> >>>> For me too. This bug occur in September. Is it still present in >>>> asterisk 1.4.12.1. I also have asterisk 1.4.4 on a different box and >>>> there everything works like in 1.2.21. >>>> I need the old behaviour to have everything working flawlessly. >>>> >>>> Thanks >>>> >>>> Andrew >>>> > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > >
-- Cheers Andrea ____________________________________ Andrea Cristofanini CTO - VoIP Gedam Europe S.r.l. - (Torino,Italy) Gedam Advanced Communication Ltd - (Dunedin,New Zealand) Strada da Bertolla all'abbadia di Stura, 151 - 10156 Torino - IT GSM. +39-329.1871756 - PSTN. +39-011.19824516 - FAX. +39-011.8338622 - http://www.gedameurope.com/ http://freevoip.gedameurope.com/ http://www.faropbx.com/ http://www.pbxsolution.net/ _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
