Duplexed PGs are implemented to provide fault tolerance in Unified ICM software communication with peripherals. The duplexed PGs use a private network. The PG private network synchronizes certain processes within a duplexed PG pair. It also conducts "heartbeat detection", a process by which each PG sends a heartbeat packet every 100ms to keep track of the "health" of the other PG.

PGs use a combination of the hot standby and synchronization approaches to fault tolerance. In the hot standby approach, one set of processes is called the primary, and the other is called the backup. In this model, the primary process performs the work at hand while the backup process is idle. In the event of a primary process failure, the backup process is activated and takes over. In a duplexed PG system, the Peripheral Interface Manager (PIM) processes use the hot standby approach to fault tolerance.

In the synchronization approach, the critical process is duplicated on separate computers. There is no primary and backup. Both process sets run in a synchronized fashion, processing duplicate input and producing duplicate output. Each synchronized process is an equal peer. Cisco refers to these equal peers as a synchronized process pair. In a duplexed PG system, the Open Peripheral Controller (OPC) process operates as a synchronized process pair.

The following figure shows how to use hot standby and synchronization in a duplexed Peripheral Gateway.

The OPC processes communicate with each other through a private network connection and the Cisco Message Delivery Service (MDS). The MDS provides a synchronizer service which combines the input streams from the PIMs and PG Agents on both sides of the PG to ensure that both OPC processes see exactly the same input.

The OPC process activates PIMs and PG Agents on each side of the duplexed PG. The OPC process also supplies uniform message sets from various PG types to the Unified ICM central controller.

The PIMs manage the interface between different types of ACDs and the OPC. PIMs are duplicated on each side of the system and operate in hot standby mode. A PIM can be active on either side of the duplexed PG, but not on both sides at the same time. For example, in the preceding figure PIMs 1 and 2 are active on Side A; PIM 3 is active on Side B. The duplexed OPCs communicate with each other through the MDS to ensure that a PIM is active only on one side at a time.

The duplexed PG architecture protects against a failure on one side of the PG. For example, if an adapter card controlling access to an ACD fails, a hot standby PIM can use the alternate PIM activation path. As shown in the preceding figure, PIM3 was activated from Side B of the PG. This might be in response to an adapter failure between the Side A PIM3 and ACD3. In this type of failure scenario, the PG can maintain communication with the attached ACD.

Only one PG Agent actively communicates with a side of the central controller. When messages arrive at the central controller, they are delivered to both sides by the central controller Synchronizer process. The PG maintains idle communication paths to both sides of the central controller in case a switch-over to the other side of the central controller or PG is necessary.

A maximum of two PGs can run on a single hardware platform. A single PG can serve only one type of ACD, but can also contain one or more VRU PIMs and/or Media Routing PIMs provided that the server hardware has the capacity to support the aggregate processing load. For a single hardware platform to serve two different types of ACDs, you need two PGs—one for each peripheral type. The following figure shows some possible PG options.

As shown in the preceding figure, you can have an Aspect PG on PGA and an Aspect PG on PGB. This duplexed PG pair can serve multiple Aspect ACDs. One Aspect Peripheral Interface Manager (PIM) is added through Peripheral Gateway Setup to connect each Aspect ACD to this PG. In this example, three Aspect PIMs are installed on each PG. The PIM is the Unified ICM software interface between the PG and different types of contact center peripherals. One PIM is required for each peripheral connected to a PG.

In a mixed contact center environment, you may want to run two different types of PGs on a single hardware platform. For example, you may want to put an Aspect PG and a DEFINITY ECS PG on the same computer. In this way, one hardware platform can serve two types of ACDs provided that the hardware platform has the necessary memory and CPU capacity to support the aggregate processing load.

In most PG configurations, the PG is located with the ACD at a contact center site. The PG communicates with the central controller via the Unified ICM visible network WAN links. These WAN links can be a dedicated circuit, or—if Quality of Service (QoS) is implemented—the corporate WAN. When Administration & Data Servers are located with PGs and ACDs at the contact center site, both PGs and Administration & Data Servers can share the WAN links to the central controller. If the PG is collocated with the Unified ICM central controller, the PGs connect directly to the Unified ICM visible LAN. The following figure shows an example of a standard PG configuration.

Some ACDs allow a remote connection to the Unified ICM Peripheral Gateway. In a remote ACD configuration, the PGs are located at the central site along with the CallRouter, Logger, and NIC. The ACD is located at a remote contact center site.

For information on remote PG support, see the ACD Supplement for the particular ACD. Usually Alcatel, Aspect, Avaya, Avaya ACC ACDs are supported over the WAN. However, in all cases, you must check with the ACD manufacturer for any WAN limitations.

The VRU PG can communicate remotely with VRU's via a TCP/IP network. However, you must ensure that the network link between the PG and VRU system provides enough bandwidth to support the call load for the VRU.

Connecting multiple PGs to the same ACD is required when multiple Unified ICM customers need to share the same service bureau ACD. For this configuration to be possible, the ACD must allow multiple CTI applications to share its CTI link(s). Support for multiple PG connections varies depending on the ACD platform. See the appropriate Cisco Unified ICM software ACD Supplement and contact your ACD vendor to determine the availability of this functionality.