Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

MWI issue comes and goes?

Status
Not open for further replies.

WideTrac

IS-IT--Management
Oct 23, 2003
56
US
OV250 system integrated with a AT&T switch using FLT-A cards.
We have users that the MWI stops working. The OV250 is not sending the Set/Clear command. We must delete and rebuild the users Mbx to get the MWI working again.
We have tried turning the MWI's "Off"-"On" using the Octel but it does not fix the issue.
This system is integrated with several switchs, all switches are AT&T Definty, cn:5400

Any ideas?
 
Are you using the option to turn all lights off in the reformat menu?

Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
We have tried that option and the users MWI did not start working. This happens about every few days to a couple weeks when two to three users have there MWI's stop working for no reason. So far the only fix is to rebuild the mailbox and that does not go over to good.
The system has been checked and has no errors at the time, validity test and drive verify passed.
 
Just to clear on this the Octel is hooked to a AT&T PBX that is using DCS to other AT&T PBX's. Or are you using QSIG? And then out of the blue the MWI stops working on a mailbox and you can't see it even trying to turn the light on or off in the online CDR?

If the Reformat option 8 sub menu 3 "Turn off all message waiting indicators" is used and a subscriber is allowed to enter their mailbox to delete a message or another user is allowed to send a new message to a mailbox before the Menu 13 "Turn Message Waiting Indicators Back On" is allowed to be done, then message waiting will stop working on these mailboxes.

Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
Is this a new install? or was it working and then it stopped?

Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
The system has been installed for a long time. The MWI issue has been going on for some time and has an issue about two to three times a month. The Octel just forgets the users has the MWI set to "Y" and just stops sending the set/clear command.
 
Do you have more than one MWI port and do they take calls or not

Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
Also if you use menu 9 to turn off the MWI by saying no to MWI do you see an event in the CDR? and also one when you turn it on. This should show a event 18 in the CDR when it is turned off even if it thinks the light is already off.

I have looked at my notes and do not see anything that matches this to a "T" but I am not familiar with your site so there could be more info I am missing.

I have seen things like this before but not just like this. Have you run a garbage collect on the system?

Has TAC looked at this ?


Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
Six MWI ports are set for MWI and are not dedicated ports
The Mbx has been toggled in Menu 9 but no activity seen in the CDR, 18, trace. The only way to get the MWI back for the user after the system forgets about it, is to rebuild the Mbx.
Garbage collect has been ran.
I have not involved the TAC but if it continues I will give them a call.

 
How many users are on the system? 6 MWI ports seems like way to many. We have systems with 5000 plus users with 2 MWI ports.

What may be occurring is a mwi port is trying to set a message and the port in the MWI table it is picking is in use. If the port is still in use after the buffer is full then it will lose the info and the light will not come on. That is why CN 5400 strongly recommends you use dedicated MWI ports. That way the MWI set or reset command is not lost if the port is in use by a user in their mailbox for a long time.

Have you run the reformat option to fix the MWI port tables?

Just me but I would immediate change the MWI ports to be dedicated as soon as possible and see if that makes the problem go away. You may also want to consider reducing the number of MWI ports.

Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
The system would give you a failure code if the MWI did not go out because of the Line Seize Failure.
If the ports are not dedicated then the MWI will just slow down under heavy traffic.
We are loosing the user sofware configuration that tells the system the user has MWI capabilities. All other users work fine when this issue occurs.
It is a random user issue and not the same user every time.
 
dedicate your MWI ports, run the procedures Ken mentioned to get that done. One or two MWI ports is all you will need. TAC will make a very strong suggestion to do that before they try and help, if they even attempt to help once they here you don't have dedicated MWI ports
 
Dedicated ports is not the issue here. The issue is system droping MWI activity on a users mailbox.
TAC will not be called anyway
I will not be back on this one until Monday. Got to go fishing :))
 
You say that dedicated ports are not the issue but I can tell you from years of working on these systems that I very well may be the issue. Also MWI would not slow down as the ports only job would then be to turn the light on and off and not take calls on top of the MWI commands.

You also said that the problem has always been in the system and presumably over many software upgrades.

So the only constant is the fact that the MWI ports are not dedicated.





Ken Means

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)
 
Not just the same product, but maybe this text can give you some ideas...
We have seen this also on OCTEL 200/300's.
One of the cases was solved due to the missing grounding between the PBX and the OCTEL 200.
An electrician has remowed the common grounding between the PBX and the OCTEL on the same day we upgraded the OCTEL. Therefore it was NOT easy to point out where the fault was. After the grounding was reconnected the OCTEL 200 (using SIC-8 integration board towards a Nortel PBX) again could turn on MWI lamps and turn them off after the meassages had been listened to.
///doktor
 
We will give it a try and see what happens, hey I am game for anything and I am sure the customer just wants the MWI working correctly.
 
if you are game for anything, try dedicating your MWI ports like both Ken and I have suggested. It might just work and you will be the hero in your customers eyes.


 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top