----- Original Message ----
> From: Kevin P. Fleming <[EMAIL PROTECTED]>
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> <[email protected]>
> 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
_______________________________________________
-- 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
