AvMiu_MC failure on MWI CM3.2.2{C} VM3.1.5

[douglas.heppler]

I get a port failure and reset when turning the MWI on and off. It still seems to work now and then even though the warning messeges in the event viewer say the port failed. Looks like the port trying to turn on or off the lamp tries and fails and reconnects to CM. Sometimes the lamp goes out sometimes not?

Error messages as follows :

Component Miu : Thread 0x00000A4C had a failure on Port 4 in Method CAvTSP abstraction: Selsius_SetMWI{}

DESCRIPTION HardFailure from line DevSpecific

DETAILS:

DestAddress: 2000

Messages: 0

State: OFF

ErrorCode: 0x00000102

Next error code reads:

Failed to set message waiting lamp for {username} ext 2000, switch 0. cluster 0, reason SetMWI failed with 0x80004005

Your thoughts would be greatly appreciated.

Doug Heppler

Bell Canada

[oliviers]

That "102" is a timeout, and that timeout is probably a timeout that happens after the TSP dials the MWI DN. The TSP is waiting for a specific skinny message to come back from CCM after dialing the MWI DN.

Is there any chance that the MWI DN overlaps with another dial pattern? What is the MWI DN?

We can start by looking at the AvSkinnyTSP traces when this happens. If you can set all of them with the exception of "keepalives", repro the problem and then post those traces, I can take a look.

This would show the skinny communication b/w Unity and CCM for that MWI.

[douglas.heppler]

Hi,

Thanks for responding, My MWI DN for on is 4001 and 4000 for off. As far as I know I have no overlapping dial pattern. I have no dial pattern set up for internal DN's, they work fine between extensions. Do I need to create a pattern for the internal DN's and MWI DN's?

Attached is the log file I created, not sure if I did it correctly but I can see the errors.

Doug

Moderator Note:

Trace removed due to size.

[oliviers]

Those are the AvCsMgr traces. We'll need to look at the AvSkinnyTSP traces with the AvSkinnyTSP diagnostics enabled.

[douglas.heppler]

Sorry I'm taking so long, first time in the log file generator tool.

I've hopefully got the log file your looking for this time.

Doug

Moderator Note:

Trace removed due to size.

[oliviers]

13:36:53:719 (CiscoUnity_TSP,116,SkinnyTSP,11) [Thread 0x0000065C] [Device 8] TSPI_lineDevSpecific hdLine 20867880.

13:36:53:718 (CiscoUnity_TSP,116,SkinnyTSP,18) [Thread 0x0000065C] [Device 8] CAvTapiLine::SetMwi: szExtension 2000 fMWIon 1.

13:36:53:719 (CiscoUnity_TSP,116,SkinnyTSP,21) [Thread 0x0000065C] [Device 8] CSkinny::SetMWIOn szMWIOn szExtension.

13:36:53:718 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x0000065C] [Device 8] CSkinny::SendOffHookWithCgpn 2000.

13:36:53:719 (CiscoUnity_TSP,116,SkinnyTSP,21) [Thread 0x0000065C] [Device 8] CSkinny::GenerateDigits 4001 No Delay.

13:36:53:718 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x0000065C] [Device 8] CSkinny::GenerateDigit: button = 4.

13:36:53:719 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x0000065C] [Device 8] CSkinny::GenerateDigit: button = 0.

13:36:53:718 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x0000065C] [Device 8] CSkinny::GenerateDigit: button = 0.

13:36:53:719 (CiscoUnity_TSP,116,SkinnyTSP,13) [Thread 0x0000065C] [Device 8] CSkinny::GenerateDigit: button = 1.

13:37:23:718 (CiscoUnity_TSP,116,SkinnyTSP,16) [Thread 0x00000838] [Device 8] CAvSkinnyController::WaitForEvent signalled LineTimer.

Yup, it's a timeout. Above here, it shows that after dialing the MWI, it has waited 30 seconds for the skinny message that it wants; it never got it. The TSP is waiting for the "proceed" skinny call state message to come back after dialing that MWI DN.

