App_voicemail.c: No origtime?!

I have a weird problem with an asterisk using MySQL for Voicemail storage with ODBC.

I have upgraded from MySQL 5.1 to 5.7 (but I tried 8 as well), dumping all the data in an SQL file and then loading back, but I can’t access the Voicemail messages using the VoiceMailMain application.

When the application load, the PIN number is requested and validate, the message selected, but the message “No origtime” is returned.

How can I debug this issue? Which info can I check to try to identify the problem?

Please consider the “origtime” field is correctly set in the table

Connected to Asterisk 13.23.0 currently running on mirtafrontend (pid = 7318)
> 0x7f45f400a6a0 – Strict RTP learning complete - Locking on source address
– <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’)

There was a bug in an old Asterisk version which generate same messages, but it was not MYSQL the DB, anyway you can take a look and also try an upgrade of asterisk

Thank you, but that was not the case. I am running latest asterisk 13.23 as you can see from the log.

Yes I didnt see it before

When you see that message, it’s because the message envelope file / data retrieved from the file system / database / IMAP backend did not have the origtime attribute stored in it. That could happen for a variety of reasons:

  1. In an IMAP backend, the e-mail message does not have the necessary X-Asterisk-VM-Orig-time header on the e-mail.
  2. The value stored in the message could not be converted to an integer value (as the time value should be epoch seconds)
  3. Something manipulated the message envelope file and/or created a message envelope file that was incomplete, causing it to be corrupted.

So some questions:

  1. Can you investigate your message envelope files that are in the backend to verify that they do in fact all have a valid origtime value?
  2. Do you have anything external that creates or otherwise manipulates messages?
  1. I checked the file record on MySQL database and indeed they have a valid int(11) value. I have activated the log of SQL queries and executed the query manually to verify the value.

I have edited the app_voicemail.c to check for the duration instead of the origtime and the problem is not the origtime field, but the function ast_variable_retrieve(msg_cfg, “message”, “origtime”)) that is returning NULL

I checked the ast_variable_retrieve function defined in main/config.c and the problem is on the ast_variable_browse, returning no items.

  1. No, I have not…

So, the question is, “why my system is unable to read the config”?

What do the contents of the message envelope file look like?

Sorry, I don’t understand your question. The voicemail is on ODBC backend, in a MySQL database. Which table/field are you interested in?

Anyone have an idea how to fix this? This is a major pain int he butt issue!

I have worked around the issue, but I need your advice on how to definitively solve the issue.

The problem is in the MySQL ODBC driver version 8.0.12. By downgrading the package to 8.0.11-1, solves the issue. For CentOS 6 users, they can just run “yum downgrade mysql-connector-odbc-8.0.11-1.el6” and then restart asterisk.

Where should be this issue reported? Asterisk or MySQL?


That was my problem too. Using Asterisk 13.22. reverting back to mysql-connector 8.0.11 fixed it


I had the same problem too. What a pain!:

See my post: