Summary:	ASTERISK-21486: Call answered by a dynamic agent and then SIP transferred to an external number is not written to CDR
Reporter:	David Brillert (aragon)	Labels:
Date Opened:	2013-04-17 08:14:04	Date Closed:	2013-04-24 13:35:57
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:	11.3.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	CentOS 5 64 bit Intel	Attachments:	( 0) extensions.conf.txt ( 1) Master.csv ( 2) Master1.csv ( 3) messages ( 4) messages.txt ( 5) modules.conf.txt ( 6) queues.conf.txt ( 7) sip.conf.txt
Description:	Incoming call to app_queue is answered by an ACD agent is collected by CDR. The agent does SIP transfer to an external number and the CDR is not collected. This only effects calls to an ACD queue as far as I can tell. For example: Incoming call to an extension is collected by CDR if the extension does SIP transfer to an external number the CDR is collected. I'm attaching verbose asterisk messages log with sip set debug on and the Asterisk master.csv file for the broken scenario.
Comments:	By: David Brillert (aragon) 2013-04-17 08:24:28.057-0500 Summary of /var/log/asterisk/messages file attached: The call flow comes from an external Asterisk server with phone extensions 8000 and 8001 registered. Agent 1 is logged to extension 6000 Extension 8000 dials 5555551234 to ring queue Agent 1 Extension 6000 answers 5555551234 and does SIP blind transfer to 8001 8001 picks up No CDR collected for Agent 1 Extension 6000 answers 5555551234 and does SIP blind transfer to 8001 This is a serious problem because the call to extension 8001 or any other external transfer from an agent extension cannot be billed. By: Rusty Newton (rnewton) 2013-04-22 14:46:43.309-0500 We'll need more info: * sip.conf * queues.conf * agents.conf * extensions.conf (specifically the dialplan involved with these calls) We'll need a new Asterisk log with SIP debug, VERBOSE and DEBUG at level 5. Your log was missing just the DEBUG messages. And of course the CDR generated from the new test. What module are you using for the CDR backend? By: David Brillert (aragon) 2013-04-22 15:31:10.282-0500 The dial plan is encrypted AGI so difficult to upload. sip.conf general extension.conf for the agent Not using chan_agent modules.conf Master(1).csv messages with debug and verbose 5 core 5 sip debug enabled Using cdr_odbc By: Rusty Newton (rnewton) 2013-04-22 16:33:49.477-0500 Thanks for the additional info. I don't see any obvious cause. Though in most CDR cases the issue is not obvious. Transfers have been notorious for issues in CDR. Unfortunately for CDR there is much undefined behavior for transfer scenarios. That is a big reason why CEL (Channel Event Logging) https://wiki.asterisk.org/wiki/display/AST/CEL+Design+Goals was created. This makes it difficult to tell what is a bug and isn't, and even if developers attempt to fix it then it's likely to break something else for you. The whole scenario is definitely something the development team is trying to address in Asterisk 12 and beyond https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification Did this behavior work in a previous version within the same 11 branch? By: David Brillert (aragon) 2013-04-24 12:18:07.603-0500 I tested Asterisk 11.0.1 and 1.8.21 with the same results. I did some additional testing with my Polycom phones and determined the following information which should be helpful. If the agent logged into the Polycom phone is doing a blind SIP transfer to an external interface then the outgoing call does not appear in the CDR. If the agent logged into the Polycom phone is doing an attended SIP transfer to an external interface then the outgoing call DOES appear in the CDR. This probably affects other handsets that do blind SIP transfers as well but easily reproduced with Polycom phones. My messages file already includes the SIP debug info during the blind SIP transfer. By: Matt Jordan (mjordan) 2013-04-24 13:35:46.300-0500 The behavior of CDRs in transfer scenarios is undefined. As Rusty alluded to, this is for two reasons: # For a long time, people have disagreed about what CDRs should look like when a transfer occurs. The lack of any clear consensus led the Asterisk development team to the creation of CELs, in which a billing system can determine what should be billed and when. # The Asterisk bridging core in many ways makes determining what a CDR should look like an incredibly brittle operation. Attempts to change the behavior in CDRs in release branches - particularly in transfer scenarios - led to many regressions. Eventually, the developer community decided that it would no longer attempt to change the behavior of CDRs in release branches. What does that mean? # While the behavior may not be desirable, the fact that (a) CDRs have undefined behavior in transfer scenarios, and (b) it is not a change in behavior in a release branch (at least, so far as we cna tell) means we will not address this as a 'bug'. # Any improvement made to CDR code is already being done for [Asterisk 12|https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification]. In particular, externally initiated transfers (both blind and attended) have been specified. Since the bridging code is being completely redone and the CDR engine is being rewritten, there's no real point in keeping this issue open for the current work (particularly since there are ASTERISK issues tracking all of that work, as noted on the [Bridging Project Page|https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project]. Finally, you may be able to perform a work around to the current situation by using [ForkCDR|https://wiki.asterisk.org/wiki/display/AST/Asterisk+11+Application_ForkCDR]. This application was written specifically for scenarios in which you want a CDR record and one is not created for you automatically by Asterisk, e.g., in transfer scenarios. Given all of this, I'm going to close out this issue as "Won't Fix". I understand this may not be ideal, but given all of the above, I don't see this issue being addressed in any release branch of Asterisk. If, however, it can be determined that the behavior of CDRs changed in a release branch in the scenario described above, we can re-open this issue. If that is the case, please contact a bug marshal in #asterisk-bugs and we'll be happy to do so. By: Matt Jordan (mjordan) 2013-04-25 09:21:43.833-0500 David - It's possible that this is the same issue as ASTERISK-21394. If so, can you test the patch that Steve attached to the issue? If that resolves the issue and this is the same as that, we'll keep this closed out as a duplicate of that issue, but that will at least mean we can fix your CDR problem.