[asterisk-users] CDR

[Grey Man]

----- Original Message ----
> From: Steve Murphy <murf at parsetree.com>
> To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>
> Sent: Thursday, 27 December, 2007 5:44:01 PM
> Subject: Re: [asterisk-users] CDR
> 
> Greyman--
> 
> No real new functionality in 1.4, except a cdr.conf option that
> lets
> 
 you
> control whether you see one-channel cdrs.
> 
> I haven't been working on CDR's the last few months in favor of other
> projects that seem a little more urgent. Plus, I have some folks urging
> me NOT to proceed until some architectural issues are discussed, which
> might be wise. I have been working on one bug where I did make some
> substantive changes to how the CDR's are generated, but it is almost
> certain that these changes will only show up in trunk.
> 
> I've reached the limit of what I can do in 1.4; it is simply impossible
> to do anything with CDR's in 1.4 without tearing the very fabric
> of
> 
 time
> and space, and just plain getting everybody upset... at least,
> those
> 
 who
> were not erased from existence by the tear... on a more serious note,
> the changes are intrusive enough, the behavior changes big enough, that
> they really don't qualify to be applied to a current release.
> 
> It's a huge job! My past work was just in the ZAP channel driver code,
> and because it's so asynch, and all split up into different code, it's
> really tough to get the right pieces in the right places at the right
> time in the right way.
> 
> What this all says is that I'm most likely NOT doing it the right way.
> And what worries me most is that there might not be any "right"
> way.
> 
 But
> I'm still new to this, and will get back around to it hopefully fairly
> soon.
> 
> murf

Hi Steve,

Thanks for the update.

I agree it's complicated and looks like it does require a look at the design of Asterisk and where CDR's are generated. As you've already documented and lots of us have discovered generating a single CDR for each bridged call is not suitable when CDR's are used for billing and blind and attended transfers are taking place.

For any SIP (can't speak for other channels but most likely the same) service providers running Asterisk that are not aware of this problem you will not be getting correct CDR's on blind and attended transfers. Also depending on your dial plan users may be able to send a 302 Redirect response (301 or 302) to an incoming call and get a free outgoing call. This has the potential to cost you money which is very dangerous if any of your users cotton on to it. The easiest way to check your susceptibility is to do call an expensive destination, blind transfer to a free destination and then check the CDRs and pay close attention to the call durations of each CDR.

I'll go back to trying to find a way to detect and block dangerous REFER requests at the SIP Proxy before they get to Asterisk.

Regards,

Aaron
 




      Make the switch to the world's best email. Get the new Yahoo!7 Mail now. www.yahoo7.com.au/worldsbestemail