Callback - Embedded Voicemail

[Cabarrus]

We have one extension 1085 that gets multiple callbacks w/ blinking light through-out the day and its a callback from the voice mail system with no message left. The light then turns off after it is checked and comes back later in the day.

I am a bit lost on how to troubleshoot / fix this issue. The phone number is a DN of a phone and also a multicall button on some other phones.

thanks

 

[paterson]

Is it possible that ext 1085 is the first member of a hunt group? And that this hunt group has a VM box?

_______________________________________________________________

If you did not take enough time to get it right the first time...

What makes you think that you have time to fix it?

 

[Cabarrus]

I double checked and we're not, but thanks for the suggestion!

 

[IrwinMFletcher]

You could look at the diag.dat file and see if anyone was trying to leave a message, or if it was some message that is 'stuck'. You should see the occurrences of the mwi attempts from voicemail:

07/29 14:33:29 INFO 4729-36 Msg V4a705dad.001 for 2003
07/29 14:33:32 INFO 8483-04 mwi: vb_dial[*902003]

 

[Cabarrus]

I assume I look at the diag.dat file via telnet? I havent done that process before, if you could elaborate. thanks

 

[IrwinMFletcher]

Yep, sorry. ftp into the controller and change to:

/vmail/c/voxdrv

diag.dat should be there, it's a plain text file

 

[Cabarrus]

ok i got the log open up and search for 1085 and see it listed a lot: 732 is a feature access code to deactivate message waiting. Does this help at all, or should i be looking for something else? thanks

07/29 13:23:59 INFO 7013-11 Logged in to mailbox 1085
07/29 13:23:59 DEBUG 5300-11 vtmsgcheck=0[msg1085.vox,0]
07/29 13:23:59 INFO 5932-11 say_mbox_stats: f_handle=392, totmsgs=0, nm=0, om=0, tt=-1, em = 0, ret=0
07/29 13:23:59 INFO 1203-11 vta_s12: fh=392, tm=0, mrc=0
07/29 13:24:02 INFO 8483-20 mwi: vb_dial[7321085]

 

[IrwinMFletcher]

ok, so the first line means that someone logged into the mailbox, most likely to check messages. The next line means that it is checking to see how many messages that mailbox has, which is 0. So it then turns off the MWI if it was on (the last line). So basically this section of logs are when someone logs in to check the messages, and it turns off the lamp.

If you don't see any entries with "vb_dial[XXX1085]", where XXX is your FAC for turning on MWI, then it isn't voicemail that is turning on the lamp, but someone/thing else.

I wonder if that would show up in the SMDR?

Any chance someone is just being a pain and dialling the FAC directly?

 

[UncleRalph]

This can also happen if the phone has non-prime line appearances it.
Example: a phone has a series of Key Line appearances on the left side of the phone that is in a hunt group that has a voice mail.

What happens is a call will go to the huntgroup DN then fwd to a VM box and the caller leaves a message.
The VM then lights the light of the Hunt Group. In reality what this does is light the light of the 1st MEMBER of the hunt group. The system then lights the light of the 1st phone where the 1st member appears.

Way to find this is to see if there are non-prime keys on the phone that are in a hunt group. Look at the hunt group to find the 1st member, then go to the Multi line set group assignment form to see what the 1st phone is that it appears on.

Confusing I know.

Ralph

 

[kwbMitel]

Ditto for what UncleRalph says.

Are there Non-Prime keys on the phone that are members of a Huntgroup where the huntgroup has a voicemail box associated with it?

This one drove me crazy for a while.



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

 

[Cabarrus]

I have hunt group 1070 w/ made up extensions 5001,5002,5003 and we have 1085,1086,1087,1088 and all four phones have 500? buttons assigned to them, but since extension 1085 is first in numerical order, i assume that is why its blinking 1085?

this is starting to make sense

 

[kwbMitel]

Yes, 1085 would be the first programmed with the keys and as such becomes the destination of the Msg Lamp.

There are 2 ways to resolve this issue.

1 - Delete Hunt Group 1070
- Program 1070 as a Key App or Phantom extension
- Create New Hunt Group such as 1*1070
- Add members 500x to hunt group
- Route 1070 to 1*1070 on an immediate basis and VM as 1st alternative
- Create MWI key on phone(s) for 1070


