| Summary: | ASTERISK-28152: mysql two record | ||||
| Reporter: | Mesut Altürk (multimesut) | Labels: | |||
| Date Opened: | 2018-11-06 01:15:45.000-0600 | Date Closed: | 2018-11-14 16:59:21.000-0600 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | CDR/cdr_adaptive_odbc | ||
| Versions: | 13.23.1 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) debug_log_123456.txt ( 1) debug_log_cdr.txt ( 2) Ekran_Alıntısı.JPG | |||
| Description: | We have updated asterisk version from 13.2.0 to 13.23.1. In the following case, double-throwing records.
*******extensions.conf******* [DLPN_DialPlan1] exten = 630,1,Queue(630,tkXx,,,,queue-set.php,) [macro-stdexten-record-test] exten => s,1,NoOp(Test) *******queue-set.php******* #!/usr/bin/php -q <?php require_once('phpagi.php'); require_once('phpagi-asmanager.php'); $agi=new AGI(); $agi->exec("Macro","stdexten-record-test"); ?> | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2018-11-06 01:15:47.250-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Kevin Harwell (kharwell) 2018-11-07 17:04:03.435-0600 Please enable CDR debugging and attach the log as a *.txt file for when the issues occurs. As well if not already done, bump up the core debug and verbose logging to at least level '5'. More info can be found on the [Collecting Debug Information|https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information] wiki page. Thanks! By: Mesut Altürk (multimesut) 2018-11-08 02:13:05.521-0600 Hello. I added. thanks. By: Kevin Harwell (kharwell) 2018-11-08 10:29:04.518-0600 [~multimesut] The log you attached appears to be the exact same log from before (just renamed with the 'txt' extension). Did you attach the wrong one? If not please turn on the debugging I mentioned above and attach that new log file as well. Thanks! By: Mesut Altürk (multimesut) 2018-11-09 00:16:30.732-0600 Hello Kevin Harwell , yes i have added the same file. :) the names of the same confused. "debug_log_cdr.txt" I have added a new file. I followed the steps below. core set verbose 5 core set debug 5 cdr set debug on module reload logger By: Kevin Harwell (kharwell) 2018-11-14 16:59:09.609-0600 From what I can tell Asterisk is working as it should. First, if you have not already, take a look at the [CDR Specification|https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification] page. It states the following: {quote} If a channel dials another channel and then continues on in the dialplan, the CDR for the dial operation is finalized and a new CDR is created. {quote} From the attached log this appears to be exactly what is happening. You can follow the transitions for channel 'SIP/101-00000059' and see that the first CDR for that channel gets finalized right after re-entering the dialplan that's initiated by the AGI: {noformat} $agi->exec("Macro","stdexten-record-test"); {noformat} This generates the first record in your database. A new CDR for channel 'SIP/101-00000059' immediately gets created, and is the one used for the rest of the call. Again you can follow the transitions in the log. As well you can verify that the start/end timestamps match as well for both inserted records. Hope that helps! By: Mesut Altürk (multimesut) 2018-11-15 00:53:54.957-0600 Hello Kevin Harwell, thank you for your interest. But there was no this behaviour on "asterisk 13.2.0" on "Addons/cdr_mysql" modul. I think it is wrong what it does now. Channel is not changing but it makes one CDR more. I'd call "ForkCDR" if i want it to create CDR. There is no any other code that i can prevent it to create a second CDR. It does not create any CDR if i call "NoCDR". I think there should be a code for these situations like "NoTwoCDR" even it does not prevent. Thank you. By: Asterisk Team (asteriskteam) 2018-11-15 00:53:55.481-0600 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Kevin Harwell (kharwell) 2018-11-16 13:30:22.767-0600 I went back to Asterisk 13.2.0 and ran a similar test. 13.2.0 exhibited the current behavior in that two CDR records were created for the given channel in the specified scenario. If two CDR records are created then both of those would propagate to any CDR backend writer. I checked the cdr_adaptive_odbc module and nothing has changed in that since 13.2.0 that would have effected the writing of records, so I assume it would have and would still write two database records since two CDRs were created. However based on your last comment it sounds like you are using the addons/cdr_mysql module. This module has been [deprecated since 1.8|https://wiki.asterisk.org/wiki/display/AST/MySQL+CDR+Backend]. If that is what you are using then it's possible there was a bug in that code that might have gotten fixed, and it now properly writes all propogated records. Unfortunately there appears to be nothing for us to do for this. Given the scenario, and the log file it appears things are working as they should, so this is not a bug. If it worked before then I'd say that was the bug. | ||||
