[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-31 01:28 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 :).
====================================================================== 

---------------------------------------------------------------------- 
 (0094457) greyvoip (reporter) - 2008-10-31 01:28
 http://bugs.digium.com/view.php?id=11849#c94457 
---------------------------------------------------------------------- 
mdu113 the accountcode is what gets used to associate a channel to a user
and it's completely simple and unambiguous to associate a channel with a
user whereas associating a bridge to a user, which is the current
situation, is not. With a bridge which end "owns" the call. Obviously we
have all worked out how to cope with it for standard incoming and outgoing
calls but above that and as we're seeing here it gets messy. I've confined
my transfer scenarios to two specific cases but if you look at a blog post
murf did a while ago your head will end up spinning with all the
scenarios.

murf when I say a CDR per channel I have probably confused things
slightly. I'm not so much referring to the SIP or IAX channel but to one
CDR per ast_channel struct. At the moment each ast_channel does seem to
maintain it's own CDR structure up till a point but then when bridged use
bits and pieces from the two channels are combined or one overwrites the
other. If they were kept separate and each generated a CDR it would
completely solve the problem.

I think it is now possible to put a workaround in for the tarbsfer CDRs in
1.6.0.1 using the dialplan. Blind transfers are currently the broken ones
and they do go back to the dialplan when the transfer occurs so forkcdr and
a bit of mangling could be used. Previously it was attended transfers that
nothing could be done about but now they are actually correct in 1.6.0.1 so
that's something. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-31 01:28 greyvoip       Note Added: 0094457                          
======================================================================