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

---------------------------------------------------------------------- 
 (0094391) greyvoip (reporter) - 2008-10-30 06:05
 http://bugs.digium.com/view.php?id=11849#c94391 
---------------------------------------------------------------------- 
mdu113 in answer to your question it's already possible to "hack" together
a CDR for a Blind Transfer by making use of the fact that when the Transfer
occurs it goes through the TRANSFER_CONTEXT (I've probably got that name
wrong). Doing this adds extra complexity to your dialplan and billing logic
but it can be done and I'd say that's less of an effort then a code change
for a quick fix.

murf it would be extremely disingenuous for me to criticise your efforts
since you are the only core developer to take an interest in this very
"un-sexy" area. I for one and am very appreciative of your efforts and any
criticisms I might make are definitely not directed towards you
personally.

What frustrates me with regards to this bug is that I can't understand why
it's not given a very high priority. As I've said a few times this is
costing providers money. And I'm not just saying that, I have literally
placed calls with public ITSP's and obtained free call legs (of course I
kept the legs brief as I'm not out to cost anybody anything). I contacted
those ITSP's and one denied he had the problem, despite the fact that I had
placed the free call and another one was very worried but not enough so to
jump on this bug report and help me agitate ;-).

Despite all the comments to the contrary the fix for this problem is
conceptually simple. The Asterisk designers have incorrectly created a
1-to-1 relationship between CDRs and bridges. There is no way that is ever
going to work in complicated call scenarios and in fact as we see here it's
not even working for next to the simplest ones! The fix is to break the
1-to-1 relationship between bridges and CDRs and instead make it 1-to-1
between channels and CDRs. Conceptually it's that easy and I can vouch for
it working in other softswitches.

I should take the time to look at doing a fix for this myself but what
puts me off is the fact that unless there is agreement on the design with
the powers that be (aka Russell and/or Kevin) in the first place any patch
by a non-core developer is not going to make it anywhere near Asterisk when
it's so close to the bone!

As for CEL and the new CDR approach I've mentioned before that it scares
me a lot. Again I'm not trying to criticise for the sake of it and CEL
sounds like it's going to be good for some things but retrofitting it for
CDR's looks to me like a sledge hammer for a thumb tack solution.

And while I'm ranting away I would also argue that at the very least this
bug should not be closed while the solution is not fixed regardless of
whether it's too hard or not. Closing the bug will give people the false
impression it's been fixed. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-30 06:05 greyvoip       Note Added: 0094391                          
======================================================================