[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-02 06:08 CST
====================================================================== 
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 :).
====================================================================== 

---------------------------------------------------------------------- 
 (0094501) frawd (reporter) - 2008-11-02 06:08
 http://bugs.digium.com/view.php?id=11849#c94501 
---------------------------------------------------------------------- 
greyvoip, I still think in the chain transfer scenario we should have:

1. A, B, 1 to 5
2. A, C, 2 to 4
3. C, D, 3 to 5

instead of what you propose:

1. A, B, 1 to 5
2. B, C, 2 to 4
3. C, D, 3 to 5

Why? Because we cannot bill B for something he didn't do. When A blind
transfers to C, it happens on A's context and it is like if A called C
(just like in the attended transfer case). What if B didn't want to be
transfered to C or is not aware of this transfer (ex: hotline blind
transfering you to other service)? I understand in some cases you would
want to bill B (operator connecting B to destination), in that case you can
always relate easily with the second CDR having the same B channel id as
the first one. What do you think?

As of the long list of CDRs associated with the channel, it would be
exactly like if you used a forkCDR trick for each transfer (but in better
as automated). I doubt you have lots of situations where a call is
transfered so many times that the CDR list grows to affect performance, and
in that case forkCDR tricks would be much worse. Remember that non-related
CDRs are not inherited and posted.

The advantage is that it seems to be a very simple fix compared to a total
redesign that is never going to make it into 1.4 (sorry, i need that fix
now!). I just need to know where to call that function (do transfers happen
in the channel drivers or just in res_features?).

About your proposal of 1-1 link from CDR to channel, it's probably the
best idea for the future (1.6.*), but seems quite difficult to implement in
current versions, and I see it a bit complicated for a billing system to
relate channels together in order to bill actual calls (even tho it must be
feasible adding new variables to the CDR or using ANI/Accountcode).

Thanks for the feedback, anyone knows how to remove that "LICENSE PENDING"
thing (I sent my information using that form and don't know what happens
next)? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-11-02 06:08 frawd          Note Added: 0094501                          
======================================================================