[Home]

Summary:ASTERISK-10083: Unavailable and Busy messages are deleted.
Reporter:Nick Barnes (bcnit)Labels:
Date Opened:2007-08-14 17:59:09Date Closed:2007-08-17 14:01:05
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_voicemail
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Voicemail(user@context,su) causes /var/spool/asterisk/voicemail/context/user/unavail.gsm (or WAV/wav) to be played once and then deleted. Subsequent calls to Voicemail(user@context,su) then just play Alison's standard voicemail greeting.

A strange warning message is also displayed when VM recording is complete.

The process seems to be (in the following, 'unavail' and 'busy' are interchangeable:

1 - Call to Voicemail(user@context,su) is issued
2 - Directory /var/spool/asterisk/voicemail/context/user/unavail is created (with no content)
3 - Empty file /var/spool/asterisk/voicemail/context/user/unavail.txt is created.
4 - /var/spool/asterisk/voicemail/context/user/unavail.gsm (or WAV/wav) is played.
5 - /var/spool/asterisk/voicemail/context/user/unavail.* is deleted.
6 - Voicemail is recorded as:

   -- Recording the message
   -- x=0, open writing:  /var/spool/asterisk/voicemail/context/user/tmp/qMXbOo format: wav49, 0x9aadac8
   -- x=1, open writing:  /var/spool/asterisk/voicemail/context/user/tmp/qMXbOo format: gsm, 0x9a841b8
   -- x=2, open writing:  /var/spool/asterisk/voicemail/context/user/tmp/qMXbOo format: wav, 0x9f34ac0

7 - The warning message similar to:

[Aug 15 00:00:36] WARNING[24341]: app_voicemail.c:1629 base_encode: Failed to open log file: /var/spool/asterisk/voicemail/context/user/tmp/UdrEnJ.WAV: No such file or directory

is given (note that the filename in (7) is different to the one in (6).


****** ADDITIONAL INFORMATION ******

ODBC storage is being used and voicemails are successfully being inserted in the database.

Asterisk version is 1.4.10.1 (not available as an option in the drop-down!).

Doing 'ls' in the voicemail directory whilst a call is in progress shows:


# Before the call is made
[root@pbx user]# ls
busy.gsm  busy.wav  busy.WAV  greet  INBOX  temp  tmp  unavail

# Whilst the busy greeting is played
[root@pbx user]# ls
busy  busy.gsm  busy.txt  busy.wav  busy.WAV  greet  INBOX  temp  tmp  unavail

# After the call has finished
[root@pbx user]# ls
busy  greet  INBOX  temp  tmp  unavail
Comments:By: Mark Michelson (mmichelson) 2007-08-15 13:32:19

The warning about base_encode failing to open the file is most likely due to the fact that you have enabled the volgain option for voicemail but do not have sox installed on your system. If you don't have sox installed, then install it and see if that warning still appears.

As far as I can tell, that shouldn't have any bearing on your disappearing greetings, but it will at least get rid of the warning you're seeing.

By: Mark Michelson (mmichelson) 2007-08-15 14:29:26

By any chance, were you using file system storage for voicemail and then switch over to ODBC storage later? If so, were the disappearing greetings recorded prior to the switch to ODBC storage?

The reason I ask is that ODBC stores greetings in the database but creates temporary files when someone calls voicemail so Asterisk can play them when needed. Those files are then intentionally deleted after being played. If the greetings were originally recorded using file system storage, then they never made it into the database to begin with, so the behavior you're describing would be exactly what I'd expect.

Anyway, if this is the case, then the correct course of action is to rerecord the greetings so that they get stored properly in the database.

By: Nick Barnes (bcnit) 2007-08-16 02:28:57

The "Failed to open log file" message was caused by the absence of sox.

However, I am concerned that the error message is a little misleading - surely a .WAV file is not a log file. Also, there were no errors other than:

[Aug 15 17:36:06] WARNING[30646] app_voicemail.c: Failed to open log file: /var/spool/asterisk/voicemail/vitell/home/tmp/ylZFYX.WAV: No such file or directory

in the Asterisk log. Surely there should be some reference that the call to sox failed?

Anyway, my bad. Apologies for this one.

By: Nick Barnes (bcnit) 2007-08-16 02:38:45

Hmmm. Yes, the greetings were recorded before the switch and yes, this is the reason why. I have updated the Wiki with a warning about this.

However, I am concerned that Asterisk isn't behaving in a sensible way - surely if it's working from ODBC and there's no busy/unavail message there, then it shouldn't play any message at all (or, it should play a local file if one exists and then NOT delete it) - to play a local file and then delete it is rather bizarre behaviour.

I think what I'm saying is that if Asterisk is going to work in a certain way, then that's fine, however, if it can work in that way successfully, then that way should not make changes which mean that it can't work in exactly the same way again.

So, when running in ODBC mode, is it possible then to make app_voicemail either not play local files or not to delete them if it does?

By: Mark Michelson (mmichelson) 2007-08-16 10:36:03

I agree that a .WAV file is indeed not a log file, and so I will change that message to not state so. I ran a test where I removed sox from my system and recorded a voicemail with volgain=1 and attach=yes. I saw this in my CLI:

bin/sh: sox: not found

I think this should appear in your logs, so I will see about getting it changed to print to a log instead of the CLI.

By: Digium Subversion (svnbot) 2007-08-16 10:40:44

Repository: asterisk
Revision: 79690

------------------------------------------------------------------------
r79690 | mmichelson | 2007-08-16 10:40:43 -0500 (Thu, 16 Aug 2007) | 5 lines

base_encode is not trying to open a log file, so we should not call it a log file in the warning.

(related to issue ASTERISK-10083, reported by bcnit)


------------------------------------------------------------------------

By: Digium Subversion (svnbot) 2007-08-16 10:41:26

Repository: asterisk
Revision: 79691

------------------------------------------------------------------------
r79691 | mmichelson | 2007-08-16 10:41:25 -0500 (Thu, 16 Aug 2007) | 13 lines

Merged revisions 79690 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r79690 | mmichelson | 2007-08-16 10:58:34 -0500 (Thu, 16 Aug 2007) | 5 lines

base_encode is not trying to open a log file, so we should not call it a log file in the warning.

(related to issue ASTERISK-10083, reported by bcnit)


........

------------------------------------------------------------------------

By: Nick Barnes (bcnit) 2007-08-16 10:46:11

Just double checked and I am definitely not seeing a message mentioning sox at either the console or in the logs.

By: Mark Michelson (mmichelson) 2007-08-16 10:50:34

Now to address your comment about voicemail acting sensibly. On one hand, I agree that from a user perspective, it seems chaotic, but from a developer standpoint, it makes more sense (but is far from perfect). I'm going to look at possibly getting things changed so that they do act more sensibly. My fear is that the change needed would be too intrusive to introduce into the 1.4 branch, but I could be wrong.

By: Nick Barnes (bcnit) 2007-08-16 11:00:00

Heh. I appreciate that it'll be a compromise!

I really appreciate the work you're doing on this and my other bugs. If you're at Astricon, I'll buy you a beer!

By: Mark Michelson (mmichelson) 2007-08-17 13:52:29

Good news! I've written a patch which should make things smoother for those who switch from file storage to ODBC storage in the future. The way the patch works is that if it can't retrieve the file from the database but finds it in the file system, it inserts the file into the database. That way, the transition should be seamless and will not necessitate the re-recording of voicemail greetings.

After I commit it, this issue will be closed.

My current plan is to be at Astricon. I'll see you there!

By: Mark Michelson (mmichelson) 2007-08-17 14:01:04

Fixed in rev 79906 of 1.4 and 79907 of trunk