[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-30 12:02 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 :).
====================================================================== 

---------------------------------------------------------------------- 
 (0094421) murf (administrator) - 2008-10-30 12:02
 http://bugs.digium.com/view.php?id=11849#c94421 
---------------------------------------------------------------------- 
mdu113 -- I like your idea about providing a dialplan workaround; 
There are at least two ways to do a blind transfer/attended transfer--
one via the 'features' machanism; and the other built into the channel
driver (chan_sip in your case, I guess).

I see that the blindtransfer routines in both features.c and chan_sip.c
set the channel variable "BLINDTRANSFER" on both the referer and refer-ee,
with the name of the opposing channel. I do not see this machinery in the
atxfer code, tho, in either place...

Would it help if I added BLINDTRANSFER_UNIQUEID, that contains the
uniqueid setting of the opposing channel?  (You guys will love the linkedid
coming up in trunk someday.(soon, I hope)) 

I traced the code in the attended xfer in features.c (res_features.c in
1.4), and understand the flow, but there at least 4 separate failure exits
from the process, and how/if to set an ATTENDEDTRANSFER variable (if we
decide that's best) is problematic. Maybe we just set the BLINDTRANSFER
var(s) on attended transfers, too, then, and avoid the hassle of having two
vars to check. We could set it in the new channel and refer-ee channels
just before the final bridge between the two....

What to when the attended transfer is initiated, but the number wrong, the
called party doesn't answer, the referred party hangs up in the middle of
the process, etc. need to be decided...


Also, most sip phones allow the provide the hold/conference
buttons/facilities, where the phone itself bridges the two channels to make
a 3-way...

Greyvoip -- As to bridge-based vs channel based, it *was* channel based,
(really, it still basically is) and I shifted to bridge-based to solve
definite problems with legs not getting reported in xfers. The code is very
"folded"-- maximizing the sharing of code and minimizing code redundancy,
which is good, very good, but makes it a nightmare to isolate particular
circumstances where you need to do "this" instead of the normal "that"...
another factor that complicates things is that the CDR gathers 3 events and
contains copies of channel fields, creating confusion about when updates
occur, if at all, if channel fields are changed.

davidw -- don't get discouraged. Getting your brain wrapped around all the
ramifications of the CDR code is not a 10-minute process, at least it isn't
for me. If you feel you've reached nirvana and understand it all, we need
to talk! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-30 12:02 murf           Note Added: 0094421                          
======================================================================