Core Solution Component Considerations. Cisco Hosted Collaboration Solution for Contact Center

Design Consideration

Core Solution Component Considerations

Call Flow

New call for agent based

Logical Call Routing

Caller --> TDM-IP --> Perimeta SBC -->CUBE-E

--> Unified CVP --> Perimeta SBC--> Unified

Communications Manager

The following table lists the supported system call flows.

Note

1

Configure TDM gateway at Perimeta SBC, see

Add CUBE(E) Adjacency, on page 487

2

Configure TDM gateway at shared layer, similar to PSTN configuration.

Table 21: Supported System Call Flows

System Call Flows

Conference to IVR

Bridged transfer

Router requery

Postroute using Unified CVP

Prerouting

Translation route with third-party VRU

ICM routing to devices other than Cisco HCS Unified CCE

Supported

Yes

Yes

Yes

Yes

No

No

No

Table 22: Avaya Call Flow

Call Flow

New call from local PSTN gateway

Logical Call Routing

Caller --> CUBE(E) --> Unified CVP --> TDM -->

Avaya

Post Routed call from Avaya Agent – CUCM Agent

Avaya Agent --> Avaya --> Unified CVP --> Unified

Communication Manager --> Agent

Core Solution Component Considerations

This section describes the High availability and Bandwidth, Latency & QoS considerations for Cisco HCS

Contact Center core components:

94

Installing and Configuring Guide for Cisco HCS for CC 11.0(1)


Core Component Design Considerations

•

Core Component Design Considerations, on page 95

•

Core Component High Availability Considerations, on page 105

•

Core Component Bandwidth, Latency and QOS Considerations, on page 117


The section describes the design considerations for Cisco for Contact Center core components:

•

Unified CCE Design Consideration, on page 95

•

Unified CVP Design Considerations, on page 98

•

Unified CM Design Considerations, on page 101

•

Unified IC Design Considerations, on page 103

Unified CCE Design Consideration

This section describes the Unified CCE design for each deployment:

•

Unified CCE Design for 500 Agent Deployment, on page 96

•


•


•



95


Unified CCE Design for 500 Agent Deployment

Figure 22: Unified CCE Design for 500 Agent Deployment




96







97





Unified CVP Design Considerations

This section describes the CVP design for each deployment:

•

Unified CVP Design for 500 Agent Deployment, on page 99

•


•


•


98



Unified CVP Design for 500 Agent Deployment

Figure 26: Unified CVP Design for 500 Agent Deployment





99





100






Unified CM Design Considerations

This section contains the Unified CM cluster design considerations for HCS deployment models.

•

Unified CM Design for 500 and 1000 Agent Deployment Models , on page 101

•

Unified CM Design for 4000 Agent Deployment Model , on page 102

•

Unified CM Design for 12000 Agent Deployment Model, on page 103

Unified CM Design for 500 and 1000 Agent Deployment Models


101


Unified CM Design for 4000 Agent Deployment Model


102



Unified CM Design for 12000 Agent Deployment Model


Unified IC Design Considerations

This section describes IC design for each deployments:

•

Unified IC Design for 500 and 1000 Agent Deployments, on page 104

•

Unified IC Design for 4000 Agent Deployment, on page 104

•

Unified IC Design for 12000 Agent Deployment, on page 105


103


Unified IC Design for 500 and 1000 Agent Deployments

Figure 30: Unified IC Design for 500 and 1000 Agent Deployments


Unified IC Design for 4000 Agent Deployment

Figure 31: Unified IC Design for 4000 Agent Deployment

104



Unified IC Design for 12000 Agent Deployment

Figure 32: Unified IC Design for 12000 Agent Deployment

Core Component High Availability Considerations


This section describes the High Availability considerations for Cisco HCS for Contact Center core components:

•

Unified CCE High Availability, on page 107

•

Unified CVP High Availability, on page 109

•

Unified CM High Availability, on page 111

•

Gateway High Availability, on page 115

•

MRCP ASR/TTS High Availability, on page 115

•

Cisco Finesse High Availability, on page 115

The following table shows the failover scenarios for the HCS for Contact Center components, the impact on active and new calls, and the postrecovery actions.


105



Table 23: HCS for Contact Center Failover

Component

Unified CM

Gateway

MRCP

ASR/TTS

Failover scenario

Visible network failure

New call impact

Disrupts new calls while the phones route to the backup subscriber. Processes the calls when the routing completes.

Active call impact Post recovery action

In-progress calls remain active, with no supplementary services such as conference or transfer.

After the network of the primary subscriber becomes active, the phones align to the primary subscriber.

Call manager service in Unified

CM primary subscriber failure



After the call manager service in the Unified CM primary subscriber recovers, all idle phones route back to the primary subscriber.

Unified CM CTI

Manager service on primary subscriber failure



After the Unified

