MWI stopped working, 1

[rejackson]

MM 5.2.1 on SIP to audocodes then QSIG to CM 6.3. MWI stopped out of the blue. Not working on any stations. Several different errors in operational history viewer. All seem to have something to do with Port 0 but I dont know what that is.

I have done the MWI data base rebuild and the FEDBsync but neither made a difference.

MWI request to 'Reset' the lamp has been called for extension: 101463 on port 0
WARNING NT significant event with ID '3221227238' was reported with strings 'Reset\n101463\nProxy/gateway temporarily unavailable\n'.

MWI request to 'Reset' the lamp has been called for extension: 101496 on port 0
MWI notification being sent to high-level component for extension 101486, error Reset, request Proxy/gateway temporarily unavailable from port 0
MWI request to 'Set' the lamp has been called for extension: 101497 on port 0
MWI notification being sent to high-level component for extension 101497, error Set, request Proxy/gateway temporarily unavailable from port 0

 

[kepetersen]

Port 0 in SIP is the MWI port.
Is this a multi-MAS system or single?
Looks like it is referring to the SIP gateway has unavailable.
Any reset changes on the switch or MM?

 

[rejackson]

It is a single MAS. Since we upgraded the CM in May we have been trying to get a direct SIP connection to it so during testing the BP would have me change the PBX config to point to the SM instead of the audiocodes. Then we change it back after testing. But we had not done any testing like that for 2 weeks when this problem started so the SIP IP address is the Audiocodes gateway. The ports to it are 1-23 and they function for the call traffic going through. Is there a distinct configuration item that would be port 0?

 

[KenMeans]

In the VMSC do you have an entry for the gateway and a PBX as well?

And are you using IP or name for the connection to the gateway. You said that you had been changing the connection between the Audiocodes and the CM so it may be that something is not set right or has been changed in the CM or the gateway.

You need to turn on the SIP trace in the VMSC so that it will put out detailed info on the SIP connection in the OHV.



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)

 

[rejackson]

Just a gateway titled audiocodes and with the IP address of the audiocodes device. During testing we would change the address to the SM. I hear you about the recent changes but nothing has been changed for 2 weeks.

I dont see anything for turning on SIP tracing in the Op hist viewer or VMSC. Where would that be?

 

[rejackson]

I found the sip trace info in another of your posts. Thanks Ken

 

[rejackson]

Ken,

It took a few tries but I finally saw sip traces by starting live capture first then turning them on. Nothing shows up that seems related to MWI. These traces do. I could not get it to export so I copied these one at a time. They were from an MWI process

MWI notification being sent to high-level component for extension 301179, error Set, request busy device from port 0
Socket connect timed out.
MWI notification being sent to high-level component for extension 101115, error Set, request Unknown error from port 0
MWI request to 'Set' the lamp has been called for extension: 301179 on port 0
MWI notification being sent to high-level component for extension 101383, error Set, request busy device from port 0

Other traces show SIP talk to the audiocodes so I sniffed the MAS ethernet interface and see a lot of talk to the audiocodes SIP address. Mostly UDP but some TCP and no apparent timeouts on any socket. It looks more like an internal process, whatever that high-level component is that is busy and returning unknown errors.

 

[KenMeans]

Has anything been changed on the T-1 Qsig side ? This is something that would happen if the qsig port was not open or available for outbound.

I will keep looking but if this was working and now it is not i don't think that it changed itself.



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)

 

[KenMeans]

Have you reset the gateway?

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)

 

[rejackson]

Yes I reset the gateway and MSS and MAS. Rebuilt the mdi data base and did the fedbsync. Everything else over the qsig is working which makes me think it is internal to the mas not a problem over the qsig.

 

[KenMeans]

I think it is a problem between the MAS and the gateway or the gateway and the PBX. If the MM is trying to send the MWI then it knows that it needs to be updated and is sending the command it always has. The rejection is come back due to the gateway /PBX not allowing it or that it is blocked in some way.

Did you say you are using TCP or TLS ?

If it is tls i would change it to TCP

