MWI Help

[wpetilli]

I've seen many threads on issues related to this, but not usually in this order so i'm in need of some guidance.

I have a MM3.1 (2mas/1mss) via QSIG/DS1 connections in regional hub A. In addition to this CM there are other LSP sites also hung off this hub CM. There is also another regional hub B CM that connects to hub A via QSIG/H.323 trunks. Hub B has several LSP sites as well using the MM in hub A. We are seeing issues where MWI comes on with the onset of a new msg (normal); However, within 20-30 minutes the light goes off w/o the user listening to the msg. This is happening to users hung off of hub B. OPHV shows MM sending the order to light the light (3X actually), but there is no msg from it telling it to take the light away. In the MWI DB the msg lamp shows as on, so I'm not sure why these user phones are losing the light.

Any ideas on what to try or where to look deeper at this? Also, what is the actual path the MWI takes from MM down to the user phone?

 

[KenMeans]

Are the users that are having this issue new on the MM or have they been using it for some time ?

I am asking as the old VM (If there is one) may be sending the command to turn it off.

Ken Means

http://www.tel-is.com

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)

 

[wpetilli]

No, they aren't new. I just can't figure out what is triggering the light to go out on these users. I mean the MM is definitely overdue for a reboot, but I'd imagine this would be way more widespread than this one set of folks. I was going to blow away the mailbox/extension, but the fact it's not just happening to one person makes me not want to go that route. Does the MWI take the same path through the network as a standard audio call (traverses the IP trunks etc.. and follows CAC in a NR)? The private unknown numbering tables have the necessary entries.. I just can't see how this is happening.

 

[KenMeans]

i'm not sure the the path is relevant it simply uses the data channel for the Cusick however if it turns the light on and the light is been turned off then the issue isn't with the path at all. If you doing MWY refresh does the light come back on

Ken Means

http://www.tel-is.com

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)

 

[wpetilli]

There was some utility on the MAS.. forgot exactly, but it opened up and let you input an extension and gave an option for on/off. After the light had gone out and with the new messages sitting there we flagged to on. The light came back on, but went out again within 15 mins or so.

 

[KenMeans]

Clearly it is not the MM doing this. If the lamp is on and the MM is not sending the off command I am not sure how the CM or gateway could turn it off. I assume that if you stat the station it shows that the light is on from QSIG right?

Are you the only one that works on the telecom in this environment ?

I swear the only thing that can really do that is a different VM system. I have seen it many times. Hard to say at this point without doing a mst on the station.





Ken Means

http://www.tel-is.com

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)

 

[wpetilli]

I haven't traced the station and can almost 99% guarantee there's no legacy audix out there. If you status the station the msg is not there when the light goes out. And I tend to agree that I don't see mm sending the turn off notification.
It's not the GW since all the phones are registered up to the main procr. I will do a full end to end trace tmrw.

 

[wpetilli]

I went into subscriber options of the user and flagged off MWI and flagged it back on. The light came back on the user phone and then I did a list trace stat xxxx/q, waited the usual 15 mins or so and the only thing that showed up in the trace was:

10:58:16 rcv GRQ ext 7237
endpoint [10.192.208.56]:49300
switch [10.192.222.70]:1719
10:58:16 snd GCF ext 7237
endpoint [10.192.208.56]:49300
switch [10.192.222.70]:1719
10:58:16 rcv RRQ ext 7237
endpoint [10.192.208.56]:49300
switch [10.192.222.70]:1719
10:58:16 denial event 1934: IP RRJ-Ext already reg
endpoint 10.192.208.56 data0:0x8b89
10:58:16 snd RRJ ext 7237
endpoint [10.192.208.56]:49300
switch [10.192.222.70]:1719


Not really sure what those messages mean, or if they are related to MWI

 

[KenMeans]

It looks like something is trying to register the sta and it is already registered.

If it registers it again it may negate that MWI at that time.

Ken Means

http://www.tel-is.com

"I find that the harder I work, the more luck I seem to have."
- Thomas Jefferson (1743-1826)

 

[wpetilli]

Hmmm.. I shut that switchport for now. Not sure that event is related, but.. I went on the MAS and ran the MWIQSIG.exe utility.. not sure if you've ever seen it, but it pops up a box with an extension field, the choice between T1 or E1 and MWI on or off. I put in the user extension, chose E1 and clicked MWI on. I status's the station of the user with the messages and the light came back on and has stayed on. I guess he'll have to log in, clear the msg's, ensure the light goes out and start over again. Other than that I see nothing out of the ordinary. The servers haven't been rebooted since 2/21, so the next step is to schedule a reboot.