VM Pro bumps calls from Auto Attendant

[tmckeown]

I've just run into a very odd condition that I can't seem to figure out. I have tried rebooting our VM Pro server and the IP412 system, but I still have this problem:

After hours, we have all calls go to the auto attendant.

First caller gets into the auto attendant and listens to the prompts.

If a second call comes in, the first call is dumped from the auto attendant as if the person has pressed the 7 key. This unfortunately routes them to a different department that never closes. That department then wonders why they got the call.

I know this is pretty vague, but has anyone run into anything similar? I have not made any config changes in months, so I'm not sure how this might have developed.

We are using VM Pro 3.1 (21) and IP 412 3.1 (65)

Anyone care to guess where I would start to track this down? It kind of seems like we don't have licenses for more than one VM port. But, we have valid licenses for four ports.

Thanks for the help.

 

[jconrad0305]

what type of lines. i am thinking that maybe there is cross-talk on analog lines that ,ay be causing the problem. also you can set the vmpro service to "interact with desktop" to give you the screen where you can look at the vm process and see why they are going where they are going.

ACA & ACS IPO Implementation

http://www.computingagain.com

 

[Ragnorak]

There is a debug tool for VM Pro. If you run it the tool should tell you exactly why the call got transferred. If it doesn't you at least have a log file you can dump in Avaya tech support's lap. I've used it in the past and it was most helpful.

 

[tmckeown]

Thanks for the help. I'll look into the tool. A log should tell me something about it.

I don't think it's cross-talk related. The first caller who gets bumped always gets bumped at the exact same time into the auto-attendant.

 

[tmckeown]

I thought I should give this a wrap-up so anyone with a similar issue would know what the solution was.

To recap: When multiple callers were in the auto attendant when our IPO412 was set to night, all the callers get bounced out of the auto attendant before they press any buttons. This is hard to believe, but the problem was with the female voice we used for the auto attendant scripts. Her voice would occasionally hit the same pitch as a DTMF "7", which then bounced people out to whatever the "7" selection was. I confirmed this by setting up some debugging tools for VM Pro with an Avaya tech. We made a bunch of calls in after hours and watched them get bumped out of the AA. In all cases, no one pressed a key on a phone, yet the log showed them pressing "7" at about the same point in each call.

We rerecorded the AA scripts with a male voice and the problem is now solved. Talk about a bizarre case.

 

[ThePhoneMn]

Not at all hard to believe, this has been ongoing with VMPro for a long time now. I know this sounds like a broken record, but you think they would've fixed this by now!?

 

[aarenot]

In VMPRO, if you have any issue with calls being sent with questionable intent, turn off the ability of DTMF to interupt prompts. This requires the caller to wait until the prompt is done talking, but lets you know if it is an issue with simulated DTMF. I have seen this a few times over the years, it is rare, but not unheard of. It is also common of almost every VM I have ever worked on, and that is probably about 30 different types of VM systems.

Often just re-recording with the same voice will solve the problem, you can use the same person usually. This is not a VMPRO problem only, it is just one that does not turn up that often. I would guess about every couple hundred you might find one, I have seen at least a dozen.