CM CTI Manager service on primary subscriber recovers, peripheral gateway side B remains active and uses the

CTI Manager service on the

Unified CM backup subscriber. The peripheral gateway does not switch over.

Primary gateway is unreachable

New calls redirect to the backup gateway.

In-progress calls become inactive.

After the primary gateway restores, calls (active and new) route back to the primary gateway.

Primary server is not accessible

New calls redirect to the backup ASR/TTS server

In-progress calls remain active and redirect to the backup ASR/TTS server.

After the primary server restores, calls

(active and new) route back to the primary ASR/TTS server.

106




Component

Blade

WAN Link

Failover scenario

Blade failover

New call impact

Disrupts new calls while backup server components become active.

Active call impact Post recovery action

In-progress calls become inactive.

After backup server components restores, calls

(active and new) route back to the primary server.

Unified CM calls survivability during WAN link failure.

The new calls redirects to the Survivable

Remote Site Telephony

(SRST).

The in-progress calls redirects to the

Survivable Remote Site

Telephony (SRST).

After the WAN

Link restores, the calls redirects to the

Unified

Communications

Manager.

Unified CVP calls survivability during WAN link failure.

A combination of services from a TCL script (survivability.tcl) and SRST functions handles survivability new calls.

The TCL script redirects the new calls to a configurable destination.

A combination of services from a TCL script (survivability.tcl) and SRST functions handles survivability in-progress calls.

The TCL script redirects the new calls to a configurable destination.

Note

The destination choices for the

TCL script are configured as parameters in the Cisco IOS

Gateway configuration.

The new calls can also be redirected to the alternative destinations, including the SRST, *8

TNT, or hookflash. For transfers to the SRST call agent, the most common target is an

SRST alias or a Basic

ACD hunt group.

Note

The destination choices for the

TCL script are configured as parameters in the Cisco IOS

Gateway configuration.

The in-progress calls can also be redirected to the alternative destinations, including the SRST, *8

TNT, or hookflash. For transfers to the SRST call agent, the most common target is an

SRST alias or a Basic

ACD hunt group.

After the WAN

Link restores, the calls redirects to the

Unified CVP.

Unified CCE High Availability

In 500 and 1000 agent deployment model the Unified CCE Call Server contains the Unified CCE Router,

Unified CCE PG, CG, and the CTI OS server and the Database server contains the Logger and the Unified


107



CCE Administration Server and Real-Time Data Server. In 4000 agent deployment the Unified CCE Rogger contains Router and Logger, Unified PG server contains PG, CG, and CTI OS Server.

This section describes how high availability works for each component within a Unified CCE Call Server and

Unified Database Server or within CCE Rogger and PG servers.

Agent PIM

Connect Side A of Agent PIM to one subscriber and Side B to another subscriber. Each of Unified CM subscribers A and B must run a local instance of CTI Manager. When PG(PIM) side A fails, PG(PIM) side

B becomes active. Agents’ calls in progress continue but with no third-party call control (conference, transfer, and so forth) available from their agent desktop softphones. Agents that are not on calls may notice their CTI desktop disable their agent state or third-party call control buttons on the desktop during the failover to the

B-Side PIM. After the failover completes, the agent desktop buttons are restored. When PG side A recovers,

PG side B remains active and uses the CTI Manager on Unified CM Subscriber B. The PIM does not fail-back to the A-Side, and call processing continues on the PG Side B.

VRU PIM

When the VRU PIM fails, all the calls in progress or queued in the Unified CVP does not drop. The Survivability

TCL script in the Voice Gateway redirects the calls to a secondary Unified CVP or a number in the SIP dial plan, if available. The redundant (duplex) VRU PIM side connects to the Unified CVP and begins processing new calls upon failover. The failed VRU PIM side recovers, and the currently running VRU PIM continues to operate as the active VRU PIM.

CTI Server

CTI Server is redundant and resides on the Unified CCE Call server or PG. When the CTI Server fails, the redundant CTI server becomes active and begins processing call events. Both CTI OS and Unified Finesse

Servers are clients of the CTI Server and are designed to monitor both CTI Servers in a duplex environment and maintain the agent state during failover processing. Agents (logged in to either CTI OS desktops or Cisco

Finesse) see their desktop buttons dim during the failover to prevent them from attempting to perform tasks while the CTI Server is down. The buttons are restored as soon as the redundant CTI Server is restored and the agent can resume tasks . In some cases, an agent must sign in again after the failover completes.

CTI OS Server

CTI OS server is a software component that runs co-resident on the Unified CCE Call server or PG. Unlike the PG processes that run in hot-standby mode, both of the CTI OS Server processes run in active mode all the time. The CTI OS server processes are managed by Node Manager, which monitors each process running as part of the CTI OS service and which automatically restarts abnormally terminated processes. When a CTI

