Summary:	ASTERISK-14945: CDR blind transfer problem
Reporter:	Joao Carvalho (foxfire)	Labels:
Date Opened:	2009-10-06 10:44:41	Date Closed:	2011-07-26 14:25:41
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	CDR/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) console.txt
Description:	When performing a Blind transfer on a phone of an incoming phone call, and transfering it before the called party answers will mess up the CDR records. CDR records are correct when the call is answered before the transfer ocurs. I only consider this major, because without a working workaround i can not upgrade to 1.6 and will have to continue with 1.4 ****** ADDITIONAL INFORMATION ****** This problem  messes up billing. I believe it can be reproduced basicly whith any hard and softphone that does blind transfer. In my case i used an Polycom 330. Let me give you a scenario: A calls B B transfers call to C if B transfers after C answers all is OK if B transfers before C answers some variables are messed up. 2 records can be fouund in the CDR with the same uniqueid. The first record is correct and show the correct call records for A-B. The second shows the wrong userfield. Instead of showing userfield B-C it will show userfield A-B. Callerid is also wrong and shows A as the originator instead of B.But that us not a problem because i depend only on the userfield for billing. A temporary workaround would be including the userfield in the dialstring so that lastdata would contain the info, how can i increase the charsize of that variable ? i tried increasing it in mysql but that is not enaught. I checked the source code but found it a bit confusing about the size definition of that variable.
Comments:	By: David Woolley (davidw) 2009-10-06 11:53:58 I think this is a chan_sip issue, and probably needs the standard sip bug attachments. From the context, it looks likely that this is a SIP tranfer, not an Asterisk features transfer, but it might be worth confirming this. You may find that the difference is the result of how the phone handles the transfer.  SIP wasn't designed with the forwarder pays billing policy in mind, but rather with the ability to optimise the call route.  If Asterisk were to actually pass the REFER back up stream, the party A to party C call would appear as a completely seperate call, that might not even go through Asterisk.  It is only because Asterisk doesn't do this that it is possible to attempt to bill this case. One possibility that I can see here is that the phone sends the REFER/Replaces to A in one case and to C in the other case.  Both are allowed by the RFCs, as far as I know.  I wonder if it is sending it to C when the call is established and to A, otherwise.  The protocol traces would help to show whether that is the case.  It may even be dropping the unanswered call and sending a simple REFER. When you say user fields, I take it that you mean CLI and "extension" number. Note that there is a new CDR mechanism, channel event logging, being introduced from about version 6.2, which is intended to make billing complex cases possible. (Added later: Of course, if the REFER were pushed up stream, you might not incur any costs, so that is probably less important.  However, it is still fairly clear to me that SIP transfers were not designed to make billing easy.) By: Joao Carvalho (foxfire) 2009-10-06 12:21:09 That that was quick,thank you. I did some more tests, most fields are correct such as clid,src.dst,channel,dstchannel ,lastapp,lastdata but userfield is wrong i set the userfield with the call and billing option for example: userfield=3001,003519232322,TRUNK1,ROUTE:003519 later on i can decide depending the case who to bill the call to What is happening is that i get the wrong userfield i get the acct of the internal call userfield=3003,3001 so the call will not get billed. For now i found a very ugly workaround. first i changed lastdata size to 256. next i am dialing for example with Dial(IAX2/log@pr/003519232322,60,RTtWwKk,,3001,003519232322,TRUNK1,ROUTE:003519) because there are no 5 and 6 argument in dial it will not confict and the string goes into the CDR. As i said this is ugly an unprofessional i would love if this would work the other way By: Joao Carvalho (foxfire) 2009-10-07 08:35:23 I am unable to see any Moved Temporarily on the console, but i might have to increase the debug level for that. Just in case i uploaded the console log for the call. There you can see 6002 calls 6001 6001 transfers to 0035196... 0035196... answers and hangs up In both cdr records the userfield contains "6002ASTERISK-5842" By: Leif Madsen (lmadsen) 2009-10-07 08:39:13 I don't see how this is related to 15983 at all... By: Leif Madsen (lmadsen) 2011-07-26 14:25:35.615-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks! (The real solution here is to use Channel Event Logging which was designed specifically for this type of control.)