Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
Unified CVP design for high availability
Download this chapter
Unified CVP design for high availabilityUnified CVP design for high availability
Download the complete book
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1) (PDF - 5 MB)
 Feedback

Contents

Unified CVP design for high availability

 

This chapter describes guidelines and best practices for designing a high-availability Unified CVP system.

This chapter covers the following topics:

New or changed chapter information

The following table lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.

 
Table 1 New or Changed Information Since the Previous Release of This Document

New or Revised Topic

Description

Updated content for Application Control Engine

  

Deleted content related to Content Services Switch

  

Overview

A high-availability design provides the highest level of failure protection. Your solution may vary depending upon business needs such as:

  • Tolerance for call failure
  • Budget
  • Topological considerations

Unified CVP can be deployed in many configurations that use numerous hardware and software components. Each solution must be designed in such a way that a failure impacts the fewest resources in the call center. The type and number of resources impacted depends on how stringent the business requirements are and which design characteristics you choose for the various Unified CVP components. A good Unified CVP design is tolerant of most failures but sometimes not all failures can be made transparent to the caller.

Unified CVP is a sophisticated solution designed for mission-critical call centers. The success of any Unified CVP deployment requires a team with experience in data and voice internet working, system administration, and Unified CVP application configuration.

Before implementing Unified CVP, use careful planning to avoid costly upgrades or maintenance later in the deployment cycle. Always design for the worst failure scenario, with future scalability in mind for all Unified CVP sites.

In summary, plan ahead and follow all the design guidelines and recommendations presented in this guide and in the latest version of the Cisco Unified Communications Solution Reference Network Design (SRND) Based on Cisco Unified Communications Manager, available at:

http:/​/​www.cisco.com/​en/​US/​products/​sw/​voicesw/​ps556/​products_​implementation_​design_​guides_​list.html

For assistance in planning and designing your Unified CVP solution, consult your Cisco or certified Partner Systems Engineer (SE).

A Note About the Unified CVP Call Server Component

The other chapters of this document treat the Unified CVP Call Server as a single component because those chapters have no need to examine it in any more depth than that. When discussing Unified CVP high availability however, it is important to understand that there are actually several parts to this component:

  • SIP Service — Responsible for processing incoming and outgoing calls via SIP.
  • ICM Service — Responsible for the interface to ICM. The ICM Service communicates with the VRU PG using GED-125 to provide ICM with IVR control. The ICM Service was part of the Application Server in previous releases of Unified CVP, but now it is a separate component.
  • IVR Service — Responsible for the conversion of Unified CVP Microapplications to VoiceXML pages, and vice versa. The IVR Service was known as the Application Server in previous Unified CVP versions.

Layer 2 switch

Figure 1. Redundant Unified CVP System. The following illustration shows a high-level layout for a fault-tolerant Unified CVP system. Each component in the Unified CVP site is duplicated for redundancy. The quantity of each of these components varies based on the expected busy hour call attempts (BHCA) for a particular deployment.



In this illustration, two switches provide the first level of network redundancy for the Unified CVP Servers:
  • If one switch fails, only a subset of the components becomes inaccessible. The components connected to the remaining switch can still be accessed for call processing.
  • If a ACE is used, its redundant partner must reside on the same VLAN in order to send keep-alive messages to each other via Virtual Router Redundancy Protocol (VRRP), a protocol similar to Hot Standby Router Protocol (HSRP). If one of the switches fails, the other ACE is still functional.

For more information on data center network design, See the Data Center documentation available at

http:/​/​www.cisco.com/​go/​designzone


Note

NIC teaming is not currently supported in the Unified CVP solution.

Cisco recommends that the NIC card and ethernet switch be set to 100 MB full duplex for 10/100 links, or set to auto-negotiate for gigabit links.

Originating gateway

The function of the originating gateway in a Unified CVP solution is to accept calls from the PSTN and direct them to Unified CVP for call routing and IVR treatment.

This section covers the following topics:

Configuration

For the most current information on how to provide redundancy and reliability for originating gateways and T1/E1 lines, see the latest version of the Cisco Unified Contact Center Enterprise Solution Reference Network Design (SRND), available at:

http:/​/​www.cisco.com/​en/​US/​products/​sw/​custcosw/​ps1844/​products_​implementation_​design_​guides_​list.html

In addition, consider the following issues when designing gateways for high availability in a Unified CVP solution:

  • When used in ICM-integrated models, the originating gateway communicates with Unified CVP using SIP. Unlike MGCP, and SIP do not have redundancy features built into the protocol. Instead, SIP relies on the gateways and call processing components for redundancy.
  • When configuring the gateway, it is best to bind the SIP signaling to the virtual loopback interface, as illustrated in the following configuration examples: SIP: 
    voice service voip sip
  bind control source-interface Loopback0
  bind media source-interface Loopback0
    This configuration allows call signaling to operate independent of the physical interfaces. In this way, if one interface fails, the other interface can handle the traffic. Each gateway interface should be connected to a different physical switch to provide redundancy in the event that one switch or interface fails. Each interface on the gateway is configured with an IP address on a different subnet. The IP Routers for the network is configured with redundant routes to the Loopback address through the use of static routes or a routing protocol. If a routing protocol is used to review the number of routes being exchanged with the gateway, and consider using filters to limit the routing updates so that the gateway is only advertising the loopback address and not receiving routes.

Call disposition

If the originating gateway fails, the following conditions apply to call disposition:

  • Calls in progress are dropped. There is nothing that can be done to preserve these calls because the PSTN switch has lost the D-channel to all T1/E1 trunks on this gateway.
  • New calls are directed by the PSTN carrier to a T1/E1 at an alternate gateway, provided the PSTN switch has its trunks and dial plan configured to do so.

SIP proxy