OS client loses connection to CTI OS side A, it automatically connects to CTI OS server side B. During this transition, the buttons of the CTI Toolkit Agent Desktop are disabled and return to the operational state as soon as it is connected to CTI OS server B. Node Manager restarts CTI OS server A. When the failed server restarts, new agent desktop sessions can sign in on that server. Agent desktops that are signed in on the redundant server remain on that server.

108




Unified CCE Call Router

The Call Router software runs in synchronized execution. Both of the redundant systems run the same memory image of the current state across the system and update this information by passing the state events between the servers on the private connection. If one of the Unified CCE Call Routers fails, the surviving server detects the failure after missing five consecutive TCP keepalive messages on the private LAN. During Call Router failover processing, any Route Requests that are sent to the Call Router from a peripheral gateway (PG) are queued until the surviving Call Router is in active simplex mode. Any calls in progress in the Unified CVP or at an agent are not impacted.

Unified CCE Logger

If one of the Unified CCE Logger and Database Servers fails, there is no immediate impact except that the local Call Router is no longer able to store data from call processing. The redundant Logger continues to accept data from its local Call Router. When the Logger server is restored, the Logger contacts the redundant

Logger to determine how long it was off-line. The Loggers maintain a recovery key that tracks the date and time of each entry recorded in the database and these keys are used to restore data to the failed Logger over the private network. Additionally, if the Unified Outbound Option is used, the Campaign Manager software is loaded on Logger A only. If that platform is out of service, any outbound calling stops until the Logger is restored to operational status.

Unified CCE Administration and Data Server

The Unified Contact Center Enterprise Administration and Data Server provides the user interface to the system for making configuration and scripting changes. This component does not support redundant or duplex operation as do the other Unified Contact Center Enterprise system components.

Unified CVP High Availability

Unified CVP high availability describes the behavior of the following Unified CVP solution components.

•

Unified CVP Call Server, on page 109

•

Unified CVP Media Server, on page 110

•

Cisco Voice XML Gateway, on page 110

•

Unified CVP Reporting Server, on page 111

•

Unified CM, on page 111

Unified CVP Call Server

The Unified CVP Call Server component provides the following independent services:

•

Unified CVP SIP Service, on page 110

•

Unified CVP IVR Service, on page 110


109



Unified CVP SIP Service

The Unified CVP SIP Service handles all incoming and outgoing SIP messaging and SIP routing. If the SIP service fails, the following conditions apply to call disposition:

• Calls in progress - If the Unified CVP SIP Service fails after the caller is transferred (including transfers to an IP phone or VoiceXML gateway), then the call continues normally until a subsequent transfer activity (if applicable) is required from the Unified CVP SIP Service.

• New calls - New calls are directed to an alternate Unified CVP Call Server.

Unified CVP IVR Service

The Unified CVP IVR Service creates the Voice XML pages that implement the Unified CVP Micro applications based on Run VRU Script instructions received from Cisco Unified Intelligent Contact Management

(ICM). If the Unified CVP IVR Service fails, the following conditions apply to the call disposition:

• Calls in progress - Calls in progress are routed by default to an alternate location by survivability on the originating gateway.

• New calls - New calls are directed to an in-service Unified CVP IVR Service.

Unified CVP Media Server

Store the audio files locally in flash memory on the VoiceXML gateway or on an HTTP or TFTP file server.

Audio files stored locally are highly available. However, HTTP or TFTP file servers provide the advantage of centralized administration of audio files. If the media server fails, the following conditions apply to the call disposition:

• Calls in progress - Calls in progress recover automatically. The high-availability configuration techniques make the failure transparent to the caller.

• New calls - New calls are directed transparently to the backup media server, and service is not affected.

• The Unified CVP VXML Server executes advanced IVR applications by exchanging VoiceXML pages with the VoiceXML gateways’ built-in voice browser. If the Unified CVP VXML Server fails, the following conditions apply to the call disposition:

◦Calls in progress - Calls in progress in an ICM-integrated deployment can be recovered using scripting techniques.

◦New calls - New calls are directed transparently to an alternate Unified CVP VXML Server.

Cisco Voice XML Gateway

The Cisco VoiceXML gateway parses and renders VoiceXML documents obtained from one or several sources.

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

• Calls in progress - Calls in progress are routed by default to an alternate location by survivability on the ingress gateway.

• New calls - New calls find an alternate VoiceXML gateway.

110




Unified CVP Reporting Server

The Reporting Server does not perform database administrative and maintenance activities such as backups or purges. However, the Unified CVP provides access to such maintenance tasks through the Operations

Console. The Single Reporting Server does not necessarily represent a single point of failure, because data safety and security are provided by the database management system, and temporary outages are tolerated due to persistent buffering of information on the source components.

Unified CM

The Unified CVP Call Server recognizes that the 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.

Additional activities in the call (such as hold, transfer, or conference) are not possible. After the parties go on-hook, the phone routes to another Unified CM server.

