Mitel Forums - The Unofficial Source
Mitel Forums => MiVoice Office 250/Mitel 5000 => Topic started by: SteAnnesIT on January 09, 2014, 12:08:44 PM
-
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,
-
How many voicemail ports do you have? Maybe all your ports are busy at certain times of the day?
-
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!
-
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).
-
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,
-
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).
-
Thank you for the information! Wish our Mitel could have told me this when I complained about it.
Regards,
-
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.
-
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.
-
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!
-
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.
-
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
-
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,
-
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.
-
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.
-
SteAnnesIT,
Moving Mailboxes to PBX B would work as long as you moved all the voicemail boxes over unless you want to buy some licensing for networking the two voicemails together. If you don't move them all then you won't be able to forward messages between the two voicemail systems or have them in Group Lists together.
How many users do you have? Moving a ton of mailboxes over and changing the forwarding paths to go to the new voicemail system can take time, but the good thing is it can be done offline and then loaded up. The bad thing is that unless you backup all the old mailboxes the users will lose everything and have to reset them. You would also have to remember to make sure that all the extension have their voicemail set to the new voicemail under associated extensions; this can be a copy/paste thing, but it has to be done for the phones to work properly.
The issue is that now all users for the company will be reduced to 4 ports for voicemail so if the voicemail system takes a lot of messages and users are constantly trying to get into it then you just make your problem worse by reducing the amount of ports they have to work with.
You could do what Dwayneg suggests, but it would be best if you found out what is using up 8 ports at the same time.
Can I assume that all the Trunking comes into PBX A or does each site have its own Trunking?
Thanks,
TE
-
After I asked for the quote from my provider and I said "Yah, umm, too expensive" they replied saying what dwayneg suggested, moving some of the ACD messages over to the PBX B system. So I'm going to let them think on that and see if they can come up with a solution that way.
-
I've also set Overflow from 30 seconds to 72 seconds which was it's bracketed default number to see if that makes any difference. Recall we have set at 1800 seconds, our Overflow message instructs callers in the queue that they can press X to leave a message so we (Marketing director) decided to have a longer Recall timer because we have customers that like to wait in the queue and get mad if they can't lol.
-
Something simple, but just checking: the TIME OUT Digit Translation in each of your queue announcements is set to HANGUP, right? I know, that's counter-intuitive...but I see folks all the time who set digit translation for time out to send the call back to the HG. WRONG, that will recycle the call to the HG as a new call which not only puts the caller back at the end of the line but causes him to hear the ANNOUNCEMENT probably more often than he would have heard the OVERFLOW. Set TIMEOUT to HANGUP and it only hangs up the announcement, not the whole call, and caller retains place in queue. The other destination, RECALL, removes the call from the group entirely and sends somewhere else.
-
It sounds like the system is not programmed correctly, rather than other issues.
An apology greeting playing every 30 seconds is excessive and annoying. I would go through all the programming, then check the length of the greetings. I’ll bet you can make this problem go away pretty quickly.
-
dwayneg,
Announcement is: Hang up
Overflow is: Hang up
Recall is: Transfer to Mailbox
-
SteAnnesIT,
The way your Call Routing Announcements are set it correct.
The Announcement timer determines the amount of time a call will remain unanswered before it is picked up by the hunt group’s announcement phone or in this case a Call Routing Announcement (CRA). It is started when the call is received at the hunt group. I normally set this to 30 seconds
The Overflow Timer is kind of an odd duck timer as it is started when the Announcement timer expires (or, if there is no announcement phone, when the call is received by the hunt group) and it is restarted each time the call leaves the overflow phone. I normally set this to 60 or 90 seconds, but in your case you may want to set it out further.
The Recall Timer determines the amount of time a call will circulate through the hunt group (unanswered) before being sent to the hunt group’s recall destination phone. The timer is started when the hunt group receives the call.
Thanks,
TE
-
Keep in mind that if your MB's are on seperate systems, you lose the ability to forward msgs from MB to MB. Although, you can get around that with UM to a certain extent.
I know it's to late now, but I've requested that our sales force leave "Basic VM" enabled on all networked systems, even when selling a centralized VM solution. That way even if the primary VM or networking goes down, I don't lose front end Auto Attendants and I have additional resources for HG announcements locally.