[asterisk-bugs] [Asterisk 0010452]: Unavailable and Busy messages are deleted.

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10452 
====================================================================== 
Reported By:                bcnit
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10452
Category:                   Applications/app_voicemail
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.10  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             08-14-2007 17:59 CDT
Last Modified:              08-16-2007 02:38 CDT
====================================================================== 
Summary:                    Unavailable and Busy messages are deleted.
Description: 
Voicemail(user at 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 at 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 at 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).

====================================================================== 

---------------------------------------------------------------------- 
 bcnit - 08-16-07 02:38  
---------------------------------------------------------------------- 
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? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-16-07 02:38  bcnit          Note Added: 0068906                          
======================================================================