[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
Target Version:             1.4.25
Asterisk Version:           1.4.17 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2008-01-26 11:11 CST
Last Modified:              2009-03-02 21:07 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 :).
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0013892 After upgrading from 1.4.21.2 to 1.4.22...
====================================================================== 

---------------------------------------------------------------------- 
 (0101064) sverre (reporter) - 2009-03-02 21:07
 http://bugs.digium.com/view.php?id=11849#c101064 
---------------------------------------------------------------------- 
I've just added two agi scripts written in php, attendedtransfer.agi and
settransferfield.agi that allow you to create a link from the prematurely
ending CDR to the continuing CDR with the idea that you can post process
the CDR after the fact.

It works for me on 1.4.22, no idea if it works on other versions.

You will need to add the field transferfield to your CDR MySQL table,
you'll need to change the MySQL username and password in
settransferfield.agi, and you'll need to call the AGI script from your
dialplan, for example:

exten => h,1,DeadAGI(attendedtransfer.agi)
exten => h,n,GotoIf($[${LEN(${CHANNELDSTFROM})} > 0]?attendedtransfer)
exten => h,n,MacroExit()
exten =>
h,n(attendedtransfer),DeadAGI(settransferfield.agi,${CHANNELDSTTO},${CHANNELDSTFROM})

You probably want to wrap that in some kind of check for a blind transfer
(use the ${BLINDTRANFER} variable to find out, and then call
settransferfield.agi in that scenario as well - but I haven't gotten that
far yet.

I've tested it in the following scenarios:

A->B, A->C, Transfer
A->B, A->C, swap, transfer
A->B, C->A, transfer
A->B, C->A, swap, transfer
B->A, A->C, transfer
B->A, A->C, swap, transfer
B->A, C->A, transfer
B->A, C->A, swap, transfer

I've NOT tested it with two sequential transfers.

Some important notes:

This script is a dirty hack, and it's not written very well. In hindsight,
I should have tested for each of the 8 above scenarios and done a case
statement. As it is, it's a bunch of nested if's. I programmed one scenario
and figured it would work on all, then started adding exceptions and ended
up with this as the result. If i make a neater version, I'll post it here.

The settransferfield.agi could perhaps have used the existing MySQL link,
but it was easier to use php's inbuilt mysql functions.

There are NO GUARANTEES about anything here. If it works for you, great.
If not, don't use it, or better yet, revise it.

It figures out which of the above scenarios is happening by calling
asterisk at the command line with a "show channel XYZ" command, and
extracting information from that. I've had to use things like the number of
DIALEDPEER, BRIDGEPEER variables present, and link to other channels by
their contents. This makes this hack EXTREMELY SUSCEPTIBLE to changes in
the show channel command. Even changing the order of reported variables
will give weird results. Use it at your own risk. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-02 21:07 sverre         Note Added: 0101064                          
======================================================================