[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 
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-16 23:14 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0100238) murf (administrator) - 2009-02-16 23:14
 http://bugs.digium.com/view.php?id=11849#c100238 
---------------------------------------------------------------------- 
No, I cannot expect that the next release will contain the set of fixes I'm
working on now. Change one thing, and you have to change a bunch of things.
To get what we want, I have to make changes in several places. And the
effects of a change reach out and touch other parts of the system. That's
the deal with systems built in-line like this. And why I abominate them. 

The current situation stands this way: I've made significant improvements
and fixed several problems, but the fixes broke both the blind transfer and
attended transfers. I fixed the blind transfer mechanism to behave the same
braindead way it used to, but that's not easily done with attended
transfers. It's a delightfully interwoven sequence of local channels,
masquerading, and multiple threads. For instance, the last part, where the
transferred party and the transferee converse, is done in its own thread.
The dial operation to the transferee is done in the realms of executing the
dialplan to get the end party via a local channel -- after all, you might
just as easily have transferred the party to a recording as to another
extension. In my manipulations, I see from 3 to 5 CDRs, all of them
garbage, and the two I *WANT* to publish get tossed!

Well, this is an all-or-nothing sort of situation. I can't release the fix
with attended transfers braindead; I'd be better off tossing the whole wad
and closing all the bugs. On the other hand, I'm understanding all the
mechanics and their consequences more and more as I tinker and experiment
and study them. I feel like what I want to do is doable; I simply have to
turn off all the CDR's that normally would be generated, and allow the two
I'm building in the atxfer routine to get posted. Couldn't be simpler, eh?

Well, if I can achieve this with atxfer, then I need to revisit the blind
xfer, and get that to do the same also. It's just that it operates a fairly
different way. No local channel. Just an asyncgoto. I'll have to suppress
the CDR's that normally would be output, and generate the two (pretty much
the same stuff) that I would with the attended xfer.

If anyone is interested, I can attach a patch that will give you exactly
what I am working on at present. It has one main problem-- a crash when the
tranferee (the party "C") answers the call (A calls B, and A xfers B to C).
The crash is because the CDR pointer is corrupted, which normally would
imply the channel has been destroyed, and freed, reallocated for something
else, and the cdr pointer overwritten. Which, btw, is not really very good
news. I've got 5 pages of notes on the subject already, not including the
dozens of sets of log message outputs I've captured and analyzed so far,
each capturing a little more state over the last, as I insert more and more
debug tracing. It's a matter of tracing the unique ID's, and CDR pointers,
as a lot of cdr's internally are copies of each other and share the same
unique ID's. There's a zombie or two to watch out for in the mix as well,
the makings of a real horror story!

Oh, and because two CDR's are getting generated, that creates somewhat of
an ambiguous situation for when the h-exten is run on C when it gets hung
up. Which CDR will you be seeing and able to mod when the hangup routine
runs? This is new territory! A is the only dialing party in this particular
sequence, but he's called both B and C. Now, A is hung up while B and C
converse, but A is the guy responsible for both calls, so his h-exten needs
to be saved to coincide with the publishing of the two CDR's. This is so
against the philosophy of the h-exten running philosophy, yet it needs to
be, as most people use the h-exten to tweak the CDR going out the door...
The philosophy is all wrong in this instance. The h-exten is run on all
closing channels; it really shouldn't have been tied to CDR's.  If we were
smart, we'd define a CDR extension, and a before a CDR got posted, it would
get run. Only problem with that is: the channel the CDR might be associated
with could be gone. How do you execute dialplan without a channel? Well,
OK, at hangup time for B and C, we could execute the h-exten for them;
that's a little complicated by the fact that B and C are both peers, and
don't have a pbx associated with them! Hmmm, are you getting a feel for
what I'm playing with?


And, all the while, I'm haunted by the following questions: is it worth
it? Will the code really be better? Will we as devs and users really be
benefited by what I'm doing? If I can pull it off, you guys wanting valid
CDRs will definitely be benefited, but at a high price to me and the code,
I'm afraid!

Ok, enough said. I've got at least another week of work ahead of me, and I
still can't guarantee that I can deliver what everybody wants: working
h-exten, CDR's the way we described, and no bad/unwanted CDR's.  Maybe I
can, maybe I can't. That's the honest truth at the moment.

All I can hope is that I find some good, solid places to make some good,
solid, reasonable tweaks that will get us what we need, and not louse up
everything I've already accomplished! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-16 23:14 murf           Note Added: 0100238                          
======================================================================