[Home]

Summary:ASTERISK-12633: CDRs produced on blind transfer are incorrect
Reporter:mdu113 (mdu113)Labels:
Date Opened:2008-08-22 15:19:34Date Closed:2008-09-16 17:39:40
Priority:MinorRegression?No
Status:Closed/CompleteComponents:CDR/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) ast_cdrbug.txt
( 1) parking_crash2.txt
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

****** ADDITIONAL INFORMATION ******

My production systems are currently running on SVN-branch-1.4-r118858 and I'm  now testing the latest stable code. The problem doesn't exist in r118858, so it's definitely caused by some change after that.
The console output and produced CDRs from both r118858 and current 139283 are in attached ast_cdrbug.txt
I did see in the svn log that there was a bunch of cdr-related changes made since 118858. I wouldn't claim to understand them, but it was my understanding that they are done in the backward compatible manner.
Comments:By: mdu113 (mdu113) 2008-08-22 15:37:27

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.
By: Digium Subversion (svnbot) 2008-09-11 17:46:18

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 ASTERISK-12633)
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
By: mdu113 (mdu113) 2008-09-15 17:02:54

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
By: Steve Murphy (murf) 2008-09-16 17:39:38

As in 13251, issue 13425 seems to be a separate issue; a fix concerning this
bug may have exacerbated or brought it forward; I do not know, but if jpeeler
has a fix in 13425, then this bug need not be opened unless more directly implicated, or a fix involves changing the fixes here.