Cisco Cisco IPCC Web Option Technical References
Fault Tolerance for Avaya ARS PG Gateway
13
1.2. Avaya ARS PG Implementation
Figure 2 shows that the Avaya ARS PG interfaces with the traditional
Unified ICM components similar to the traditional ACD PG. The PG (or
PGs if duplexed) interfaces with the PBX through the ISAGI protocol using
the Avaya Gateway process as translators.
Unified ICM components similar to the traditional ACD PG. The PG (or
PGs if duplexed) interfaces with the PBX through the ISAGI protocol using
the Avaya Gateway process as translators.
Figure 2: Avaya ARS Interface
The Avaya Gateway communicates with the PBX using the ASAI protocol
over a standard Ethernet network connection. Through this API, the Avaya
Gateway is able to monitor and control telephony resources. In a duplex
configuration, only the active PG will have an active communication path
with the AES Server.
over a standard Ethernet network connection. Through this API, the Avaya
Gateway is able to monitor and control telephony resources. In a duplex
configuration, only the active PG will have an active communication path
with the AES Server.
1.3. Fault Tolerance for Avaya ARS PG Gateway
Only one side of a duplexed PG is active at a time. The Avaya Gateway on
the active side will have an active connection with the AES Server. The
inactive side’s Gateway connection to the AES Server will not be active. If
the active side of the duplexed PG goes down, the AES Server connection
will become inactive. The inactive side will then attempt to become active
and the AES Server should allow the connection to that PG’s Gateway.
the active side will have an active connection with the AES Server. The
inactive side’s Gateway connection to the AES Server will not be active. If
the active side of the duplexed PG goes down, the AES Server connection
will become inactive. The inactive side will then attempt to become active
and the AES Server should allow the connection to that PG’s Gateway.
The PIM gathers information from the Avaya PBX to provide to the Avaya
Gateway when it starts up. These messages include setting up device
monitoring, sending snapshot requests to get current state of devices, and
getting a list of current calls on the switch and information related to those
calls. The information is processed in the order received and the results are
stored in the Gateway to be sent to the PIM when required.
Gateway when it starts up. These messages include setting up device
monitoring, sending snapshot requests to get current state of devices, and
getting a list of current calls on the switch and information related to those
calls. The information is processed in the order received and the results are
stored in the Gateway to be sent to the PIM when required.
This entire procedure of collecting status messages for the Avaya Gateway is
controlled by the PIM. The PIM again gathers this information from the
Unified ICM Configuration. Information concerning the current Agent States
is also gathered if hard phone support is configured.
controlled by the PIM. The PIM again gathers this information from the
Unified ICM Configuration. Information concerning the current Agent States
is also gathered if hard phone support is configured.
These status messages are important in the case where one side goes down
and the other side needs to start up and continue normal processing. The
caller should generally be unaware that one of the sides went down.
and the other side needs to start up and continue normal processing. The
caller should generally be unaware that one of the sides went down.