[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:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13364
Category:                   CDR/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
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-08-22 15:37 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
====================================================================== 

---------------------------------------------------------------------- 
 (0091662) mdu113 (reporter) - 2008-08-22 15:37
 http://bugs.digium.com/view.php?id=13364#c91662 
---------------------------------------------------------------------- 
Also, if it matters, 1122 (call originator)- xlite softphone, 101 (the
one's doing transfer) polycom 501, 1100 (final destination) - cisco 7960. 
The transfer was done by polycom blind transfer feature. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-08-22 15:37 mdu113         Note Added: 0091662                          
======================================================================