[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 21:05 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 :).
====================================================================== 

---------------------------------------------------------------------- 
 (0094496) frawd (reporter) - 2008-11-01 21:05
 http://bugs.digium.com/view.php?id=11849#c94496 
---------------------------------------------------------------------- 
Excuse if the approach is too naive, having only been a few hours with CDRs
I assume that it is wrong, please tell me why!

The idea would be to use the existing CDR linked list structure, which
apparently is only used to store current and forked CDRs, to store
inherited CDRs from transferers, to be posted at a later time. Whenever we
have a transfer, and before hanging up (and posting CDRs) the transferer,
we would move the CDRs from the transferer to the transferee only if they
are related, otherwise leaving them on the transferer channel to be posted
when the transfer completes.

The following simple scenarios illustrate the idea.

* Blind transfer:
1. A calls B: this bridge has CDR1 (A->B)
2. A blind transfers B to C: the new bridge has CDR2 (A->C) plus inherited
CDR1 (A->B), CDR1 is not posted yet
3. B or C hangs up: CDR1 and CDR2 posted

Resulting CDRs:
CDR1 (A->B): start=1, end=3
CDR2 (A->C): start=2, end=3


* Attended transfer:
1. A calls B: this bridge has CDR1 (A->B)
2. A calls C: this bridge has CDR2 (A->C)
3. A transfers B to C: the new bridge has CDR1 + CDR2
4. B or C hangs up: CDR1 and CDR2 posted

Resulting CDRs:
CDR1 (A->B): start=1, end=4
CDR2 (A->C): start=2, end=4


* Chained transfer:
1. A calls B: this bridge has CDR1 (A->B)
2. A blind transfers B to C: the new bridge has CDR2 (A->C) + CDR1 (A->B)
3. C calls D: this bridge has CDR3 (C->D)
4. C transfers B to D: CDR2 is posted (not related to B or D), the new
bridge remains with CDR3 (C->D) + CDR1 (A->B)
5. B hangs up: CDR1 and CDR2 posted

Resulting CDRs:
CDR1 (A->B): start=1, end=5
CDR2 (A->C): start=2, end=4
CDR3 (C->D): start=3, end=5

The attached patch show a new function, ast_cdr_transfer to be called on
transfers (but where??), and a new flag AST_CDR_FLAG_INHERITED that
prohibits changing anything to them but the end-time and duration when they
are to be posted (like the AST_CDR_FLAG_LOCKED from forkCDR). Could it be
useful in anyway? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-11-01 21:05 frawd          Note Added: 0094496                          
======================================================================