[asterisk-users] CDR

[Atis Lezdins]

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