Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations dencom on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Voicemail Pro not operational

Status
Not open for further replies.

jgonzalez77

IS-IT--Management
Jun 28, 2008
46
US
Hi Guys, could sure use some help here.

Have an IPO 500 on v5.0(8) with voicemail pro.

Starting today, incoming calls are not being answered by the auto attendant. Nothing's changed on the system. Usually the receptionist answers the phone, but if she's away it's supposed to go to the auto attendant, instead it just rings and rings.

I should add that if the receptionist transfers to an extension, that extensions voicemail box does answer.

Here's what I'm seeing in monitor, but I don't know where to begin to fnd the problem (and yes, I already rebooted the VoiceMail Pro Server);

1535911907mS CMTARGET: 1.19.1 4782 Q931 Trunk:1 CHAN=1: ActionVoicemailTimeout
1535911907mS CMTARGET: 1.19.1 4782 Q931 Trunk:1 CHAN=1: SELECT: TRY VOICEMAIL orig_hg(100) orig_user()
1535911907mS CMTARGET: 1.19.1 4782 Q931 Trunk:1 CHAN=1: ADD VM TARGET
1535911907mS CMTARGET: Voicemail Pro not operational
1535911908mS CMTARGET: 1.19.1 4782 Q931 Trunk:1 CHAN=1: ADD VM TARGET: FAILED availability=0
1535911908mS CMTARGET: 1.19.1 4782 Q931 Trunk:1 CHAN=1: ActionVoicemailTimeout: VM Target not found
1535921908mS CMTARGET: 1.19.1 4782 Q931 Trunk:1 CHAN=1: ActionVoicemailTimeout
1535921908mS CMTARGET: 1.19.1 4782 Q931 Trunk:1 CHAN=1: SELECT: TRY VOICEMAIL orig_hg(100) orig_user()
1535921908mS CMTARGET: 1.19.1 4782 Q931 Trunk:1 CHAN=1: ADD VM TARGET
1535921908mS CMTARGET: Voicemail Pro not operational



Thanks in advance!

 
I would first make sure the address for the VMail server in Manager is correct. Check network communication between your IP500 and the server, check to make sure there isn't a software firewall causing a problem, and if those aren't the issue, then I would save your call flows just in case and do an in-place re-install of Voicemail Pro.
 
Check the services!

Avaya_Red.gif

___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged
___________________________________________
 
Do you have manager installed on the same server ?




ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!
 
Yes, I have manager installed on the same server. I checked the services, they are running. I rebooted the server, then made sure the services started properly, and they are.

A part of the voicemail system is working because people can access their mailboxes, and callers can be routed to user mailboxes. The only thing that seems to be happening is that the auto attendant is not answering. Is it possible part of the system is hosed? I'm about to reinstall to see if that fixes it. Any other things to check before I do that?
 
Do you use Remote Desktop to make changes to the voicemail? This is recommended against by Avaya as it causes call flow corruption :)

ACS - IP Office Implement

"What the Crocodile Hat....was that?
 
there is a file on the c:\ disk of the vm server called dbgout.txt, it holds the logging of the vm pro service.
take a look at it and maybe you can find the problem there.
 
In the Manager, on the HuntGroups check if the "Announcements on" is still checked.

In VMPRo look if the Goups have an action on the "Queued" and "Still Queued"

Avaya_Red.gif

___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged
___________________________________________
 
Well... I solved the issue.

Last week someone started messing with the network wiring, brought the whole network down. We resolved that.. or so I thought.

The VM server has 2 network cards in it, BOTH were configured with valid LAN IPs (different IPs of course). Earlier today I noticed that both NICs were connected to the network, so I called the guy that set it up and asked why, he didn't know but assumed it had always been like that. I made sure that in Manage it was pointing to the "main" NIC, yet the problem persisted. Finally, I disabled the second NIC and voila! it started working.

So I'm thinking that during the network mess last week, someone connected the 2nd NIC just assuming it had to be connected. I really don't know. Nevertheless... problem solved.

Sheesh.
 
Personally, I like to use two NICs in my servers and use both LAN ports (or on a 412 the LAN and WAN ports) each on a different subnet, one is the "real" network that is used to communicate with clients, other IP Office units, H323 phones, etc, the other LAN is directly connected to the IP Office or on a shared physical or partitioned switch shared between VMailPro, the IP Office and the Delta Server, etc. All VMail traffic goes over that other subnet on the second LAN port, this has resolved all the quality problems you can get on a very busy network.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top