[cisco-voip] FW: Unity Failover and PIMG Integration question
Zachary Gillman (US)
Zachary.Gillman at us.didata.com
Tue Dec 18 16:00:25 EST 2007
We contacted Cisco SE on this account and here is the response:
Here is what I received back from my Unified Communications group.
Tell them to uncheck the box "Failover if a call arrives on an inactive
secondary server".
TAC will still support them.
Thanks,
Zack
-----Original Message-----
From: Pat Hayes [mailto:pat-cv at wcyv.com]
Sent: Friday, December 14, 2007 8:06 AM
To: Zachary Gillman (US)
Cc: cisco-voip at puck.nether.net; Robert Volta (US)
Subject: Re: FW: [cisco-voip] Unity Failover and PIMG Integration
question
Comments inline:
-------- Original Message --------
From: "Zachary Gillman \(US\)" <Zachary.Gillman at us.didata.com>
To: pat-cv at wcyv.com
Cc: cisco-voip at puck.nether.net, "Robert Volta \(US\)"
<robert.volta at us.didata.com>
Subject: FW: [cisco-voip] Unity Failover and PIMG Integration question
Date: 12/13/2007 9:03 AM
> <snip>
>
>
>
> As we tested, the PIMG will route the call to the secondary server
> only when unreachable via ip. It didn't seem to have state awareness
> of the failover pair or the av-services. As long as you could ping
> the primary Unity server, it was attempting to route to the primary.
> When we manually failed over, we received a busy from the Nortel/Pimg
> call attempt. When we disable the switchport that the primary
> connects to, it fails over just fine. The IP phones do work when
> manually failing over and back. This is a PIMG and CallManager
> integration. The failover monitor will failover if a call lands on an
> inactive secondary if its a PIMG call or a CCM call.
>
<ph> You're correct in that the PIMG doesn't directly monitor any
services in Unity. It does, however, monitor whether or not the primary
answers it's sip messages, as well as send keep alives. If those fail,
after a configurable amount of time, it will switch to the backup. Do
keep in mind that it needs to time out once, so the switchover won't be
immediate. If you're not seeing that happen in all circumstances, I'd
assume that you missed a setting or two from the integration guide. Most
of the settings around this are on the SIP and Gateway Advanced pages,
might want to double check. Failing that, since it is all SIP message
based, it should be easy enough to see what is going on in each case and
why by reviewing who sends and responds to what messages. Just enable
the voip traces on the PIMG, they'll show you the messages in both
direction in a fairly easy to read format.
> <snip>
>
>
>
> There is a checkbox to automatically failover and there is a seperate
> checkbox to failover when the secondary receives a call. I agree with
> you if you don't check the first one, that defeats the purpose of
> failover. We are talking about the second option to failover if a
> call is received on an inactive secondary server.
>
<ph> I'm aware you're talking about the option to failover upon
receiving a call on the failover. I don't think it'll bother anyone if
you leave it off, but that'll keep you from automatically failing over
in conditions where the primary is still 'up', but won't answer calls.
>
> <snip>
>
>
>
> We ran into a situation where we maxed out the CCM ports, received a
> call on the inactive secondary, it failed over, the PIMG had
> connectivity to the Primary, tried to route calls to it, and failed.
>
<ph> If you're maxing out the CCM ports, then the integration is
under-sized. If it was a rare situation and folks are that worried about
it triggering a failover, you can set the busy action on your line group
to try next member, but do not try next group.
>
>
>
> <snip>
>
>
>
> Again, it was the CCM that invoked the failover.
>
Keep in mind that, in this case, it's going to take the PIMG a little
while (based on config) to give up on the primary and start sending
calls to the failover.
-----------------------------------------
Disclaimer:
This e-mail communication and any attachments may contain
confidential and privileged information and is for use by the
designated addressee(s) named above only. If you are not the
intended addressee, you are hereby notified that you have received
this communication in error and that any use or reproduction of
this email or its contents is strictly prohibited and may be
unlawful. If you have received this communication in error, please
notify us immediately by replying to this message and deleting it
from your computer. Thank you.
More information about the cisco-voip
mailing list