With out having access to the system it is had to tell.

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)

 

[KenMeans]

if you can post some screen shots of the PBX setup and the SIP domain name.



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)

 

[ChuckRCT]

I'm not sure if this is your particular problem, but I've seen a similar problem on a couple systems at MM 5.2. When you change the SIP Gateway info sometimes the data is changed, but not removed from the VMD database. If you look at it in VMSC the Gateway info appears to be correct, but in reality you have additional Gateway info that doesn't display and has not been removed. I'd look at the traces as Ken suggests and just verify that the MWI SIP Notify messages are really going to the AudioCodes gateway and not something else that doesn't exist.

Chuck
RCT Technologies

 

[rejackson]

I figured this out, sort of, at least it is working again. I noticed that the session manager that was being used in our testing of the direct SIP link CM to MM without the audiocodes) was crashed or gone into standy mode. When I started it again and restarted MM for the 20th time MWI started working. I did a packet trace and can see the notifys going from the MAS to the Session manager. Even though all the other communication is going to the audiocodes. So after completing our testing and reverting back to the audiocodes link the MWI process is still using the Session manager address. That sounds like what Chuck was describing only it is just affecting the MWI process.

MWI problem resolved, 3 problems left.

1) The system is running split now with part of the connection using each path. Is there a rebuild/resync process for the VMD data base like I have been using on the MWI and FEDB?

2) The reason we have not cut over to the direct SIP connections is that the SIP history information is breaking the coverage for any call made by a vector. There is this string of history entries starting with the vdn that called the vector and the MM is using the first entry in the history for the mailbox lookup. I have seen posts about this problem but never saw any solutions. The BP is stumped. We applied all current SPs and patches to the MM, no help.

3) Our SIP trunk for CM is still being installed but I am worried about the stability of the SM. It is a HP DL360 G7 and from what I have read it seems like it is going into standby mode like an idle PC. The button is red/amber and when I press it, it starts answering pings pretty quick. I don't know what the OS is but it seems like something in the OS config is letting it go to standby when idle.

 

[KenMeans]

For item 2 how is the call getting to the vdn?

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)

 

[rejackson]

The call goes to vdn from incoming call treatment on a trunk. The vdn can also be dialed directly and the same thing happens. The vdn goes to a vector. In the vector the option to enter extension works but if it rolls to voicemail it uses the number of the VDN and doesn't find the mailbox. Option to dial by name should go to a caller app at ext 100057 but it doesn't.

 

[rejackson]

This closed thread describes the same problem

thread1496-1651135

The sip trace from the session manager has
100005 - the vdn
101348 - my extension which is the account it should have gone to
100081 - the voicemail hunt group extension

The OHV on MM shows the call was to 100005.

I think its a CM problem but because of the MM involvement I thought their MM threads could help.

 

[ChuckRCT]

Check out the Avaya Configuration notes for the MM with SM Section 8 Considerations / Alternatives:

Called party information is not identified by MM in certain call scenarios such as when using vectoring.

This was corrected in Avaya CM 3.1.4 and CM 4.0.1; corresponding changes were made in the minimum required MM release as noted in Section 2.0.
If you are integrating to an Avaya CM 3.1.4 (or later) or CM 4.0.1 (or later) you need to activate the necessary features in the Modular Messaging System to support these releases. On MM go to C:\Avaya_Support\Registry_Keys on each MAS and double-click on the file “CalledPartyAlgorithm-New1.reg.”

MAS services must be restarted for it to take effect. This will change the way MM reads the SIP History Information records used to integrate the call.

Chuck
RCT Technologies

 

[rejackson]

Wow Chuck thanks. It described our problem exactly. It took a while to get time t test it but I did it last night and the cover is going to the correct MM account now. The register change in the Avaya support directory is dated from 2008. It really hard to believe our BP didnt have any knowledge of it.

Thanks again

 

[KenMeans]

I had forgotten all about that.

It's funny but years ago people were upset that it did not work like that. As it would go to the mailbox of the last number it hit and not the first (Called Party) number.

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)