Installing and Configuring Cisco Hosted Collaboration Solution for Contact Center, Release 9.0
Design Considerations
Downloads: This chapterpdf (PDF - 1.89MB) The complete bookPDF (PDF - 8.51MB) | Feedback

Design Considerations

Contents

Design Considerations

Deployment Considerations

Cisco HCS for Contact Center supports a subset of the deployment options described in the Unified Contact Center Enterprise Solution Reference Network Design (SRND).

The 500 and 1000 agent deployment shown in the following figure illustrates the deployment options available to Cisco HCS for Contact Center and shows the options that are not supported.


Note


This is not an exhaustive list. As a rule, if an option or feature is not mentioned in this document, it is not supported in this deployment.


Figure 1. Cisco HCS for Contact Center and Solution Reference Network Design

The following figure shows the logical view of Cisco Hosted Collaboration Solution for Contact Center.

Figure 2. Cisco HCS for Contact Center Logical View



Operating Considerations

This section describes the features, configuration limits, and call flows for the Cisco Hosted Collaboration Solution for Contact Center.

Peripheral Gateways

The following table describes the deployment of the Peripheral Gateways.

  HCS for Contact Center Deployment Notes
Two Peripheral Gateways are supported in this deployment One generic PG with five Peripheral Interface Managers (PIMs)-required. The five PIMs are:
  • One Unified CM PIM
  • Four Voice Response Unit (VRU) PIMs.

One Media Routing (MR) PG with a Multichannel PIM and an Outbound PIM-required. This PG must be configured.

Two of the four VRU PIMs connect to the two Unified CVPs on Side A. Other two VRU PIMs connect to the two Unified CVPs on Side B.

Agent and Supervisor Capabilities

The following table lists the agent and supervisor capabilities for both the 500 and 1000 agent deployment.

Table 1 Agent and Supervisor Capabilities
 

HCS for Contact Center Deployment

Notes
Call Flows All transfers, conferences, and direct agent calls use ICM script.
CRM Integration CRM integration is allowed with custom CTI OS Toolkit or Cisco Finesse API.
  • Cisco Finesse gadgets
  • Cisco Finesse Web API or CTI OS APIs
  • Existing CRM connectors
You can integrate with CRM in many ways. You can use:
  • Cisco Finesse gadgets to build a custom CRM-integrated desktop. For example, this can be a Cisco Finesse gadget that fits in a CRM browser-based desktop.
  • Cisco Finesse Web API or CTI OS APIs or the CTI Server protocol to integrate into a CRM application
  • Existing CRM connectors. The connectors available from Cisco for SAP. Each of these connectors has its own capacity limits:
    • SAP can support up to 250 agents and supervisors. Max 3 CPS. Requires its own server. Supports Unified CM BIB-based Recording or Silent Monitoring. Does not support Mobile Agents, Outbound, or Multichannel.
Desktop
  • Cisco Finesse
  • Cisco Computer Telephony Integration Option (CTI OS) Desktop:
    • .NET
    • Java CIL
    • Win32
Browser for Agent Login Cisco Finesse
Desktop Customization Cisco Finesse API

CTI OS Toolkit Desktops

CTI OS Toolkit Desktops are listed above, under Desktop.
Mobile Agent Configured on the Unified CCE Call Server virtual machine. Call-by-Call mode is not supported in this deployment.
Recording Following are the supported recording types:
  • Unified CM-based (BiB), preferred
  • SPAN (Silent Monitoring Server) for Mobile Agent
This requires Recording Server.

Silent Monitoring

You can configure either Unified CM-based or SPAN-based but not both. If you configure Unified CM-based silent monitoring, you cannot monitor mobile agents.

A separate server is required for SPAN-based silent monitoring.

You can configure either Unified CM-based or SPAN-based but not both. If you configure Unified CM-based silent monitoring, you cannot monitor mobile agents.

A separate server is required for SPAN-based silent monitoring.

Agent Greeting Yes
Whisper Announcement Yes
Outbound Dialer Yes

Voice Infrastructure

The following table lists the voice infrastructure for both the 500 and 1000 agent deployment.



Table 2 Voice Infrastructure
 

HCS for Contact Center Deployment

Notes

Music on Hold

Cisco Unified Communications Manager Unicast/Multicast

Proxy

No

High Availability (HA) and load balancing are achieved using these solution components:

  • Time Division Multiplexing (TDM) gateway and Unified CM, which use the SIP Options heartbeat mechanism to perform HA.
  • Unified CVP servers, which use the SIP server group and SIP Options heartbeat mechanism to perform HA and load balancing.

Ingress Gateways

ISR G2 Cisco Unified Border Element with combination VXML

3925E and 3945E are the recommended GWs.

For SPAN based Silent Monitoring, the Ingress gateway is spanned.

You must configure the gateway MTPs to do a codec pass-through because the Mobile Agent in HCS is configured to use G729 and the rest of the components in HCS support all the codecs.

Protocol

Session Initiation Protocol (SIP) over TCP

SIP over UDP, H323, Media Gateway Control Protocol (MGCP) are not supported.

Codec

  • IVR: G.711ulaw and G.711alaw
  • Agents: G.711ulaw, G.711 alaw, and G.729a

G.722, iSAC, and iLBC are not supported.

Media Resources

Gateway-based:

  • Conference bridges
  • Transcoders and Universal Transcoders
  • Hardware and IOS Software MTPs

Unified CM-based (Cisco IP Voice Media Streaming Application) that are not supported:

  • Conference bridges
  • MTPs

Phones

CTI Controlled with BiB:

  • 99xx series: 9951 and 9971 are supported.
  • 89xx series: 8941, 8945, and 8961 are supported.
  • 797x: 7975 is supported.
  • 796x: 7961G, 7962G, and 7965G are supported.
  • 794x: 7941G, 7942G, and 7945G are supported.
  • 69xx series: 6921, 6941, 6945 and 6961 are supported
  • IP communicator
  • Mobile Agent
HCS for CC supports all the phones that Unified CCE supports, as long as the phone supports the Built-in-Bridge (BIB), CTI-controlled features under SIP control. SCCP is not supported.

Administration Guidelines

The following table lists the administration tools for both the 500 and 1000 agent deployment.



Table 3 Administration
 

HCS for Contact Center Deployment

Notes

Supported:

Not supported:

Provisioning

  • Unified CCE Configuration tools
  • Unified CCE Web Administration
  • Unified CCDM Web Administration
  • Unified CCE Internet Script Editor
  • Unified CVP Operations Console
  • Unified Intelligence Center Web Administration
  • Cisco Finesse Web Administration
  • Unified Communications Domain Manager Web Administration

Cisco Agent Desktop Admin