The SIP proxy server provides dial plan resolution on behalf of SIP endpoints, allowing dial plan information to be configured in a central place instead of statically on each SIP device. A SIP proxy server is not required in a Unified CVP solution, but it is used in most solutions because of the benefits of centralized configuration and maintenance. Multiple SIP proxy servers can be deployed in the network to provide load balancing, redundancy, and regional SIP call routing services. In a Unified CVP solution, the choices for SIP call routing are:

  • SIP proxy server
    • Advantages: Weighted load balancing and redundancy. Centralized dial-plan configuration. SIP proxy may already exist or be used for other applications for dial-plan resolution or intercluster call routing.
    • Disadvantages: Additional server or hardware required for SIP proxy if not already deployed.
  • Static routes using Server Groups (DNS SRV records) on a DNS Server
    • Advantages: Weighted load balancing and redundancy.
    • Disadvantages: Unable to use of an existing server depends on the location of the DNS server.. The ability to share or delegate DNS server administration rights may be limited in some organizations. Dial-plan configuration needs to be configured on each device individually (Unified CM, Unified CVP, and gateways). DNS SRV lookup is performed for each and every call by Unified CVP. If the DNS server is slow to respond, is unavailable, is across the WAN, so the performance is affected.
  • Static routes using local DNS SRV records
    • Advantages: Weighted load balancing and redundancy. Does not depend on an external DNS Server, thus eliminating a point of failure, latency, and DNS Server performance concerns.
    • Disadvantages: Dial plan must be configured on each device individually (Unified CM, Unified CVP, and gateways).

Note
The options for static routes using SRV with a DNS Server, or using Server Groups, can introduce some unexpected, long delays during failover and load balancing with UDP transport on the Unified CVP Call Server when the primary destination is shut down or is off the network. With UDP, when a hostname has multiple elements with different priorities in the Server Group (srv.xml), the Unified CVP does two attempts for each element, with 500 msec between each attempt. If the first element does not answer, it tries the next element one second later. This delay occurs is on every call during failure, depending on load balancing, and is in accordance with section 17.1.1.1 of RFC 3261 regarding the T1 timer. If server group heartbeats are turned on, then the delay may only be incurred once, or not at all, depending on the status of the element. This apply to TCP as well.
  • Static routes using IP addresses
    • Advantages: Does not depend on any other device (DNS or Proxy) to deliver calls to the destination.
    • Disadvantages: No redundancy possible for SIP calls from Unified CVP. Dial plan must be configured on each device individually. This option is used for environments that do not have redundancy (single server) or for lab deployments.

Each device in the Unified CVP solution can use the above methods for determining where to send a call. The Unified CVP Call Server interface to the SIP network is through the Unified CVP SIP Service, which is discussed in the section on Unified CVP SIP service.

Cisco Unified SIP Proxy (CUSP) support

The 9.0(1) release of Unified CVP has been validated with Cisco Unified SIP Proxy Server (CUSPServer) version 1.1.4. This means that Unified CVP now supports only CUSP proxy servers.

CUSP deployment methods

There are two deployment options supported with CUSP proxy in the CVP solution.

Deployment option A - Redundant SIP proxy servers
This method:
  • Consists of 2 gateways for redundancy, geographically separated, 1 proxy module each, using SRV priority for redundancy of proxies, no HSRP.
  • Starting with Unified CVP 8.5(1) CUSP can co-reside with VXML or TDM gateways. In earlier versions of Unified CVP due to platform validation restriction co-residency was not supported, and a dedicated ISR was required for proxy functionalities.
  • TDM gateways are configured with SRV or with Dial Peer Preferences to use the primary and secondary CUSP proxies.
  • CUSP is set with Server Groups to find primary and back up Unified CVP, Unified CM and VXML gateways.
  • Unified CVP is set up with Server Group to use the primary and secondary CUSP proxies.
  • Cisco Unified CM is set up with a Route Group with multiple SIP Trunks, to use the primary and secondary CUSP proxies.
Example of option A

In this example, ISR1 is on the east coast and ISR2 is on the west coast. The TDM gateways will use the closest ISR, and only cross the WAN when needing to failover to the secondary priority blades.

The SRV records look like this:

east-coast.proxy.atmycompany.com
blade 10.10.10.10 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 2 weight 10 (this blade is in ISR2 on west coast)

west-coast.proxy.atmycompany.com
blade 10.10.10.20 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.10 priority 2 weight 10 (this blade is in ISR1 on east coast)
Deployment option B - Redundant SIP proxy servers (double capacity)
This method:
  • Consists of 2 gateways for redundancy, 2 proxy modules in each chassis. All 4 proxy servers are in active mode with calls being balanced between them.
  • Uses SRV to load balance across proxies with priority.
  • The ISR is dedicated to the proxy blade function and is not co-located as a VXML gateway, nor as a TDM gateway, due to platform validation restrictions on CUSP.
  • TDM gateways are set with SRV or with Dial Peer Preferences to use the primary and secondary CUSP proxies.
  • CUSP is set with Server Groups to find primary and back up Unified CVP, Unified CM and VXML gateways.
  • Unified CVP is set up with Server Group to use the primary and secondary CUSP proxies.
  • Cisco Unified CM is set up with Route Group with multiple SIP Trunks, to use the primary and secondary CUSP proxies.
Example of option B

With this example ISR1 is on the east coast and ISR2 is on the west coast. The TDM gateways will use the closest ISR, and only cross the WAN when needing to failover to the secondary priority blades. The SRV records look like this:

east-coast.proxy.atmycompany.com
blade 10.10.10.10 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 1 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.30 priority 2 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.40 priority 2 weight 10 (this blade is in ISR2 on west coast)

west-coast.proxy.atmycompany.com
blade 10.10.10.30 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.40 priority 1 weight 10 (this blade is in ISR2 on west coast)
blade 10.10.10.10 priority 2 weight 10 (this blade is in ISR1 on east coast)
blade 10.10.10.20 priority 2 weight 10 (this blade is in ISR1 on east coast)

Performance matrix for CUSP deployment

CUSP baseline tests were done in isolation on the proxy, and capacity numbers (450 TCP, 500 UDP transactions per second) should be used as the highest benchmark, and most stressed condition allowable.
A CVP call, from the proxy server perspective, entails on average, 4 separate SIP calls:
  • Caller inbound leg
  • VXML outbound leg
  • Ringtone outbound leg
  • Agent outbound leg

When a consult with CVP queuing occurs, an additional 4 SIP transactions will be incurred for the session, effectively doubling the number of calls.

CUSP design considerations

Always turn the Record Route setting off on the proxy server to avoid a single point of failure and allow fault tolerance routing, as well as increase the performance of the Proxy server. Using record route setting on the proxy server doubles the impact to performance, as shown in the CUSP baseline matrix, and also breaks the high availability model since the proxy becomes a single point of failure for the call, if the proxy were to go down.