New calls are directed to an alternate Unified CM server in the cluster.

Unified CM High Availability

•

Unified CM Design Considerations, on page 101

•

Unified CM High Availability Scenarios , on page 111

Unified CM High Availability Scenarios

This section contains various high availability scenarios including Unified CM PG and Unified CM services.

•

Cisco Call Manager and CTI Manager Service Fail , on page 111

•

Cisco CTI Manager Service Fails , on page 112

•

Cisco Call Manager Service Fails , on page 114

Cisco Call Manager and CTI Manager Service Fail

This scenario describes about a complete system failure or loss of network connectivity on Unified CM

Subscriber A. The Cisco CTI Manager and Call Manager services are both active on the same server, and

Unified CM Subscriber A is the primary CTI Manager in this case. The following conditions apply to this scenario.

• All phones and gateways are registered with Unified CM Subscriber A.

• All phones and gateways are configured to re-home to Unified CM Subscriber B( here B is the backup).

• Unified CM Subscriber A and B are each running a separate instance of CTI Manager.

• When all of the software services on Unified CM Subscriber A fail (call processing, CTI Manager, and so on), all phones and gateways re-home to Unified CM Subscriber A.

• PG side A detects a failure and induces a failover to PG side B.

• PG side B becomes active and registers all dialed numbers and phones; call processing continues.


111



• After an agent disconnects from all calls, the IP phone re-homes to the backup Unified CM Subscriber

B. The agent will have to log in again manually using the agent desktop.

• When Unified CM Subscriber A recovers, all phones and gateways re-home to it.

• PG side B remains active, using the CTI Manager on Unified CM Subscriber B.

• During this failure, any calls in progress at an UCCE agent will remain active. When the call is completed, the phone will re-home to the backup Unified CM Subscriber B automatically.

• After the failure is recovered, the PG will not fail back to the A side of the duplex pair. All CTI messaging will be handled using the CTI Manager on Unified CM Subscriber B, this will communicate to Unified

CM Subscriber A to obtain phone state and call information

Figure 33: Subscriber Failure

Cisco CTI Manager Service Fails

This scenario describes about a CTI Manager service failure on Unified CM Subscriber A. The CTI Manager and Cisco Call Manager services are both active on the same server, and Unified CM Subscriber A is the primary CTI Manager in this case. However, all phones and gateways are registered with Unified CM Subscriber

A. During this failure, both the CTI Manager and the PG fail-over to their secondary sides. Because the JTAPI

112




service on PG side B is already logged into the secondary (now primary) CTI Manager, the device registration and initialization time is significantly shorter than if the JTAPI service on PG side B had to log into the CTI

Manager. The following conditions apply to this scenario.


• All phones and gateways are configured to re-home to Unified CM Subscriber B (here B is the backup).

• Unified CM Subscribers A and B are each running a separate instance of CTI Manager.

• When CTI Manager service on Unified CM Subscriber A fails, PG side A detects a failure of the CTI

Manager on that server and induces a failover to PG side B.

• PG side B registers all dialed numbers and phones with Unified CM Subscriber B, and call processing continues.

• After an agent disconnects from all calls, that agent's desktop functionality is restored to the same state prior to failover.


113



• When Unified CM Subscriber A recovers, PG side B continues to be active and uses the CTI Manager on Unified CM Subscriber

Figure 34: CTI Manager Failure

Cisco Call Manager Service Fails

This scenario describes about a failure on Cisco Call Manager service on Unified CM Subscriber A. The CTI

Manager and Cisco Call Manager services are both active on the same server, and Unified CM Subscriber A is the primary CTI Manager in this case. However, all phones and gateways are registered with Unified CM

Subscriber A. During this failure, Cisco CTI Manager is not affected because the PG communicates with the

CTI Manager service, not the Cisco Call Manager service. All phones re-home individually to the standby

Unified CM Subscriber B, if they are not in a call. If a phone is in a call, it re-homes to Unified CM Subscriber

B after it disconnects from the call. The following conditions applies to this scenario.


• All phones and gateways are configured to re-home to Unified CM Subscriber B (that is, B is the backup).

• Unified CM Subscribers A and B are each running a separate instance of CTI Manager.

114




• When Cisco Call Manager service in Unified CM Subscriber A fails, phones and gateways re-home to

Unified CM Subscriber B.

• PG side A remains connected and active, with a CTI Manager connection on Unified CM Subscriber

A. It does not fail-over because the JTAPI/CTI Manager connection has not failed. However, it will see the phones and devices being unregistered from Unified CM Subscriber A (where they were registered) and will then be notified of these devices being re-registered on Unified CM Subscriber B automatically.

During the time that the agent phones are not registered, the PG will disable the agent desktops to prevent the agents from attempting to use the system while their phones are not actively registered with a Unified

