Solved: unity 7 failover

nixon1234 · ‎04-24-2009

Get message on the failover server port 12 has detected an incoming call. The system is in inactive mode and is configuered to fail over in this condition. Fail over to this system will occour, and the call will be answered.

We have 60 ports and we have never been close to exceeding the limit there..any ideas?

Tray Stoutmeyer · ‎04-24-2009

So far most of the comments seem to come from a CUCM perspective and they are correct. Phones should not be in a partiion or calling search space that can call any voicemail port dn numbers. The fact that the call that was detected is not on port 1 initially looks like this may be the case. Normal failover should hit port 1 on the failover server and be detected there. Anything hitting a port other then port 1 would be suspect as being a direct call. If CDR doesn't show anything around the time of the failover, set these traces on Unity for both the primary and secondary for the next failover.

MACRO:

Call Flow

Call Control

TSP

Collect on the back end after a filover from both server the following traces.

AvCsMgr

SvcHost

Also get the Gather Unity System Info cab file

To do this, go to your Unity Tools Depot and double-click the Gather Unity System Info (GUSI) under Reporting Tools. Click save to file to get the .cab formatted file. I would then open a case with TAC to have the traces looked at. Usually we can determine if it's a direct call by looking at the svchost trace from the failover server during the time of failure. We will find a line that says "Call matched a voicemail port, chaning call to direct." If so it's a dead ringer for bad CSS and partitions on your phone allowing that type of call to happen.

Tray

Thank You,

Tray

View solution in original post

Jaime Valencia · ‎04-24-2009

i'd try checking CDR, the best practice is a phone should not be able to dial directly a VM port but many guys do not follow this and maybe someone dial it by mistake

HTH

java

if this helps, please rate

HTH

java

if this helps, please rate

nixon1234 · ‎04-24-2009

This has happened 3 or 4 times this month and they are usually different ports..

Where in the CDR?

Tray Stoutmeyer · ‎04-24-2009

So far most of the comments seem to come from a CUCM perspective and they are correct. Phones should not be in a partiion or calling search space that can call any voicemail port dn numbers. The fact that the call that was detected is not on port 1 initially looks like this may be the case. Normal failover should hit port 1 on the failover server and be detected there. Anything hitting a port other then port 1 would be suspect as being a direct call. If CDR doesn't show anything around the time of the failover, set these traces on Unity for both the primary and secondary for the next failover.

MACRO:

Call Flow

Call Control

TSP

Collect on the back end after a filover from both server the following traces.

AvCsMgr

SvcHost

Also get the Gather Unity System Info cab file

To do this, go to your Unity Tools Depot and double-click the Gather Unity System Info (GUSI) under Reporting Tools. Click save to file to get the .cab formatted file. I would then open a case with TAC to have the traces looked at. Usually we can determine if it's a direct call by looking at the svchost trace from the failover server during the time of failure. We will find a line that says "Call matched a voicemail port, chaning call to direct." If so it's a dead ringer for bad CSS and partitions on your phone allowing that type of call to happen.

Tray

Thank You,

Tray