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

[Erick Bergquist]

In the failover configuration, you can also disable unity failing over
when it receives a call on the inactive node. By default this behavior
is enabled.


On Wed, Jul 15, 2009 at 9:43 AM, Lelio Fulgenzi<lelio at uoguelph.ca> wrote:
> It seems strange that Cisco would choose to use the port usage as a trigger,
> rather than a heartbeat or something. Minimally, since the backup system has
> SCCP ports, it could go into a "sanity check" mode as soon as it receives a
> call on one of it's ports. Before it triggers failover, it calls the ports
> on the primary system and sends some DTMF tones. If it gets the correct
> reply, it stays in passive mode.
>
>
> ----- Original Message -----
> From: Matthew Saskin
> To: Erick Bergquist
> Cc: cisco-voip at puck.nether.net
> Sent: Wednesday, July 15, 2009 10:33 AM
> Subject: Re: [cisco-voip] Port 2 has detected an incoming call. This
> systemis in inactive mode and is configured to fail over in thiscondition.
> 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
>
> ________________________________
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>