Voicemail will not transfer to console operator extension

[APM]

Hi All,

I find myself in need of the Mitel sages once again!

We have the 'operator' for some voicemail boxes configured to be that of their secretary.  This works as expected and if a caller presses 0 (instead of leaving a message) they are transferred to the number specified.

The problem is for boxes where we specify the operator as either of our console operator numbers (421 or 221 site dependant).  If a caller presses 0 (instead of leaving a message) the following occurs:

"You are now being transferred to the operator"
~ a few seconds of hold music circa 3 ~
"I'm sorry but no one is available to take your call.  That mailbox is full and cannot accept any new messages.  Please try again at another time".

The caller can then attempt other numbers.  421, 221 and 0 all result in a similar failure.  Keying another number (i.e. a colleague) does work however.  So it seems to me that there is a specific issue with our console operators being specified.

Any ideas guys and girls?

[acejavelin]

Did you check mailboxes 221, 421, and 0 to make sure they are not actually full? Also, check your Transfer method in VM Options, my guess is that it is set to Supervised, so if the destination is busy or does not answer, the call is "recalled" back to the mailbox. In most situations you would want this to be set to Unsupervised so it basically blind transfers.

[ralph]

First check the mailboxes to see if the extension matches the mbox.  It doesn't have to.
I'd bet the 0 mailbox isn't going to where you think it is.  It probably has an extension other than 0 programmed in it.
if you dial the extension that is programmed in the 0 mailbox from your desk phone, it may be an invalid number.

Get someone to log into these boxes and clear out all those messages you have in there.

Ralph

[APM]

Hi guys, thanks for the responses so far.

There are no mailboxes on either controller for numbers 421 or 221.  However each controller has a 0 mailbox.  These did both turn out to be full (as no one had any idea they existed!).  By making room on these boxes the caller no longer receives the 'mail box full' message however prior to that step the call does not appear to go through to the specified console operator either (when the hold music is playing).  This is the principle issue as we don't really want callers to be dumped at a mailbox, we want them to reach a console operator.

The supervised transfer setting is set to false which would be backed up by the fact that when a regular desk extension is specified (rather than a console number) is transfers correctly without further intervention.

So, any ideas on why the consoles don't receive the calls when regular desk extensions do?

Thanks again guys

[ralph]

In the 0 mailbox, change the extension to be one of the consoles and then retry.
So if a button on the console is 555, edit mailbox 0 and change the extension to be 555.

Ralph

[APM]

Hi Ralph,

I tried changing the extension for the 0 mailbox on my local controller (site B) to a console number, this sadly did not help.  This also had the side effect of upsetting the method the console operator uses to direct a caller to someone's VM box in that the console operator had was requested number/passcode details for the VM system.

I'm afraid I can't quite grasp what you have said in your second line - think there might be a typo or two.

I have however discovered that this problem may only be affecting site B.  I called into a site A extension and VM box on an external connection and the call did forward to the console operator as expected rather than just falling back to voicemail.

I should point out that while we have a controller at both sites and console operators at both sites, both console operators are configured to connect and operate from the site A controller.  I therefore wonder if site B is failing to direct to a console operator because there is no logical console operator for that site (even if they are physically there).

[acejavelin]

Are these "consoles" REAL consoles, like 5550 IP Consoles, or just IP Sets with PKM's... it can make a big difference (consoles use LDN appearances which are handled differently).

Also, consider changing your 0 mailboxes to Transfer Only mailboxes, it might help... Make sure you define "0" as a system speed call number to the appropriate extension in each controller.

[APM]

Hi Ace,

Yes these are exactly 5550 IP consoles.  I'll try the transfer option you mentioned and double check the system speed calls for 0.

Thanks again.

[acejavelin]

You should have an LDN appearance that is for the "Operator" calls, we usually use a different LDN key and extension, then make mailbox 0 a transfer only mailbox to and put the extension of the LDN appearance in the Extension field, not the base extension of the console. You can also use the system speed call method the same way.

[APM]

Hi All,

I eventually got to the bottom of this (or rather a Mitel engineer did).  Frankly it started to go over my head a little but the short version is that there was an entry in the 'Class of Restriction group' which meant that the VM system was not allowed to dial a number from our other site.  As our console operators are logically both at the 'other site' this gave the weird behaviour that any local extension could be specified and work, but extensions at the other site would not.

Hope this helps someone in the future!

Thanks again to those who attempted to help