Extension Busy after VM use

Ok, I’ve had this problem a few times in the last couple months… where
a specific extension will go straight to VM and appears to be in use when it really isn’t. The only way to clear it has been to restart asterisk… a soft hangup does nothing.

What I think I’ve found, at least in todays occurence is, that when in VM and in the message menu, pressing the # key make the VM system non-responsive, and you must hangup the handset… tada, that extension is now always busy.

Any ideas how to stop this from happening, besides keeping users from pressing the wrong key? Or, how to clear it when it does without restarting asterisk?

voicemail is a compiled chunk of code in asterisk. You’ve not provided any info on software versions you are running so it’s not possible to see if it is a known bug without that info.

But it sounds like it might be a bug in asterisk.

Versions… I knew I forgot something in the post



I have the same problem
Asterisk (Ver.

After I did the upgrade, I was working through the voicemail prompts and eventually noticed that the extension is not able to get incoming calls. All calls go directly to voicemail.

Version of asterisk?

Asterisk Version 1.4.19

Did you ever figure out why? This happens about once a month to at least one user… and the only thing I can see so far is it’s related to pressing either the # or * ket in voiceail when it’s not one of the options the system is expecting.

what is being described sounds like it would be an issue within Asterisk and likely not related to FreePBX.

Some questions. Are the phones local or remote? Next, do the phones have call waiting enabled? (Or asked differently does the phone have multiple call appearances, e.g. line keys, that can take more than 1 call at a time). If they don’t have CW enabled, when this happens, and you type ‘show hints’ at the CLI, what does asterisk say the state of the phone is in the hint?

From what is described, this sounds like either a strange Asterisk issue or a phone related issue, and more than likely a phone issue especially if you tell me that CW is enabled.

most of the telephones are local (on the same subnet and a single switch as the server).

I’m not sure about call waiting, however, they are SNOM 370. They do have line keys, so we can have multiple calls, however, I checked to make sure the telephone does not have a call on hold… if I press the line keys, each responds with a dial-tone. Below is the output from show hints, and FYI extension 8116 is the one currently experienceing the issue, and you’ll note it indicates it is “inUse” when in fact it is not. And as stated before, if I do a
soft hangup SIP/8116-b7805790 it says it’s requested, but does not hangup the line.
Again, the only thing I can point to at this point was being in the VM system, and pressing either # or * when it was not a valid option, then there was no response to any key presses, and I hung up the telephone and it was in the condition.

Any ideas?
-= Registered Asterisk Dial Plan Hints =-
[email protected] : SIP/701&SIP/702&SIP/ State:Unavailable Watchers 0
[email protected] : 9 State:Unavailable Watchers 0
[email protected] : IAX2/8329 State:Unavailable Watchers 0
[email protected] : SIP/8302 State:Unavailable Watchers 0
[email protected] : SIP/8301 State:Idle Watchers 0
[email protected] : IAX2/8239 State:Idle Watchers 0
[email protected] : SIP/8237 State:Unavailable Watchers 0
[email protected] : SIP/8216 State:Unavailable Watchers 0
[email protected] : SIP/8208 State:Unavailable Watchers 0
[email protected] : SIP/8204 State:Unavailable Watchers 0
[email protected] : SIP/8202 State:Unavailable Watchers 0
[email protected] : SIP/8193 State:Idle Watchers 0
[email protected] : SIP/8192 State:Idle Watchers 0
[email protected] : SIP/8181 State:Idle Watchers 0
[email protected] : SIP/8177 State:Unavailable Watchers 0
[email protected] : SIP/8162 State:Idle Watchers 0
[email protected] : SIP/8160 State:Idle Watchers 0
[email protected] : SIP/8147 State:Idle Watchers 0
[email protected] : SIP/8145 State:Idle Watchers 0
[email protected] : SIP/8144 State:Idle Watchers 0
[email protected] : SIP/8142 State:Idle Watchers 0
[email protected] : SIP/8139 State:Idle Watchers 0
[email protected] : SIP/8138 State:Idle Watchers 0
[email protected] : SIP/8137 State:InUse Watchers 0
[email protected] : SIP/8134 State:Idle Watchers 0
[email protected] : SIP/8133 State:Idle Watchers 0
[email protected] : SIP/8128 State:Idle Watchers 0
[email protected] : SIP/8127 State:Idle Watchers 0
[email protected] : SIP/8126 State:Idle Watchers 0
[email protected] : SIP/8125 State:Idle Watchers 0
[email protected] : SIP/8124 State:Idle Watchers 0
[email protected] : SIP/8123 State:Idle Watchers 0
[email protected] : SIP/8122 State:Idle Watchers 0
[email protected] : SIP/8119 State:Idle Watchers 0
[email protected] : SIP/8118 State:Idle Watchers 0
[email protected] : SIP/8117 State:Idle Watchers 0
[email protected] : SIP/8116 State:InUse Watchers 0
[email protected] : SIP/8114 State:Idle Watchers 0
[email protected] : SIP/8111 State:Idle Watchers 0
[email protected] : SIP/8110 State:Idle Watchers 0
[email protected] : SIP/8108 State:Idle Watchers 0
[email protected] : SIP/8105 State:Idle Watchers 0
[email protected] : SIP/8104 State:Idle Watchers 0
[email protected] : SIP/8102 State:Idle Watchers 0
[email protected] : SIP/8101 State:Idle Watchers 0
[email protected] : CUSTOM/2001 State:Unavailable Watchers 0
[email protected] : CUSTOM/911 State:Unavailable Watchers 0
[email protected] : park:[email protected] State:Idle Watchers 0
[email protected] : park:[email protected] State:Idle Watchers 0
[email protected] : park:[email protected] State:Idle Watchers 0
[email protected] : park:[email protected] State:Idle Watchers 0
[email protected] : park:[email protected] State:Idle Watchers 0
[email protected] : park:[email protected] State:Idle Watchers 0
[email protected] : park:[email protected] State:Idle Watchers 0
[email protected] : park:[email protected] State:Idle Watchers 0
[email protected] : park:[email protected] State:Idle Watchers 0
[email protected] : park:[email protected] State:Idle Watchers 0

well clearly Asterisk thinks it is inUse. When you type ‘show channels’ what does it show for the currently hung channel to see why it is hanging?

As far as making another call to it, if you don’t have CW set on the phone (which you can do from the GUI on the extension tab) then FreePBX will not try to send another call to it even though you have multiple line keys.

If you have CW set, then FreePBX should be attempting to send anther call to it. If that call goes to VM, it would imply the phone itself is rejecting the call or is otherwise unreachable for some reason. You can turn on sip debugging against that peer and see the sip message which will show you if an attempt is even made to reach it.

OK, here’s show channels on that extension

SIP/8116-b7805790 *[email protected]:10 Up VoiceMailMain([email protected])

I enabled CW and called the extension and it rung through, so that helps at least. Now, if I have CW enabled, and I’m REALLY on a call, will it ring the telephone and then go to VM after some timeout?

So, since with CW enabled it rings the telephone, that means it’s not the telephone? And what does it mean is the cause for being stuck in VM?


VoiceMailMain() is a compiled routine inside asterisk. You can find the actual code for it in the asterisk source at apps/app_voicemail.c So as Philippe has stated yesterday and I did on May 14th it is a asterisk issue.

I understand it is a asterisk issue… however, doesn’t this forum help with asterisk issues as well, or just FreePBX issues?

And now, after enabling CW and having the extension actually ringing, now when the extension is answered, it occasionally (I would guess at this point 50% of the time) immediatley puts the caller into VM, and the extension telephone plays a dialtone. And I don’t think it’s because of a timeout on CW, since the extension has been answered in 1 ring and done it, and has been answered in 3 rings and not.

So, if this is something to be addressed somewhere other than this forum, please point me in the right direction.

thank you

your application is hung in the Asterisk voicemail routine. That is what:

SIP/8116-b7805790 *[email protected]:10 Up VoiceMailMain([email protected])

is telling you. There may be something in the log to help diagnose what crashed, but it is clearly unstable behavior in Asterisk. It would be worth scanning their bug system to see if there are any issues that may be similar.

As far as your calls going straight to VM 50% of the time , hard to say. If you have CW enabled, FreePBX will alays try to call the phone if it shows as available. (whether it is inuse, ringing, onhold, etc.). It’s always possible for a phone to signal back busy for various reasons - you would have to turn on sip tracing to further diagnose.

As far as what people will help you with on this forum, the answer is - anything that they have the skill set to do so. However, when you start to dive deeper into asterisk and other areas, you will have fewer people around and it is worth trying resources more dedicated to those areas.

Thank you…

I appreciate your response and insight. It is often hard for a tadpole to know exactly what is happening and with what… so, I really do appreciate your patience. I’ll check ut the BUG system and see if there is any help there. In the mean time, I guess I’ll just have to restart the server anytime this happens until I can determine how to stop it from re-curring. Again, thank you for your help.

My favorite way is to break the user who does it fingers… But my boss has warned my to not do it as it would put yet another employee out on company disability.

Off the record he also said if it was not for the disability issue and we did it once or twice we’d never have users doing it again…

Good luck…