Serviceability

  • Unified System Command Line Interface (CLI)
  • RTMT Analysis Manager Diagnosis

RTMT Analysis Manager Analyze Call Path

IVR and Queuing

The following table describes the IVR and call queuing to help optimize inbound call management for both the 500 and 1000 agent deployment.



Table 4 IVR and Queuing
 

HCS for Contact Center Deployment

Notes

Supported:

Not supported:

Voice Response Unit (VRU)

  • Unified CVP Comprehensive Model Type 10
  • Unified CVP VRU types other than Type 10
  • Cisco IP IVR
  • Third-party IVRs

Caller Input

  • DTMF
  • Automatic Speech Recognition and Text-to-speech (ASR/TTS)

Dual Tone Multi-Frequency (DTMF)

  • RFC2833
  • Keypad Markup Language (KPML)

Video

None

Media Server

  • Third-party Microsoft Internet Information Services (IIS), coresident on the Unified CVP Call Server and VXML Server
  • Tomcat

Reporting

The following table contains information on the reporting for both the 500 and 1000 agent deployment.

Unified Intelligence Center historical reporting data and Call Detail data are pulled from the Logger database. Retention is 400 days for historical data and 35 days for Call Detail data.

Table 5 Reporting
 

HCS for Contact Center Deployment

Notes

Tool

Cisco Unified Intelligence Center is the only supported reporting application.

Not supported with reporting from Logger:

  • Exony VIM
  • Third-party reporting applications

Supported with reporting from AW/HDS/DDS:

  • Exony VIM
  • Third-party reporting applications
  • Custom reporting

Database

Historical and Call Detailed Data is stored on the Unified CCE Data Server.

Retention

The logger database retention period is 400 days (13 months) of historical summary data and 35 days (five weeks) of detailed TCD and RCD records.

If you require longer retention periods, add a single Historical Data Server (HDS) to the deployment. See the following table for the HDS minimum requirements.

Data beyond the configured retention time is purged automatically at 12:30 AM and uses the time zone setting of the core server.

Follow Cisco best practice guidelines to run the purge at off-peak hours or during a maintenance window.

Note that you can control or change the automatic purge schedule through the command line interface. You can change it if the automated purge does not occur during your off-peak hours.

The purge has a performance impact on the Logger.

Customers who install the External AW-HDS-DDS on separate servers can point Cisco Unified Intelligence Center to either the logger or the External AW-HDS-DDS, but not to both.

Reports

Each supervisor can run four concurrent Real-Time reports and two historical reports:

  • Real-Time reports contain 100 rows.
  • Historical reports contain 2000 rows.

Table 6 HDS Minimum Requirements

Virtual Machine

vCPU

RAM (GB)

Disk (GB)

CPU Reservation (MHz)

RAM Reservation (MB)

Unified CCE HDS

1

2

80 (OS) 512* (Database)

2048

* Size the database drive to accommodate the required retention period. Install the database drive on a RAID 10 disk. For more information about the HDS sizing, refer Virtualization of Unified CCE.

Third-party Integration

The following table contains third-party integration information for both the 500 and 1000 agent deployment.



Table 7 Third-Party Integration

Option

Notes

Recording

All Recording applications that are supported by Unified CCE are supported on HCS for CC. For details, see Recording section in Agent and supervisor capabilities.

Wallboards

All Wallboard applications that are supported by Unified CCE are supported on HCS for CC.
Note    Unified Intelligence Center can also be used for Wallboards.

Workforce Management

If you need access to real-time or historical data, then you will require AW-HDS-DDS. All Workforce Management applications that are supported by Unified CCE are supported on HCS for CC.

Database Integration

Unified CVP VXML Server is supported.

ICM DB Lookup is supported.

Automated Call Distributor (ACD)

None

Interactive Voice Response (IVR)

  • Unified IP IVR is not supported.
  • No third-party IVRs are supported.

Configuration Limits

Agents, Supervisors, Teams, Reporting Users

Group Parameter 500 Agent Deployment 1000 Agent Deployment
Agents Active/Configured Agents 500/3000 1000/6000
Active/Configured Cisco Mobile Agent 125/750 (included in maximum 500 concurrent agents) 250/1500 (included in maximum 1000 concurrent agents)
Outbound 125 (included in maximum 500 concurrent agents) 250 (included in maximum 1000 concurrent agents)
Supervisors/Teams Active/Configured Supervisors 50/300 100/600
Active/Configured Agent teams 50/300 100/600
Supervisors per team 1 1
Agents per supervisor 9 9
Reporting Users Active/Configured 50/300 100/600

Load

Group Parameter 500 Agent Deployment 1000 Agent Deployment
Call Flows Maximum call load for Agents 30 calls per hour per agent 30 calls per hour per agent
Unified CVP VXML Application Database Element (requests per second) 35 35
Outbound Dialer per system 1 1
Dialer ports per system 500 1000
Number of Agent and IVR Campaigns 50 100
Campaign skill groups per campaign 20 20
Skills per Agent

15

15
Dialing Modes
  • Preview
  • Direct Preview
  • Progressive
  • Predictive
  • Preview
  • Direct Preview
  • Progressive
  • Predictive
Total Numbers of Agents 125 250
Port Throttle 5 10

Unified CCE Configuration Limits

Group Parameter 500 Agent Deployment 1000 Agent Deployment
Configured Objects Dialed numbers (External) 1000 1000
Dialed numbers (Internal) 1000 1000
Dialed numbers (Outbound) 500 500
Labels 500 1000
Call types, skill groups/interval 500 1000
Routing Script Active/Configured 250/500 500/1000
Call Types Active/Configured 250/500 500/1000
Bucket Intervals   500 1000
Network VRU Scripts   500 1000
Reason Codes   100 100
CTI Server All events clients 9 (Includes CTIOS, Finesse and 5 other CTI All Event Clients) 9 (Includes CTIOS, Finesse and 5 other CTI All Event Clients)
Agent with Trace ON   50 100
Skill Groups Skill groups (system wide) 3000 3000
Skill groups/agent 15 15
Maximum agents/skill group 50 50
Statistics refresh rate 10 sec. (default) 10 sec. (default)
Persistent ECC Arrays 0 0
Scalars 5 5
Size of each scalar 20 20
Non-Persistent ECC Bytes 2000 2000
Reskilling Dynamic (operations/hr.) 120 120
Number of agent statistics elements   Default Default
Desktop Settings Statistics Default Default
Security Off Off
Agent trace level On On
CTI OS security N/A Must be off Must be off

Call Flows

The call flows in the following figures represent units of call flow functionality. You can combine these call flow units in any order in the course of a call.

