| Summary: | ASTERISK-28112: Asterisk is not able to use newly released mysql connector odbc 8.0.12 for voicemail | ||||
| Reporter: | Leandro Dardini (ldardini) | Labels: | |||
| Date Opened: | 2018-10-17 16:20:55 | Date Closed: | 2018-12-28 12:39:19.000-0600 | ||
| Priority: | Minor | Regression? | |||
| Status: | Closed/Complete | Components: | Applications/app_voicemail/ODBC | ||
| Versions: | 13.23.1 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | CentOS 6 and 7, 64bit | Attachments: | ( 0) extconfig.conf ( 1) func_odbc.conf ( 2) odbc.ini ( 3) odbcinst.ini ( 4) res_odbc.conf ( 5) voicemail.conf | ||
| Description: | When upgrading package on CentOS from mysql-connector-odbc version 8.0.11 to 8.0.12, it is no more possible to listen to voicemails. The message returned on the console is
{quote} Connected to Asterisk 13.23.0 currently running on mirtafrontend (pid = 7318) > 0x7f45f400a6a0 – Strict RTP learning complete - Locking on source address 79.37.122.94:4012 – <SIP/79-Ve2Aze-00000006> Playing ‘vm-youhave.ulaw’ (language ‘en’) – <SIP/79-Ve2Aze-00000006> Playing ‘digits/1.ulaw’ (language ‘en’) – <SIP/79-Ve2Aze-00000006> Playing ‘vm-INBOX.ulaw’ (language ‘en’) – <SIP/79-Ve2Aze-00000006> Playing ‘vm-and.ulaw’ (language ‘en’) – <SIP/79-Ve2Aze-00000006> Playing ‘digits/2.ulaw’ (language ‘en’) – <SIP/79-Ve2Aze-00000006> Playing ‘vm-Old.ulaw’ (language ‘en’) – <SIP/79-Ve2Aze-00000006> Playing ‘vm-messages.ulaw’ (language ‘en’) – <SIP/79-Ve2Aze-00000006> Playing ‘vm-onefor.ulaw’ (language ‘en’) – <SIP/79-Ve2Aze-00000006> Playing ‘vm-first.ulaw’ (language ‘en’) – <SIP/79-Ve2Aze-00000006> Playing ‘vm-message.ulaw’ (language ‘en’) [2018-09-12 23:01:13] WARNING[7738][C-00000007]: app_voicemail.c:8851 play_message: No origtime?! – <SIP/79-Ve2Aze-00000006> Playing ‘vm-advopts.ulaw’ (language ‘en’) – <SIP/79-Ve2Aze-00000006> Playing ‘vm-repeat.ulaw’ (language ‘en’) {quote} Downgrading ODBC connector to 8.0.11 restores working app_voicemail. | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2018-10-17 16:20:56.045-0500 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: George Joseph (gjoseph) 2018-10-24 12:51:41.074-0500 Can we get the following asterisk config files... extconfig.conf res_odbc.conf voicemail.conf func_odbc.conf And the system odbc files... /etc/odbc.ini /etc /odbcinst.ini If you can, trim all the files down to just what's necessary to reproduce the problem. thanks By: Leandro Dardini (ldardini) 2018-10-24 18:00:06.403-0500 Requested files By: George Joseph (gjoseph) 2018-10-26 13:18:49.551-0500 Can you confirm that there is an integer column named origtime in your database. Is it populated? We've had reports of other mysql related issues due to mysql getting more strict about how columns are populated. I just wanted to make sure we didn't have a similar issue. Also, what version of mysql itself are you running and are oyu running both mysql and the connector from Centos packages? By: Leandro Dardini (ldardini) 2018-10-26 16:16:44.128-0500 I can confirm there is a INT(11) column for origtime. This is the complete export for the current voicemail_message table. {quote} CREATE TABLE IF NOT EXISTS `voicemail_messages` ( `id` int(11) NOT NULL AUTO_INCREMENT, `dir` char(255) COLLATE utf8_unicode_ci NOT NULL DEFAULT '', `msgnum` int(11) NOT NULL DEFAULT '0', `context` char(80) COLLATE utf8_unicode_ci DEFAULT NULL, `macrocontext` char(80) COLLATE utf8_unicode_ci DEFAULT NULL, `callerid` char(80) COLLATE utf8_unicode_ci DEFAULT NULL, `origtime` int(11) DEFAULT NULL, `duration` int(11) DEFAULT NULL, `recording` longblob, `flag` char(30) COLLATE utf8_unicode_ci DEFAULT NULL, `category` char(30) COLLATE utf8_unicode_ci DEFAULT NULL, `mailboxuser` char(30) COLLATE utf8_unicode_ci DEFAULT NULL, `mailboxcontext` char(30) COLLATE utf8_unicode_ci DEFAULT NULL, `msg_id` varchar(40) COLLATE utf8_unicode_ci NOT NULL, `transcript` longblob, PRIMARY KEY (`id`), UNIQUE KEY `dirmsgnum` (`dir`,`msgnum`), KEY `voicemail_messages_dir` (`dir`), KEY `mailboxcontext` (`mailboxcontext`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=3747 ; {quote} I have tried running MySQL 5.7 and MySQL 8.0 and that doesn't change the outcome. I tried running MySQL on the same server as asterisk and in a separate server and that doesn't change the outcome. If I use MySQL ODBC 8.0.11 it works perfectly, if I use ODBC 8.0.12, it doesn't work. In MySQL ODBC change log they report they have refactored the codebase removing old legacy code... maybe they have refactored too much. By: George Joseph (gjoseph) 2018-10-29 15:48:46.402-0500 OK, I can reproduce this now. By: Sean Bright (seanbright) 2018-12-28 12:39:19.759-0600 This appears to be a bug in the MySQL ODBC Driver: https://bugs.mysql.com/bug.php?id=92947 If you modify the SQL statement in {{retrieve_file}} in {{app_voicemail.c}} to exclude the {{recording}} and {{transcript}} columns from the table that [~ldardini] provided, the query returns a row. With those columns the driver reports that there were no rows, but you can see from network captures that the data is being returned by MySQL. Until MySQL fixes the bug, you should continue to use version 8.0.11 of their driver. | ||||