AVST CallXpress / CM4.1 MWI issue 2

[DJPlaZma]

We recently upgraded from an old Audix to AVST CallXpress 7.91. Since that time MWI behavior has been erratic. More to the point, on random phones the MWI will stay lit after the AVST has called out to turn the light off.

After leaving a message in a vmail box I observe the AVST call back to the switch to turn the light on via the Line Status application on the AVST (MSG + xxxx). After it hangs up I perform status station xxxx on the CM4.1. It indicates Message Waiting: SPE.

The user then logs in and listens to the message and I observe the AVST calling the CM 4.1 to turn off the MWI via the Line Status application on the AVST. (MSG - xxxx). At that point the MWI should go out. After it hangs up I again perform status station xxxx on the CM4.1. It still indicates Message Waiting: SPE.

Like I said, it tends to happen to random stations. All stations are setup as follows:
LWC Reception: spe
LWC Activation: y

Display System-Paramaters Customer-Options:
Mode Code for Centralized Voice Mail: Y

On the AVST / Integration Options the following is set for Message Waiting Settings:
Set MWI Dialing Template: 177pppxp
Clear MWI Dialing Template: 178pppxp
Where 177 and 178 are the LWC on/off activation codes.

Several times a day I need to manually do a clr amw all xxxx on the PBX to clear the errant light.

Anyone have any issues like this in the past? If so, how did you deal with it?



-DJ PlaZma
Single-Handedly Keeping the 80s Alive!

http://www.PlaZmaRadio.com

 

[1a22ip]

Is the Audix still connected. If so it might have unheard messages in the users mailbox. I am currently between Voice Mails systems and this happens to the test group of users when someone leaves a message in the old system.

Hope this makes sense
ED

1a2 to ip I seen it all

 

[DJPlaZma]

1a22ip,

Thanks for the response.

The Audix has been physically removed and all translations removed from the PBX as well. I thought about that as a part of my troubleshooting, which prompted me to do away with the Audix related translations. Still, it's apparent that it's the AVST turning on the light now, since that Audix is gone and it registers as spe.

OH, the fun we had with our test group, too. "Oh, my light's on, but I don't have any new messages!"...Check Audix...and then the inevitable replies/forwards with the Audix users...

Thanks for your input! It just confirmed that all my troubleshooting wasn't done in vain.


-DJ PlaZma
Single-Handedly Keeping the 80s Alive!

http://www.PlaZmaRadio.com

 

[ChuckRCT]

So it sounds like you have the AVST integration with either digital sets or analog stations. You can do a list trace in the switch on the AVST station that is doing the MWI. Check and see what it is doing and dialing. One guess is that the AVST station "thinks" it is going off hook, getting dial tone, and then sending the LWC codes, but in reality the AVST station isn't waiting for dial tone long enough before it starts dialing the codes. Your list trace in that scenario would only show the station going off hook and then back on hook with no digits.

There are a couple parameters that you can adjust in the AVST to have it wait longer. Also, the AVST has debug logs that you can turn on to help troubleshoot.


Chuck
RCT Technologies

 

[DJPlaZma]

Chuck,

Great suggestions. I thank you. Off to do some troubleshooting.

-DJ PlaZma
Single-Handedly Keeping the 80s Alive!

http://www.PlaZmaRadio.com

 

[Teleman7777]

We have a few of these configs installed and the mwi is a constant issue. What I've had luck with is putting a pause before sending your first digit in your mwi string: pp177ppXp but it can be fickle.
We have moved to the Sip integration on a couple of sites and that seems to work very well.

Pete

 

[platinum8]

We've worked this issue on a number of sites with D82 type integration to AVST. Seems that at the newer CM releases there is more of a delay in responding to the MWI on or off dial string.
Best fix has been to add 3 pauses at the end of the MW dial string. If the VM port disconnects before CM finishes sending the "success tone" the operation fails.

Al

 

[DJPlaZma]

Thanks for the recommendation. I just made the change and will wait to see if it happens again.

-DJ PlaZma
Single-Handedly Keeping the 80s Alive!

http://www.PlaZmaRadio.com

 

[dufus2506]

The other thing I'd make sure is that the AVST has one, and only one, port setting and clearing MWI.

A station cannot clear LWC messages that are set by another station unless it has global message retrieval permissions. (Which would be an entirely different code string.) If you use LWC to set the MWI, you need to be sure that the same station that sent the LWC message is the same one that tries to clear it.

Yes, it may be a bit slower if there's a lot of MWI to set or clear, but designating one port to set and clear the MWI is the only way to be certain that they CAN be cleared.

Carpe dialem! (Seize the line!)

 

[telm59]

the AVST "remembers" the port used to set the mwi and uses the same port to clear. setting only 1 port for mwi could bring the system to its knees. Another option is QSIG integration.much faster than D82/84

 

[dufus2506]

I'd check on that "remembers" thing.

If you have LWC messages from multiple phone extensions, then it's not remembering too well.

If the port that sent the LWC message was in use (taking a message for example) then it couldn't be used to clear a LWC message. That would cause lots of help desk calls when message waiting lamps take 45-60 seconds to clear after hearing your messages.

In my experience, 1 port can handle many hundreds of users as long as you don't try to send broadcast messages. That would cause serious lag in updating MWI status.

Common MWI set and clear messages take only seconds to complete. Even if you had 48 ports in service, you're not looking at a lot of traffic for an MWI port.

Carpe dialem! (Seize the line!)