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

Wed Jan 28 10:07:23 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-01-28 10:07 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0098960) murf (administrator) - 2009-01-28 10:07
 http://bugs.digium.com/view.php?id=11849#c98960 
---------------------------------------------------------------------- 
Welcome to CDR land!

I've come to the conclusion that storing CDR's on a channel is not the way
to go. The operations done to channels pose some logically impossible
choices. It kinda reminds me of Quantum Mechanics; and the fate of coupled
photons, but in our case, nothing ties our photons (channels) together-- A
masquerade shifts the guts of a channel into a new channel, and the new
channel even gets the name. The old channel, stripped of all its active
info, including its name (it gets a ZOMBIE added to its old name), is left
to die. It is meant for the two versions of the channel to be owned by
different threads.  Either one could actually die and be destroyed before
the other. The new channel gets the CDR. The old one keeps the PBX pointer.
The new channel is now a "peer". This works fine for parking, but other
cases... well, not so well.  If a hangup occurs for the new channel, the
old channel neither knows nor cares. Yes, you could look up a channel by
name, but... that's a really, really, expensive and odious procedure, and
there's no guarantee you'll find it... it might have been destroyed
already!

There is no universally acceptable solution to which channel in a
masquerade should get what info; indeed, in some cases you won't know until
one of the channels is dying, or reconnected. That's why I think CEL is the
way to go. You are at a level above the channels, independent of them, with
snapshots of the data that was stored on the channel at that moment. You
have the power to select what channel info goes into a CDR. My chief
challenges will be to recognize patterns and generate the proper CDRs from
them. CEL will gather all the events from all the channels involved, and
can easily decide what to do in retrospect. If we spot a gotcha, I can
refine the matching alg.

I've been thinking about another possible approach, where we build into
the transfer code the decisions about where things should be shuffled
between interacting channels. There are points in the code where you have
pointers to all the interacting channels at once, and these would be good
places to make sure the CDR data gets shuffled around, but even this
approach is subject to the  weakness that you can't make decisions before
you know the outcomes, and thus possibly this approach would fail also.

Add to all this the fact that code paths overlap in the pbx engine, and
the nice and elegant generality of the situation hides particular cases you
might need to discern. And the fact that "peer" and "channel" roles are
hard-wired into the various function calls, and it's not at all clear how
to handle colliding/changing peer/channel relationships...

And, add to that the "simple" running of the h (hangup) extension in the
dialplan when certain (channel role) channels are being hung up... and the
combinatorial mess that results when xfers, parks, etc happen is just ...
breathtaking. You see, masquerades don't always happen in all situations in
the course of xfers... so....

I love challenges, but tweaking is no longer an option. It's time to
rewrite.

But, I don't want to discourage innovation-- if womeone finds a magic
solution, I don't want to discourage them from trying... 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-28 10:07 murf           Note Added: 0098960                          
======================================================================