Figure 3. Basic Call Flow with IVR and Queue to an Agent



Figure 4. Consult Call Flow with IVR and Queue to a Second Agent



Figure 5. Blind Transfer Call Flow with IVR and Queue to a Second Agent




Note


Conference call flows are the same as consult call flows. Both conference call flows and consult call flows conference the call with the agents, rather than holding them during consult. Hold/resume, alternate/reconnect, consult/conference call flows invoke the session initiation protocol (SIP) ReINVITE procedure to move the media streams. Conference to interactive voice response (IVR) call flow is similar to conference with no agent available call flow.


The following table shows the SIP trunk call flow.

Table 8 SIP Trunk Call Flow
Call Flow Logical Call Routing
New call from CUBE-SP Caller -->CUBE-SP-->CUBE-E--> Unified CVP-->Unified Communications Manager
New call from Unified Communications Manager (internal help desk) Caller ---> Unified Communications Manager ---> CUBE-E ---> Unified CVP
Post routed call from agent-to-agent Agent 1 --> Unified Communications Manager --> Unified CVP

Note


All new calls always enter the Cisco IOS gateway (CUBE-E or TDM-IP gateway) and are associated with the Unified CVP survivability service.

The following table shows the TDM gateway (Local PSTN breakout) call flow.

Table 9 TDM gateway (Local PSTN breakout) Call Flow
Call Flow Logical Call Routing
New call from local PSTN gateway Caller --> TDM-IP--> Unified Communications Manager--> CUBE-E--> Unified CVP--> Unified Communications Manager
New call from Unified Communications Manager (internal help desk) Caller ---> Unified Communications Manager ---> CUBE-E ---> Unified CVP
Post routed call from agent-to-agent Agent 1 --> Unified Communications Manager --> Unified CVP--> Unified Communications Manager

Note


All new calls always enter the Cisco IOS gateway (CUBE-E or TDM-IP gateway) and are associated with the Unified CVP survivability service.

The following table lists the supported system call flows.

Table 10 Supported System Call Flows

System Call Flows

Supported

Conference to IVR

Yes

Bridged transfer

Yes

Router requery

Yes

Postroute using Unified CVP

Yes

Prerouting

No

Translation route with third-party VRU

No

ICM routing to devices other than Cisco HCS Unified CCE

No

Domain and Active Directory Considerations

The Unified CCE uses Active Directory (AD) to control users' access rights to perform setup, configuration, and reporting tasks. AD also grants permissions for different components of the system software to interact; for example, it grants permissions for a Distributor to read the Logger database. For more information, see Staging Guide for Cisco Unified Contact Center Enterprise Release 9.x(y).

To meet these requirements, Cisco HCS for Contact Center must have its own set of Windows Server 2008 Standard R2 domain controllers configured in native mode. For more information, see Call Flows. The domain controller must meet the minimum requirements shown in the following table.

Table 11 Domain Controller Minimum Requirements

Virtual Machine

vCPU

RAM (GB)

Disk C (GB)

CPU Reservation (MHz)

RAM Reservation (MB)

Cisco HCS Domain Controller

1

4

40

1400

512


Note


Use 2 vCPUs for larger directories.


Cisco HCS for Contact Center supports two AD deployment models:

The following figure shows the Cisco HCS for Contact Center AD deployment.

Figure 6. Cisco HCS for Contact Center AD Deployment



AD at Customer Premises

In the AD at the customer premises model, the service provider needs to request that the customer add entries into the customer AD to enable the service provider to sign into the system deployed in the domain. The service provider should be a local machine administrator and belong to the setup group for components that need to be installed and managed in the Cisco HCS for Contact Center environment. To run the Domain Manager, the service provider must be a domain administrator or a domain user with domain read and write permissions to create Organizational Units (OU) and groups.

The end-customer use of the Cisco HCS for Contact Center solution is limited if the customer premises AD is inaccessible to the Cisco HCS for Contact Center Virtual Machines. Cisco strongly advises service providers to work with end customers to ensure that they understand the potential service limitations when they use the AD at the customer premises model.

Cisco HCS for Contact Center also supports a deployment where the Cisco HCS for Contact Center components are associated with the AD at the service provider premises, and the CTI OS client desktops are part of the customer premises corporate AD. Consider the following for the AD in this deployment:

  • The instance administrator account is created in the service provider domain.
  • The instance administrator uses the Unified CCDM and Unified Intelligence Center to create agents, supervisors, and reporting users in the service provider domain.
  • The instance administrator configures all supervisors and reporting users.

AD at Service Provider Premises

In the AD at the service provider premises model, the service provider must have a dedicated AD for each customer instance. Each customer AD needs to be updated with Cisco HCS for Contact Center servers and accounts. The service provider administrator needs to be added to each customer AD to manage the Contact Center environment.

You can use overlapping IP addresses for each customer deployment. For example, Cisco Unified Border Element—Enterprise, Unified CCE, and Unified CVP should be able to overlap IP addresses across customers. When you use overlapping IP addresses, the static Network Address Translation (NAT) provides access from the management system (Cisco Unified Operations Manager and Unified Communications Domain Manager) to each Cisco HCS for Contact Center environment.


Note


You must create a two way external trust between each customer AD and Service provider Management AD to integrate customer instance with Unified CCDM.You must also open the ports in the ASA firewall. Refer to the section Install and Configure ASA Firewall and NAT.


Storage and Blade Placement Considerations

SAN Configuration for 500 Agent Deployment

The 500 agent deployment requires 3.25 TB of SAN storage for the core components.

The following table contains the SAN configuration for the 500 agent deployment. In this table, the C drive is the active primary partition used for the operating system and applications, and the D drive is a secondary partition used for the database.



Table 12 SAN Configuration for the 500 Agent Deployment

RAID Group*

VM Datastore

Disk Drive

Virtual Machine

A1 - RAID5

Datastore-A1

425 GB

C:

Unified CCE Call Server, Side A

Unified Intelligence Center Publisher

Cisco Finesse Publisher

A2 - RAID5

Datastore-A2

1100 GB

C:

Unified CCE Data Server, Side A

Unified CVP Reporting Server

D:

Unified CCE Data Server, Side A

Unified CVP Reporting Server

A3- RAID5

Datastore-A3

350 GB

C:

Unified CVP Call Server 1A

Unified Call Manager Publisher

Unified Call Manager Subscriber 1A

B1 - RAID5

Datastore-B1

425 GB

C:

Unified CCE Call Server, Side B

Unified Intelligence Center Subscriber

Finesse Subscriber

B2 - RAID5

Datastore-B2

650 GB

C:

Unified CCE Data Server, Side B

D:

Unified CCE Data Server, Side B

