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

Asterisk Bug Tracker noreply at bugs.digium.com
Wed Feb 11 14:52:01 CST 2009


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 
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-02-11 14:51 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0099930) murf (administrator) - 2009-02-11 14:51
 http://bugs.digium.com/view.php?id=11849#c99930 
---------------------------------------------------------------------- 
OK, there is a window of opportunity here, I think!

I'm currently working on a fix for 13892; and due to the intertwinement
[is that an official English word?) of the CDR system in Asterisk, my fixes
cause regressions, which require fixes that cause other regressions, etc.
Anyway, they reached into the behavior of both the blind xfer and the
attended transfer. The blind xfer was pretty easy to restore, but the
attended xfer is really whacked out, (my current case is where A calls B,
and B axfers A to C), generating 4 CDRs, with 8 unique start, ans, end
times, involving a local channel pair, and masquerades on both sides of the
two local channels involved; A total of 9 CDR's; 4 bridge CDRs and 5
involved channels.

This is what I think you would want to see in this case:

CDR1: chan: A; dstchan: B; st: when A picks up or arrives; ans: when B
ans; 
      end: when C hangs up (used to be when B finished the xfer)
CDR2: chan: B; dstchan: C; st: when C starts ringing; ans: when C ans;
      end: when A/C hang up.

In the case where A calls B, A attended-xfers B to C, this is what I
think you want in this case:

CDR1: chan: A; dstchan: B; st: when A picks up or arrives; ans: when B
ans; 
      end: when C hangs up (used to be when A finished the xfer)
CDR2: chan: A; dstchan: C; st: when C starts ringing; ans: when C ans;
      end: when B/C hang up. (there is no room in the CDR to express that
      B and C were connected during this CDR's timespan)

Is this correct? I can't guarantee that I can pull this off; if it
involves too much channel-foo outside the attended xfer func, I may to
leave it at the way-it-used-to-be; we shall see.

You can see where I'm at if you play with the d14.dig1 patch on 1.4 svn
(attached to 13892) . The rules are simple: do everything in the attended
xfer func in res_features.c, or forget it. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-11 14:51 murf           Note Added: 0099930                          
======================================================================




More information about the asterisk-bugs mailing list