lgherb

My vendor is stumped on this one, so I thought I'd give this forum a try.

We have a MICS 7.0 system with a PRI and Nortel Voice Mail 4.1 housed in an Apps Mod II. I did all of the original programming on the KSU and Apps Mod when we biught it refurbished on the web.

Everything was working fine for about 3 years until we had a problem with our PRI circuit that had Verizon/MCI and our new equipment/service vendor pointing the finger at each other as to the problem. To make a long story short, the problem eventually turned out to be a Verizon issue with the circuit, but we ended up replacing our KSU and upgrading from 4.1 to 7.0 and upgrading Voice Mail from 4.0 to 4.1 in the process of "fixing" that problem.

Here's the new problem:

Once we upgraded the KSU our Voice Mail DN changed from 301 to 302. This was what was listed via "Feature 985".

We changed our target lines for the PRI to go to 302 and changed all of our extensions to forward to 302 on "Busy" or "No Answer". (When everything was working, these were set to 301.)

The problem that manifested was that the AA would answer outside calls but when the caller dialed a specific extension, the call would go right back to the CCR menu instead of transferring to the extension that the outside caller dialed.

Here is where it gets kind of weird.

On a lark, I changed my extension to forward to the old Voice Mail DN on "Busy" or "No Answer" and that seemd to fix the problem for having the AA route calls to my extension. I then changed all sets to forward to the old (301) DN for busy and no answer.

This created a couple of new quirks.

1. If I call another extension internally the other extension rings 4 times, then stops ringing at the extension that I dialed but the call does not forward to that person's voice mail box. In my handset, the extension keeps ringing.

2. External calls answered by one person do not forward to voice mail if transferred to another extension that does not answer in 4 rings. The call gets transferred back to the station that answered the call.

After conferring with the vendor, they suggested that maybe the port on the 6 port combo card that the NAM was plugged into might be flaky, so they suggested that I move the fiber cable from port 6 to port 5 in the combo card and reboot.

This predictably changed the Voice Mail DN from 302 to 285, verified by "Feature 985". I then changed the target lines for the PRI to reflect the new VM DN and updated all stations accordingly.

The exact same problem manifested itself. Outside calls would get answered by the AA but would route back to the main CCR menu when they dialed an extension.

I programmed my extension to forward to 302 (last known VM DN) and this did not fix that problem. But programming my extension to forward to 301 (the VM DN we had for over 2 years) did fix that problem. All extensions have been upgraded to forward to 301 on busy/no answer so we can receive calls and if unanswered external calls go to the appropriate voice box.

However we still have the 2 problems I enumerated above.

I have searched through KSU and VM programming and find nothing that references set 301 (aside from the sets all having the forward to 301 on busy/no answer.)

Does anyone have any idea of what is going on here? I am tired of paying for service calls to my vendor and I know the predictable suggestion to replace the NAM with a new Call Pilot system will be next.

I doubt that this is a hardware issue. It has to be a programming issue. Something has the old Voice Mail DN of 301 in memory.

In the 'Port/DN Status' sub menu in maintenance, there is no port assigned to DN 301...it goes from 300 to 302 as I scroll through the DN numbers.

Any help would be greatly appreciated.

lgherb