B3- RAID5

Datastore-B3

300 GB

C:

Unified CVP Call Server 1B

Unified CVP OAMP Server

Unified Call Manager Subscriber 1B

Blade Placement for 500 Agent Deployment

The 500 agent deployment requires two a single high density B230M2-VCDL1 blade for the mandatory components and the Unified CVP reporting server.

The following tables contain the blade placement for the 500 agent deployment, chassis 1 and 2.

The following tables provide the required IOPS. Use the IOPS 95th percentile value to design the SAN array and the IOPS average value to monitor the SAN array.


Note


The vCPU is oversubscribed, but the overall CPU MHz and memory is not oversubscribed for the blade.


Table 13 Blade Placement for the 500 Agent Deployment - Chassis 1
Blade Virtual Machine vCPU RAM (GB) Disk C (GB) Disk D (GB) CPU Reservation (MHz) RAM Reservation (MB)

A1

Unified CCE Call Server Side A

2

4

80

3300

4096

Unified CCE Data Server Side A

2

6

80

512

3400

6144

Unified CVP Server No.2

4

4

150

1200

4096

Unified Intelligence Center Publisher

2

6

146

800

6144

Cisco Finesse Publisher

4

8

146

2750

8192

Unified CM Publisher

2

4

80

2500

4096

Unified CM Subscriber 2 4 80 2500 4096

Unified CVP Reporting Server

4

4

80

300

2500

4096

Table 14 IOPS, Disk Read, and Disk Write - Chassis 1
Blade Virtual Machine IOPS Disk Read Kbytes/sec Disk Write Kbytes / sec
Peak 95th Percentile Average Peak 95th Percentile Average Peak 95th Percentile Average

A1

Unified CCE Call Server Side A

217.25 74.76 58.48 6592 139.4 63.84 14160 3691.05 2437.47

Unified CCE Data Server Side A

748.4 370.72 199.14 935 183.6 66.64 2994 1799.3 626.68

Unified CVP Server No.1

56.7 16.46 10.59 206 194 111.58 307 205 115.27

Unified Intelligence Center Publisher

1079.7 754.12 194.51 2230 496.35 72.76 4429 3145.5 877.9

Cisco Finesse Publisher

160 150 150

Unified CM Publisher

172.65 72.31 58.32 1068 5 9.11 1860 1775.1 1218.23
Unified CM Subscriber 172.65 72.31 58.32 1068 5 9.11 1860 1775.1 1218.23

Unified CVP Reporting Server

1242.65 1165.93 308.36 20510 14942.8 3437.69 6860 4800.75 1132.1

Note


Monitor SAN performance for IOPS and disk usage. If usage exceeds thresholds, redeploy disk resources during the service window.


Table 15 Blade Placement for the 500 Agent Deployment - Chassis 2
Blade Virtual Machine vCPU RAM (GB) Disk C (GB) Disk D (GB) CPU Reservation (MHz) RAM Reservation (MB)

B1

Unified CCE Call Server Side B

2

4

80

3300

4096

Unified CCE Data Server Side B

2

6

80

512

3400

6144

Unified CVP Server No.2

4

4

150

1200

4096

Unified Intelligence Center Subscriber

2

6

146

800

6144

Cisco Finesse Subscriber

4

8

146

2750

8192

Unified CM Subscriber Side B

2

4

80

2500

4096

Unified CVP OAMP

2

4

40

1200

4096

Table 16 IOPS, Disk Read, and Disk Write - Chassis 2
Blade Virtual Machine IOPS Disk Read Kbytes/sec Disk Write Kbytes / sec
Peak 95th Percentile Average Peak 95th Percentile Average Peak 95th Percentile Average

B1

Unified CCE Call Server Side B

217.25 74.76 58.48 6592 139.4 63.84 14160 3691.05 2437.47

Unified CCE Data Server Side B

748.4 370.72 199.14 935 183.6 66.64 2994 1799.3 626.68

Unified CVP Server No.2

56.7 16.46 10.59 206 194 111.58 307 205 115.27

Unified Intelligence Center Subscriber

1079.7 754.12 194.51 2230 496.35 72.76 4429 3145.5 877.9

Cisco Finesse Subscriber

160 150 150

Unified CM Subscriber Side B

172.65 72.31 58.32 1068 5 9.11 1860 1775.1 1218.23

Unified CVP OAMP

44.25 42.95 39.91 973 0.05 5.72 1055 273.05 251.02

Note


Monitor SAN performance for IOPS and disk usage. If usage exceeds thresholds, redeploy disk resources during the service window.


SAN Configuration for 1000 Agent Deployment

The 1000 agent deployment requires 4.5 TB of SAN storage for the core components. The following table contains the SAN configuration for the 1000 agent deployment. In this table, the C drive is the active primary partition used for the operating system and applications, and the D drive is a secondary partition used for the database.

Table 17 SAN Configuration for the 1000 Agent Deployment

RAID Group

VM Datastore

Disk Drive

Virtual Machine

A1 - RAID5

Datastore-A1

575 GB

C:

Unified CCE Call Server, Side A

Unified CVP Call Server 1A

Unified Intelligence Center Publisher

Cisco Finesse Publisher

A2 - RAID5

Datastore-A2

1500 GB

C:

Unified CCE Data Server, Side A

Unified CVP Reporting Server

D:

Unified CCE Data Server, Side A

Unified CVP Reporting Server

A3 - RAID5

Datastore-A3

550 GB

C:

Unified CVP Call Server 2A

Unified Call Manager Publisher

Unified Call Manager Subscriber 1A

B1 - RAID5

Datastore-B1

575 GB

C:

Unified CCE Call Server, Side B

Unified CVP Call Server 1B

Unified Intelligence Center Subscriber

Cisco Finesse Subscriber

B2 - RAID5

Datastore-B2

900 GB

C:

Unified CCE Data Server, Side B (Operating System Drive)

D:

Unified CCE Data Server, Side B (Database Drive)

B3 - RAID5

Datastore-B3

400 GB

C:

Unified CVP Call Server 2B

Unified CVP OAMP Server

Unified Call Manager Subscriber 1B

Blade Placement for 1000 Agent Deployment

The 1000 agent deployment requires a single high density B230M2-VCS1 blade for the mandatory core components.

The tables also include the IOPS required for the 1000 agent deployment. Use the IOPS 95th percentile value to design the SAN array and the IOS average value to monitor the SAN array.


Note


The vCPU is oversubscribed, but the overall CPU MHz and memory is not oversubscribed for the blade.


Table 18 Blade Placement for the 1000 Agent Deployment - Chassis 1
Blade Virtual Machine vCPU RAM (GB) Disk C (GB) Disk D (GB) CPU Reservation (MHz) RAM Reservation (MB)

