transfer to voice-mail does not work

[brewski6666]

New ICP 3300 MXE 9.0 with PRI
I have two issues

1-I created Hunt groups *xxxx (xxxx= the extension number of the mail box) and reroute the hunt groups to 7000.
When I test the transfer to voice mail internally(with TRANSFER and *xxx) it works, but when I try to transfer an external call it does not work (it say’s out of service!).

2- when I listen to a new message on a voice mail box and hung-up, the MWI lamp still on
And when a access the mail box again the message is still considered as NEW.
This happens to all voice mail box’s on the system.
Any idees?

 

[MitelInMyBlood]

Take a look at faq1329-6963 and try that method. This is the only method I know for certain works.

 

[kwbMitel]

No idea's for #1

#2 is design intent. If you don't tell the system to save or delete it will remain in the original queue - New.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[MitelInMyBlood]

Same as in the Octel Overture Systems. The user must take responsibility to make disposition of the message. However, once listened-to, Octel messages will not re-illuminate the lamp.

 

[kwbMitel]

Sorry, for #2 I missed the lamp staying on part. That is not normal if the message is listened to. (unless there are new messages that have not been accessed)

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[IrwinMFletcher]

For #2, make sure the MWI Disable FAC is set. Test to make sure that it works on a set.

i.e.

*90xxxx to turn on the MWI
*91xxxx to turn off the MWI

where *90 is the MWI on FAC, *91 is the MWI off FAC and xxxx is an extension to test.

 

[kwbMitel]

For IrwinFletcher - Embedded mail does not use Dialed message waiting if programmed correctly.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[IrwinMFletcher]

I'm not sure what you mean by 'Dialed message waiting', but you need to program MWI FAC codes as part of EMEM programming. EMEM ports act as emulated sets, and they use that FAC to toggle the lamp.

 

[kwbMitel]

Irwin.

I'm not so sure that it does. If the last VM port is not in the hunt group, it will show up as dialed MWI. If the system is programmed correctly it shows up as a callback.

The Dialed MWI can be cancelled using the FAC. The Callback cannot.

From my Centigram SS4 integration days, I believe the set emulation is actually using softkeys to sent MWI, not the FAC. I may be wrong, I admit, but its what makes sense to me.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[IrwinMFletcher]

Ah, I see the differentiation you are talking about now. True, callbacks are issued by call control I believe, EMEM uses MWI FAC. I once had a set stuck in the state where I couldn't remove the lamp (through either message callback or through EMEM). I ended up deleting the set and programming it again. I've never played around with leaving a port out of a hunt group.

Also, he is a snip from a diag.dat file:

02/24 17:14:37 INFO 8483-03 mwi: vb_dial[*902003]

Here, EMEM is using the FAC to turn on the lamp on extension 2003.

 

[TheMitelGuy]

kwbMitel: You said "From my Centigram SS4 integration days, I believe the set emulation is actually using softkeys to sent MWI, not the FAC. I may be wrong, I admit, but its what makes sense to me." You are 100% correct. The EMEM is really a chipset that comes from the original SS4150s (the nice touch screens). You are correct sir/madam.

MitelInMyBlood: The article you pointed to is a good one - however it will not work for NuPoint. For NuPoint you can do the exact samething, with the exception of using *, you have to use 1-9 instead, so *XXX may look like 3XXX. Most customer's don't care, but * is nice to use.

 

[brewski6666]

Thanks to all for your reply.
- For the first issue I found that the call rerouting for DID was not set, that’s why I was able to transfer an internal call to voicemail but not the external calls, now it works.
_ For the second issue I noticed that if I listen to a new message than I press 5 (to save it) and hung-up, the MWI lamp turns off. I understand from that itch time we listen to a new message,
We have to press 5 for the MWI to turns off.
My question is: is it the way that the MITEL embedded voicemail works or it’s a bug in my system? (before my new experience on MITEL systems I was working for long time on NORTEL systems, and on Nortel systems, when we listen to a new message and hung-up the message state turns to SAVED automatically without pressing any key and the MWI lamp turns off by itself.

 

[TheMitelGuy]

With EMEM (embedded mail) you must either KEEP (5/K) or DELETE (3/D) the message, eitherwise it will remain as NEW.

With NuPoint you can customize the system to keep it as NEW or automatically mark it as saved.

 

[IrwinMFletcher]

MitelGuy, I concur EMEM uses 4150 emulation, however the MWI is actually dialed (see my previous post). The soft keys (touch screen display messages) are used by the emulation to determine the state of the phone.

I'm guessing the 'persistent' state of the MWI was to save storage space. In other words, keep bugging the user to either delete or save the message.

 

[MitelInMyBlood]

TheMitelGuy - Going back to my sx2K days, the FAC is still a requirement. The difference comes into play regarding whether the "code" is issued from a voice mail port (member of the voice mail hunt group) versus a port which is not a member. In the latter case "Dialed Message Waiting" is set against the target versus a "callback" being set against the target if the port it a member of the VM hunt group.

We use this exact feature on a maintenance phone that is a member of the VM hunt group (but set in permanent DND mode) so we can manually enable/disable a callback against a set after performing a move in OPS because OPS does not properly handle the status of MWI callbacks. By virtue of it being in permanent DND it can be a member of the VM HG but will never have a VM call presented to it. Very handy during moves to keep the customer happy.