Unity MWI port 16 going bananas/balistic/out of control

[allan.wells]

The System is configured correctly 1000's of events are being written into event viewer see below. CPU hitting high 80%

Disabled port 16 in UTIM and every thing is ok will reboot box during a scheduled outage.

What could be the cause of this as it has been working for over a year

EVT_FAIL_MWI_OFF_COLLISION

ID: 128

Source: CiscoUnity_Tsp

Message: Cisco Unity-CM TSP device %1 (Cisco Unity port %2): An attempt to turn OFF the message waiting indicator (MWI) for extension %3 failed because a collision occurred with an incoming call on the same port.%n%nThe MWI request will be retried. But to prevent collisions, we recommend that ports setting MWIs be isolated from ports handling incoming calls. If the MWI status remains unchanged for an extended period of time or if there are many of these warnings from Cisco Unity in a short period of time, there may be an MWI misconfiguration or another problem.%n%nFor more information, refer to the "Message Waiting Indicators" chapter in the Cisco Unity Troubleshooting Guide.

Cisco Unity-CM TSP device %1 (Cisco Unity port %2): An attempt to turn OFF the message waiting indicator (MWI) for extension %3 failed because a collision occurred with an incoming call on the same port.%n%nThe MWI request will be retried. But to prevent collisions, we recommend that ports setting MWIs be isolated from ports handling incoming calls. If the MWI status remains unchanged for an extended period of time or if there are many of these warnings from Cisco Unity in a short period of time, there may be an MWI misconfiguration or another problem.%n%nFor more information, refer to the "Message Waiting Indicators" chapter in the Cisco Unity Troubleshooting Guide.

Thanks

Allan

[ranpierce]

MWI ports or out going calls are reccomeded to be on the last ports and incoming calls on the first ports. That way you can avoid a collision.

Depending on how many ports you have and how many incoming calls you have is how many ports you want to dedicate to outgoing. For instance I do 14 incoming to 2 outgoing.

rlp

[eschulz]

With Skinny signalling on the ports, actual collisions are nearly impossible. Instead, this error more likely means some other failure occurred. For example, if Unity failed to recieve dialtone or an offhook callstate when attempting an MWI call, then it might use this error message to report the failure. You may need to dig into some traces from CCM and/or Unity to understand what is going on.

-Eric

[MikeTomasko]

How many ports do you have total? How are your VM ports set to hunt?

[ranpierce]

I have 16 total

14 hunt incoming, 2 for outbound which includes MWI TRAP and Message Notification.

rlp

But read what Eric said. Although I have my questions about that. Eric knows far more about it than I do though. My question is why did Cisco recommend dividing the skinny ports until recently. Is it because of a newer TSP? Newer knowledge about skinny?

are you using ccm and skinny?

rlp

[eschulz]

Earlier versions of CCM could not pass MWI across ICTs. In those cases then the only way to provide centralized voicemail across multiple clusters was to have VM ports connecting directly to each cluster. I believe it is the Annex M1 tunnelling on H.323 trunks that opens up more options here.

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guide_chapter09186a00806e8c64.html#wp1046951

-Eric

[ranpierce]

Thx Eric, I just had a meeting with at Cisco SE that told me that all the ports could be incoming and outgoing in Unity 4.2.1 (we are upgrading from 4.0(5) and I was skeptical. But now reassured.

rlp

[ranpierce]

I have an idea for port 31. hold on.

rlp

[Jaime Valencia]

the recommendation about incoming outgoing ports is to have 20-25% of the ports dedicated to outgoing calls from unity and not to accept any incoming calls

to make sure of this disable those capabilities thru the UTIM and take the ports from the line group in CCM to avoid any accidental incoming calls

starting with TSP 8 if i recall correctly the behavior for the VM ports hunting changed from previous versions in which there was no a specific order in which to use them. starting on that release inbound calling is bottom-up (port 1,2,3,4,... etc) and outbound call top-down (port n, n-1, n-2, etc)

usually the last port from the integration is the one that sends the MWI for all users, unless it's incredibly busy and then unity may use other port to help on this

you might want to open the port status monitor to find out exactly to which subscriber is the mwi that fails and confirm or discard a collision

again, if the VM ports for outbound are not in the line group and have incoming calls disabled thru utim this scenario would seem unlikely

HTH