sundance-communications.com/forum Forums TDM Business Telephone Systems Avaya - Lucent Telephones & Systems Avaya Magix R4.0 VM Problem

I'm having a serious problem with my Magix VM not picking up calls.

When a caller calls into the main # the VM will not pick up the calls. The caller is hearing the phone ring then dead air when the VM picks up.

The customer can internally transfer calls and leave messages but they can not transfer an outside call to VM.

We changed out the VM for another but having the exact same problem. We moved the VM to a different slot but that had no affect. We also changed out processor but still having the same problem.

The Magix R4.0 Processor and R4.0 VM had been working fine for about 1 year and only now acting up the day after a big thunder storm.

They have a T1 PRI coming in from a company called PaeTec and have been a PaeTec Customer for about 10 months with no issues.

PaeTec did dial into their PRI and said everything is working fine on their end.

The crazy thing is we installed a R1 VM and the auto attendant picked up. Why did it work for a R1 but not for the R4?

It's looks like to me that you've lost your Main Day or Night Greeting. Log in and go to AA 1 day mode and listen to the Greeting.

I agree it sounds like the VM is answering, but there isn't any greetings recorded. I would check the recorded greatings.
Also will each port answer if you dial them individually?

Yes, you could dial each port that is assigned to the voicemail and it should answer.

Have you tried re-recording the greetings or, maybe, assign another one of the 4 available auto attendants to handle calls?

The Magix Messaging 4.0 has all their recordings in place.

The system build is a Magix 4.0 Processor, (3) 412TDL, Magix Messaging, D100 and a 016 TTR. The CO is providing a MPLS with a PRI appearance 5ESS switch type, ESF framing.

Again the issue is when an external call is made the Messaging picks up up with dead air.

You can call the VM with no propblems internally.

You can also make a call via the CO provided lines and it works because the call never leaves the provided router.

I even jumped a line cord between the 016 TTR and port 801 of 412 TDL and renumber the extension as the DID number and the auto attendant answered.

Any DID extension rings down just fine.

When the coverage to Voicemail occurs is when it seems to fail.

We try renumbering calling groups as a DID and have it overflow directly to an AA it also fails.

Please contact us 856-235-1411 to discuss the problem.

Is Calling Group extension that Overflow to AA had been assigned as AA#1 extension and Integrated VM type? How is your incoming routing set up? make sure that Max number of digits in VM set to 4.

PM sent.

I had a call from a tech who saw my post on here and he has Magix R2.5 VM. They too are having the same problem at the same time. They also have the same provider. The provider tested remotely but would not send a tech on site. They said there system tested fine and the fact the the R1 is working tells them there is no need for a tech to go on site.

How can two VMs have the same problem at the same time with the same provider?

We hooked up a T-Bird and the system worked fine.

The billing for this is getting out of control. I may have to call in Avaya Direct to prove there is nothing wrong with the system but of course this will be far from a free service.

If anyone has a suggestion please feel free to email me or post on this site.

Still fighting this one? Sorry about not following up again, TK. We had talked about what digits were sent to a hunt group when the type was set to Integrated VMI. Here's a grab that I took one time when troubleshooting a similar problem:



There are two telling things in my example string of #01#819##. The #01# tells VMS that it's an outside call (a #03# is sent on station to station calls); the 819## says that the call came in on trunk number 19.

When #03# is sent--as it is with DID calls--I believe the destination extension number is what follows.

I'm curious what the T-Bird saw. I suppose if you don't have any grabs that we can always turn on some trace features in Monitor. In our conversation several weeks ago, you had said this problem crept up when the carrier changed something about the way they send you the Caller ID. It seems like there is something in there that is confusing Merlin Messaging. It's picking up because the number of coverage rings has been met, but maybe there is silence because it can't determine whether it's an inside or outside call. Inside calls trigger the call-answer feature, outside calls trigger the automated attendant. DID calls, while technically originating from the outside, are really just a special case of inside calls.

I especially don't understand why renumbering a Calling Group to a DID (when then overflowed to VM) didn't work, especially if calling other DID numbers directly DOES work. Did you ever try making an entry in the Route by Dial Plan table to renumber the digits sent on the Listed Directory Number to point to 770? If you're confused by that, perhaps I should dial in a take a look.

I know you've tried several MM release 4.0 blades, and that each gave the same result. Why this problem doesn't appear with an older VM card is beyond me.

OK If DID's work,try renumbering an adjunct to match the main number,instead of a calling group.
Or route the main number in you PRI table to point to the adjunct with coverage to a voicemail AA.