A1

Unified CCE Call Server Side A

4

8

80

5000

8192

Unified CCE Data Server Side A

4

8

80

750

5100

8192

Unified CVP Call Server No. 1 Side A

4

4

150

1800

4096

Unified CVP Call Server No. 2 Side A

4

4

150

1800

4096

Unified Intelligence Center Publisher

2

6

146

800

6144

Cisco Finesse Publisher

4

8

146

8000

8192

Unified CM Publisher

2

6

80

80

3600

6144

Unified CM Subscriber Side A

2

6

80

80

3600

6144

Unified CVP Reporting Server

4

4

80

438

2500

4096

Table 19 IOPS, Disk Read , and Disk Write - Chassis 1
Blade Virtual Machine IOPS Disk Read Kbytes / sec Disk Write Kbytes / sec
Peak 95th Percentile Average Peak 95th Percentile Average Peak 95th Percentile Average

A1

Unified CCE Call Server Side A

250.25

81.24

71.58

9646.8

156.07

89.472

28204.8

9224.8

6366

Unified CCE Data Server Side A

822.34

410.14

231.41

9483.6

1180.98

388.992

26792.4

2768.94

1318.908

Unified CVP Call Server No. 1 Side A

93.96

21.25

15.82

9459.6

276

215.34

21686.4

1248.8

547.356

Unified CVP Call Server No. 2 Side A

93.96

21.25

15.82

9459.6

276

215.34

21686.4

1248.8

547.356

Unified Intelligence Center Publisher

1345.89

802.22

310.56

2455

520.33

265.22

4952.02

3846.87

1010.25

Cisco Finesse Publisher

160

150

150

Unified CM Publisher

800

700

320

Unified CM Subscriber Side A

800

700

320

Unified CVP Reporting Server

1355.23

1235.21

540.35

23151.77

16233.34

3810.23

7320.66

5202.3

1478.89


Note


Monitor SAN performance for IOPS and disk usage. If usage exceeds thresholds, redeploy disk resources during the service window.


Table 20 Blade Placement for the 1000 Agent Deployment - Chassis 2
Blade Virtual Machine vCPU RAM (GB) Disk C (GB) Disk D (GB) CPU Reservation (MHz) RAM Reservation (MB)
B1

Unified CCE Call Server Side B

4

8

80

5000

4096

 

Unified CCE Data Server Side B

4

8

80

750

5100

8192

 

Unified CVP Call Server Side B No. 1

4

4

150

1200

4096

 

Unified CVP Call Server Side B No. 2

4

4

150

1200

4096

 

Unified Intelligence Center Subscriber

2

6

146

800

6144

 

Cisco Finesse Subscriber

4

8

146

8000

8192

 

Unified CM Subscriber Server Side B

2

6

80

80

3600

6144

 

Unified CVP OAMP

2

4

40

1200

4096

Table 21 IOPS, Disk Read , and Disk Write - Chassis 2
Blade Virtual Machine IOPS Disk Read Kbytes / sec Disk Write Kbytes / sec
Peak 95th Percentile Average Peak 95th Percentile Average Peak 95th Percentile Average

B1

Unified CCE Call Server No. 1 Side B

250.25

81.24

71.58

9646.8

156.07

89.472

28204.8

9224.8

6366

Unified CCE Data Server Side B

822.34

410.14

231.41

9483.6

1180.98

388.992

26792.4

2768.94

1318.908

Unified CVP Call Server Side B No. 1

93.96

21.25

15.82

9459.6

276

215.34

21686.4

1248.8

547.356

Unified CVP Call Server Side B No. 2

93.96

21.25

15.82

9459.6

276

215.34

21686.4

1248.8

547.356

Unified Intelligence Center Subscriber

1345.89

802.22

310.56

2455

520.33

265.22

4952.02

3846.87

1010.25

Cisco Finesse Subscriber

160

150

150

Unified CM Subscriber Server Side B

800

700

320

Unified CVP OAMP

64.02

54.92

42.99

2426.4

5.02

16.524

1254.2

310.8

287.23


Note


Monitor SAN performance for IOPS and disk usage. If usage exceeds thresholds, redeploy disk resources during the service window.


High Availability Considerations

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

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

Table 22 HCS for Contact Center Failover
Component Failover scenario New call impact Active call impact Post recovery action
Unified CM Visible network failure

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

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 Disrupts new calls while the phones route to the backup subscriber. Processes the calls when the routing completes. In-progress calls remain active, with no supplementary services such as conference or transfer.

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 Disrupts new calls while the phones route to the backup subscriber. Processes the calls when the routing completes. In-progress calls remain active, with no supplementary services such as conference or transfer.

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 fail-back.

Gateway 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.
MRCP ASR/TTS 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.
Blade Blade failover Disrupts new calls while backup server components become active. In-progress calls become inactive. After backup server components restores, calls (active and new) route back to the primary server.
WAN Link 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 CM.
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.

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

VMware High Availability

High availability (HA) provides failover protection against hardware and operating system failures within your virtualized Cisco HCS for Contact Center environment.

The following lists the VMware HA considerations for deploying Cisco HCS for Contact Center with VMware HA enabled:

  • Cisco HCS does not support VMware Distributed Resource Scheduler (DRS).
  • Select the Admission Control Policy: Specify a failover host. When an ESXi host fails, all of the VMs on this host fail over to the reserved HA backup host. The failover host Admission Control Policy avoids resource fragmentation. The Cisco HCS for Contact Center deployment models assume a specific VM colocation within a Cisco HCS for Contact Center instance deployment. This VM colocation requirement guarantees system performance, and it is tested for specific Cisco HCS for Contact Center application capacity requirements.
  • Select VM monitoring status options: VM Monitoring Only.
  • Select Host Isolation response: Shut down for all the virtual machines.
  • Configure the Cisco HCS for Contact Center virtual machines with the VM restart priority shown in the following table.
Table 23 Virtual Machine Settings

Virtual Machine

VM Restart Priority

Cisco Unified Intelligence Center Low
Contact Center Domain Manager Low
Unified CVP Reporting Server Low
Unified CCE Call Server Medium
Cisco Finesse Medium
Unified CVP Servers High
Unified CCE Database Server High
  • HA is not required because the Cisco HCS for Contact Center applications are highly available by design.
  • HA Backup Hosts must be in the same cluster, but not in the same physical chassis as the Contact Center blades.
  • For more information about high availability see the VMware vSphere Availability Guide ESXi 5.0.

Note


Because the Router and PGs are co-located, an unlikely dual (Public and Private) network failure could result in serious routing degradation. The Cisco Hosted Collaboration Solution for Contact Center does not tolerate a dual concurrent network failure, so you may need to intervene to restore the system’s full functionality.


