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

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11849 
====================================================================== 
Reported By:                greyvoip
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11849
Category:                   Core-General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
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:             01-26-2008 11:11 CST
Last Modified:              01-26-2008 23:57 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 :).
====================================================================== 

---------------------------------------------------------------------- 
 greyvoip - 01-26-08 23:57  
---------------------------------------------------------------------- 
With blind transfers ForkCDR could be an option if called in the
TRANSFER_CONTEXT although it still looks quite difficult. The CDR I get
when using a ForkCDR with that approach lack the destination and don't have
any billing or answer times.

With attended transfers I can't see any way to use ForkCDR as the transfer
operation is bridging two existing calls and does not appear to go into the
dialplan again and therefore does not provide anywhere for ForkCDR to be
called.

Even if there was a way to do attended transfers with some sort of
TRANSFER_CONTEXT and ForkCDR mechanism it's pretty tricky stuff. I have
been looking at this on and off for a year now and the solution I use is to
block REFER requests on the SIP Proxy where the transfer destination is not
a free call. For other providers or people new to Asterisk the default
transfer CDR's leave them in a very dangerous situation. For instance with
1.4 at the moment the destination reported after an attended transfer is
"s". So if I place a call to one mobile number and then a second call to
another mobile number and transfer them together I will only be billed for
the time it takes me to get the transfer done. 

I've verified that it's not only my set up that's affected. I signned up
with some other known Asterisk based providers to check what I got billed
for when doing a trnasfer and in cases where the trnasfer did get through
the billing was incorrect. I kept the calls short of course :).

Incidentally murf has had a crack at improving the CDR handling, although
I think that has now stalled a bit, at least from what I can gather from
the last emails I saw on the Asterisk User's list. At the bottom of his
blog post he expresses a view on ForkCDR.

http://www.asterisk.org/node/48358

At least now in 1.4 there is the option to turn trnasfers off but I do
believe the CDR's currently being produced for blind and attended transfers
are dangerously incorrect. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-26-08 23:57  greyvoip       Note Added: 0081221                          
======================================================================