Summary:	ASTERISK-25134: Problem with CDR information with incoming calls
Reporter:	Javier Acosta (DarkS)	Labels:
Date Opened:	2015-05-26 18:32:41	Date Closed:	2015-06-16 14:37:45
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	CDR/cdr_adaptive_odbc Functions/func_cdr
Versions:	13.3.2	Frequency of Occurrence	Constant
Related Issues:
Environment:	Debian 8.0 Asterisk 13.3.2	Attachments:	( 0) 3_members_queue_incoming_call.txt
Description:	There is a problem with the CDR information in a incoming call, the Leg-A Channel in the incoming call the information in the Database for the CDR is incorret in the Leg-A (the call disposition is "NO ANSWER" and the billsec and duration is set to 0), in the extension h the DumpChan and NoOp of this variables show the same information. In the database the Leg-B that answer the call has duration and billsec bit the others ringing Legs has duration too, the disposition in the Leg-B is correct but no the duration. In Asterisk 1.8 the Leg-A disposition is ANSWER and the billsec and duration are correct and the Leg-B is correct in the Database table. I think that maybe there is a bug in the new way to track the CDR information in Asterisk 13. Please tell me if that is a bug, in case that is a bug please tell me where to start searching for that bug
Comments:	By: Javier Acosta (DarkS) 2015-05-27 10:53:37.479-0500 In Asterisk 11 the incoming call Leg-A information is still incorrect, the call disposition appear as NO ANSWER but the billsec and duration are populated and has the correct information, but the Leg-B has the incorrect information again with the call disposition in NO ANSWER and billsec and duration set to 0. As i commented this happen in incoming calls that are routed to Queues, i think that this problem is linked with the new CDR function that before the channel bridge lock the CDR modification, i don't know exactly where is the problem, but in the CDR written to the DB the information is incorrect too. I attach a DB CDR entry of call that sound in a 3 members queue and answer the ext002 member, as you can seen all the 3 Leg-B has duration and billsec and the main call has no time. I keep tracking this issue. By: Rusty Newton (rnewton) 2015-05-28 19:09:35.199-0500 We require additional debug to continue with triage of your issue. Please follow the instructions on the wiki [1] for how to collect debugging information from Asterisk. For expediency, where possible, attach the debug with a '.txt' file extension so that the debug will be usable for further analysis. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Rusty Newton (rnewton) 2015-05-28 19:10:26.399-0500 Please provide the requested debug log showing the output for the call in question. You should provide new CDR log output along with the debug. By: Rusty Newton (rnewton) 2015-05-28 19:10:43.856-0500 Use 'Send Back' or 'Enter Feedback' to send the issue back to us once you have the information. By: Rusty Newton (rnewton) 2015-06-16 14:34:15.890-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 on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines By: Rusty Newton (rnewton) 2015-06-16 14:37:45.048-0500 In Asterisk 12 we developed a specification for CDR in Asterisk. Comparing 1.8 to 12 or beyond is not completely useful as there were some big changes. If you choose to pursue this issue in the future then please compare the behavior to the spec and in a new issue point out where the issue fails to meet the spec. Then provide steps for reproduction of the issue along with full debug logs and corresponding CDR logs. We need all of that information to examine and investigate the issue. Fixes or changes to CDR are not made lightly as they tend to break more than they fix.