[cisco-voip] Port 2 has detected an incoming call. This system is in inactive mode and is configured to fail over in this condition. Fail over to this system will occur, and the call will be answered.

Wed Jul 15 13:33:59 EDT 2009

Thank you.  Where is that setting adjusted?  What menu/interface?

Steve Miller
Telecom Engineer
Dickstein Shapiro LLP
1825 Eye Street NW | Washington, DC 20006
Tel (202) 420-3370| Fax (202) 330-5607
MillerS at dicksteinshapiro.com 

________________________________

From: Matthew Saskin [mailto:msaskin at gmail.com] 
Sent: Wednesday, July 15, 2009 10:34 AM
To: Erick Bergquist
Cc: Miller, Steve; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Port 2 has detected an incoming call. This
system is in inactive mode and is configured to fail over in this
condition. Fail over to this system will occur, and the call will be
answered.

There are also a few defects out there (CSCsc62073 is a feature request
I believe) where even though all primary unity ports aren't busy if they
don't respond for any particular reason the call will hunt across all
entries in a line group and move on the next line group (secondary unity
server).  If the call failures are caused by a condition such as
location out of bandwidth, and not by the unity server not answering,
this could lead to an unnecessary failover if bandwidth becomes
available and the call is allowed to route once the system is routing it
through the secondary line group.  

"Fix" for this scenario is an adjustment to the "stop routing on out of
bandwidth flag" service parameter.  Default is false, setting it to true
will "fix" this scenario.

As odd as it seems, I've seen it affect quite a number of my customers.

-matt

On Tue, Jul 14, 2009 at 11:02 PM, Erick Bergquist <erickbee at gmail.com>
wrote:

	You need to put all your voicemail ports in a partition that no
CSS
	has access to, and just make sure the voicemail pilot # and
associated
	hunt pilot is in a partition phone DNs/etc have access to with
another
	CSS. There are no changes that need to be made in Unity.

	I usually just put the voicemail ports in a partition called
	VoicemailPorts (or similar).

	I recently did this on a 6.1.x system to fix this problem, and
when I
	went under the VM port setup to change the partition the Line
group
	updated itself so I didn't have to change the line groups
afterward
	either.

	The only time one needs to dial a VM port DN directly is for
some
	advanced troubleshooting scenario and you can put a CSS on a
test
	phone to do that if that need ever comes up.

	On Tue, Jul 14, 2009 at 3:13 PM, Miller,
	Steve<MillerS at dicksteinshapiro.com> wrote:
	> A call seems to have arrived at a time when it would be
impossible for the
	> Primary Unity system to be busy.  How do I prevent this call
from hitting
	> the secondary and forcing a failover as it did?
	>
	>
	> Steve Miller
	> Telecom Engineer
	> Dickstein Shapiro LLP
	> 1825 Eye Street NW | Washington, DC 20006
	> Tel (202) 420-3370| Fax (202) 330-5607
	> MillerS at dicksteinshapiro.com
	>
	>
	>
	> --------------------------------------------------------
	> This e-mail message and any attached files are confidential
and are intended
	> solely for the use of the addressee(s)
	> named above. This communication may contain material protected
by
	> attorney-client, work product, or other
	> privileges. If you are not the intended recipient or person
responsible for
	> delivering this confidential
	> communication to the intended recipient, you have received
this
	> communication in error, and any review, use,
	> dissemination, forwarding, printing, copying, or other
distribution of this
	> e-mail message and any attached files
	> is strictly prohibited. Dickstein Shapiro reserves the right
to monitor any
	> communication that is created,
	> received, or sent on its network.  If you have received this
confidential
	> communication in error, please notify the
	> sender immediately by reply e-mail message and permanently
delete the
	> original message.
	>
	> To reply to our email administrator directly, send an email to
	> postmaster at dicksteinshapiro.com
	>
	> Dickstein Shapiro LLP
	> http://www.DicksteinShapiro.com
	>
	>
========================================================================
======
	>

	> _______________________________________________
	> cisco-voip mailing list
	> cisco-voip at puck.nether.net
	> https://puck.nether.net/mailman/listinfo/cisco-voip
	>
	>
	_______________________________________________
	cisco-voip mailing list
	cisco-voip at puck.nether.net
	https://puck.nether.net/mailman/listinfo/cisco-voip

--------------------------------------------------------
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s)
named above. This communication may contain material protected by attorney-client, work product, or other 
privileges. If you are not the intended recipient or person responsible for delivering this confidential
communication to the intended recipient, you have received this communication in error, and any review, use, 
dissemination, forwarding, printing, copying, or other distribution of this e-mail message and any attached files 
is strictly prohibited. Dickstein Shapiro reserves the right to monitor any communication that is created, 
received, or sent on its network.  If you have received this confidential communication in error, please notify the 
sender immediately by reply e-mail message and permanently delete the original message. 

To reply to our email administrator directly, send an email to postmaster at dicksteinshapiro.com

Dickstein Shapiro LLP
http://www.DicksteinShapiro.com

==============================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090715/5913ad43/attachment.html>