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 >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> --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
