[asterisk-bugs] [Asterisk 0011849]: Missing CDR's for Transfers

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11849 
====================================================================== 
Reported By:                greyvoip
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   11849
Category:                   CDR/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.17 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-01-26 11:11 CST
Last Modified:              2008-11-01 23:38 CDT
====================================================================== 
Summary:                    Missing CDR's for Transfers
Description: 
At the moment there is one CDR generated per generic bridge. This tends not
to create any problems when the bridge has been created by something like:

SIP User -> Asterisk -> PSTN

The CDR generated will have the PSTN number as the destination and the SIP
User's accountcode.

When a transfer is undertaken the one CDR per generic bridge approach
breaks down. An example call flow for a blind transfer is:

SIP User -> Asterisk -> PSTN
PSTN <- Asterisk -> PSTN (this is after the user has blind transferred the
first call to a second PSTN number)

At the moment Asterisk will correctly generate a CDR for the first call
leg but for the second call leg there is a problem. For the sconed call leg
both ends of the bridge are now billable but as Asterisk only generates a
single CDR per bridge one of the legs will not get billed. 

A straight forward fix (at least architecturally) would be to generate a
CDR for each end of the bridge instead of combining both ends into a single
CDR. It would mean some extra CDR's for the standard SIP User -> PSTN call
but it's a lot easier to filter out CDR's to ignore than it is to try and
work out how to handle ones that are missing.

I've classified this as major since it's costing me (and other providers)
money every time a user does a transfer :).
====================================================================== 

---------------------------------------------------------------------- 
 (0094497) greyvoip (reporter) - 2008-11-01 23:38
 http://bugs.digium.com/view.php?id=11849#c94497 
---------------------------------------------------------------------- 
frawd I think this is exactly the sort of discussion that should take
place. The issue we are dealing with here is a design one so if we can come
up with a good one perhaps we'd be able to get buy off on it.

As far as the linked CDR list it seems a bit complicated to me and I'm not
so sure the mechanism is flexible enough to cope with all scenarios. I know
this particular bug report is focused on two specific cases, being Blind
and Attended Transfers, but if a new design, as oppossed to a fix, is going
to be implemented it should be able to cope with every scenario we can
think of.

In your Chained Transfer example I think that the CDRs required are:

[Format: <A number>, <B number>, <duration>]

1. A, B, 1 to 5
2. B, C, 2 to 4 (since this is a blind transfer A has asked B to call C)
3. C, D, 3 to 5

The complication to me is the fact that a single bridge could end up with
a long list of CDRs and on each transfer Asterisk would need to look over
the list and attempt to work out which CDRs are applying to channels that
are still up and which CDRs should be posted for channels that have been
hung up. I can see the logic getting pretty convoluted.

The solution I propose which is a 1-to-1 link between a CDR and each
channel would make it very easy for Asterisk to determine when a CDR gets
posted. Each time a channel is hung up a CDR is posted, that's it black and
white and no chance of losing any information if a transfer or other
application scenario comes up that wasn't anticipated.

Using that approach and with your Chained Transfer example the CDRs
produced would be:

* = Asterisk

1. A (non-billable) , *, 1 to 2
2. * (accountcode=A), B, 1 to 5
3. * (accountcode=B), C, 2 to 4
4. C (non-billable) , *, 3 to 4
5. * (accountcode=C), D, 3 to 5

The example has 5 call legs and 5 CDRs. 

If I was getting that information in the CDRs I would be able to bill
correctly. An extra nicety would be a way to link all the calls together to
show a more succinct call history to the user but that's a minor
consideration compated to getting accurate accounting.

If incoming calls need to be billed, if for example you are a toll free
number provider, then the chained transfer approach means a billing engine
would have to start working out whether each CDR should generate two
billing records or not. With the CDR per channel approach it's a simple
matter of allocating an accountcode to the incoming call and putting a rate
in. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-11-01 23:38 greyvoip       Note Added: 0094497                          
======================================================================