Record Route is turned off by default on CUSP.


Note

Upstream Element Routing with SIP Heartbeats

With CUSP proxy, any response to a INVITE or OPTIONS is a good response, so CUSP will not mark an element down when it receives a response. If the response is configured in the failover response code list for the server group, then CUSP will failover to the next element in the group; otherwise, it will send the response downstream as the final response.

Configuration

The following sections discuss configuration of the SIP Proxy Server and Cisco IOS Gateways using SIP. It is not meant to be an exhaustive list of configuration options but only highlights certain configuration concepts.

SIP proxy server configuration

The SIP Proxy Server should be configured with static routes that point at the appropriate devices (Unified CVP Call Servers, VoiceXML gateways, Cisco Unified Communications Manager cluster, and so forth). The SIP Proxy Server configuration allows you to specify the priority of the routes. In the case where there are multiple routes to the same destination, you can configure the SIP Proxy to load-balance across the destinations with equal priority or to send the calls in a prioritized manner using different priorities.

To reduce the impact of a Proxy Server failure, Cisco recommends that you disable the RecordRoute header from being populated by the SIP Proxy Server. In this way, the inbound calls route through a SIP Proxy; but once they reach the Unified CVP Call Server (Call Server), the signaling is exchanged directly between the originating device and the Call Server, and a SIP Proxy failure will not affect the calls in progress.

Cisco IOS gateway configuration

With Cisco IOS gateways, dial-peers are used to match phone numbers, and the destination can be a SIP Proxy Server, DNS SRV, or IP address. The following example shows a Cisco IOS gateway configuration to send calls to a SIP Proxy Server using the SIP Proxy's IP address. 

sip-ua sip-server ipv4:10.4.1.100:5060 

dial-peer voice 1000 voip
 session target sip-server
 ...

The sip-server command on the dial-peer tells the Cisco IOS gateway to use the globally defined sip-server that is configured under the sip-ua settings. In order to configure multiple SIP Proxies for redundancy, you can change the IP address to a DNS SRV record, as shown in the following example. The DNS SRV record allows a single DNS name to be mapped to multiple Reporting Servers. 

sip-ua sip-server dns:cvp.cisco.com

dial-peer voice 1000 voip
 session target sip-server
 ...

Alternatively, you can configure multiple dial-peers to point directly at multiple SIP Proxy servers, as shown in the following example. This configuration allows you to specify IP addresses instead of relying on DNS. 

dial-peer voice 1000 voip session target ipv4:10.4.1.100
 preference 1
 ...
dial-peer voice 1000 voip
 session target ipv4:10.4.1.101
 preference 1
 ...

In the preceding examples, the calls are sent to the SIP Proxy server for dial plan resolution and call routing. If there are multiple Unified CVP Call Servers, the SIP Proxy server would be configured with multiple routes for load balancing and redundancy. It is possible for Cisco IOS gateways to provide load balancing and redundancy without a SIP Proxy Server. The following example shows a Cisco IOS gateway configuration with multiple dial-peers so that the calls are load-balanced across three Unified CVP Call Servers. 

dial-peer voice 1001 voip session target ipv4:10.4.33.131
 preference 1
 ...
dial-peer voice 1002 voip
 session target ipv4:10.4.33.132
 preference 1
 ...
dial-peer voice 1003 voip
 session target ipv4:10.4.33.133
 preference 1
 ...

DNS SRV records allow an administrator to configure redundancy and load balancing with finer granularity than with DNS round-robin redundancy and load balancing. A DNS SRV record allows you to define which hosts should be used for a particular service (the service in this case is SIP), and it allows you to define the load-balancing characteristics among those hosts. In the following example, the redundancy provided by the three dial-peers configured above is replaced with a single dial-peer using a DNS SRV record. Note that a DNS server is required in order to do the DNS lookups. 

ip name-server 10.4.33.200 
dial-peer voice 1000 voip
 session target dns:cvp.cisco.com

With Cisco IOS gateways, it is possible to define DNS SRV records statically, similar to static host records. This capability allows you to simplify dial-peer configuration while also providing DNS SRV load balancing and redundancy. The downside of this method is that, if the SRV record needs to be changed, it must be changed on each gateway instead of on a centralized DNS server. The following example shows the configuration of static SRV records for SIP services handled by cvp.cisco.com, and the SIP SRV records for cvp.cisco.com are configured to load-balance across three servers. 

ip host cvp4cc2.cisco.com 10.4.33.132ip host cvp4cc3.cisco.com 10.4.33.133
ip host cvp4cc1.cisco.com 10.4.33.131

(SRV records for SIP/TCP) 

ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc3.cisco.comip 
host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc2.cisco.com
ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc1.cisco.com

(SRV records for SIP/UDP) 

ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc3.cisco.comip 
host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc2.cisco.com
ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc1.cisco.com

Unified CVP SIP service

The Unified CVP SIP service is the service on the Unified CVP Call Server that handles all incoming and outgoing SIP messaging and SIP routing. The Call Server can be configured to use a SIP proxy server for outbound dial plan resolution, or it can be configured to use static routes based on IP address or DNS SRV. Call Servers do not share configuration information about static routes; therefore, if a change needs to be made to a static route, then the change must be made on each Call Server's SIP service. Cisco recommends that you use a SIP Proxy Server to minimize configuration overhead.

Configuration

If only a single SIP Proxy server is needed for outbound call routing from the Call Server, choose the SIP Proxy configuration when configuring the SIP Service. In the Unified CVP Operations Console Server, configure the following:

  • Add a SIP Proxy Server and specify the IP address of the server.

Under the Call Server SIP Service settings, configure the following:

  • Enable Outbound Proxy = True
  • Use DNS SRV type query = False
  • Outbound Proxy Host = SIP Proxy Server configured above

When using multiple SIP Proxy servers for outbound redundancy from the Call Server, configure the SIP Proxy with a DNS name and configure DNS SRV records in order to reach the SIP Proxy Servers. The DNS SRV records can exist on an external DNS Server, or they can be configured in a local DNS SRV record on each CVP server. In the OAMP Console, configure the following:

  • Add a SIP proxy server and specify DNS name of the server.

Under SIP Service configuration, configure the following:

  • Enable Outbound Proxy = True
  • Use DNS SRV type query = True
  • The DNS SRV record should then be configured with the list of SIP Proxy Servers.

