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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=11849 
====================================================================== 
Reported By:                greyvoip
Assigned To:                mnicholson
====================================================================== 
Project:                    Asterisk
Issue ID:                   11849
Category:                   CDR/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
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-06-02 19:18 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 :).
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0013892 After upgrading from 1.4.21.2 to 1.4.22...
related to          0014398 Calls coming in then out do not get rec...
====================================================================== 

---------------------------------------------------------------------- 
 (0105921) sverre (reporter) - 2009-06-02 19:18
 https://issues.asterisk.org/view.php?id=11849#c105921 
---------------------------------------------------------------------- 
As promised, I've uploaded the version 2 of my AGI scripts - which is a
hack workaround to make sure Asterisk user's customer's aren't able to make
expensive phone calls without getting billed.

Some notes:
 - It depends on MySQL CDRs
 - It depends on having populated uniqueid's
 - It comes with no warranty and no support
 - It could probably be done better another way, but it works

Installation
 - Remove "v2-" from the front of the file names
 - Put the AGI files in /var/lib/asterisk/agi-bin/
 - Edit them to change database username/password
 - Give them permissions (e.g. rwxr-xr-x)
 - Call them from extensions.conf
 - Add the field transferto to your cdr table in MySql

Extensions.conf

exten => h,1,Macro(transfers)
; You probably need this in both your outgoing and incoming contexts

[macro-transfers]
exten => s,1,GotoIf($[${LEN(${BLINDTRANSFER})} > 0]?blindtransfer)
exten => s,n,DeadAGI(attendedtransfer.agi)
exten => s,n,GotoIf($[${LEN(${UNIQUEIDTO})} > 0]?attendedtransfer)
exten => s,n,MacroExit()
exten =>
s,n(attendedtransfer),DeadAGI(settransferfield.agi,${UNIQUEID},${UNIQUEIDTO})
exten => s,n,MacroExit()
exten => s,n(blindtransfer),DeadAGI(blindtransfer.agi)
exten => s,n,DeadAGI(settransferfield.agi,${UNIQUEIDFROM},${UNIQUEIDTO})
exten => s,n,MacroExit()

How it works (attended transfers):
 - When an attended transfer completes, the ending CDR points to the
continuing CDR by way of the BRIDGEPEER variable. By looking up that
channel information, the UNIQUEID can be retrieved to go in the MySQL
transferto field of the ending CDR.
 - Different circumstances change exactly where to retrieve the UNIQUEID
from, but the circumstance can be deduced from the contents of the channel
information.

How it works (blind transfers):
 - In some cases, same as above
 - In other cases, the uniqueid of the two CDR's is the SAME, and in that
scenario the AGI calls "setuniqueid.agi" to change one of them before
linking them 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-02 19:18 sverre         Note Added: 0105921                          
======================================================================