Cisco Cisco Unified Contact Center Enterprise 8.5(1) Guía De Diseño
3-7
Cisco Unified Contact Center Enterprise 7.0, 7.1, and 7.2 SRND
OL-8669-16
Chapter 3 Design Considerations for High Availability
Data Network Design Considerations
gateways are deployed, then one T1 per voice gateway (total of five) would be enough to achieve the
same level of redundancy. Thus, you can reduce the number of T1 lines required by adding more voice
gateways and spreading the risk over multiple physical devices.
same level of redundancy. Thus, you can reduce the number of T1 lines required by adding more voice
gateways and spreading the risk over multiple physical devices.
The operational cost savings of fewer T1 lines might be greater than the one-time capital cost of the
additional voice gateways. In addition to the recurring operational costs of the T1 lines, you should also
factor in the one-time installation cost of the T1 lines to ensure that your design accounts for the most
cost-effective solution. Every installation has different availability requirements and cost metrics, but
using multiple voice gateways is often more cost-effective. Therefore, it is a worthwhile design practice
to perform this cost comparison.
additional voice gateways. In addition to the recurring operational costs of the T1 lines, you should also
factor in the one-time installation cost of the T1 lines to ensure that your design accounts for the most
cost-effective solution. Every installation has different availability requirements and cost metrics, but
using multiple voice gateways is often more cost-effective. Therefore, it is a worthwhile design practice
to perform this cost comparison.
After you have determined the number of trunks needed, the PSTN service provider has to configure
them so that calls can be terminated onto trunks connected to all of the voice gateways (or at least more
than one voice gateway). From the PSTN perspective, if the trunks going to the multiple voice gateways
are configured as a single large trunk group, then all calls will automatically be routed to the surviving
voice gateways when one voice gateway fails. If all of the trunks are not grouped into a single trunk
group within the PSTN, then you must ensure that PSTN rerouting or overflow routing to the other trunk
groups is configured for all dialed numbers.
them so that calls can be terminated onto trunks connected to all of the voice gateways (or at least more
than one voice gateway). From the PSTN perspective, if the trunks going to the multiple voice gateways
are configured as a single large trunk group, then all calls will automatically be routed to the surviving
voice gateways when one voice gateway fails. If all of the trunks are not grouped into a single trunk
group within the PSTN, then you must ensure that PSTN rerouting or overflow routing to the other trunk
groups is configured for all dialed numbers.
If a voice gateway with a digital interface (T1 or E1) fails, then the PSTN automatically stops sending
calls to that voice gateway because the carrier level signaling on the digital circuit has dropped. Loss of
carrier level signaling causes the PSTN to busy-out all trunks on that digital circuit, thus preventing the
PSTN from routing new calls to the failed voice gateway. When the failed voice gateway comes back
on-line and the circuits are back in operation, the PSTN automatically starts delivering calls to that voice
gateway again.
calls to that voice gateway because the carrier level signaling on the digital circuit has dropped. Loss of
carrier level signaling causes the PSTN to busy-out all trunks on that digital circuit, thus preventing the
PSTN from routing new calls to the failed voice gateway. When the failed voice gateway comes back
on-line and the circuits are back in operation, the PSTN automatically starts delivering calls to that voice
gateway again.
With H.323 voice gateways, it is possible for the voice gateway itself to be operational but for its
communication paths to the Unified CM servers to be severed (for example, a failed Ethernet
connection). If this situation occurs in the case of a H.323 gateway, you can use the busyout-monitor
interface command to monitor the Ethernet interfaces on a voice gateway. To place a voice port into a
busyout monitor state, use the busyout-monitor interface voice-port configuration command. To
remove the busyout-monitor state on the voice port, use the no form of this command. As noted
previously, these gateways also provide additional processing options if the call control interface is not
available from Unified CM to reroute the calls to another site or dialed number or to play a locally stored
.wav file to the caller and end the call.
communication paths to the Unified CM servers to be severed (for example, a failed Ethernet
connection). If this situation occurs in the case of a H.323 gateway, you can use the busyout-monitor
interface command to monitor the Ethernet interfaces on a voice gateway. To place a voice port into a
busyout monitor state, use the busyout-monitor interface voice-port configuration command. To
remove the busyout-monitor state on the voice port, use the no form of this command. As noted
previously, these gateways also provide additional processing options if the call control interface is not
available from Unified CM to reroute the calls to another site or dialed number or to play a locally stored
.wav file to the caller and end the call.
With MGCP-controlled voice gateways, when the voice gateway interface to Unified CM fails, the
gateway will look for secondary and tertiary Unified CM subscribers from the redundancy group. The
MGCP gateway will automatically fail-over to the other subscribers in the group and periodically check
the health of each, marking it as available once it comes back on-line. The gateway will then fail-back
to the primary subscriber when all calls are idle or after 24 hours (whichever comes first). If no
subscribers are available, the voice gateway automatically busies-out all its trunks. This action prevents
new calls from being routed to this voice gateway from the PSTN. When the voice gateway interface to
Unified CM homes to the backup subscriber, the trunks are automatically idled and the PSTN should
begin routing calls to this voice gateway again (assuming the PSTN has not permanently busied-out
those trunks). The design practice is to spread the gateways across the Unified CM call processing
servers in the cluster to limit the risk of losing all the gateway calls in a call center if the primary
subscriber that has all the gateways registered to it should fail.
gateway will look for secondary and tertiary Unified CM subscribers from the redundancy group. The
MGCP gateway will automatically fail-over to the other subscribers in the group and periodically check
the health of each, marking it as available once it comes back on-line. The gateway will then fail-back
to the primary subscriber when all calls are idle or after 24 hours (whichever comes first). If no
subscribers are available, the voice gateway automatically busies-out all its trunks. This action prevents
new calls from being routed to this voice gateway from the PSTN. When the voice gateway interface to
Unified CM homes to the backup subscriber, the trunks are automatically idled and the PSTN should
begin routing calls to this voice gateway again (assuming the PSTN has not permanently busied-out
those trunks). The design practice is to spread the gateways across the Unified CM call processing
servers in the cluster to limit the risk of losing all the gateway calls in a call center if the primary
subscriber that has all the gateways registered to it should fail.
Voice gateways that are used with Cisco Unified Survivable Remote Site Telephony (SRST) option for
Unified CM follow a similar failover process. If the gateway is cut off from the Unified CM that is
controlling it, the gateway will fail-over into SRST mode, which terminates all trunk calls and resets the
gateway into SRST mode. Phones re-home to the local SRST gateway for call control, and calls will be
processed locally and directed to local phones. While running in SRST mode, it is assumed that the
agents also have no CTI connection from their desktops, so they will be seen as not ready within the
Unified CM follow a similar failover process. If the gateway is cut off from the Unified CM that is
controlling it, the gateway will fail-over into SRST mode, which terminates all trunk calls and resets the
gateway into SRST mode. Phones re-home to the local SRST gateway for call control, and calls will be
processed locally and directed to local phones. While running in SRST mode, it is assumed that the
agents also have no CTI connection from their desktops, so they will be seen as not ready within the