Network Link Failure

The following lists considerations when the network link fails between Cisco HCS for Contact Center setup and Active Directory:

  • Call traffic is not impacted during the link failure.
  • The virtual machines in the domain restrict sign in using the domain controller credentials. You can sign in using cached credentials.
  • If you stop Unified CCE services before the link fails, you must restore the link before starting the Unified CCE components.
  • You will not be able to access the local PG Setup or sign in to the Unified CCE Web Setup.
  • If the link fails while the Cisco HCS services are active, access to Unified CCE Web Setup, configuration tools, and Script Editor fails.
  • Although the Unified CCDM allows login to the portal, access to the reporting page fails.
  • The administrator and superusers can access or configure any attribute except the Reporting Configuration in Cisco Unified Intelligence Center OAMP portal.
  • Agent supervisors cannot sign in to the Cisco Unified Intelligence Center Reporting portal, however supervisors already signed in can access the reports.

Unified CCE High Availability

The Unified CCE product in Cisco HCS solution is categorized into Unified CCE Call Server and Unified CCE Database Server. The Unified CCE Call Server contains the Unified CCE Router, Unified CCE PG, CG, and the CTI OS server. The Database server holds the Logger and the Unified CCE Administration Server and Real-Time Data Server. Each component in the Unified CCE solution is duplicated with a redundant or duplex component.

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

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 are dropped. 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 in the Unified CCE Call server. 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 without having to log in again to the desktop application.

CTI OS Server

CTI OS server is a software component that runs co-resident on the Unified CCE Call Server. 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.

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 CCE Administration and Data Server provides the user interface to the system for making configuration and scripting changes. This component does support redundant or duplex operation as do the other Unified CCE system components.

Unified CVP High Availability

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

Unified CVP Call Server

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

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.

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

Visible Network Failure

Cisco HCS Release 9.0 supports two subscribers; Subscriber A and Subscriber B, each running a local instance of CTI Manager to provide JTAPI services for the Unified CCE peripheral gateways. If the public network of Subscriber A fails, then the peripheral gateway of Subscriber B becomes active. Because the visible network is down, the remote Unified CM subscriber at side A cannot send the phone registration event to the remote peripheral gateway. This results in the failure of active calls. After the network of the Subscriber A becomes active, the phones align to Subscriber A.

Call Manager Service in Subscriber Failure

When the call manager service in Unified CM Subscriber A fails, all registered phones route to Unified CM Subscriber B. However, calls that are in progress with agent phones remain active, but with no phone services such as conference or transfer. Peripheral gateway side A remains active as the CTI manager connection is not lost to Subscriber A.

Subscriber B registers all dialed numbers and phones and therefore the call processing continues. When call manager service in Unified CM Subscriber A recovers, all idle phones route back to Subscriber A.

Unified CTI Manager Service Failover

If the Unified CM CTI Manager service on Subscriber A fails, the peripheral gateway side A detects a failure of the CTI Manager service and induces a failover to peripheral gateway side B. Peripheral gateway side B registers all dialed numbers and phones with the Unified CM CTI Manager service on Subscriber B and call processing continues. Agents with calls in progress stay in progress, but with no third-party call control (conference, transfer, and so on) will be available from their agent desktop soft phones. When the Unified CM CTI Manager service on Subscriber A recovers, peripheral gateway side B remains active and uses the CTI Manager service on Unified CM Subscriber B. The peripheral gateway does not fail-back.

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

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.

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.

AWDB

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:
  • 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 n minutes or seconds, the agent is forced to log out.

Congestion Control Considerations

Congestion Control protects the Central Controller from overloading. When you enable the Congestion Control, the new calls entering that exceed the Calls Per Second (CPS) capacity of the contact center are rejected or treated by the Routing Clients at call entry point. This prevents an overload on the call router and ensures call-processing throughput when the system is subjected to overload.

Deployment Types

After upgrading or installing the system, configure the system to a valid deployment type. If the supported deployment type is not set, the PGs and NICs cannot connect to the Central Controller and process the call.

The following table lists the supported deployment types with guidelines for selecting a valid deployment type.

Table 24 Supported Congestion Control Deployment Types
Deployment Type Code Deployment Name Guidelines for Selection

11

HCS-CC 1000 Agents

This deployment type is automatically set as part of the install for the HCS-CC 1000 agents deployment type and is unavailable for user selection.

12

HCS-CC 500 Agents

This deployment type is automatically set as part of the install for the HCS-CC 500 agents deployment type and is unavailable for user selection.

Congestion Treatment Mode

There are five options available to handle the calls that are rejected or treated due to congestion in the system. Contact center administrators can choose any of the following options to handle the calls:
  • Treat call with Dialed Number Default Label - The calls to be rejected due to congestion are treated with the default label of the dialed number on which the new call has arrived.
  • Treat call with Routing Client Default Label - The calls to be rejected due to congestion are treated with the default label of the routing client on which the new call arrived.
  • Treat call with System Default Label - The calls to be rejected due to congestion are treated with the system default label set in Congestion Control settings.
  • Terminate call with a Dialog Fail or RouteEnd - Terminates the new call dialog with a dialog failure.
  • Treat call with a Release Message to the Routing Client - Terminates the new call dialog with release message.

The treatment options are set either at the routing client or at global level system congestion settings. If the treatment mode is not selected at the routing client, then the system congestion settings are applied for treating the calls.

Congestion Control Levels and Thresholds

Congestion Control algorithm works in three levels; each level has an onset and an abatement value. Rising to higher congestion can happen from any level to any level. However reducing the congestion level occurs one level at a time.

The following table shows the percentage of the CPS capacity for different congestion levels.



Table 25 Congestion levels and capacities
Congestion Levels Congestion Level Threshold (Percent of Capacity)

Level1Onset

110%

Level1Abate

90%

L1Reduction

10%

Level2Onset

130%

Level2Abate

100%

Level2Reduction

30%

Level3Onset

150%

Level3Abate

100%

Level3Redution

Variable reduction from 100% to 10%

Congestion Control Configuration

Configure the congestion control settings using the Congestion Settings Gadget and the Routing Client Explorer tool. Use the Congestion Settings Gadget to set the system level congestion control. Use the Routing Client Explorer tool to select the Routing Client level treatment options.

After you select the deployment type, the system starts computing the various metrics related to the congestion control and system capacity, and generates the real time report. However, the system cannot reject or treat the calls until you turn on the Congestion Enabled option in the Congestion Control Setting Gadget.

Real Time Capacity Monitoring

