Message Waiting Lites 1

[harry111]

3 networked Magix's 1 location has the voice mail, message lights will not lite at remote locations, I was told this is a programming issue.

 

[gregarican]

I have two location with private PRI networking. I have seen Message Waiting Light delays and errors noted as such in the System Error Logs. Since we use PRI the D Channel carries the MWL updates, and this is at least more reliable and faster than using T1 E&M trunks for private networking due to E&M requiring TTR resources and other factors.

If the MWL's aren't going at all I would suggest looking at your voice mail system programming. For example, our Octel 50 has to issue a #53 for MWL On and a #*53 for MWL Off. Since this is a global setting if your Centralized Voice Mail system is working at least for the local site's MWL's then perhaps look at the tie lines.

Are you doing tandem PRI or tandem T1? How many lines are you using for the tandem setup? Do you see any suspicious errors in the System Error Log?

 

[harry111]

Thanks for the help

 

[jamiller]

mwi:
This sounds like my own problem.We are using e&m tie lines
and the t1 is split with 6 tie lines to one location and 4 tie lines to the second location. I do not believe you can lite the message waiting lites over e&m tie lines. please let me know if i am wrong

 

[gregarican]

From what I have read you can, but the updates occur slower because a trunk is taken up for the communication. If you don't have a lot of capacity then this would be even more the case. Harry 111, how many trunks do you have between sites? And how many extensions are at the remote site? If there's a disparity then therein might be your problem. Do you see errors in the System Error Log indicating MWL timeout issues?

Looking at my Network Reference manual that Avaya put out E&M tie lines are indeed supported for the MWL feature, but the update traffic competes with other calls along the trunks. And I would imagine any internal contention priorities wouldn't favor the MWL updates.

Since these are presumable prviate point to point lines why don't you consider provisioning them as PRI? Replacing the E&M cards with DS1 cards and using Common Channel Signaling rather than Robbed Bit Signaling will probably give you richer features, improved performance, etc. If it's a private line you can decide what to put on it. Using E&M you are going to run into TTR resource issues (causing calls not to be handed off), lack of ISDN identifiers, slow MWL updates, longer call setup times, etc.

 

[gregarican]

You can download the Merlin Network Reference for details on Avaya's website

http://support.avaya.com/japple/css...onService(runStatement,avaya.css.UsageUpdate)

It's written for Legend but goes for the Magix as well. Hope this helps!

 

[gregarican]

One thing I forgot to ask was if you had the remote site extension ranges listed in the CVM site's non-local UDP. If you don't then the local site's voice mail system wouldn't be able to reach the remote site extensions in order to send out of the MWL updates. Can the CVM site's users dial the remote site extensions directly? Or do they have to go through a DID? If they can't dial directly then chances are the voice mail system can't either for MWL updates.

If you don't see any MWL Facility Timeout or Touch-Tone Receiver errors in the System Error Logs at the local or remote sites (respectively) then I would suggest checking the dial plan at your Centralized Voice Mail site. The Voice Mail Integration conversion number has to be able to route to the remote site extensions through non-local dialplan.

Let me know what the final outcome is, as I'm curious as to what's going on.