CM Subscriber B

• Call processing continues for any devices not registered to Unified CM Subscriber A. Call processing also continues for those devices on Unified CM Subscriber A when they are re-registered with their backup subscriber.

• Agents on an active call will stay in their connected state until they complete the call; however, the agent desktop will be disabled to prevent any conference, transfer, or other telephony events during the failover.

After the agent disconnects the active call, that agent's phone will re-register with the backup subscriber, and the agent will have to log in again manually using the agent desktop.

• When Unified CM Subscriber A recovers, phones and gateways re-home to it. This re-homing can be set up on Unified CM to gracefully return groups of phones and devices over time or to require manual intervention during a maintenance window to minimize the impact to the call center.

• Call processing continues normally after the phones and devices have returned to their original subscriber.

Gateway High Availability

If the primary gateway is unreachable, the CUBE redirects the calls to the backup gateway. Active calls fail.

After the primary gateway becomes accessible, calls are directed back to the primary gateway.

MRCP ASR/TTS High Availability

The VoiceXML gateway uses gateway configuration parameters to locate an ASR/TTS primary and the backup server. 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 attempts to connect to the primary server.

Cisco Finesse High Availability

Cisco Finesse high availability affects the following components:

•

CTI, on page 116

•

AWDB, on page 116

•

Cisco Finesse Client, on page 117

•

Desktop Behavior, on page 117


115



CTI

Pre-requisites for CTI high availability

The prerequisites for CTI high availability are as follows:

1

The Unified CCE is deployed in Duplex mode.

2

The backup CTI server is configured through the Finesse Administration Console.

When Cisco Finesse loses connection to the primary CTI server, it tries to reconnect five times. If the number of connection attempts exceeds the retry threshold, Cisco Finesse then tries to connect to the backup CTI server the same number of times. Cisco Finesse keeps repeating this process until it makes a successful connection to the CTI server.

A loss of connection to the primary CTI server can occur for the following reasons:

• Cisco Finesse misses three consecutive heartbeats from the connected CTI server.

• Cisco Finesse encounters a failure on the socket opened to the CTI server.

AWDB

Note

The new calls and the existing calls do not have any impact during the CTI failover.

During failover, Cisco Finesse does not handle client requests. Requests made during this time receive a

503

Service Unavailable error message. Call control, call data, or agent state actions that occur during CTI failover are published as events to the Agent Desktop following CTI server reconnection.

If an agent makes or answers a call and ends that call during failover, the corresponding events are not published following CTI server reconnection.

Additionally, CTI failover may cause abnormal behavior with the Cisco Finesse Desktop due to incorrect call notifications from Unified CCE. If during failover an agent or supervisor is in a conference call, or signs-in after being on active conference with other devices not associated with another agent or supervisor, the following desktop behaviors may occur:

• The desktop does not reflect all participants in a conference call.

• The desktop does not reflect that the signed-in agent or supervisor is in an active call.

• Cisco Finesse receives inconsistent call notifications from the Unified CCE.

Despite these behaviors, the agent or supervisor can continue to perform normal operations on the phone and normal desktop behavior resumes after the agent or supervisor drops-off the conference call.

Pre-requisites for AWDB high availability

The prerequisites for Administrative Workstation Database (AWDB) high availability are as follows:

• The secondary AWDB is configured.

• The secondary AWDB host is configured through the Finesse Administration Console.

The following example describes how AWDB failover occurs:

116



Core Component Bandwidth, Latency and QOS Considerations

• When an agent or supervisor makes a successful API request (such as a sign-request or call control request) their credentials are cached in Cisco Finesse for 30 minutes from the time of the request.

Therefore, after an authentication, that user is authenticated for 30 minutes, even if both AWDB(s) are down. Cisco Finesse attempts to re-authenticate the user only after the cache expires.

• AWDB failover occurs if Cisco Finesse loses connection to the primary server and it tries to reconnect to the secondary server. If it cannot connect to any of the AW servers and the cache expired, it returns a

401 Unauthorized HTTP error message.

Cisco Finesse repeats this process for every API request until it connects to one of the AW servers.

During failover, Cisco Finesse does not process requests, but clients still receive events.

Note

The new calls and the existing calls do not have any impact during the AWDB failover.

Cisco Finesse Client

With a two-node Cisco Finesse setup (primary and secondary Cisco Finesse server), if the primary server goes out of service, agents who are signed-in to that server are redirected to the sign-in page of the secondary server.

Client failover can occur for the following reasons:

• The Cisco Tomcat Service goes down.

• The Cisco Finesse Web application Service goes down.

• The Cisco Notification Service goes down.

• Cisco Finesse loses connection to both CTI servers.

Desktop Behavior

If the Cisco Finesse server fails, the agents logged into that server are put into a NOT READY or pending

NOT READY state. Agents remain unaffected as they migrate to the back up side.