I guess it's off the CCM logs to see why that message isn't coming back. Or, if it is an overlapping dial plan, and the digit "#" is a terminator for a dial string, you could try changing the MWI settings on Unity's TSP to be 4000# and 4001#. That'll require a restart of Unity.

[douglas.heppler]

Great... Thanks! Ok a timeout because Call Manager isn't responding to the TSP as I understand it. I've set the TSP's to be 4000# and 4001# and rebooted the system but I still get the same events. FYI, One time all the configured ports disconnected and reconnected {all four, only four configured so far} but mostly it seems the last two ports 3 & 4 disconnect. I assume that Unity goes to the last port to do MWI {4 in my case} and goes to 3 when it can't find port 4.

Since I'm in the primary build phase, I have only two dial patterns created :

9.1XXXXXXXXXX

9.XXXXXXXXXX

I'll try to look at the Call Manager logs and see if I can get some info there

Thanks,

[douglas.heppler]

I've looked into the Call Manager logs and I found the following:

------------------------------------------------------------------------------------------

03/18/2003 16:44:14.803 Cisco Messaging Interface|kVMDNConfigurationError - Voice-mail DN for CMI invalid. Invalid VoiceMailDN: App ID:Cisco Messaging Interface Cluster ID:ccm-Cluster Node ID:ccm|<:CCM-CLUSTER><:CCM><:ALARM>

------------------------------------------------------------------------------------------------

I've deleted all 4 Voice Mail ports in CM and created 8 new ones {used to have 4}. I still get the last two ports disconnecting, port 8 and 7 now instead of 3 & 4

[oliviers]

That diag makes me think that the CMI is installed and configured on CCM. For Unity's use, it shouldn't be.

[douglas.heppler]

There was a default CMI set up in Call Manager and I deleted it. Rebooted both the Unity and Call Manager, still getting the same warning in event viewer {ports disconnecting} however the MWI lights seem to turning on and off everytime regardless.

You can dial the MWI DN from a phone and turn on and off the MWI manually, this should rule out a dial pattern issue.

Any Ideas?

[douglas.heppler]

Watching the Unity Status Monitor, port monitor as I leave a message: I see port 1 answer the voice mail call then I see port 8 dialing the MWI and I see the light come on the phone. The port monitor keeps going for the full 30 seconds on port 8 even though the lamp has come on the phone, it stops and a few seconds later it tries to dial the MWI again on port 8 even though the lamp has been lit.

It's as if Unity has called the MWI DN and Call Manager has lit the lamp but Unity doesn't know this and keeps trying again and again to light the lamp?

[oliviers]

Sounds like that "proceed" skinny message still is not coming back. Do the CCM and AvSkinnyTSP diagnostics look the same as when the CMI was enabled?

[douglas.heppler]

After I removed the Call manager CMI configuration, I can't perform that trace as it's no longer an option. I've attached a new AvSkinnyTSP log.

Thanks,

Doug

Moderator Note:

Trace removed due to size.

[kthorngr]

oliviers is correct in that CMI is not used for Unity - Please disable this service. Hopefully disabling this service will solve the timeout issue.

What oliviers is looking for is detailed Cisco CallManager (ccm) traces to correspond with the AvSkinny traces. We need to see why CallManager is not send the call proceeding signal back to Unity for sucessful MWI. A snippet of the MWI setting from both servers would be useful.

when you dial the MWI on DN from the phone, does the light turn on right away or does it take around ten seconds?

[douglas.heppler]

Hello,

I've tried deleting the CMI from CM and rebooted both the Call Manager and the Unity servers and I have the same trouble.

Can you provide me with more direction on which trace is required from the Call Manager as with the CMI deleted that trace is no longer an option in Call Manager?

I'll post you the information from the MWI settings from both servers later. I've gone over those settings a few times and researched settings info on the Web but they seem ok.

Most times the MWI light comes on right away once the message is sent but the odd time it does take a few seconds {5-10}. The odd time it does not light at all, more often if there is an issue, it's because te MWI light won't go out after you clear the messages. When this happens and I send a new message and clear that one the light will go out. Also, you can turn it off and on no problem by dialing the MWI DN's.

Thanks,

Doug