[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-10-29 16:41 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 :).
====================================================================== 

---------------------------------------------------------------------- 
 (0094380) mdu113 (reporter) - 2008-10-29 16:41
 http://bugs.digium.com/view.php?id=11849#c94380 
---------------------------------------------------------------------- 
I've got an idea that I want to share and discuss with you. First of all, I
do agree that actually fixing the cdrs is the best thing to do, but if
that's too hard and involves some complex design decisions, may be we can
use the following workaround.
I think blindly transferred calls can be billed properly with no changes
to asterisk exploiting the inheritable channel variables and cdr
userfield.
The dialplan logic would be something like follows:

if BLINDTRANSFER is set {
   Set(CDR(userfield)=${XFERRER}
}
Set(__XFERRER=${UNIQUEID})

i.e. we set XFERRER variable to channel uniqueid for every call and in
case of blind transfer it will be inherited and available in the new call.
By putting it into userfield we can now correlate to cdrs generated and
calculate the correct billing time. Now, for our favorite example:
1. A calls B. Talks to B for 10 seconds
2. A blindly transfers B to C
3. C answers and they talk for 60 seconds
4. call ends
we have the following 2 cdrs:
   Start time    Uniqueid    Billsec    Userfield
1. 00:00         01          10 
2. 00:15         02          60         01
Now this 2 cdrs can be correlated as 2nd being a transfer of 1st and so
correct billing time can be calculated for the 1st cdr as 
billsec_1=(start_time_2 - start_time_1)+billsec_2
As far as I can tell (and according to my testing) it's going to work for
any blind transfer scenario.
I think something like that can also be used for attended transfers with
some help from asterisk. If transfer handling code, where all information
is available, could set some channel variable for the transferred call that
would contain an id of the transferror, then in the 'h' extension we could
catch that value and put it in userfield, thus making it possible to
correlate 2 generated cdrs to each other and so calculate the correct
billing time.
What do you think? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-29 16:41 mdu113         Note Added: 0094380                          
======================================================================