Voicemail Busy

[SteAnnesIT]

I have a system with two Mitel 5000's connected via IP.  Sometimes the programmed button to dial the voicemail extension (they used 1555) lights up solid (these are 8568s and 5320s) and during this time when you try to call voicemail it displays "Voicemail Busy" and then you have to wait and eventually it dials through to voicemail and allows you to enter your password.  I have asked my Mitel installer (who I'm not very happy with) to look into this or tell me the exact reason for this happening but they haven't solved it or told me why it is so.

Voicemail is on PBX A,  and I'm noticing this from my office which has phones connected to PBX B.  All voicemail for all extensions is configured to be stored on PBX A.

Does anyone have any ideas suggestions or know the cause if this annoyance?

Thanks,

[marcolive]

How many voicemail ports do you have? Maybe all your ports are busy at certain times of the day?

[SteAnnesIT]

Let me guess, more licences?  every bloody thing needs more licences LOL.  I'm surprised I can push a damn button on these phones without having to get a new licence each time.

So where in the configuration tool would I find the amount of licences my voicemail has?  I do have access to it the Mitel Sys Admin & Diags so I could take a look.

Thanks!

[dwayneg]

Voice Processor/Timers and Limits/Number of Voice Channels

Some stop-gap measures: If you're delivering queue messages in your hunt groups, increase timers so messages play less often.  If you're calling cells or pagers to deliver VM messages, increase timers so they call less often. If you're using auto attendant, be sure most-used choices are offered first so callers exit sooner.  Discourage use of record-a-call.  Set max ports for queue announcements and outdials to 1 or 2, to be sure ports are left for VM (Voice Processor/Application-Related Info/Time Slot Groups...create a new group with only 1 or 2 channels, assign all unimportant apps to use this group by going into each).

[SteAnnesIT]

Voice Processor > Timers and Limits > Number of Voice Channels: Value = 8

Oh for #($&# sake (really fed up with the failure of the provider to properly plan for a system like this.  It's like they just threw it on the wall assuming it would just work out of the box......).  How can this value be increased?  So every time we have a customer in the queue listening to a menu message they're taking up a channel?  and we have a PRI for crying out loud. That isn't even enough for half of the possible customers calling in, let alone staff checking voicemail.

Thanks,

[dwayneg]

You can increase the available voice channels, it's a license...PN is 840.0460 for each 4 additional ports.  Believe max is 32.  These are used while caller is hearing queue messages (not music on hold).  If you're playing a message every 60 seconds, for example, and increase the timer to 90 seconds you're going to reduce traffic by 33%.  And try my suggestion for setting up a new time slot group.  If you assign all the queue messages to a group that only allows 4 ports and leave the voice mail in the default group of 8 that will cause queue messages to just wait if all 4 ports are full, while VM gets access to all 8 ports any time, and 4 ports even if queue is busy.  Maybe you can replace some of your queue messages with ordinary Music/Message-on-Hold, which doesn't use ports at all.  Remember that you can use File-Based MOH to deliver specialized messages for different groups (up to 5 messages), so if you're playing a lot of queue messages this might be a cost-effective solution.
One more thing: I've seen installs where even though customer had more than 4 ports, tech forgot to increase size of default Time Slot Group to matching number, limiting available ports (8 ports available but only 4 can be used).

[SteAnnesIT]

Thank you for the information!  Wish our Mitel could have told me this when I complained about it.

Regards,

[acejavelin]

Just a note, not to startle you but so you don't get sticker shock... this license is kind of expensive, for each block of 4 VM Ports (840.0460 license), the MSRP is around $1000, so finding a way to manage VM usage is sometimes a good procedure money wise.

Also, depending on your system size and traffic, additional hardware like an expansion processor or external PS-1 processor could be required if increasing VM capacity significantly, but I can't say for sure without knowing your configuration and usage.

[DND ON]

Eight channels for a PRI answered by an auto attendant is certainly reasonable. Keep the greetings short, and don't try to use CRAs where MOH is called for.

As to the licenses, it's easier to upload a license than having to add hardware.

[dwayneg]

One more thing: since all your vmail boxes are on PBX A, move some of your announcements to PBX B...that's 4 more ports for free!

[SteAnnesIT]

There's an idea.  yup 4 ports sitting on PBX B doing nothing as far as I know.

Can the license be moved?  Could I get the extra 4 ports that were added to PBX A, and have them moved to PBX B.   The ACD/HuntGroup is on PBX B and that is where incoming callers are generally sent.  Then there would be 4 ports on PBX A which would be available for general voicemail and the odd person calling in via our backdoor number.

We have an unlimited IP Networking license, that had to be added after they realized PRI on PBX A, and ACD on PBX B with only an 8 Channel IP Networking license between the two PBXs wasn't a really intelligent thing to do... 

Just received quote from provider....  4-Port Voicemail Upgrade $1,150.00,  yah this isn't going to get approved. LOL.

Thanks for helping!

I have another question about Teleworker,  I'll make a new thread for that later.

[Tech Electronics]

SteAnnesIT,

Unlike the 3300 the 5000 isn't allowed to move licensing between systems. To do this would require your vendor to work with Mitel Direct to remove the licensing from the Hardware ID on PBX A and put it on the Hardware ID on PBX B. They will also require that the Compact Flashcard (CF) be sent back after a new Hardware ID was assigned to PBX A. All in all this is not a fun thing to do. Your best bet would be to move the (2) Compact Flashcards around, but since all the information is on the Compact Flash cards your systems will be down while that is going on. Most vendors do no want to do this free of charge since it is time consuming which may make the cost greater than the $1,150.00 dollars depending on labor costs for after hours work and testing. Your best bet is to redesign though if you are not willing to pay for the licensing, but then again it may turn out to cost more in the long run as it is not an ideal situation.

You may be able to give your call flow information and we may be able to give you a better solution based on that. The other possibility is to attach a copy of your database from both sites if you are not able to follow all the call flows easily.

Thanks,

TE

[SteAnnesIT]

Okay so I had an idea.  What if staff extension voicemail boxes were moved to PBX B, which is sitting there with 4 Ports doing nothing?  This way perhaps?! when a staff person tries to dial voicemail they won't get a busy error?!

Regards,

[dwayneg]

If you have multiple groups move just some of the announcements, or if a single group move OVERFLOW but not ANNOUNCEMENT.  If I were working on this I'd leave any preliminary announcements such as screening and auto attendant on PBX A because that's where the PRI is.  Then I'd create duplicate queue announcements on PBX B, and also a voice mail on B though I don't plan to use it.  I'd put a button on my phone representing vmail B.  Then I'd start changing some of my ANNOUNCEMENT and OVERFLOW fields in hunt groups to point to my new PBX B announcements, a few at a time.  Watch your two vmail buttons throughout the day...when they neither light, you have moved the right number of announcements and your problem is solved.  Check occasionally if traffic or volume increase.

[dwayneg]

Moving staff mailboxes doesn't sound like fun, especially if some are doing remote notification or vmail to email...a lot of stuff to key manually.