|Summary:||ASTERISK-21822: Adaptive CDR Not Written When Call Ends In Blind Transfer|
|Date Opened:||2013-05-24 18:45:46||Date Closed:||2013-06-25 19:17:03|
|Description:||When a call ends with a blind transfer, cdr_adaptive isn't written at all.|
|Comments:||By: JoshE (n8ideas) 2013-05-24 19:21:51.657-0500|
May need to be a little more clear. The scenario I'm working with is a blind transfer to a parking lot extension. Looking at code this appears relevant.
If I do an attended transfer to the parking lot extension, adaptive cdr is written properly.
By: Rusty Newton (rnewton) 2013-05-30 16:47:12.068-0500
First, you haven't provided sufficient information for investigation of the issue. Please read through the guidelines. https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines
We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
If CDR records are not being written, we should either see
(a) something in the DEBUG logs illustrating that a call completed but the cdr_adaptive_odbc backend failed to pick it up,
(b) the backend picked it up but failed to write it, or
(c) the backend processed it normally.
If it's the first two possibilities, then a DEBUG log will help us determine why. If its the third, then its a system configuration issue or a problem on the MySQL end.
Be sure the DEBUG messages are set to at least level 5.
By: Rusty Newton (rnewton) 2013-06-14 15:16:22.603-0500
Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information can be found at http://www.asterisk.org/developers/bug-guidelines
By: Rusty Newton (rnewton) 2013-06-21 09:14:20.851-0500
Reopened at request of Josh-E. He's going to attach further debug.
By: JoshE (n8ideas) 2013-06-24 17:13:18.698-0500
So I went ahead and ran with debug set to 10, and there is literally nothing in the debug logs that indicates anything about CDR. I am only loading the cdr_adaptive_odbc backend. Not running any others. But it appears that a call terminating with a blind transfer is handled differently than a single hangup.
Is there another / better way to grab debug on this?
By: Rusty Newton (rnewton) 2013-06-25 15:05:55.425-0500
Since you didn't post the log. I have to ask: Did you see any "DEBUG" messages in your logs? If not, DEBUG may not have been enabled correctly.
More than likely there was just no CDR processed for that scenario.
See Matt Jordan's comment at ASTERISK-21486 for an explanation of why we won't be making any changes or fixes to CDR, unless this issue is a behavior change inside the release branch.
Can you confirm whether this behavior changed within the release branch? If so, what was the last version of 11 that had it working?
By: JoshE (n8ideas) 2013-06-25 18:27:05.099-0500
Yeah, so definitely nothing debug logs. We had it on.
This is version 11.4 and I can't confirm this ever worked in 11 branch. I know for sure on 11.3 and 11.4 this behavior is completely broken. On the *exact* same call scanerio, just ending the call in an attended transfer rather than a blind transfer, it works normally.
By: Rusty Newton (rnewton) 2013-06-25 19:16:06.370-0500
Ok. Sounds like this is still undefined behavior for CDR then. We recommend trying [Channel Event Logging|https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=5242932] as it was created due to these issues with CDR.
I'll copy/paste MJordan's comment from the ASTERISK-21486 issue for other viewer's reference:
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.