unity 7 failover

Answered Question
Apr 24th, 2009
User Badges:

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?

Correct Answer by Tray Stoutmeyer about 8 years 3 months ago

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


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Jaime Valencia Fri, 04/24/2009 - 07:46
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    2011

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

nixon1234 Fri, 04/24/2009 - 07:58
User Badges:

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

Where in the CDR?

Correct Answer
Tray Stoutmeyer Fri, 04/24/2009 - 08:52
User Badges:
  • Cisco Employee,

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


Actions

This Discussion