After choosing a functional deployment model and distributed deployment options, Unified CVP solution designers must choose the amount of availability required. Unified CVP solution designers can increase solution availability in the following areas:

• Multiple gateways, Unified CVP Servers, Unified CVP VXML Servers and VRU PGs—Enables inbound and outbound call processing and IVR services to continue upon component failure.

• Multiple call processing locations—Enables call processing to continue in the event of a loss of another call processing location.

• Redundant WAN links—Enables Unified CVP call processing to occur upon failure of individual WAN links.

• ACE—Used for server load balancing and failover.

It is also possible to use a combination of these high availability options to be utilized.

Note	Unified CVP VXML Server is coresident with Unified CVP Call Server.

For information to provide redundancy and reliability for originating gateways and T1/E1 lines, see the latest version of the Design Guide for Cisco Unified Customer Voice Portal available at http://www.cisco.com/c/en/us/support/customer-collaboration/unified-customer-voice-portal/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, SIP does not have redundancy features built into the protocol. Instead, SIP relies on the gateways and call processing components for redundancy. The following configurations allow call signaling to operate independent of the physical interfaces. In this way, if one interface fails, the other interface can handle the traffic.

  • With dial-peer level bind, you can set up a different bind based on each dial peer. The dial peer bind eliminates the need to have a single interface reachable from all subnets. Dial peer helps in segregating the traffic from different networks (for example, SIP trunk from SP side and SIP trunk towards Unified Communications Manager or CVP). The dial peer level binding is illustrated in the following configuration example:

      Using voice-class sip bind 
       dial-peer voice 1 voip
       voice-class sip bind control source-interface GigabitEthernet0/0
    

  • For other gateways, global binding should be used. 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 are 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, then consider using filters to limit the routing updates so that the gateway is only advertising the loopback address and not receiving routes. It is best to bind the SIP signaling to the virtual loopback interface, as illustrated in the following configuration example:

    SIP

      voice service voip
       sip
        bind control source-interface Loopback0
        bind media source-interface Loopback0

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

• Calls in progress are dropped. These calls cannot be preserved because the PSTN switch loses 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 that the PSTN switch has its trunks and dial plan configured.

Unified CVP has been validated with Cisco Unified SIP Proxy Server (CUSPServer), which implies that Unified CVP supports only CUSP proxy servers.

• CUSP is a dedicated SIP proxy server.

• CUSP server runs on the gateway.

  For additional information, see the Solution sizing tool at http://tools.cisco.com/cucst/faces/login.jsp.

  Note	For information on CUSP version numbers, see the Hardware and System Software Specification for Cisco Unified Customer Voice Portal at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/prod_technical_reference_list.html.

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.

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

If the Proxy Server Record Route is set to on, it impacts the performance of the proxy server (as shown in the CUSP baseline matrix) and it also breaks the high-availability model because the proxy becomes a single point of failure for the call. Always turn the Record Route setting of the Proxy Server to off to avoid a single point of failure, to allow fault tolerance routing, and to increase the performance of the Proxy Server.

Record Route is turned off by default on CUSP.

Note

Upstream Element Routing with SIP Heartbeats With CUSP proxy, any response to an 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.

The standard for Unified CVP and CUSP proxy sizing is to define four SIP calls for every one CVP call, so considering there are 500 UDP transactions per second, the CPS rate is 500 / 4 = 125. The overall number of active calls is a function of Call Rate (CPS) * call handle time (CHT). Assuming an average call center call duration of 180 seconds (CHT), you get an overall active call value of 22,500 calls. Because one Call Server can handle approximately 900 simultaneous calls, it allows a single CUSP proxy to handle the load of 18 CVP Call Servers. A customer deployment should include consideration of the CPS and the CHT to size the proxy for their solution.

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 based on the priorities.

To reduce the impact of a Proxy Server failure, you can 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.

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 the dial peer configuration while also providing DNS SRV load balancing and redundancy. The disadvantage 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.132
   ip 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.com 
   ip 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.com 
   ip 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

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 enter 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.

When a Call Server fails with calls in progress, it is possible to restore all calls if certain gateway configuration steps are done. 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 described 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 happens 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 that 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 Call Server Sizing for call server call rate details.

For call survivability, configure the originating gateways as described in the latest version of the Configuration 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

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 method 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.

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 is awaiting for 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.)

The Server Group heartbeat default setting tracks 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 endpoints. 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, because 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 Guide for Cisco Unified Customer Voice Portal for typical configurations for the Server Group feature, available at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

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.

Observe the following design considerations when implementing Server Group:

• When you use the Local SRV configuration, you cannot use 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.

The Unified CVP log file has traces that display endpoint status events. See the Unified CVP System CLI instructions in the Configuration 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.

No additional configuration is required for SIP service to use IVR service. By default, the SIP service uses 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 use this information to determine 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 IOS VoiceXML Gateway 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

Note	For configuring the same feature in Cisco VVB, see section "Cisco VVB configuration for Comprehensive Call Flows".

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 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 IOS Voice 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 Guide for Cisco Unified Customer Voice Portal, available at:

https://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html

The 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.

If 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 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	VXML Server uses two features 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 Cisco Unified CVP VXML Server and Cisco Unified Call Studio, available at https://www.cisco.com/c/en/us/support/customer-collaboration/unified-customer-voice-portal/products-user-guide-list.html.

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 from the Ingress Gateway and can be 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 do not want the IVR leg of the call to go back to the Ingress Voice Gateway. 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.

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 method. 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 the 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 ACE.

Note	This feature is not required for Cisco VVB as DNS is used to resolve the hostname.

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 in the previous section (Unified CVP Microapplication Configuration) makes the failure transparent to the caller. If the media request fails, 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 the 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.

For the CVP Whisper Announcement service failover to function, duplicate the Whisper media on multiple Media Servers that are mapped by using the ACE VIP address.

For the Agent Greeting failover feature to function, configure the Agent Greeting service to duplicate the greetings recording on multiple Media Servers by configuring the default Media Server to act as a proxy. Afterwards, map the ACE VIP address to the farm of Media Servers.

For more information, see Agent Greeting and Whisper Announcement Feature Guide for Cisco Unified Contact Center Enterprise.

When scripting in Cisco Unified Call Studio, unlike with ICM scripting, there is no reverse 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.

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.

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 (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.

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

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.

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.

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

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.