Summary:	ASTERISK-12118: build app_voicemail with IMAP_STORAGE .voicemessage forwording failed.
Reporter:	smth-bal (balsamcn)	Labels:
Date Opened:	2008-05-30 15:52:53	Date Closed:	2008-07-29 10:46:49
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_voicemail
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) voicemail_console_debug5
Description:	build voicemail with IMAP_STORAGE. call into voicemail box to forward a message listened to another voice mailbox extension.got failed. on cli: Warning 'Unable to open /var/spool/asterisk/voicemail/default/202//msg0000.txt in read-only mode'. As fact, the file does not exit there when attempt to forward the message. the differece is you can find the wav file at /var/spool/asterisk/voicemail/defaul/202/tmp/msg0000.WAV when listening. Things like IAMP works sometimes but on forwarding. ****** ADDITIONAL INFORMATION ****** I tried on 1.4.19.2 and 1.4.20.1 .same problem since same code used there. ;) this issue happened at copy_plain_file(xxx.xxx)
Comments:	By: Mark Michelson (mmichelson) 2008-06-02 12:42:07 Can you please upload the full console output with debug level set at 5 when this failure happens? Thanks! By: smth-bal (balsamcn) 2008-06-02 13:53:07 It's only set debug level to 5 at app_voicemail.c. Is the information enough? By: Mark Michelson (mmichelson) 2008-06-02 13:54:54 That should be fine. By: Mark Michelson (mmichelson) 2008-06-19 11:00:05 I think the patch on issue ASTERISK-12232 might be what will fix this issue. I have not yet reviewed the patch fully, so it may change somewhat before its inclusion in Asterisk. Testing it would be helpful in being sure that it fixes this issue. Thanks! By: smth-bal (balsamcn) 2008-06-25 16:55:33 Unfortunately, the patch on issue 0012897 could not solve the issue I reported. due to the different behavior. see attached file above, you would find that the forwarding was failure at doing open/copy the source voice message .it had not even reached the next function "vm_forwardoptions(...)" yet. I did tested. same result as it I reported before. thanks By: Mark Michelson (mmichelson) 2008-07-08 10:29:49 I have found the problem here, have reproduced it locally, and have made a quick-and-dirty fix that makes forwarding possible, but there's no way I could commit it as-is. What was throwing me off is that I thought the source of the problem was what caused the warning on the console to appear, but that is an indirect result of the actual problem. When using file-based storage of voicemails, two files are created: the actual sound file, and a text file which contains information about the voicemail, such as its duration, the time it was sent, etc. When using IMAP storage, the information about the voicemail is stored as MIME headers in the message that is generated, so there's no need to try to manipulate a text file at all. The failure occurs because there is no text file on the file system for the message which is being forwarded. What I've done to correct this problem is to place a "return 0;" immediately at the beginning of the vm_forwardoptions function. This allows me to be able to forward messages correctly. The problem with this method is that it still displays warning on the console about not being able to copy the text file and it disables the ability to prepend a message to the voicemail. I will work on a fix for this today and hopefully have it done soon. Thanks for your patience on this. By: Digium Subversion (svnbot) 2008-07-09 15:11:46 Repository: asterisk Revision: 129439 A   team/mmichelson/imap_consistency/ ------------------------------------------------------------------------ r129439 | mmichelson | 2008-07-09 15:11:38 -0500 (Wed, 09 Jul 2008) | 21 lines Based on the problem reported in issue ASTERISK-12118, I did some investigation of app_voicemail and have found massive inconsistencies when using IMAP storage and using other types of storage. When using ODBC storage, if a file needs to be manipulated, the file is downloaded and placed into temporary storage on the file system along with a text file with metadata. This way, the message can be manipulated in the same way as if file storage were used. IMAP, on the other hand, never actually creates a text file and seems to be inconsistent with when the sound file is downloaded and destroyed. The goal of this branch is to make IMAP's RETRIEVE and DISPOSE macros mimick the ODBC implementation. By taking these simple steps, I believe that several of the IMAP-only routines in app_voicemail can be completely removed, thus reducing the code size and making app_voicemail more consistent. I've created this branch against the 1.4 Asterisk branch because in my view, all of this work is a huge bug fix. ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=129439 By: Digium Subversion (svnbot) 2008-07-29 10:46:45 Repository: asterisk Revision: 134223 U   branches/1.4/apps/app_voicemail.c ------------------------------------------------------------------------ r134223 | mmichelson | 2008-07-29 10:46:45 -0500 (Tue, 29 Jul 2008) | 30 lines Merging the imap_consistency branch. The main aim of this branch was to make the IMAP code function in the same manner as the ODBC code does, eliminating the need for so many IMAP-specific code chunks. The focal point of all of this work was to make the various macros (e.g. RETRIEVE, DISPOSE) functionally equivalent. While doing the above work, I also fixed a few bugs that I came across in my testing. Among these were 1. Fixed message forwarding. This was completely broken when using IMAP. 2. Fixed the inability to save new messages as old and vice versa. 3. Fixed the "delete" options in voicemail.conf when using IMAP storage. Even though a few bugs were fixed and the code is a lot more consistent, the one thing that was *not* improved in this branch was performance. The merge of this to trunk may not come immediately due to the amount of work it will probably involve. (closes issue ASTERISK-12118) Reported by: balsamcn ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=134223