To configure the Local DNS SRV record on each server, under the SIP service configuration, check Resolve SRV records locally.

To use a Server group for redundant proxy servers:

  1. Select resolve SRV records locally and type in the name of the server group for the outbound proxy domain name.
  2. Under System > Server Groups, create a new server group with two proxy servers that have priority 1 and 2.
  3. Deploy the server group configuration to the Call Server.

High availability for calls in progress

In the event that a Call Server fails with calls in progress, it is possible to salvage all calls if certain gateway configuration steps. A Call Server can fail if one of the following occurs:

  • The server crashes.
  • The process crashes.
  • The process stops.
  • The network is out.

The configuration discussed in this section protects against all of these situations. However, if one of the following two scenarios occurs, recovery is not possible:

  • Someone stops the process with calls in progress. This situation occurs, when a system administrator forgets to do a Call Server graceful shutdown. In this case the CVP Call Server will terminate all active calls to release the licenses.
  • The Call Server exceeds the recommended call rate. Although there is a limit for the absolute number of calls allowed in the Call Server, there is no limit for the call rate. In general, exceeding the recommended calls per second (cps) for an extended period of time can cause erratic and unpredictable call behavior on certain components. You must ensure the components of the Unified CVP solution is sized correctly and balance the call load according to the weight and sizing of each call processing component. See the Sizing for call server call rate details.

For call survivability, configure the originating gateways as described in the latest version of the Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP), available at:

http:/​/​www.cisco.com/​en/​US/​products/​sw/​custcosw/​ps1006/​products_​installation_​and_​configuration_​guides_​list.html

The survivability.tcl script also contains some directions and useful information.

In the event of most downstream failures (including a Call Server failure), the call is default-routed by the originating gateway. Note that survivability is not applicable in the Unified CVP Standalone and NIC-routing models because there is no Unified CVP SIP service in those models.

There is also a mechanism for detection of calls that have been cleared without Unified CVP’s knowledge:

  • Unified CVP checks every 2 minutes for inbound calls that have a duration older than a configured time (the default is 120 minutes).
  • For those calls, Unified CVP sends an UPDATE message. If the message receives a rejection or is undeliverable, then the call is cleared and the license released.

The CVP SIP service can also add the Session expires header on calls so that endpoints such as the originating gateway may perform session refreshing on their own. RFC 4028 (Session Timers in the Session Initiation Protocol) contains more details on the usage of Session expires with SIP calls.

Call disposition

Calls are handled as indicated for the following scenarios:

  • Calls in progress If the Unified CVP SIP Service fails after the caller has been transferred (transfers include transfer to an IP phone, VoiceXML gateway, or other egress gateway), then the call continues normally until a subsequent transfer activity (if applicable) is required from the Unified CVP SIP Service. If the caller and is awaiting further activity, there is a period of 9 to 18 seconds of silence before the caller is default-routed by survivability to an alternate location. If the call has not yet been transferred, the caller hears 9 to 18 seconds of silence before being default-routed by survivability to an alternate location. (Survivability does not apply in NIC-routing models.)
  • New calls New calls are directed by the Unified SIP Proxy to an alternate Unified CVP Call Server. If no Call Servers are available, the call is default-routed to an alternate location by survivability. (Survivability does not apply in NIC-routing models.)

Server group

A Server group is a dynamic routing feature that enables the originating endpoint to know status of the destination address before attempting to send the SIP INVITE. Whether the destination is unreachable over the network, or is out of service at the application layer, the originating SIP user agent has knowledge of the status through a heartbeat mechanism.

The Server group features adds a heartbeat mechanism with endpoints for SIP. This feature allows faster failover on call control by eliminating delays due to failed endpoints.


Note
  • Server groups are not automatically created. Server groups are not created by the upgrade to Release 9.0(1). You must explicitly configure Server groups for their deployment, and turn the feature on after upgrading, in order to take advantage of the feature.
  • Upgrade for customers who already use Local SRV. Customers who already have an srv.xml file configured with local SRV must run the import command mentioned below in order to put their configuration into the Unified CVP Operations Console Server database. Do this before saving and deploying any new server groups to avoid overwriting your previous configuration.

The Unified CVP SIP Subsystem builds on the local SRV configuration XML available with Release 9.0(1).

A Server group consists of one or more destination addresses (endpoints), and is identified by a Server group domain name. This domain name is also known as the SRV cluster domain name, or FQDN. The SRV mechanism is used, but the DNS server resolution of the record is not performed. Server groups remains the same as local SRV implementation (srv.xml), but the Server groups feature adds the extra heartbeat mechanism on top of it, as an option.


Note
  • Server groups in Unified CVP and SIP proxy servers work the same way.
  • Only endpoints defined in a Server group may have heartbeats sent to them.
  • With record-routes on proxy set to off, any mid-dialog SIP message such as REFER or REINVITES would bypass the elements defined in server group. These messages would be directly delivered to the other end point in the dialog.

In the previous releases, you used the srv.xml configuration file to configure SRV records locally, to avoid the overhead of DNS SRV querying. However, the method of configuration was manual, and could not be pushed from the Unified CVP Operations Console Server (Operations Console). Also, there was no validation on the min and max values for fields.

Release 9.0(1) adds this configuration into the Operations Console SIP subsystem using the Server groups concept. The Server group term just refers to the local SRV configuration. When you turn on Server groups with Heartbeat, you get the dynamic routing capability for Unified CVP to monitor the status of endpoints. This feature only covers outbound calls from Unified CVP. To cover the inbound calls to Unified CVP, the SIP proxy server can send similar heartbeats to Unified CVP, which can respond with status responses.

Server group heartbeat settings

The Server group heartbeat default setting track the ping interval between any two pings; it is not the interval between pings to the same endpoint. The Server group does not ping at a specific interval and ping all elements because this approach would introduce a fluctuation on CPU usage. Also, it takes more resources when the system has to ping many end points. For example, to ping 3 elements across all groups at 30 second intervals, you have to set the ping interval at 10 seconds.

It is less deterministic for reactive mode because elements that are currently down can fluctuate, so the ping interval fluctuates with it.


