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

Asterisk Bug Tracker noreply at bugs.digium.com
Mon Sep 15 17:02:55 CDT 2008


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:                     closed
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:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2008-08-22 15:19 CDT
Last Modified:              2008-09-15 17:02 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0092539) mdu113 (reporter) - 2008-09-15 17:02
 http://bugs.digium.com/view.php?id=13364#c92539 
---------------------------------------------------------------------- 
As I described in issue 13425, this fix introduced a crash in one-touch
parking.
If parking fails (because extension specified in PARKINGEXTEN already
exists) then asterisk now crashes, while it doesn't crash in previous
revision 142474 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-15 17:02 mdu113         Note Added: 0092539                          
======================================================================




More information about the asterisk-bugs mailing list