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 IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Octel 250 MWI Issue

Status
Not open for further replies.

mob46x

Technical User
Jan 30, 2004
24
US
I am trying to diagnose an Octel 250 rel. 02.01.05-1 with MWI problems. We are experiencing both stuck on and off lights. I checked the CDR and the Octel does not appear to be sending out a message to the switch to turn on the light (no event code 18). There is only one port designated to turn on the MWI’s and that’s it’s sole purpose. What are my other options? I included some possible relevant info below.

ACP Used for Integration: N
Type of PBX or Centrex VPMOD is on: F - PBX Integration Device / AT&T 85

Thank you...
 
is the port that is set for MWI taking any incoming calls ?

I would run a cdr trace on the mailbox that this is happining on and see when the last time the light was turned on and then look at the events after that to see if it ever tried to turn it off or on after that. How many users do you have on the system and how many ports as it could be a stacking problem with just one port.



Ken Means

 
This is happening on a larger scale and many users are affected. The CDR only goes back 2 days and this problem is older then that. We have 8 ports and only 1 is dedicated to MWI's with no other functions assigned. There are 122 MBX's built but in reality there are less then 60 users. I already tried 13.5 to turn the MWI's back on and that didn't work. What else can I check?

Thanks in advance...
 
The first question is whether there is no message waiting activity at all or if there is intermittent message waiting activity. If there is no message waiting activity then some things to check would be to make sure that the 1 port that is dedicated for message waiting is actally working. Maybe you could do the Port Testing utility in Menu 20 to check and verify that you have dial tone on that message waiting port.

Another simple thing to check for is to make sure that the amphenol connector is tightly secured to the FLT card. If port 1H is doing the message waiting the connector may have loosened up enough to cause a problem.

Hopefully that will give you a starting point. If it is intermittent problems then doing the CDR utility that Ken Means mentioned would be something to try. There must be a lot of activity in the voicemail if you can only go back 2 days. Maybe you could check and see what type of records you are collecting in the CDR database and possibly set them to No temporarily and just track one particular mailbox.

You could also look in the Avaya PBX and stat the station that is dedicated for message waiting to see what state it is in.

You could also try to busy out and release this station assuming you have sufficient privileges to do the busy-out and release in the Avaya PBX.

You could use the Review Card Management utility in Menu 13 in the Octel 250 to pop the FLT card out and re-insert to see if that does anything(remember that this will obviously stop the voicemail from answering calls for a few minutes while the FLT card is intializing).
 
The failure is constant. I will re-seat the card tonight and check the amphenol connector.
That port is not in the hunt group therefore we could not status that station. I thought this was the proper configuration. It did work at some point. Am I correct to assume this?
 
Another thing to check may be the Status Log to see if there are any errors that would point to a problem.

Just as a side note:

I have an Octel 250 system where there are 800 mailbox users and the CDR collection is set to Yes for everything except for line 10 Message Review. If I look at the Call Detail Recording Status the "CDR Disk Space Free" is at 0% with 7020 blocks setup for CDR. When I do a CDR trace I can go back about 3 weeks. It just seems that only going back 2 days would require a lot of activity.

 
Your right, the port should not be in the hunt group if it is dedicated for message waiting. I didn't think that this would stop you from doing a STAT STA XXXX from the Avaya PBX terminal though(unless maybe you don't have the right privileges in the Avaya PBX to do the command).
 
It turns out that another tech was in there without our knowledge and messed with the CDR feature (turned it off then on). We found two issues. First we realized that someone took the MWI port out of service and then the FLT card had to be reseated.

Thank you for all your help.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top