If a client disconnects, the agent is put into a NOT READY state with reason code 255. If the agent reconnects within minutes or seconds, the agent is forced to log out.


This section describes the bandwidth and QOS considerations for Cisco HCS for Contact Center core and optional components.

•

Unified CCE Bandwidth, Latency and QOS Considerations, on page 118

•

Unified CVP Bandwidth, Latency and QOS Considerations, on page 121

•

Unified CM Bandwidth, Latency and QOS Considerations, on page 122

•

Unified IC Bandwidth, Latency and QOS Considerations, on page 123

•

Cisco Finesse Bandwidth, Latency and QOS Considerations, on page 126


117



Unified CCE Bandwidth, Latency and QOS Considerations

Agent Desktop to Unified CCE Call Servers/ Agent PG

There are many factors to consider when assessing the traffic and bandwidth requirements between Agent or

Supervisor Desktops and Unified CCE Call Servers/Agent PG. While the VoIP packet stream bandwidth is the predominant contributing factor to bandwidth usage, you must also consider other factors such as call control, agent state signaling, silent monitoring, recording, and statistics.

The amount of bandwidth required for CTI Desktop to CTI OS Server messaging is (0.5 x n) + (16 x cps), where n is the number CTI Clients and cps is the number of calls per second.

For example, for a 500 agent deployment, for each contact center (datacenter) and remote site the approximate bandwidth is, (0.5 x 500) + (16 x 1) = 340 kbps.

For example, for a 1000 agent deployment, for each contact center (datacenter) and remote site the approximate bandwidth is, (0.5 x 1000) + (16 x 8) = 608 kbps.

Cisco supports limiting the latency between the server and agent desktop to 400 ms round-trip time for CTI

OS (preferably less than 200 ms round-trip time).

Unified CCE Data Server to Unified CCE Call Server for 500 and 1000 Agent Deployment Model

Unified CCE Central Controllers (Routers and Loggers) require a separate network path or link to carry the private communications between the two redundant sides. Latency across the private separate link must not exceed 100 ms one way (200 ms round-trip), but 50 ms (100 ms round-trip) is preferred.

Private Network Bandwidth Requirements for Unified CCE

The following table is a worksheet to assist with computing the link and queue sizes for the private network.

Definitions and examples follow the table.

Note

Minimum link size in all cases is 1.5 Mbps (T1).

Table 24: Worksheet for Calculating Private Network Bandwidth

Component

Router +

Logger

Effective

BHCA

Multiplication

Factor

Recommended

Link

Multiplication

Factor

Recommended

Queue

* 30 * 0.8

Total Router

+ Logger

High- Priority

Queue

Bandwidth

118




Component Effective

BHCA

Unified CM

PG

Unified VRU

PG

Unified CVP

Variables

Multiplication

Factor

Recommended

Link

Multiplication

Factor

Recommended

Queue

* 100 * 0.9

* 120

* ((Number of Variables *

Average

Variable

Length)/40)

* 0.9

* 0.9

Add these numbers together and total in the box below to get the PG

High- Priority

Queue

Bandwidth

Total Link

Size

Total PG

High-Priority

Queue

Bandwidth

If one dedicated link is used between sites for private communications, add all link sizes together and use the

Total Link Size at the bottom of the table above. If separate links are used, one for Router/Logger Private and one for PG Private, use the first row for Router/Logger requirements and the bottom three (out of four) rows added together for PG Private requirements.

Effective BHCA (effective load) on all similar components that are split across the WAN is defined as follows:

Router + Logger

This value is the total BHCA on the call center, including conferences and transfers. For example,10,000

BHCA ingress with 10% conferences or transfers are 11,000 effective BHCA.

Unified CM PG

This value includes all calls that come through Unified CCE Route Points controlled by Unified CM and/or that are ultimately transferred to agents. This assumes that each call comes into a route point and is eventually sent to an agent. For example, 10,000 BHCA ingress calls coming into a route point and being transferred to agents, with 10% conferences or transfers, are 11,000 effective BHCA.

Unified VRU PG

This value is the total BHCA for call treatment and queuing coming through a Unified CVP. 100%treatment is assumed in the calculation. For example, 10,000 BHCA ingress calls, with all of them receiving treatment and 40% being queued, are 14,000 effective BHCA.

Unified CVP Variables

This value represents the number of Call and ECC variables and the variable lengths associated with all calls routed through the Unified CVP, whichever technology is used in the implementation.

Example of a Private Bandwidth Calculation

The table below shows an example calculation for a combined dedicated private link with the following characteristics:

• BHCA coming into the contact center is 10,000.


119



• 100% of calls are treated by Unified CVP and 40% are queued.

• All calls are sent to agents unless abandoned. 10% of calls to agents are transfers or conferences.

• There are four Unified CVPs used to treat and queue the calls, with one PG pair supporting them.