Note
  • Heartbeat Behavior Settings for Server groups. To turn off pinging when the element is up, set the Up Endpoint Heartbeat Interval to zero (reactive pinging). To turn off pinging when the element is down, set the Down Endpoint Heartbeat Interval to zero (proactive pinging). To ping when the element is either up or down, set the heartbeat intervals to greater than zero (adaptive pinging).
  • Heartbeat Response Handling. Any endpoint that CVP may route calls to should respond to OPTIONS with some response, either a 200 OK or some other response. Any response to a heartbeat indicates the other side is alive and reachable. A 200 OK is usually returned, but CUSP Server may return a 483 Too Many Hops response, since the max-forwards header is set to zero in an OPTIONS message. Sometimes the endpoints may not allow OPTIONS or PING, and may return 405 Method Not Allowed.

By default, Server group heartbeats are monitored using a UDP socket connection. The transport type can be changed to TCP from the Operations Console Server Groups window.

Whenever an element has an unreachable or overloaded status, that element is marked as down completely, that is for both UDP and TCP transports. When the element is up again, transports are routed for both UDP and TCP.


Note

TLS transport is not supported.

Duplicate Server Group Elements is not monitored because the primary element is already monitored..


Note

See the Configuration and Administration Guide for Cisco Unified Customer Voice Portal for typical configurations for the Server groups feature. The Document is available at: http:/​/​www.cisco.com/​en/​US/​products/​sw/​custcosw/​ps1006/​products_​installation_​and_​configuration_​guides_​list.html.

Static routes validation

The hostname or IP address of a static route is validated at startup and configuration deployment time with a DNS lookup resolution. If the hostname does not resolve to an A record or SRV record, then the route is disabled and a notice is printed in the Unified CVP error log. The calls cannot pass to this route in this state. If the host is in the local SRV Server groups configuration as an SRV name, then the host is not checked, because it resolves to a local SRV name. IP addresses pass the validation.

Design considerations

Observe the following design considerations when implementing Server Groups:

  • When you use the Local SRV configuration, you cannot use with the DNS SRV configuration. However, elements may be declared as A record host names instead of IP addresses, and resolved through a DNS server lookup or in the Operating System host file.
  • In the CUSP Proxy CLI, define the SRV cluster name (such as proxy-servers.cisco.com) in the service parameters section of the proxy configuration. Otherwise a 404 not found rejection may result.

Diagnostics

The Unified CVP log file has traces which show endpoint status events. See the Unified CVP System CLI instructions in the Configuration and Administration Guide for Cisco Unified Customer Voice Portal, available at: http:/​/​www.cisco.com/​en/​US/​products/​sw/​custcosw/​ps1006/​products_​installation_​and_​configuration_​guides_​list.html.

Unified CVP IVR service

High availability was achieved by configuring the Unified CVP Voice Browser and VoiceXML gateways with a list of application server IP addresses and/or using the ACE. With Unified CVP 4.0 and later releases, the IVR Service is tightly coupled with the SIP Service. If the IVR Service goes out of service, the SIP Service will be taken out of service as well so that no further calls are accepted by the Unified CVP Call Server.

Configuration

No additional configuration is needed in order to tell the SIP Service which IVR Service to use. By default, the SIP Service use the IVR Service that resides on the same server. It is also no longer necessary to configure the VoiceXML gateway with the IP address of the Call Server’s IVR Service. When SIP is used, the SIP Service inserts the URL of the Call Servers IVR Service into a header in the SIP INVITE message when the call is sent to the VoiceXML gateway. The VoiceXML gateway extracts this information from the SIP INVITE and uses to determines which Call Server to use. The VoiceXML gateway examines the source IP address of the incoming call from the Call Server. This IP address is used as the address for the Call Servers IVR service.

The following example illustrates the VoiceXML bootstrap service that is invoked when a call is received: 

service bootstrap flash:bootstrap.tcl  paramspace english index 0
  paramspace english language en
  paramspace english location flash
  paramspace english prefix en

With Unified CVP 4.0 and later releases you have to configure the IP address of the Call Server. The bootstrap.tcl learns the IP address of the source Call Server and uses it as its call server. There is no need for or backup Call Server configuration because receiving a call from the Call Server means that the server is operational.

The following files in flash memory on the gateway are also involved with high availability: handoff.tcl, survivability.tcl, recovery.vxml, and several .wav files. Use Trivial File Transfer Protocol (TFTP) to load the proper files into flash. Configuration information for each file can be found within the file itself. For information, see the latest version of the Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP), available at:

http:/​/​www.cisco.com/​en/​US/​products/​sw/​custcosw/​ps1006/​products_​installation_​and_​configuration_​guides_​list.html

Call disposition

If the Unified CVP IVR Service fails, the following conditions apply to the call disposition:

  • Calls in progress are default-routed to an alternate location on the originating gateway. (Survivability does not apply in NIC-routing models.)
  • New calls are directed to an in-service Unified CVP IVR Service.

VoiceXML gateway

The VoiceXML gateway parses and renders VoiceXML documents obtained from the Unified CVP Call Server (from its IVR Service), the Unified CVP VXML Servers, or some other external VoiceXML source. Rendering a VoiceXML document consists of retrieving and playing prerecorded audio files, collecting and processing user input, or connecting to an ASR/TTS server for voice recognition and dynamic text-to-speech conversion.

For a discussion of using mixed codecs in CVP deployments, see Mixed G.729 and G.711 codec support. For a discussion of the benefits and drawbacks of each codec, refer to Voice traffic.


Note

VXML GW must not have load balanced path, as this route on VXML GW will cause a call HTTP Client Error. If the VXML GW has load balancing route to CVP Call Server, it may use a different source address to send HTTP message to CVP Call Server, which would cause CVP to return a 500 Server Error address to send HTTP message to CVP Call Server, which would cause CVP to return a 500 Server Error message. In VXML GW, it is not possible to bind any specific interface for the HTTP Client side. So, if VXML GW sends NEW_CALL using one interface and CALL_RESULT using another interface, CVP will return a 500 Server Error.

Configuration

High availability configuration for VoiceXML gateways is controlled by the SIP proxy for SIP, or the Unified CVP Call Server (Call Server). Whether the VoiceXML gateways are distributed or centralized also influences how high availability is achieved.

