Cannot transfer directly to voicemail on a new install

Brand new Trixbox 2.4.2 installation, FreePBX v2.3.1.3, nothing out of the ordinary, just some extensions and an IAX2 trunk. This system is replacing an older A@H installation but there was no “upgrade” done, everything was manually entered on the new system.

When we try to transfer someone to voicemail they head “An error has occured, goodbye”.

The extension has voicemail enabled, a password is set for the voicemail, they have setup their unavailable message, they can dial *97 and check their voicemail, the directory structure under /var/spool/asterisk/voicemail/default/ext# appears to be normal. Any idea what could be causing this?

The cli output is:
== Spawn extension (from-internal-xfer, *116, 0) exited non-zero on ‘IAX2/silva1-13’ in macro ‘dial’
== Spawn extension (from-internal-xfer, *116, 0) exited non-zero on ‘IAX2/silva1-13’
– Executing [*116@from-internal-xfer:1] Macro(“IAX2/silva1-13”, “user-logon|6|”) in new stack
– Executing [s@macro-user-logon:1] Set(“IAX2/silva1-13”, “DEVICETYPE=”) in new stack
– Executing [s@macro-user-logon:2] GotoIf(“IAX2/silva1-13”, “0?s-FIXED|1”) in new stack
– Executing [s@macro-user-logon:3] Set(“IAX2/silva1-13”, “AMPUSER=6”) in new stack
– Executing [s@macro-user-logon:4] GotoIf(“IAX2/silva1-13”, “0?5:9”) in new stack
– Goto (macro-user-logon,s,9)
– Executing [s@macro-user-logon:9] Set(“IAX2/silva1-13”, “AMPUSERPASS=”) in new stack
– Executing [s@macro-user-logon:10] GotoIf(“IAX2/silva1-13”, “1?s-NOPASSWORD|1”) in new stack
– Goto (macro-user-logon,s-NOPASSWORD,1)
– Executing [s-NOPASSWORD@macro-user-logon:1] NoOp(“IAX2/silva1-13”, “This extension does not exist or no password is set”) in new stack
– Executing [s-NOPASSWORD@macro-user-logon:2] Playback(“IAX2/silva1-13”, “an-error-has-occured”) in new stack
– Playing ‘an-error-has-occured’ (language ‘en’)
Extension Changed 111 new state Idle for Notify User 128
Extension Changed 111 new state Idle for Notify User 118
Extension Changed 111 new state Idle for Notify User 140
– Executing [s-NOPASSWORD@macro-user-logon:3] Playback(“IAX2/silva1-13”, “vm-goodbye”) in new stack
– Playing ‘vm-goodbye’ (language ‘en’)
– Executing [s-NOPASSWORD@macro-user-logon:4] Hangup(“IAX2/silva1-13”, “”) in new stack
== Spawn extension (macro-user-logon, s-NOPASSWORD, 4) exited non-zero on ‘IAX2/silva1-13’ in macro ‘user-logon’
== Spawn extension (macro-user-logon, s-NOPASSWORD, 4) exited non-zero on ‘IAX2/silva1-13’

I was able to resolve the problem. The extensions they use are 100-129. It looks like when they dialed *116 the system was trying to logon to a queue. There are no queues configured on the system, but a feature code for *11 and *12 was enabled. I disabled them and they can now dial directly into voicemail again.

as a general rule, if you have a choice, extensions are usually best off in the 4xx-7xx range (or 4xxx - 7xxx) for a variety of reasons.

We usually use 500-599, disabling chanspy if necessary, or something above 1000. But they insisted.

Speaking of extensions. Is there any plan to change the numbers that are used in future versions? They seem to jump around all over the place, 555 for one thing, 666 for another, 7777 for something else. It would be nice if we knew the hard rule was that features/modules were restricted to 1-200, or something similar, so we knew it would be safe to use extensions above a certain number?

the feature codes are a mess and jumped all over, that is why you can change the default values to what suits you.

That is what we usually do, we were just hoping that would change in a future release. Thanks.

the problem with changing it is that people are already using defaults - it is a dilema because some could use some changing but you don’t want to break someone in an upgrade. And - otherwise it makes for more painful upgrade code we have to write that compensates for the change.

Similar to above we can not transfer directly into voicemail. Our extensions are in the 4XXX range.,*11 and *12 is not enabled. Hitting transfer (we have Polycom phones) and then *4XXX places the call on hold. We checked the General settings and * is enabled. Any ideas? Are we doing something wrong?