• There is one Unified CM PG pair for a total of 900 agents.

• Calls have ten 40-byte Call Variables and ten 40-byte ECC variables.

Table 25: Example Calculation for a Combined Dedicated Private Link

Component

Router +

Logger

Unified CM

PG

Unified VRU

PG

Unified CVP

Variables

Effective

BHCA

11,000

11,000

0

14,000

Multiplication

Factor

Recommended

Link

Multiplication

Factor

Recommended

Queue

* 30 330,000 * 0.8

264,000 Total Router

+ Logger

High- Priority

Queue

Bandwidth

* 100

* 120

* ((Number of Variables *

Average

Variable

Length)/40)

Total Link

Size

1,100,000

0

280,000

1,710,000

* 0.9

* 0.9

* 0.9

990,000

0

252,000

1,242,000

Add these numbers together and total in the box below to get the PG

High- Priority

Queue

Bandwidth

Total PG

High-Priority

Queue

Bandwidth

For the combined dedicated link in this example, the results are as follows:

• Total Link Size = 1,710,000 bps

• Router/Logger high-priority bandwidth queue of 264,000 bps

• PG high-priority queue bandwidth of 1,242,000 bps

If this example were implemented with two separate links, Router/Logger private and PG private, the link sizes and queues are as follows:

• Router/Logger link of 330,000 bps (actual minimum link is 1.5 Mb, as defined earlier), with high-priority bandwidth queue of 264,000 bps

• PG link of 1,380,000 bps, with high-priority bandwidth queue of 1,242,000 bps

120




When using Multilink Point-to-Point Protocol (MLPPP) for private networks, set the following attributes for the MLPPP link:

• Use per-destination load balancing instead of per-packet load balancing.

• Enable Point-to-Point Protocol (PPP) fragmentation to reduce serialization delay.

Note

You must have two separate multilinks with one link each for per-destination load balancing.

Unified CVP Bandwidth, Latency and QOS Considerations

Bandwidth Considerations for Unified CVP

The ingress and VoiceXML gateway is separated from the servers that provide it with media files, VoiceXML documents, and call control signaling. Therefore, you must consider the bandwidth requirement for the Unified

CVP.

For example, assume that all calls to a branch begin with 1 minute of IVR treatment followed by a single transfer to an agent that lasts for 1 minute. Each branch has 20 agents, and each agent handles 30 calls per hour for a total of 600 calls per hour per branch. The call average rate is therefore 0.166 calls per second (cps) per branch.

Note that even a small change in these variables can have a large impact on sizing. Remember that 0.166 calls per second is an average for the entire hour. Typically, calls do not come in uniformly across an entire hour, and there are usually peaks and valleys within the busy hour. You should find the busiest traffic period, and calculate the call arrival rate based on the worst-case scenario.

VoiceXML Document Types

On average, a VoiceXML document between the Unified CVP Call Server or Unified CVP VXML Server and the gateway is 7 kilobytes. You can calculate the bandwidth used by approximating the number of prompts that are used per call, per minute. The calculation, for this example, is as follows:

7000 bytes x 8 bits = 56,000 bits per prompt

(0.166 call/second) x (56,000 bit/prompt) x (no. of prompts/call) = bps per branch

Media File Retrieval

You can store the Media files prompts locally in flash memory on each router. This method eliminates bandwidth considerations, but maintainability becomes an issue because you must replace the prompts on every router. If you store the prompts on an HTTP media server (or an HTTP cache engine), the gateway can locally cache voice prompts after it first retrieves them. The HTTP media server can cache many, if not all, prompts, depending on the number and size of the prompts. The refresh period for the prompts is defined on the HTTP media server. Therefore, the bandwidth utilized is limited to the initial load of the prompts at each gateway, plus periodic updates after the expiration of the refresh interval. If the prompts are not cached at the


121



gateway, a significant Cisco IOS performance degradation (as much as 35% to 40%) in addition to the extra bandwidth usage occurs.

Assume that there are a total of 50 prompts, with an average size of 50 KB and a refresh interval of 15 minutes.

The bandwidth usage is:

(50 prompts) x (50,000 bytes/prompt) x (8 bits/byte) = 20,000,000 bits

(20,000,000 bits) / (900 secs) = 22.2 average kbps per branch

QOS Considerations for Unified CVP

The Unified CVP Call Server marks the QoS DSCP for SIP messages.

Table 26: Unified CVP QoS

Component Port Queue PHB DSCP

Media Server

Unified CVP

Call Server

(SIP)

Unified CVP

IVR service

Unified CVP

VXML Server

TCP 80

TCP 5060

TCP 8000

TCP 7000

Ingress Gateway

SIP

TCP 5060

VXML Gateway

SIP

TCP 5060

CVP-data

Call Signaling

AF11

CS3

CVP-data

CVP-data

Call Signaling