In the event that a Call Server is unable to connect to a VoiceXML gateway, an error is returned to the ICM script. In the ICM script, the Send to VRU node is separate from the first Run External script node in order to catch the VoiceXML gateway connection error. If an END script node is used off the X-path of the Send to VRU node, the call is default-routed by survivability on the originating gateway. (Survivability does not apply in VRU-only models.) A Queue to Skill group node, but that method is effective only if there is an agent available. Otherwise, ICM tries to queue the caller, and that attempt fails because the Call Server is once again unable to connect to a VoiceXML gateway. An END node could then also be used off the X-path of the Queue to Skill Group node to default-route the call.


Note

There are two features for the VXML Server that assist with load balancing:

  • Limiting Load Balancer Involvement
  • Enhanced HTTP Probes for Load Balancers

See the configuration options ip_redirect and license_depletion_probe_error in the User Guide for Unified CVP VXML Server and Cisco Unified Call Studio, available at: http:/​/​www.cisco.com/​en/​US/​products/​sw/​custcosw/​ps1006/​products_​user_​guide_​list.html.

Centralized VoiceXML gateways

In this configuration, the VoiceXML gateways reside in the same data center as the Unified CVP Call Server.

SIP VoiceXML gateways

If you are using SIP static routes on the Unified CVP Call Server: under the SIP Service configuration for the Call Server, configure a static route for each Network VRU label and gateway. If the VRU label is 5551000, the static route pattern would be 5551000>. The > is a wildcard representing one or more digits, and it is needed so that the correlation-id appended to the DNIS number can be passed to the VoiceXML gateway correctly.


Note

Other wildcard characters can be used. See the topic Valid Formats for Dialed Numbers in the Ops Console online help for complete wildcard format and precedence information.

In the case of both SIP proxy or Unified CVP static routes, the next-hop address of the route can be either the IP address of the gateway or a DNS SRV record. If you are using an IP address, you must create multiple static routes, one for each VoiceXML gateway. In the case of DNS SRV, only one route for each Network VRU label is needed, and the SRV record provides for load-balancing and redundancy.

Distributed VoiceXML gateways

In this configuration, the gateway that processes the incoming call from the PSTN is separated from the Unified CVP servers by a low-bandwidth connection such as a WAN. The VoiceXML gateway is the same as the ingress gateway. This configuration is to keep the media stream from consuming bandwidth on the WAN.

SIP VoiceXML gateways

With SIP, the equivalent of the SetTransferLabel command is the Send to Originator configuration under the SIP Service. If the Network VRU label is 5551000, the Send to Originator pattern is 5551000>. The > is a wildcard pattern representing one or more digits. The SIP Service determines the originating gateway by looking at the Remote-Party-ID header in the SIP INVITE message.


Note

You can use other wildcard characters. See the topic Valid Formats for Dialed Numbers in the Operations Console online help for complete wildcard format and precedence information.

Distributed VoiceXML gateways

In this configuration, the gateway that processes the incoming call from the PSTN is separated from the Unified CVP servers by a low-bandwidth connection such as a WAN. The VoiceXML gateway is different than the ingress gateway but located at the same site. The configuration keeps the media stream at the same site and without consuming bandwidth on the WAN and optimizes VoiceXML gateway sizing when it is appropriate to separate ingress and VoiceXML gateways. In this case, setTransferLabel and Send to Originator cannot be used because you would not want the IVR leg of the call to go back to the ingress gateway. Additionally, it is also impractical to use a SIP Proxy to control the call routing because you would have to configure separate Network VRUs, Network VRU labels, and customers in ICM for each remote site. Instead, use SetSigDigits functionality.

With this method, the Call Server strips the leading significant digits from the incoming DNIS number. The value that is stripped is saved and prepended when subsequent transfers for the call occur.

SIP VoiceXML gateways

When SIP is used, the significant digits are prepended to the DNIS number, and a SIP Proxy can be configured to route calls based on those prepended digits. The static routes in the SIP Proxy for the VoiceXML gateway should have the digits prepended. Because these prepended digits were originally populated by the ingress gateway, the SIP Proxy can use them to determine which VoiceXML gateway to use based on the incoming gateway. In this way, calls arriving at a particular site can always be sent back to that site for VoiceXML treatment, with the result that no WAN bandwidth is used to carry the voice RTP stream. The Unified CVP indiscriminately prepends the sigdigits value to all transfers, including those to Unified CM. Therefore, when using Unified CM in this scenario, to strip the prepended digits when the call arrives so that the real DNIS number of the phone can be used by Unified CM to route the call, as illustrated in the following example.

Configuration of ingress gateway:

Apply a translation-rule to the incoming DNIS to prepend the value 3333: 

translation-rule 99 
 rule 1 8002324444 33338002324444

dial-peer voice 1000 voip
 translate-outgoing called 99

Assuming the DNIS number is 8002324444, the final DNIS string routed to Unified CVP is 33338002324444.

Configuration of Unified CVP SIP service:

To configure the SIP service, in the Operations Console, select the Call Server > SIP tab. Many of the settings are on the Advanced Configuration window.

Configuration of VoiceXML gateway:

Configure the Voice XML gateway to match the DNIS string, including the prepended digits: 

dial-peer voice 3000 voip 
 incoming-called number 33335551000T
 service bootstrap
 ...

Configure the Unified CVP bootstrap.tcl application with the sigdigits parameter, telling it how many digits to strip off of the incoming DNIS string: 

application 
 service bootstrap flash:bootstrap.tcl
 param sigdigits 4
 ...

Cisco Unified CM configuration (if used):

Configure Unified CM to strip the prepended digits, either by using the Significant Digits configuration on the SIP Trunk configuration page or by using translation patterns.

SIP Proxy configuration:

Define static routes on the SIP Proxy, with the prepended digit present, to be sent to the appropriate VoiceXML gateway. Because transfers to agents on a Unified CM cluster have prepended digit, the static routes for agent phones must also contain the prepended digits.

Summary of call routing:

  1. A call arrives at Unified CVP with a DNIS number of 33338002324444.
  2. Unified CVP removes four digits (3333) from the beginning of the DNIS string, leaving 8002324444.
  3. The number 8002324444 is passed to ICM for call routing.
  4. When it is time to transfer, ICM returns the label 5551000102. Unified CVP prepends 3333, giving 33335551000102.
  5. The SIP Service then resolves the address using the SIP Proxy or local static routes, and it sends the call to the VoiceXML gateway.
  6. The VoiceXML gateway bootstrap.tcl removes 3333, leaving 5551000102 for the destination address.

Call disposition

