[asterisk-users] Asterisk's DANGEROUS Transfer CDR's

[Grey Man]

----- Original Message ----
> From: Kevin P. Fleming <kpfleming at digium.com>
> To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>
> Sent: Tuesday, 29 January, 2008 9:34:23 PM
> Subject: Re: [asterisk-users] Asterisk's DANGEROUS Transfer CDR's
> 
> Grey Man wrote:
> 
> > That will work for blind transfers but not attended and even in
> the
> 
 blind transfer case the CDR's still aren't correct you're relying on
> an
> 
 informational field.
> 
> I think there is an important point being missed here; Asterisk did not
> originate the concept of CDRs, nor did it specify what they contain or
> how they are to be collected and generated.
> 
> CDRs have existed for decades before Asterisk was created, and they are
> a fairly well understood concept throughout the telephony switching
> industry. They were designed for billing, and in many
> telephony
> 
 networks
> are still used for billing.

Hi Kevin,

Thanks for responding. I'd actually prefer to use some form of real-time call control for billing within Asterisk but that's another story.

For the half a dozen or so integrations we have done with PSTN carriers the CDRs are integral to the whole process. Arguably the biggest step in the whole interconnect process is matching up the CDRs for agreement.

> However, CDRs were created before the users of those services had the
> ability to transfer calls, make three-way calls, make conference calls,
> and do other magical things. As such, there is no way in a CDR to
> represent this activity in any *complete* manner. 

I understand there are likely to always remain certain things that CDR's cannot cope with but I don't think transfers fall into that category. Would there be anything wrong with recording a CDR for each end of a bridge instead of one CDR per bridge? If one end of the bridge changes, as in the case of a transfer, you get one CDR. When the bridge hangs up you get two CDR's which in fact does make sense as a bridge is two calls/channels.

I'd be more than happy to produce call flows for: transfers, 3 way call, whatever else; with the exact CDRs if that would help to clarify things.

> Doing so will require a redesign of the CDR system, which Steve Murphy has already begun for
> Asterisk 1.6.

Yes and thanks must go to Steve for delving into this very unglamorous area it's certainly not up there with video conferencing. The worrying thing though is the CDR's for attended transfers in 1.4 are now worse than they were in 1.2. I've read through Steve's blog posting on the new design and I think there are still some problems with the CDR scenarios. Using overlapping CDRs to determine if a transfer was in progress is fragile (what happens if simultaneous calls are supported) and apart from that the new CDRs will still don't provide enough information to bill all the call legs involved in a transfer.

> As far as I am aware, everyone who builds a complete billing system for
> Asterisk and expects it to be accurate and reliable uses other means in
> addition to CDRs for collecting the information, or they restrict their
> users to not performing actions that will break the billing process.


That's fair enough I guess but there are quite a few people using Asterisk that have been relying exclusively on its CDRs that weren't aware of the inaccuracies. Certainly the 3 providers I found in the last two days weren't (I've emailed them now). 

I don't think it would be insurmountable to improve the CDR design in Asterisk. Maybe it won't get to a stage where it's perfect but if a new design was produced it would pave the way for those of us that this is a big deal for to assist in the implementation.

Regards,

Greyman.



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