[asterisk-users] CDR

Tue Oct 30 09:23:29 CDT 2007

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/