Call Signaling

AF11

AF11

CS3

CS3

10

24

10

10

24

24

Max latency

Round Trip

1 sec

200 ms

1 sec

1 sec

200 ms

200 ms

Note

The Unified CCE and Unified CVP provide a Layer 3 marking (not a Layer 2).

As a general rule, activate QoS at the application layer and trust it in the network.

Unified CM Bandwidth, Latency and QOS Considerations

Agent Phones to Unified Communications Manager Cluster

The amount of bandwidth that is required for phone-to-Unified Communications Manager signaling is 150 bps x n, where n is the number of phones.

122




For example for a 500 agent deployment model, for each contact center site the approximate required bandwidth is 150 x 500 phones = 75kbps

For example for a 1000 agent deployment model, for each contact center site the approximate required bandwidth is 150 x 1000 phones = 150kbps

Unified IC Bandwidth, Latency and QOS Considerations

Reporting Bandwidth

The following parameters have a combined effect on the responsiveness and performance of the Cisco Unified

Intelligence Center on the desktop:

• Real-time reports: Simultaneous real-time reports run by a single user.

• Refresh rate/realtime: Note that if you have a Premium license you can change the refresh rate by editing the Report Definition. The default refresh rate for Unified Intelligence Center Release 9.1(1) is 15 seconds.

• Cells per report — The number of columns that are retrieved and displayed in a report.

• Historical report — Number of historical reports run by a single user per hour.

• Refresh rate/historical — The frequency with report data are refreshed on a historical report.

• Rows per report — Total number of rows on a single report.

• Charts per dashboard — Number of charts (pie, bar, line) in use concurrently on a single dashboard.

• Gauges per dashboard — Number of gauges (speedometer) in use concurrently on a single dashboard.

Network Bandwidth Requirements

The exact bandwidth requirement differs based on the sizing parameters used, such as the number of rows, the refresh frequency, and the number of columns present in each report.

You can use the Bandwidth Calculator to calculate the bandwidth requirements for your Unified Intelligence

Center implementation. (Use the same Microsoft Excel file for Releases 9.0 and 8.5.)

Two examples for bandwidth calculation (50 and 100 users):


123



Unified

Intelligence

Center

User

Profile

Customer

Parameters

Profile 1

(500 agent deployment)

Total concurrent

Users

Number of Real

Time Reports

Value

50

Unified

1,283

Network Bandwidth Requirement (in Kbps)

Intelligence

Center–AW/HDS

Client–Unified

Intelligence

Center

1,454

Unified

Intelligence

Center--Unified

Intelligence

Center

N/A

Unified

Intelligence

Center--Unified

Intelligence

Center for each node

N/A

2

15 Real Time

Report Interval

(in second)

Number of

Average Rows per RT Report

Number of

Average

Columns per RT

Report

Number of

Historical Report

50

10

1

Historical Report

Interval (in second)

1800

800 Number of

Average Rows per Historical

Report

Number of

Average

Columns per

Historical Report

Number of

Nodes on side A

Number of

Nodes on side B

10

1

0

124




Unified

Intelligence

Center

User

Profile

Customer

Parameters

Profile 2

(1000 agent deployment)

Total concurrent

Users

Number of Real

Time Reports

Real Time

Report Interval

(in second)

Number of

Average Rows per RT Report

Number of

Average

Columns per RT

Report

Number of

Historical Report

Historical Report

Interval (in second)

Value

100

Unified

1,783

Network Bandwidth Requirement (in Kbps)

Intelligence

Center–AW/HDS

Client–Unified

Intelligence

Center

4,554

Unified

Intelligence

Center--Unified

Intelligence

Center

1,935

Unified

Intelligence

Center--Unified

Intelligence

Center for each node

967

2

15

50

20

1

1800

Number of

Average Rows per Historical

Report

Number of

Average

Columns per

Historical Report

Number of

Nodes on side

A*

Number of

Nodes on side

B*

200

20

1

2


125

Core Solution Component Considerations. Cisco Hosted Collaboration Solution for Contact Center

Core Solution Component Considerations

Core Component Design Considerations

Unified CCE Design Consideration

Unified CVP Design Considerations

Unified CM Design Considerations

Unified IC Design Considerations

Core Component High Availability Considerations

Unified CCE High Availability

Unified CVP High Availability

Unified CM High Availability

Gateway High Availability

MRCP ASR/TTS High Availability

Cisco Finesse High Availability

Core Component Bandwidth, Latency and QOS Considerations

Unified CCE Bandwidth, Latency and QOS Considerations

Unified CVP Bandwidth, Latency and QOS Considerations

Unified CM Bandwidth, Latency and QOS Considerations

Unified IC Bandwidth, Latency and QOS Considerations

Related manuals

Table of contents

Core Solution Component Considerations. Cisco Hosted Collaboration Solution for Contact Center