System Capacity Real Time provides congestion level information to the user. The report provides the following views:
  • Congestion Information View
  • Rejection Percentage View
  • Key Performance Indicators View
  • System Capacity View

Supported Gadgets for HCS

To access the gadget, on the database server, click Start and navigate to All Programs->Cisco Unified CCE Tools->Administration Tools and open Unified CCE Web administration. The following table shows the CRUD operations supported by the HCS gadgets.

Gadget Create Read Update Delete
Agent   x x (only attribute assignment)  
Attribute x x x x
Precision queue x x x x
Reason Code x x x x
Bucket interval x x x x
Network VRU script x x x x
congestion control   x x  
deploymenttype   x x  
serviceability   x    

Note


The Unified CCE does not enforce configuration limit through Unified Contact Center Domain Manager.


UCS Network Considerations

This section lists Unified Communication System (UCS) network considerations. The following figure shows:

Figure 7. UCS 5108 Chassis



Best Practices

Unified CCE on UCS B-Series Blades

The blades use a Cisco Nexus 1000v switch, a vSwitch, and an Active/Active VMNIC. The Cisco Nexus 1000v is the switching platform that provides connectivity of the private VLAN to the virtual machine. The vSwitch controls the traffic for the private and public VLANs. A single vSwitch is used with two VMNICs in Active/Active state.

Redundant Pair of Cisco UCS 2100 Series Fabric Extenders

The Cisco UCS 2100 Series Fabric Extenders provide connectivity between the blades within the chassis to the fabric interconnect.

Redundant Pair of Cisco UCS 6100 Series Fabric Interconnects

The Cisco UCS 6100 Series Fabric Interconnects provide connectivity to the fabric extender from each chassis to the external network, for example, switch, SAN.

Billing Considerations

Complete the following procedure to determine the number of phones registered to Cisco HCS for Contact Center for billing purposes.

Procedure
From the CLI of the Call Manager Publisher virtual machine, run the following query exactly as shown with no new line characters:

run sql select count(*) from applicationuserdevicemap as appuserdev, applicationuser appuser, device dev where appuserdev.fkapplicationuser = appuser.pkid appuserdev.fkdevice = dev.pkid tkmodel != 73 appuser.name = "pguser"

Note   

If you configured the application username to a name other than pguser, you must update appuser.name in the above query. This query is based on the recommended Cisco HCS for Contact Center deployment, which only requires that you add CTI route points and phones to the application user. If this is not the case, you may need to modify the query.


License Considerations

Each Cisco HCS for Contact Center license includes:

  • Premium agent capabilities
  • Cisco Unified Intelligence Center Premium
  • One Unified CVP IVR or queuing treatment
  • One Unified CVP redundant IVR or queuing treatment

One Unified CVP IVR or queuing treatment license is defined as a call that receives treatment at a VoiceXML browser for queuing or self service by a Unified CVP call server.

One Unified CVP redundant IVR or queuing treatment license is defined as a call that receives treatment on the secondary Unified CVP call server residing on the secondary side for redundancy purposes.


Note


Both Unified CVP call servers are active and can process calls. This implies that there could be times when you can handle more calls, however, Cisco supports a maximum of 1 IVR or queue treatment port per agent license.


While each HCS for Contact Center license provides a Unified CVP port for self-service or redundancy, current deployment limitations result in slightly lower capacity when running at 100% licensing capacity. For example, 500 agents licensed on a 500 agent deployment model or 1000 agents licensed on a 1000 agent deployment model.

For example, a 500 agent deployment model with 500 agent licenses includes:

  • 500 calls receiving IVR or queue treatment and 400 callers talking to agents
  • 400 calls in queue receiving IVR or queue treatment and at the same time another 500 callers talking to 500 agents
  • 450 calls receiving IVR or queue treatment at 450 agents talking

For example, a 1000 agent deployment model with 1000 agent licenses includes:

  • 1000 calls receiving IVR or queue treatment and 800 callers talking to agents
  • 800 calls in queue receiving IVR and at the same time another 1000 callers talking to 1000 agents
  • 900 agents talking and 900 agents receiving IVR or call treatment

Core Component Integrated Options Considerations

Agent Greeting Design Considerations

The following sections list the functional limitations for Agent Greeting and Whisper Announcement.

Agent Greeting has the following limitations:

  • Agent Greeting is not supported with outbound calls made by an agent. The announcement plays for inbound calls only.
  • Only one Agent Greeting file plays per call.
  • Supervisors cannot listen to agents’ recorded greetings.
  • Agent Greetings do not play when the router selects the agent through a label node.
  • The default CTI OS Toolkit agent desktop includes the Agent Greeting buttons. If Agent Greeting is not configured, the Agent Greeting buttons do not work. If you use the default desktop but do not plan to use Agent Greeting, you should remove the Agent Greeting button.
  • Silent Monitoring (CTI OS and Unified CM-based) is supported with Agent Greeting with the following exception: For Unified-CM based Silent Monitoring, supervisors cannot hear the greetings. If a supervisor clicks the Silent Monitor button on the CTI OS desktop while a greeting is playing, a message displays stating that a greeting is playing and to try again shortly.

Whisper Announcement Design Considerations

Whisper announcement has the following limitations:

  • Whisper Announcement is not supported with outbound calls made by an agent. The announcement plays only for inbound calls.
  • For Whisper Announcement to work with agent-to-agent, you can use the SendToVRU node before the call is sent to the agent. The transferred call must be sent to the Unified CVP before it is sent to another agent, so that Unified CVP can control the call and play the Whisper Announcement, regardless of which node is used to send the call to Unified CVP.
  • Whisper Announcements do not play when the router selects the agent through a label node.
  • Whisper Announcement is not supported with SIP Refer Transfers.
  • Only one Whisper Announcement file plays per call.
  • Silent Monitoring (CTI OS and Unified CM-based) is supported with Whisper Announcement with the following exception: for Unified-CM-based Silent Monitoring, supervisors cannot hear the announcements themselves. The Silent Monitor button on the supervisor desktop is disabled while an announcement is playing.

Local Trunk Design Considerations

The following figure shows these two options, Cisco Unified Border Element—Enterprise at the customer premise and TDM gateway at the customer premise.
Figure 8. CUBE-E or TDM Gateway at the Customer Premise

CUBE-Enterprise at Customer Premise