If the VoiceXML gateway fails, the following conditions apply to the call disposition:

  • Calls in progress are default-routed to an alternate location by survivability on the ingress gateway. (Survivability does not apply in NIC-routing models.)
  • New calls find an alternate VoiceXML gateway.

High availability hardware configuration on voice gateways

The individual hardware components have the following high-availability options:

  • Redundant power supplies
  • Separate components for higher availability
  • Dedicated components, which have fewer interaction issues

Example 1: Separate PSTN Gateway and VoiceXML Gateway

A PSTN gateway and a separate VoiceXML gateway provide greater availability a combine PSTN and VoiceXML gateway.

Example 2: Duplicate Components for Higher Availability

  • Two 8-T1 PSTN gateways provide greater availability than one 16-T1 PSTN gateway.
  • Two 96-port Unified CVP VXML Servers provide greater availability than one 192-port Unified CVP VXML Server.
  • Larger designs can use N+1 spares for higher availability.

Example 3: Geographic Redundancy for Higher Availability

Geographical redundancy and high availability can be achieved by purchasing duplicate hardware for Side A and Side B.

Media server

Audio files are stored locally in flash memory on the VoiceXML gateway or on an HTTP/TFTP file server. Audio files stored locally are highly available. However, HTTP/TFTP file servers provide the advantage of centralized administration of audio files.


Note

Starting with Unified CVP 9.0, you cannot install a separate media server. The media server must be co-located with the Call Server and Unified CVP VXML Server.

Unified CVP microapplication configuration

The VoiceXML gateway sends HTTP requests to an HTTP media server to obtain audio files. It uses the following VoiceXML gateway configuration parameters to locate a server when not using a ACE: 

ip host mediaserver <ip-address-of-primary-media-server>
ip host mediaserver-backup <ip-address-of-secondary-media-server>

The backup server is invoked only if the primary server is not accessible, and this is not a load-balancing mechanism. Each new call attempts to connect to the primary server. If failover occurs, the backup server is used for the duration of the call; the next new call will attempt to connect to the primary server.

Note that Media server is not a fixed name, and it needs to match whatever name was assigned to the media_server ECC variable in the ICM script.

The VoiceXML gateway also uses the following VoiceXML gateway configuration parameters to locate a server when using a ACE: 

ip host mediaserver <ip-address-of-ACE-VIP-for-media-server>
ip host mediaserver-backup <ip-address-of-ACE-VIP-for-media-server>

Because the ACE almost always locates a Media Server on the first request, a backup server is rarely invoked. However, you can configure the backup server when using a ACE for deployments where there are multiple data centers with a ACE in each.

Unified CVP microapplication call dispositions

If the Media server fails, the following conditions apply to the call disposition:

  • Calls in progress should recover automatically. The high-availability configuration techniques described above make the failure transparent to the caller. If the media request does fail, use scripting techniques to work around the error (for example, retry the request, transfer to an agent or label, or use TTS).
  • New calls are directed transparently to the backup media server, and service is not affected.
  • If the Media server is located across the WAN from the VoiceXML gateway and the WAN connection fails, the gateway continues to use prompts from gateway cache until the requested prompt expires, at which time the gateway attempts to reacquires the media and the call fails if survivability is not enabled. If survivability is enabled, the calls are default-routed.

Cisco Unified Call Studio scripting configuration

When scripting in Cisco Unified Call Studio, unlike with ICM scripting, there is no back ability for the media files. The script writer can point to Properties > AudioSettings> > Default Audio Path URI in the application and a single Media Server or the ACE VIP address for a farm of Media Servers.

Unified CVP VXML server

The VoiceXML gateway makes HTTP requests to the Unified CVP VXML Server to obtain VoiceXML documents.


Note

Starting with release 9.0, install the Unified CVP VXML Server with the Unified CVP Call Server and the Media Server. They cannot be installed separately, as in earlier releases

Configuration

The Unified CVP VXML Server high-availability configuration and behavior is different for standalone deployments and deployments that are integrated with ICM, described in the following sections.

Standalone self-service deployments

For instructions on configuring primary and backup Unified CVP VXML Servers, see the latest version of the Cisco Unified CVP Configuration and Administration Guide, available at: http:/​/​www.cisco.com/​en/​US/​products/​sw/​custcosw/​ps1006/​products_​installation_​and_​configuration_​guides_​list.html.

Specifically, it is the CVPPrimaryVXMLServer and CVPBackupVXMLServer gateway parameters that control the high availability characteristics of the Unified CVP VXML Server. If Unified CVP VXML Server load balancing and more robust failover capabilities are desired, ACE device may be used. For configuration details, see the latest version of the Cisco Unified CVP Configuration and Administration Guide. Load balancing can also be achieved without a ACE device by varying the primary and backup Unified CVP VXML Server configurations across multiple gateways.

Deployments using ICM

When a Unified CVP VXML Server is used in conjunction with ICM, the ICM script passes a URL to the VoiceXML gateway in order to invoke the VoiceXML applications. You can configure the ICM script to first attempt to connect to Unified CVP VXML Server A, and if the application fails out the X-path of the Unified CVP VXML Server ICM script node, Unified CVP VXML Server B should be tried. The IP address in the URL can also represent Unified CVP VXML Server VIPs on the ACE.

Call disposition

If the Unified CVP VXML Server fails, the following conditions apply to the call disposition:

  • Calls in progress in a Standalone deployment are disconnected. Calls in progress in an ICM-integrated deployment can be recovered using scripting techniques to work around the error as shown in the script above (for example, retry the request, transfer to an agent or label, or force an error with an END script node to invoke survivability on the originating gateway).
  • New calls are directed transparently to an alternate Unified CVP VXML Server.

    Note

    Without an ACE device, callers might experience a delay at the beginning of the call and have to wait for the system while it tries to connect to the primary Unified CVP VXML Server.

Automatic Speech Recognition and Text-to-Speech server

The VoiceXML gateway sends MRCP requests to the Automatic Speech Recognition/ Text to Speech (ASR/ TTS) servers to perform voice recognition and text-to-speech instructions that are defined in the VoiceXML document.


Note
Since MRCPv2 uses SIP to communicate with ASR/ TTS servers, use a SIP Proxy or gateway dial peers to load balance the MRCPv2 traffic.

Configuration

