Hello - I am upgrading from asterisk v1.2 to v1.6 and I am seeing a problem with recording CDRs using MySQL. Unlike all of the other postings and web pages I have found on this issue, my installation successfully stores the -first- CDR, but nothing after that.
As background info, I will note that I don't use CDRs for billing, but more in a logging fashion, to record how a given call branches through the dialplan, the selections the caller makes, info retrieved from other sources, etc. The cdr_addon_mysql module loads; I have a working cdr_mysql.conf; MySQL is running; etc., etc., etc. The fact that the first time ResetCDR is called it writes out a CDR shows that all the right pieces are in place, so it isn't any of the basic installation, set-up and config issues. By way of debugging, I pulled cdr_addon_mysql.c out of SVN (from asterisk-addons/branches/1.6.2) and added a bunch of debug assertions amidst the code that INSERTs the CDR record into the db. I see in my asterisk logs and on the asterisk console all of the expected assertions, between the first "Executing ResetCDR" and the "Inserting a CDR record." There are further "Executing ResetCDR" lines in the debug output, but -no- further log lines from cdr_addon_mysql at all. My dialplan is also stored in MySQL, and the debug output shows that the connection from asterisk to MySQL remains up and functional, so I'm fairly certain it is not a dropped MySQL connection. It looks to me as if ResetCDR simply is not calling mysql_log( ) after the first time ResetCDR is called. Is this a known issue? Has anyone else seen this behavior? Does anyone have a solution or at least a work-around? Also, a number of other subtle but important things changed between v1.2 and v1.6 -- do I need to change my basic CDR logging strategy, too? Currently, I have what amounts to a subroutine in the dialplan which calls "Set(CDR(userfield)=...." and then "ResetCDR(w)". From what I have read, this approach should still work under v1.6. Many thanks in advance. Asterisk rocks, and has served me well and been very stable as my company's 24x7 payment IVR for nearly four years. This single issue is holding up my upgrade from v1.2 to v1.6, and I anticipate many more solid years on 1.6 once this is resolved. Thanks again. -- Andrew Witt Sr. Software Systems Engineer revol wireless 216-525-1195 phone 216-240-1991 wireless 216-525-1112 fax [email protected] www.revol.com THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL, AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, forwarding, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail or telephone, and delete the original message immediately. _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
