[asterisk-users] CDR

Tue Oct 30 05:20:13 CDT 2007

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/