Summary:ASTERISK-05842: v1.2.1 requires new config setting for voicemail ARA to work
Reporter:muppetmaster (muppetmaster)Labels:
Date Opened:2005-12-14 09:54:34.000-0600Date Closed:2005-12-17 11:22:25.000-0600
Versions:Frequency of
Environment:Attachments:( 0) vmrealtimefix.txt
Description:I have been using the Asterisk Realtime Architecture since it was available and up through v1.2.0.  I upgraded to v1.2.1 without any configuration changes to the system and when I invoked 'Voicemail(u${EXTEN})' Asterisk could no longer find my voicemail users configured in the ODBC/MySQL database.  When I added the configuration item 'searchcontexts=yes' in the voicemail.conf and reloaded, all worked fine.

While I was able to work around this issue, it would seem that Asterisk should maintain backward compatibility and search for the 'default' context by default.  As when I upgraded a minor version (1.2.0 to 1.2.1) my system 'broke' without any configuration changes and I had to search this issue before I could get voicemail working again.


- Possible related items from the changelog:

* apps/app_voicemail.c, configs/voicemail.conf.sample, UPGRADE.txt:
allow previous context-searching behavior to be used if desired
(issue ASTERISK-5745)

* apps/app_voicemail.c: Only look in 'default' context when no context defined to VoiceMailMain(). (issue ASTERISK-5735)

- Related item from the example voicemail.conf:

; searchcontexts=yes   ; Current default behavior is to search only the default context
 ; if one is not specified.  The older behavior was to search all contexts.
 ; This option restores the old behavior [DEFAULT=no]
Comments:By: twisted (twisted) 2005-12-14 10:24:22.000-0600

That is correct.  My patch made it search default when no context was given, i'm going to look into seeing if the other applied patch changed that behaviour.

By: twisted (twisted) 2005-12-14 10:31:09.000-0600

This patch should fix the behaviour of searching default.  I know it used to do it automatically (and correctly).   If you can test this and it works, i'll fix it in trunk.

By: Jason Parker (jparker) 2005-12-14 11:26:12.000-0600

Code that fixes this is already in trunk and branch/1.2.  Please see ASTERISK-5805 for details.

Also, see commits 7406 and 7407 (for 1.2 and trunk, respectively).

By: Jason Parker (jparker) 2005-12-14 11:58:07.000-0600

ASTERISK-5816 has a combined patch that fixes two bugs in voicemail - this being one of them.  Try applying this patch to 1.2.1 and see if it fixes your problem.  If so, let's close this out as a duplicate.

By: twisted (twisted) 2005-12-14 12:33:57.000-0600

this obviously was not fixed.  After looking at the code, we do not look in default if we have searchcontexts commented out or set to no.  It should be a simple 3 line fix.  This code was checked out from the trunk today that I looked in.  

If the context was not given, and search was not specified, we didnt' even look for the mailbox. based on the code that corydon76 applied.  This patch fixes that behavior.

By: Jason Parker (jparker) 2005-12-14 19:14:16.000-0600

The only time find_user_realtime is called, is from find_user.  If you look at approx line 579 of app_voicemail.c, you'll see the following code

if (!context && !ast_test_flag((&globalflags), VM_SEARCH))
       context = "default";

(which is, essentially, what you have in your patch, just in a different location).  HOWEVER, if find_user_realtime were to ever be called from somewhere else, context could be null.

With that said, perhaps your patch would be a good answer, combined with the others that have already been submitted.  It would be an extra if in most cases, but...

By: Tilghman Lesher (tilghman) 2005-12-17 10:56:37.000-0600

Yeah, the patch isn't strictly needed, because it's already done in find_user().  Essentially the code in the patch inserts a test that can never succeed and thus the body will never execute.

What the bug reporter is really complaining about is that the default changed in what was supposed to be a bugfix upgrade.  I'll agree that that was undesireable, but changing it back now introduces ANOTHER change in default behavior (i.e. it worked that way in 1.2.1, why should it work a different way in 1.2.2?).  However, the change was, in fact, documented in UPGRADE.txt.

muppetmaster:  we'll try to make sure that these types of changes don't happen in the future, but please read UPGRADE.txt in the future for every upgrade of your production code.