2 - Create a new 4 digit extension, Key App, Phantom e.g. 2070
- Create a new VM for the new Extension (2070)
- Set up VM the same as current 1070 VM
- Create new Huntgroup, Type Nametag, DN = *2070
- Route Nametag group to VM on immediate basis
- Route 1070 to *2070 instead of VM
- Create MWI key on phone(s) for 2070
- Delete obsolete MB 1070


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

 

[Cabarrus]

everyone thanks a lot, especially kwbMitel!

I used option #1 with a Phantom extension, but since that uses an IP license i was interested to find out more about Key App, I am not familiar with that feature.

thanks

 

[kwbMitel]

Phantom DN's are useful for many things and can be programmed in many ways. Each has their benefits and flaws and it is up to the programmer to determine the best fit.

1) program a non-existant IP Phone.
This method is simple and easy. It also is relatively obvious to any and all service people as to it's purpose. (as long as it it named properly). The flaw is that it consumes licensing.

2) Program a hunt group.
Can be forwarded and routed much like a set. The flaw is that it has issues with lamping if sent to voicemail.

3) Program a Key line on a set.
You can program any DN on a spare key on a phone. It can be routed and forwarded but also can have an associated MWI key if integration with VM is required. If you want to create spare keys on an existing set you can simply add a PKM 48 or Dual PKM to it and program the key as you see fit. The Flaw is that using an existing set has the risk of being deleted accidently as the purpose of the keys are not obvious.

4) Use a spare ONS port on the analog main board.
If one of these is available use it. AMB ports do not consume ONS licenses. The Flaw is that there are very few ports and rarely any spare.

Typically when I am designing a system I expect to need a half dozen or so phantoms for various purposes. I use a combination of #1 and #3. I create a phantom 5220 set and add a dual PKM. This gives me 119 Programmable keys on the phone for phantoms. I number the prime line with an exotic number like 9*9999 and Name it. If you need to create BLF's for a 5550 console this is definitely the best method.


Hope this helps.


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

 

[kwbMitel]

That should have been a 5224 set with Dual PKM

A 5220 Set with DUAL PKM will only yield 109 Programmable keys. (Fine distiction I know but useful for systems with 500 or more BLF's)

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

 

[Cabarrus]

IrwinMFletcher ,

I recently checked the diag.dat file located: /vmail/c/voxdrv and for some reason it doesnt show the 731/732 feature access code information like it used to.

Is there a way to change the type of logging and maybe that is what happened?

thanks

 

[IrwinMFletcher]

The level of logging can be changed but only via the shell, the default would show any MWI activity.

Leave someone a voicemail and post the related output of the diag file. Might show something.

 

[Cabarrus]

I left a voicemail and nothing new was saved to the log file, still looked like:

10/09 03:00:02 INFO 7077-00 fileio_open:pen([/vmail/d/vm/msg/msg0.vox],2,0)=-1,ctxt=[x_compress]
10/09 03:00:02 ERROR 5308-00 x_compress(0,msg0.vox,15)=-1
10/09 03:00:02 INFO 2403-09 VT_ON:0
10/09 03:00:02 INFO 2403-10 VT_ON:0
10/09 03:00:02 INFO 2403-11 VT_ON:0
10/09 03:00:02 INFO 2403-12 VT_ON:0
10/09 03:00:02 INFO 2403-13 VT_O

Those are the last lines on the log.

I had a log file saved from last month and it used to have a lot more verbose information listed:

09/22 10:58:48 INFO 6006-12 Msg V4ab8a855.053 (09/22 10:35)) for 1341 saved
09/22 10:58:56 INFO 6006-12 Msg V4ab8ad16.071 (09/22 10:55)) for 1341 saved
09/22 10:58:58 INFO 8483-19 mwi: vb_dial[7321341]
09/22 10:58:59 INFO 2403-12 VT_ON:0
09/22 10:59:00 INFO 6001-12 Msg V4ab62c08.044 (09/20 13:20)) for 1341 deleted
09/22 10:59:09 INFO 2403-17 VT_OFF:0

You mentioned console, i assume telnet?

 

[IrwinMFletcher]

yes, sorry, console=telnet for me.

Based on the timestamps of the logs, those are from the nightly cleanup of voicemail (scheduled for 3am). Any chance that the file it full? Log into the console and see if you see any logs coming out there.

If still nothing, I would delete the current file and see if that helps (it should regenerate a new one).

 

[Cabarrus]

thanks for your help. I was a dummy and was ftping to the wrong 3300, we have two and one handles all the voicemail.