[asterisk-bugs] [Asterisk 0013364]: CDRs produced on blind transfer are incorrect

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13364 
====================================================================== 
Reported By:                mdu113
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   13364
Category:                   CDR/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 139283 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-08-22 15:19 CDT
Last Modified:              2008-09-11 17:46 CDT
====================================================================== 
Summary:                    CDRs produced on blind transfer are incorrect
Description: 
Dialplan:

[xyz]
exten => 100,1,Macro(stddial,SIP/xyz010001)
exten => 650,1,Macro(stddial,SIP/poly_650_01)
exten => 101,1,Macro(stddial,SIP/xyz010101)
exten => 1100,1,Macro(stddial,SIP/xyz110001)
exten => 1122,1,Macro(stddial,SIP/xyz112201)

[macro-stddial]
exten => s,1,GotoIf($[${ISNULL(${BLINDTRANSFER})}]?noxfer:+1)
exten => s,n,ForkCDR
exten => s,n,Set(CDR(userfield)="xfer=1")
exten => s,n,Goto(dial)
exten => s,n(noxfer),Set(CDR(userfield)="xfer=0")
exten => s,n(dial),Dial(${ARG1},15)
exten => s,n,Hangup

Scenario:
1122 calls 101, 101 answers and blind transfers to 1100

I'm storing CDRs in postgresql, so here's resulting CDR:
-[ RECORD 1 ]-----------------------
acctid      | 5597336
calldate    | 2008-08-22 15:43:30-04
clid        | "Michael" <1122>
src         | 1122
dst         | 101
dcontext    | xyz
channel     | SIP/xyz112201-081deed8
dstchannel  | SIP/xyz010101-081e4170
lastapp     | Dial
lastdata    | SIP/xyz010101|15
duration    | 16
billsec     | 12
disposition | ANSWERED
amaflags    | 3
accountcode |
uniqueid    | 1219434210.0
userfield   | xfer=0
-[ RECORD 2 ]-----------------------
acctid      | 5597337
calldate    | 2008-08-22 15:43:46-04
clid        | "Michael" <1122>
src         | 1122
dst         | 101
dcontext    | xyz
channel     | SIP/xyz112201-081deed8
dstchannel  | SIP/xyz010101-081e4170
lastapp     | Dial
lastdata    | SIP/xyz110001|15
duration    | 11
billsec     | 10
disposition | NO ANSWER
amaflags    | 3
accountcode |
uniqueid    | 1219434210.0
userfield   | xfer=0

As you can see "xfer=1" didn't make it into the 2nd CDR.
Also its disposition is "NO ANSWER", which is incorrect. dstchannel is
wrong as well
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0013431 Crash in ast_cdr_start() when Local cha...
====================================================================== 

---------------------------------------------------------------------- 
 (0092371) svnbot (reporter) - 2008-09-11 17:46
 http://bugs.digium.com/view.php?id=13364#c92371 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 142575

U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r142575 | murf | 2008-09-11 17:46:17 -0500 (Thu, 11 Sep 2008) | 20 lines

(closes issue http://bugs.digium.com/view.php?id=13364)
Reported by: mdu113

Well, fundamentally, the problems revealed in 13364 are
because of the ForkCDR call that is done before the dial. 
When the bridge is in place, it's dealing with the first
(and wrong) cdr in the list.

So, I wrote a little func to zip down to the first non-locked
cdr in the chain, and thru-out the ast_bridge_call, these
results are used instead of raw chan->cdr and peer->cdr pointers.
This shouldn't affect anyone who isn't forking cdrs before a
dial, and should correct the cdr's of those that do.

So, this change ends up correcting the dstchannel
and userfield; the disposition was fixed by a previous
patch, it was OK coming into this problem.



------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=142575 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-11 17:46 svnbot         Note Added: 0092371                          
======================================================================