Cisco Cisco IPCC Web Option Fascicule
3-40
Cisco Unified Contact Center Enterprise 7.5 SRND
Chapter 3 Design Considerations for High Availability
Peripheral Gateway Design Considerations
•
The paired-disabled side (side B in most cases) transitions to an isolated-disabled state. This side
will then check for device majority. If it is not communicating with either an Active or Idle DMP to
more than half of the configured PGs in the system, it will stop processing and stay disabled.
will then check for device majority. If it is not communicating with either an Active or Idle DMP to
more than half of the configured PGs in the system, it will stop processing and stay disabled.
•
If the B-Side has device majority, (an Active or Idle connection to more than half the configured
PGs), it will transition to a "Testing" state and send "Test Other Side" (TOS) messages to each PG.
This message is used to ask the PG if it can see the Call Router on the other side (in this case,
Router A).
PGs), it will transition to a "Testing" state and send "Test Other Side" (TOS) messages to each PG.
This message is used to ask the PG if it can see the Call Router on the other side (in this case,
Router A).
•
As soon as any (even one) PG responds to the TOS message that the A-Side is still enabled, Router B
remains in the Isolated-Disabled state and goes idle. Logger B will also go idle, as will all the DMP
connections to the PGs for Router B. All call processing will continue on Side A without impact.
remains in the Isolated-Disabled state and goes idle. Logger B will also go idle, as will all the DMP
connections to the PGs for Router B. All call processing will continue on Side A without impact.
•
If all of the PGs reply that Side A is down, or not reachable, the B-Side Call Router would
re-initialize in simplex mode (isolated-enabled) and take over all routing for the Unified ICM.
re-initialize in simplex mode (isolated-enabled) and take over all routing for the Unified ICM.
•
There is no impact to the agents, calls in progress, or calls in queue. The system can continue to
function normally; however; the Call Routers will be in simplex mode until the private network link
is restored.
function normally; however; the Call Routers will be in simplex mode until the private network link
is restored.
Additional Considerations
The Call Routers are "paired" with the Loggers and can read/write only to their own Logger for
configuration and historical data over the Private Network locally. In the event that the failure is caused
by the loss of a Private NIC card in the Call Router, and that Call Router is the enabled side, it will not
be able to write any historical data to the Logger nor will any configuration changes be able to be made
to the Logger database.
configuration and historical data over the Private Network locally. In the event that the failure is caused
by the loss of a Private NIC card in the Call Router, and that Call Router is the enabled side, it will not
be able to write any historical data to the Logger nor will any configuration changes be able to be made
to the Logger database.
The Private NIC in the Call Router is also used in some cases to communicate with carrier-based
Pre-Routing Network or SS7 interfaces. If the Private NIC fails, there would be no way to access these
services either.
Pre-Routing Network or SS7 interfaces. If the Private NIC fails, there would be no way to access these
services either.
If there are an even number of PGs checked off in the Call Router Setup, and only half of the PGs are
available, then only Side A will run. For the B-Side to be operational during a private network failure,
it must be able to communicate with more than half of the PGs in the system.
available, then only Side A will run. For the B-Side to be operational during a private network failure,
it must be able to communicate with more than half of the PGs in the system.
It is important to maintain the configuration so that "extra" PGs or PGs that are no longer on the network
are removed from the Call Router Setup panels to avoid problems with determination of device majority
for PGs that no longer exist.
are removed from the Call Router Setup panels to avoid problems with determination of device majority
for PGs that no longer exist.
If the private network fails between the Unified CM Peripheral Gateways, the following conditions
apply:
apply:
•
The Peripheral Gateway sides detect a failure if they miss five consecutive TCP keep-alive
messages, and they follow a process similar to the Call Routers, leveraging the MDS process when
handling a private link failure. As with the Central Controllers, one MDS process is the enabled
synchronizer and its redundant side is the disabled synchronizer. When running redundant PGs, as
is always recommended in production, the A side will always be the enabled synchronizer.
messages, and they follow a process similar to the Call Routers, leveraging the MDS process when
handling a private link failure. As with the Central Controllers, one MDS process is the enabled
synchronizer and its redundant side is the disabled synchronizer. When running redundant PGs, as
is always recommended in production, the A side will always be the enabled synchronizer.
•
After detecting the failure, the disabled synchronizer (side B) initiates a test of its peer synchronizer
via the TOS procedure on the Public or Visible Network connection. If PG side B receives a TOS
response stating that the A side synchronizer is enabled or active, then the B side immediately goes
out of service, leaving the A side to run in simplex mode until the Private Network connection is
restored. The PIM, OPC, and CTI SVR processes become active on PG side A, if not already in that
state, and the CTI OS Server process still remains active on both sides as long as the PG side B
server is healthy. If the B side does not receive a message stating that the A side is enabled, then
side B continues to run in simplex mode and the PIM, OPC, and CTI SVR processes become active
on PG side B if not already in that state. This condition should occur only if the PG side A server is
truly down or unreachable due to a double failure of visible and private network paths.
via the TOS procedure on the Public or Visible Network connection. If PG side B receives a TOS
response stating that the A side synchronizer is enabled or active, then the B side immediately goes
out of service, leaving the A side to run in simplex mode until the Private Network connection is
restored. The PIM, OPC, and CTI SVR processes become active on PG side A, if not already in that
state, and the CTI OS Server process still remains active on both sides as long as the PG side B
server is healthy. If the B side does not receive a message stating that the A side is enabled, then
side B continues to run in simplex mode and the PIM, OPC, and CTI SVR processes become active
on PG side B if not already in that state. This condition should occur only if the PG side A server is
truly down or unreachable due to a double failure of visible and private network paths.