Consider the following if you use the Cisco Unified Border Element—Enterprise at the customer premise:

  • Cisco Unified Border Element—Enterprise gateway and the Cisco VXML gateway reside at the customer premise and calls are queued at the customer premise.
  • The Cisco Unified Border Element—Enterprise and VXML gateway can be co-located on the same ISR, or located on different ISRs for cases where the number of IVR ports to agent ratio is small.
  • Cisco Unified Border Element— Enterprise Integrated Services Router (ISR) provides the security, routing, and Digital Signal Processors (DSPs) for transcoders.
  • Redundant Cisco Unified Border Element— Enterprise and Cisco VXML ISRs for failover/redundancy.
  • WAN bandwidth must be sized appropriately for calls from CUBE—SP to CUBE—Enterprise at the customer premise.
  • Cisco Unified Border Element Enterprise supports flow-through mode. Flow-around mode is not supported.

TDM Gateway at Customer Premise

You can route PSTN calls using local gateway trunk(s) if you prefer to keep your E1/T1 PSTN.

Consider the following if you use the TDM gateway at the customer premise:

  • Both the Cisco TDM gateway and the Cisco VXML gateway reside at the customer premise.
  • PSTN delivery is at the local customer premise.
  • The media stays local at the customer premise for the local PSTN breakout. The IVR call leg is deterministically routed to the local VXML gateway and only uses the centralized resources in spill-over scenarios.
  • When media is delivered to a different site, Cisco Unified Communications Manager location-based call admission control limits the number of calls over the WAN link.
  • Calls local to a customer premise use the G.711 codec. Calls going over the WAN link can use the G.729 codec to optimize the WAN bandwidth.
  • ASR/TTS server for local breakout is at the customer premise and resides on a UCS or bare metal server.

Location-based Call Admission Control

Location-based Call Admission Control (LBCAC) maximizes local branch resources, keeping a call within the branch whenever possible and limiting the number of calls that go over the WAN. Unified CVP supports queue-at-the-edge, a simpler and more effective configuration. Using the queue-at-the-edge functionality, the originating call from a specific branch office is routed to a local VXML Gateway based on priority. That is, it always chooses a local branch agent if possible.

Figure 9. Location-based Call Admission Control



LBCAC Concept Definitions

To configure local trunk, you must understand the following concepts:

  • Phantom Location - A default location with unlimited bandwidth used when calculating calls that are hair pinned over SIP trunk, or when the SIP call is queued at the local branch, to enable correct bandwidth calculations. The Phantom location should be assigned to the gateway or trunk for Unified CVP.
  • SiteID - The SiteID is a string of numbers that is appended to the label by the Unified CCE so that you can configure the dial plan to route the call to a specific destination, such as the branch VXML gateway or the egress gateway, or Unified CM node. The SiteID can be appended to the front or end of the label, at the end, or not at all. This configuration is separate from the Unified CM location configuration, and is specific to Unified CVP. The SiteID indicates the real location of the call and allows the deduction of the bandwith from the correct location.

For information on local trunk configuration, see LBCAC Queue-at-the-Edge configuration.

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

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

Agent Desktop to Unified CCE Call Servers

There are many factors to consider when assessing the traffic and bandwidth requirements between Agent or Supervisor Desktops and Unified CCE Call Servers. 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 recommends 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

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.

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 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 Max latency Round Trip
Media Server TCP 80 CVP-data AF11 10 1 sec
Unified CVP Call Server (SIP) TCP 5060 Call Signaling CS3 24 200 ms
Unified CVP IVR service TCP 8000 CVP-data AF11 10 1 sec
Unified CVP VXML Server TCP 7000 CVP-data AF11 10 1 sec
Ingress Gateway SIP TCP 5060 Call Signaling CS3 24 200 ms
VXML Gateway SIP TCP 5060 Call Signaling CS3 24 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.

Silent Monitoring Bandwidth Usage

With Silent Monitoring supervisors can listen to the agent calls in Unified CCE call centers that use CTI OS. Voice packets sent to and received by the monitored agent's IP hardware phone are captured from the network and sent to the supervisor desktop. At the supervisor desktop, these voice packets are decoded and played on the supervisor's system sound card. Silent Monitoring of an agent consumes approximately the same network bandwidth as an additional voice call. If a single agent requires bandwidth for one voice call, then the same agent being silently monitored requires bandwidth for two concurrent voice calls. To calculate the total network bandwidth required for your call load, multiply the number of calls by the per-call bandwidth figure for your particular codec and network protocol.

Reporting Bandwidth

Definition of Sizing

The following parameters combined affect 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.0 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):
Unified Intelligence Center User Profile Customer Parameters Value Network Bandwidth Requirement (in Kbps)
Unified Intelligence Center–AW/HDS Client–Unified Intelligence Center Unified Intelligence Center--Unified Intelligence Center Unified Intelligence Center--Unified Intelligence Center for each node
Profile 1

(500 agent deployment)

Total concurrent Users 50 1,283 1,454 N/A N/A
Profile 1 2
Profile 2 15
Number of Average Rows per RT Report 50
Number of Average Columns per RT Report 10
Number of Historical Report 1
Historical Report Interval (in second) 1800
Number of Average Rows per Historical Report 800
Number of Average Columns per Historical Report 10
Number of Nodes on side A 1
Number of Nodes on side B 0
Profile 2

(1000 agent deployment)

Total concurrent Users 100 1,783 4,554 1,934.54 967.27
Number of Real Time Reports 2
Real Time Report Interval (in second) 15
Number of Average Rows per RT Report 50
Number of Average Columns per RT Report 20
Number of Historical Report 1
Historical Report Interval (in second) 1800
Number of Average Rows per Historical Report 200
Number of Average Columns per Historical Report 20
Number of Nodes on side A* 1
Number of Nodes on side B* 2

a-Law Codec Support Considerations

HCS for Contact Center supports G.711 a-law codec. This means that the SIP carrier sends the capability as G.711 a-law and G.729. The prompts at the VXML gateway should be G.711 a-law and the agents need to support both G.711 a-law and G.729. a-law supports the following features for Cisco HCS:
  • Agent Greeting
  • Whisper Announcement
  • Call Manager Based Silent Monitoring
  • Outbound (SIP Dialer)
  • Courtesy Callback
  • Post Call Survey

Note


Mobile Agent and ASR/TTS are not supported with a-law.


For information on the core component configurations for a-law codec support, see Core Component Configurations to Support a-law Codec.

Back-Office Phone Support Considerations

Following are the considerations for the back-office phone support on the same Unified CM for HCS for Contact Center:
  • You must meet the minimum OVA requirements of Unified CM for 500 or 1000 agent deployment as described in Open Virtualization Format Files
  • If you are replacing the Contact Center agent phone already pre-sized in the OVA defined in Configuration Limits with the regular back-office phone. This does not require the re-sizing of the OVA.
  • If you plan to use the Unified CM for all the agents and additional back-office phones or want to increase the OVA size, then you must follow the guidelines for Spec-based Hardware Support and do appropriate sizing.
: