Voicemail Not Picking Up

[h382]

406v2 on 4.1.95011 (patched last week to try and resolve issue)
VM Server on 4.1.27


Older site I had upgraded to a new 406v2(403 previously)

They have Voicemail Pro running on XP, that I recently changed over to 2K3 to try and fix this issue.

The issue is simple, after so long, could be 20 minutes, could be 1 day, the voicemail service is still started, but won't pickup. Callers will hear busy/dead-air.

This wasn't an issue until we upgraded them from a 403 and 3.0 to a 406v2 and 4.1

To fix the issue, I have to restart the Voicemail Pro Service. The licenses show valid. I have an incoming call route pointed to Voicemail to test, and when they are experiencing this issue, the call doesn't even show up in System Status.

Any ideas?

 

[h382]

I was running 3.0.59 before with a 403, and the same VM Server as I have now. Didn't have issues before all the upgrades.

These issues started happening within a day or two of upgrading the system to 4.1.9 and the VM Server to 4.1.27

It's been about a month, and I have downgraded both the system firmware and VM Software to 4.0 releases, with no change. I had moved the VM Server from the original XP Machine to a 2k3 server, and it happened even more often. So, VM is back on the XP Machine, with 4.1.27 VM again. The firmware on the 406v2 is now 4.1.9(5501) or whatever that patch is.

 

[Westi]

Hello gentlemen
I read this thread with interrest but being happy not to have this problem, until Monday this week and Tuesday and today again, a newly installed IP500 running 4.1 and the voicemail stopped working but the services were running and restarting the service brought it back. So I think there is a bug in it somewhere. I will keep watching for a fix and also engage Avaya with it. Should I get a fix, I will post it.
I have 6 sites out with 4.1 and the IP 500 but only one has this problem, of course it is the biggest one with about 50 digital phones and a second site with 20 IP sets. maybe it has something to do with the IP sets becasue the other sites have only digital sets.


Joe W.

FHandw.
ACA
ACS

 

[puregold]

Have you seen this?????????????

IP Office Technical Tip
Tip no: 199
Release Date: January 23, 2008
Region: GLOBAL
Data Channels Not Being Released Cause Voicemail Issues
An issue with data channels not releasing correctly has been found when using IP Office
software releases 4.0.10, 4.0.14 and 4.1.9. Voice callers will experience ring tone no
reply or busy tone with voicemail ports available.
The issue can be recreated in a number of call scenarios:
1. A call is placed to a hunt group (it doesn’t matter if the call is directly to the hunt
group or has been transferred to the hunt group), and a user within that hunt
group is idle (has no other active or ringing calls). If the voice mail timeout
expires while there are other ringing calls on that extension (either calls directly
to that user, calls to the same hunt group or calls to a different hunt group that
contains that user), the call will never be placed to the voicemail, but the voice
mail channel will remain allocated.
2. A call answered by Auto Attendant is routed to a user within a hunt group and
another call type (DID or Internal) simultaneously rings the same user within the
hunt group. If the DID or Internal call is answered first the data channel
presenting the hunt group call may not be released, causing a port to lock up.
(Please see SSA below).
Note: Call Waiting must be set to “ON” on the Collective hunt group and on the user
within the hunt group.
When this happens you will receive a busy tone when trying to access voicemail
internally and ring tone no reply when reaching the Auto attendant.
When viewing SSA you will see more data channels in use than voice mail channels -
this is an indication of data channels locking up (See Note A below for when Data
Channels are used by the system). You will also see large congestion counts as
voicemail is not answering even though it shows channels available.
COMPAS ID: 133413 Page 2 of 2
If you experience this issue you have three options available to you.
1. Remove call waiting from the user or the hunt group.
2. Change the hunt group to a different type (other than collective).
3. Contact your distributor or open a ticket via iCare and reference Avaya CQ
39339. This will generate a ticket to Avaya Tier III who will supply Critical Patch
number 4.1.9 5501 to fix the issue. (The customer will also need to upgrade their
Voicemail Pro to version 4.1.26).
The above screen shows that the IP Office has eight voicemail channels licensed and at
this time there are three connections to voicemail active, the data channel usage count
shows six active channels, therefore this would indicate there are 3 data channels in a
locked state. On this system only five users would be able to access voicemail
concurrently, the three other callers would receive either ring tone no reply or busy.
Note A: Data Channels – from Knowledge Base on 4.1
Data Channels are used for Remote Access (RAS), Internet Access, and Voicemail
sessions. A data channel is an internal signaling resource used whenever a call is made
from the IP network to an exchange line (Central Office). For example, four people
surfing the Internet will use a single data channel since they all share the same line to
the ISP. Two people remotely accessing the Office LAN from home will use two data
channels since they have dialed in on separate lines. IP telephones do not use data
channels.
Issued by:
Avaya SSD Tier 4 Support
Contact details:-
EMEA/APAC
Tel: +44 1707 392200
Fax: +44 (0) 1707 376933
Email: gsstier4@avaya.com
NA/CALA
Tel: +1 732 852 1955
Fax: +1 732 852 1943
Email: IPOUST4ENG@Avaya.com
Internet:

http://www.avaya.com

© 2007 Avaya Inc. All rights reserved.

ACE - Avaya Certified Expert
ACI - Avaya Certified Instructor

 

[puregold]

oh yeh i think you have after reading the thread a bit more.

ACE - Avaya Certified Expert
ACI - Avaya Certified Instructor

 

[TheDoz]

Had the same problem a couple of days ago.
Everything looked normal on ip500 ver. 4.1 (9)
When you dialed *17 it just rang and rang no answer.
This is a mixture of ip phones 4621SW and digital 5420 phones.
Got a patch from avaya Tier 3. 4.1 (95011)
Upgraded to that bin file and waiting to see if problem re occures again.
I hope this will fix the problem for the customer thinks this system is the greatest.
Thanks

"The lack of money is the root of all evil"

 

[ronromano]

I have put this patch on many unit and it does the job. h382 says he is running this already and still having a problem. I told him what his issue is but he doesn't believe me.

 

[h382]

ronromano, I would believe you if that was what my issue actually was. In all attempts to troubleshoot this, I took the VM Server offline, and did a network scan with Angry IP Scanner, and as I suspected .40 did not show up on the scan until the VM Server was turned back on.

As you can see if you read, other posters are now having the same exact issue, so I think it's a little bigger of a problem than a duplicate IP address.

I do appreciate your input, it was a good thought.

 

[tlpeter]

A wild guess but did you put in an ipadres in the system tab ?
Could be that you left it default (255.255.255.255)


ACA - Implement IP Office
ACS - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[h382]

Westi, the site that I'm having this issue with is running about 40 digital sets(6408's that they were using on the old 403). So, I had no IP sets in that office.

I just installed an IP500 with about 70 5410/20's a few weeks ago(4.1.9), and so far no issues. (knock on wood)

 

[ronromano]

Listen, I know you think you have found a bug that the 5011 patch doen't fix, and you feel verified because someone else says the same thing, but you are wasting your time.

The site is in NJ? Where?

 

[h382]

LAN1 - 10.50.45.41 /24 RIP Mode, None. DHCP, Disabled
VM Type Lite/Pro - 10.50.45.40 No reserved VM ports
TFTP Server - 10.50.45.40
Time Server - 10.50.45.40
File Writer - 0.0.0.0
License Server - 10.50.45.40 (license valid)
AVPP - 0.0.0.0 (no wireless devices)

 

[ronromano]

Who says the conflict has to be with the VM? how do you know its not with the IPO?

 

[Duffman88]

TheDoz I think you actually have the data channel problem that purgold just posted. If you are getting RNA your data channels might not be freeing. Usually you can tell in SSA in the resource tab.

The problem that most of us are having (I believe unless I am missing this completely) is the voicemail actually answers the call but you get nothing but dead air. The lights are on in the VM but no one is home.

Check this Tech Tip out for your problem.

http://support.avaya.com/japple/css...eID=328264&temp.bucketID=162326&PAGE=Document

-Chris
ACA

 

[h382]

Doesn't it seem strange the Avaya releases a patch that fixes a problem very similar to mine? Sure they have found that Hunt Groups and call waiting cause this, I guess that means nothing else in their code could cause this either, that would be impossible.

The site is in San Francisco. NJ only had this problem one time(in 6 months) after a merge config, and that was it.

 

[h382]

Duffman88, that issue was discussed earlier in the thread. I know it's a big lengthy, but its up there somewhere. The issue is close to the one mentioned in the TechTip, but I have the patch running already to no avail.

 

[Duffman88]

I know you patched it and it didnt work I was writing to TheDoz.

I am right though you are getting dead air when calling the voicemail not Ring No Answer?

I have only had the opportunity to call from the outside to check this problem. I havent been able to get a *17 internally to see how the digital sets react on my problem system.

-Chris
ACA

 

[Duffman88]

The two issues even close are different. The techtip issue the system doesnt have the resources to call the voicemail so it RNAs.

Our issue from what ive seen and read the system has resources and thinks the voicemail is there. So when it sends the call to voicemail it leaves it there but the voicemail doesnt give any response.

I actually want to check my VM Debug logs to see if the VM sees the incoming call while it is "locked up". That would let us know if the voicemail is completely blind to what is going on or if it sees the call and starts to handle it, but just cant get an audio stream back to the IPO.

Just brainstorming out loud.

-Chris
ACA

 

[h382]

This is what monitor said when a called did RNA.

70120729mS ISDNL3Evt: v=1 stacknum=1 State, new=ICProceeding, old=Present id=9
70120729mS ISDNL3Evt: v=1 stacknum=1 State, new=Received, old=ICProceeding id=9
70121128mS RES: Fri 29/2/2008 15:53:33 FreeMem=46640132(83) CMMsg=5 (5) Buff=100 616 499 1046 5 Links=6390
70130715mS CMTARGET: 1.9.1 894 Q931 Trunk:1 CHAN=1: TimerExpired cause=CMTCCoverageTimeout
70130716mS CMTARGET: 1.9.1 894 Q931 Trunk:1 CHAN=1: GetNoAnswerTimer:15

********** SysMonitor v6.1 (9) [connected to 10.50.45.41 (SFOIP406v2)] **********

70131535mS PRN: Monitor Status IP 406 DS 4.1(95011)
70131535mS PRN: LAW=U PRI=1, BRI=0, ALOG=0, ADSL=0 VCOMP=0, MDM=0, WAN=0, MODU=3 LANM=0 CkSRC=1 VMAIL=0(VER=0 TYP=1) CALLS=2(TOT=894)
70135716mS CMTARGET: 1.9.1 894 Q931 Trunk:1 CHAN=1: TimerExpired cause=CMTCNoAnswerTimeout
70135717mS CMTARGET: 1.9.1 894 Q931 Trunk:1 CHAN=1: ActionNoAnswerTimeout()
70135717mS CMTARGET: 1.9.1 894 Q931 Trunk:1 CHAN=1: Retarget NOANSWER EXCEPTED=00000001 ValidTargets=1
70135717mS CMTARGET: 1.9.1 894 Q931 Trunk:1 CHAN=1: Retarget on target_cfg_user=Serena Torres
70135718mS CMTARGET: 1.9.1 894 Q931 Trunk:1 CHAN=1: ADD USER: Serena Torres depth=1 disallow_cw=0 dnd=0 real_call=1 type(CMNTypeUnknown) incl(0x1) excpt(0x1), allow_redir(1) remote=00000000
70135718mS CMTARGET: 1.9.1 894 Q931 Trunk:1 CHAN=1: SELECT: TRY VOICEMAIL orig_hg() orig_user(1926)
70135718mS CMTARGET: 1.9.1 894 Q931 Trunk:1 CHAN=1: ADD VOICEMAIL TARGET
70135719mS CMTARGET: 1.9.1 894 Q931 Trunk:1 CHAN=1: ADD VOICEMAIL TARGET: FAILED availability=0
70135719mS CMTARGET: 1.9.1 894 Q931 Trunk:1 CHAN=1: VM targeting failed. Remaining on final target Serena Torres
70135720mS CMTARGET: 1.9.1 894 Q931 Trunk:1 CHAN=1: GetNoAnswerTimer:15
70141251mS CMExtnRx: v=1905, p1=0

I only had the VMDbug running while the issue occurred, unfortunately no one was in the office at the time to give it a try. Next time it happens, I'll capture what dbug says. It's only happened once this week so far though.

 

[h382]

Let me clarify, I had VM Debug running on a different occurance, not the one I just posted about. I only had monitor running for the that first trace.

 

[Duffman88]

In that case I dont think the VM would have seen the call. Do you find your getting more RNA or more dead air?

-Chris
ACA