The ASR/TTS high-availability configuration and behavior are different for Standalone and ICM-integrated deployments, as described in the following sections.

Standalone self-service deployments

An ACE device is required in Standalone deployments to provide failover capabilities for ASR/TTS. For instructions on configuring the ACE device for ASR/TTS and on configuring the ASR/TTS Server in a Standalone deployment, see the latest version of the Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP), available at:

http:/​/​www.cisco.com/​en/​US/​products/​sw/​custcosw/​ps1006/​products_​installation_​and_​configuration_​guides_​list.html

Deployments using ICM

The VoiceXML gateway uses gateway configuration parameters to locate an ASR/TTS server both when using an ACE device and when not using a one. Note that the backup server is invoked only if the primary server is not accessible and if this is not a load-balancing mechanism. Each new call attempts to connect to the primary server. If failover occurs, the backup server is used for the duration of the call; the next new call will attempt to connect to the primary server.

The hostnames (such as asr-en-us) are fixed and cannot be modified. The only portion that may be modified is the locale. In the following example, there is a set of primary and backup English ASR/TTS servers and a set of Spanish servers. Configure the ACE, if used, according to the instructions in the latest version of the Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP), available at

http:/​/​www.cisco.com/​en/​US/​products/​sw/​custcosw/​ps1006/​products_​installation_​and_​configuration_​guides_​list.html

When an ACE is used, the IP addresses mentioned the following example would be the virtual IP address for the ASR/TTS service. 

ip host asr-en-us <ip-address-of-primary-English-ASR-server>
ip host asr-en-us-backup <ip-address-of-secondary-English-ASR-server>
ip host tts-en-us <ip-address-of-primary-English-TTS-server>
ip host tts-en-us-backup <ip-address-of-secondary-English-TTS-server>
ip host asr-es-es <ip-address-of-primary-Spanish-ASR-server>
ip host asr-es-es-backup <ip-address-of-secondary-Spanish-ASR-server>
ip host tts-es-es <ip-address-of-primary-Spanish-TTS-server>
ip host tts-es-es-backup <ip-address-of-secondary-Spanish-TTS-server>

For a discussion of using mixed codecs in CVP deployments, see Mixed G.729 and G.711 codec support. For a discussion of the benefits and drawbacks of each codec, see the Voice traffic.


Note

The ASR speech license is not released until the caller is transferred to the agent.

Call disposition

If the ASR/TTS MRCP server fails, the following conditions apply to the call disposition:

  • Calls in progress in Standalone deployments are disconnected. Calls in progress in ICM-integrated deployments can be recovered using scripting techniques to work around the error. For example, retry the request, transfer to an agent or label, switch to prerecorded prompts and DTMF-only input for the remainder of the call, an error with an END script node to invoke survivability on the originating gateway.
  • New calls in Standalone or ICM-integrated deployments are directed transparently to an alternate ASR/TTS server if a ACE is used. New calls in ICM-integrated deployments are directed transparently to an alternate ASR/TTS server if you use backup gateway.

Cisco Unified Communications Manager

Unified CVP transfers callers to Unified CCE agent phones or desktops using SIP. The Unified CVP Call Server receives an agent label from the ICM and routes the call using SIP proxy. The call is then sent to the appropriate Cisco Unified Communications Manager (Unified CM) in the cluster, which connects the caller to the agent. The Call Server proxies the call signaling, so it remains in the call signaling path after the transfer is completed. However, the RTP stream flows directly from the originating gateway to the phone. This fact becomes very significant in discussions of high availability.

Unified CVP version 9.0(1) also supports the Analysis Manager. See the Analysis Manager.

Configuration

For information on providing Unified CM for high availability, see the latest version of the Cisco Unified Contact Center Enterprise Solution Reference Network Design (SRND) available at: http:/​/​www.cisco.com/​en/​US/​products/​sw/​custcosw/​ps1844/​products_​implementation_​design_​guides_​list.html.

Call disposition

If the Unified CM process fails on the server that is either hosting the call or hosting the phone, the following conditions apply to the call disposition:

  • Calls in progress are preserved. Skinny Client Control Protocol (SCCP) phones have the ability to preserve calls even when they detect the loss of their Unified CM. The caller-and-agent conversation continues until either the caller or agent goes on-hook. The Unified CVP Call Server recognizes that Unified CM has failed, assumes the call should be preserved, and maintains the signaling channel to the originating gateway. In this way, the originating gateway has no knowledge that Unified CM has failed. Note that additional activities in the call (such as hold, transfer, or conference) are not possible. Once the parties go on-hook, the phone is assigned to another Unified CM server. When the agent goes on-hook, Real-Time Control Protocol (RTCP) packets cease transmitting to the originating gateway, which causes the gateway to disconnect the caller 9 to 18 seconds after the agent goes on-hook. If survivability has been configured on the gateway and the caller is waiting for some additional activity (the agent might think the caller is being blind-transferred to another destination), the caller is default-routed to an alternate location.
  • New calls are directed to an alternate Unified CM server in the cluster.

Intelligent Contact Management

Cisco Intelligent Contact Management (ICM) software provides enterprise-wide distribution of multichannel contacts (inbound/outbound telephone calls, Web collaboration requests, email messages, and chat requests) across geographically separated contact centers. ICM software is an open standards-based solution whose capabilities include routing, queuing, monitoring, and fault tolerance.

Configuration

For the most current information on configuring ICM for high availability, refer to the latest version of the Cisco Unified Contact Center Enterprise Solution Reference Network Design (SRND), available at

http:/​/​www.cisco.com/​en/​US/​products/​sw/​custcosw/​ps1844/​products_​implementation_​design_​guides_​list.html

Call disposition

There are many components in Cisco ICM, and call disposition varies depending on the component that fails. Although there are a few exceptions, the following conditions apply to the call disposition:

  • If the primary router fails, calls in progress are unaffected. However, if the time for the VRU PG to realign to the other router is higher that the IVR service timeout ( 5 seconds default), calls in progress are default-routed by survivability on the originating gateway. If both the Side A and Side B routers fail, calls in progress are default-routed by survivability on the originating gateway.
  • If the Logger fails, calls in progress are unaffected.
  • If the primary router fails, calls in progress are unaffected. If both the Side A and Side B routers fail, calls in progress are default-routed by survivability on the originating gateway.
  • New calls are directed to the backup ICM component.