Cisco IP Contact Center Enterprise Edition Releases 5.0 and 6.0 Solution Reference Network Design (SRND)
Deployment Models
Downloads: This chapterpdf (PDF - 606.0KB) The complete bookPDF (PDF - 3.26MB) | Feedback

Deployment Models

Table Of Contents

Deployment Models

Single Site

Treatment and Queuing with IP IVR

Treatment and Queuing with ISN

Transfers

Multi-Site with Centralized Call Processing

Centralized Voice Gateways

Treatment and Queuing with IP IVR

Treatment and Queuing with ISN

Transfers

Distributed Voice Gateways

Treatment and Queuing with IP IVR

Treatment and Queuing with ISN

Transfers

Multi-Site with Distributed Call Processing

Distributed Voice Gateways with Treatment and Queuing Using IP IVR

Treatment and Queuing

Transfers

Distributed Voice Gateways with Treatment and Queuing Using ISN

Treatment and Queuing

Transfers

Distributed ICM Option with Distributed Call Processing Model

Clustering Over the WAN

Centralized Voice Gateways with Centralized Call Treatment and Queuing Using IP IVR

Centralized Voice Gateways with Centralized Call Treatment and Queuing Using ISN

Distributed Voice Gateways with Distributed Call Treatment and Queuing Using ISN

Site-to-Site ICM Private Communications Options

ICM Central Controller Private and Cisco CallManager PG Private Across Dual Links

ICM Central Controller Private and Cisco CallManager PG Private Across Single Link

Bandwidth and QoS Requirements for IPCC Clustering Over the WAN

Highly Available WAN

ICM Private WAN

Failure Analysis of IPCC Clustering Over the WAN

Entire Central Site Loss

Private Connection Between Site 1 and Site 2

Connectivity to Central Site from Remote Agent Site

Highly Available WAN Failure

Remote Agent Over Broadband

Remote Agent with IP Phone Deployed via the Business Ready Teleworker Solution

IPCC Outbound (Blended Agent) Option

Traditional ACD Integration

Traditional IVR Integration

Using PBX Transfer

Using PSTN Transfer

Using IVR Double Trunking

Using Cisco CallManager Transfer and IVR Double Trunking


Deployment Models


There are numerous ways that IPCC can be deployed, but the deployments can generally be categorized into the following major types or models:

Single Site

Multi-Site Centralized Call Processing

Multi-Site Distributed Call Processing

Clustering over the WAN

Many variations or combinations of these deployment models are possible. The primary factors that cause variations within these models are as follows:

Locations of IPCC servers

Locations of voice gateways

Choice of inter-exchange carrier (IXC) or local exchange carrier (LEC) trunks

Pre-routing availability

IVR queuing platform and location

Transfers

Traditional ACD, PBX, and IVR integration

Sizing

Redundancy

This chapter discusses the impact of these factors (except for sizing) on the selection of a design. With each deployment model, this chapter also lists considerations and risks that must be evaluated using a cost/benefit analysis. Scenarios that best fit a particular deployment model are also noted.

A combination of these deployment models is also possible. For example, a multi-site deployment may have some sites that use centralized call processing (probably small sites) and some sites that use distributed call processing (probably larger sites). Examples of scenarios where combinations are likely are identified within each section.

Also in this chapter is a section on integration of traditional ACD and IVR systems into an IPCC deployment, with considerations on hybrid PBX/ACD deployments. Sizing and redundancy are discussed in later chapters of this IPCC design guide. For more information on the network infrastructure required to support an IPCC solution, refer to the Cisco Network Infrastructure Quality of Service Design guide, available at

http://www.cisco.com/go/srnd

For more information on deployment models for IPCC and IP Telephony, refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide, available at

http://www.cisco.com/go/srnd

Single Site

A single-site deployment refers to any scenario where all voice gateways, agents, desktops, IP Phones, and call processing servers (Cisco CallManager, Intelligent Contact Management (ICM), and IP IVR or Internet Service Node (ISN)) are located at the same site and have no WAN connectivity between any IPCC software modules. Figure 2-1 illustrates this type of deployment.

Figure 2-1 Single-Site Deployment

Figure 2-1 shows two IP IVRs, a Cisco CallManager cluster, redundant ICM PROGGERS, an Administrative Workstation (AW) and Historical Data Server (HDS), and a direct connection to the PSTN from the voice gateways. The ICM PROGGER in this scenario is running the following major software processes:

Router

Logger

Cisco CallManager Peripheral Interface Manager (PIM)

Two IVR or ISN PIMs

CTI Server

CTI Object Server (CTI OS) or Cisco Agent Desktop Servers

Within this model, many variations are possible. For example, the ICM Central Controller and Peripheral Gateways (PGs) could be split onto separate servers. For information on when to install the ICM Central Controller and PG on separate servers, refer to the chapter on Sizing IPCC Components and Servers, page 5-1.

The ICM could also be deployed in a simplex fashion instead of redundantly. For information on the benefits and design for IPCC redundancy, refer to the chapter on Design Considerations for High Availability.

The number of Cisco CallManager nodes and the hardware model used is not specified along with the number of IP IVRs or ISN servers. For information on determining the number and type of servers required, refer to the chapter on Sizing IPCC Components and Servers, page 5-1.

Also not specified in this model is the specific data switching infrastructure required for the LAN, the type of voice gateways, or the number of voice gateways and trunks. Cisco campus design guides and IP Telephony design guides are available to assist in the design of these components. The chapter on Sizing Call Center Resources, discusses how to determine the number of gateway ports.

Another variation in this model is to have the voice gateways connected to the line side of a PBX instead of the PSTN. Connection to multiple PSTNs and a PBX all from the same single-site deployment is also possible. For example, a deployment can have trunks from a local PSTN, a toll-free PSTN, and a traditional PBX/ACD. For more information, see Traditional ACD Integration, and Traditional IVR Integration.

This deployment model also does not specify the type of signaling (ISDN, MF, R1, and so on) to be used between the PSTN and voice gateway or the specific signaling (H.323 or MGCP) to be used between the voice gateway and Cisco CallManager.

The amount of digital signal processor (DSP) resources required for placing calls on hold, consultative transfers, and conferencing is also not specified in this model. For information on sizing of these resources, refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide, available at

http://www.cisco.com/go/srnd

The main advantage of the single-site deployment model is that there is no WAN connectivity required. Given that there is no WAN in this deployment model, there is generally no need to use G.729 or any other compressed Real-Time Transport Protocol (RTP) stream, so transcoding would not be required.

Treatment and Queuing with IP IVR

In this deployment model, all initial and subsequent queuing is done on the IP IVR. If multiple IP IVRs are deployed, the ICM should be used to load-balance calls across those IP IVRs.

Treatment and Queuing with ISN

In this deployment model, all initial and subsequent queuing is done using ISN. A single server may be used, with all ISN processes co-located on that server. Multiple servers, on the other hand, allow scaling and redundancy. More information can be found in the sections on Sizing ISN Components, and Design Considerations for High Availability

Transfers

In this deployment model (as well as in the multi-site centralized call processing model), both the transferring agent and target agent are on the same PIM. This also implies that both the routing client and the peripheral target are the same peripheral (or PIM). The transferring agent generates a transfer to a particular dialed number (for example, looking for any specialist in the specialist skill group).

Assuming that a match is found in the Dialed Number Plan (DNP) for the transfer request, that the DNP type is allowed for the transferring agent, and that the post-route option is set to yes, the Cisco CallManager PIM logic will generate a route request to the ICM router. The ICM router will match the dialed number to a call type and activate the appropriate routing script. The routing script looks for an available specialist.

If a target agent (specialist) is available to receive the transferred call, then the ICM router will return the appropriate label to the routing client (the Cisco CallManager PIM). In this scenario, the label is typically just the extension of the phone where the target agent is currently logged in. Upon receiving the route response (label), the Cisco CallManager PIM will then initiate the transfer by sending a JTAPI transfer request to the Cisco CallManager.

At the same time that the label is returned to the routing client, pre-call data (which includes any call data that has been collected for this call) is delivered to the peripheral target. In this scenario, the routing client and peripheral target are the same Cisco CallManager PIM. This is because the transferring agent and the target agent are both associated with the same PIM. In some of the more complex scenarios to be discussed in later sections, sometimes the routing client and peripheral target are not the same.

If a target agent is not available to receive the transferred call, then the ICM routing script is typically configured to transfer the call to an IVR so that queue treatment can be provided. In this scenario, the label is a dialed number that will instruct the Cisco CallManager to transfer the call to an IVR. Also in this scenario, the routing client and peripheral target are different. The routing client is the Cisco CallManager PIM, while the peripheral target is the specific IVR PIM to which the call is being transferred.

Multi-Site with Centralized Call Processing

A multi-site deployment with centralized call processing refers to any scenario where call processing servers (Cisco CallManager, ICM, and IP IVR or ISN) are located at the same site, while any combination of voice gateways, agents, desktops, and IP Phones are located remotely across a WAN link or centrally. Figure 2-2 illustrates this type of deployment.

There are two variations of this model:

Centralized Voice Gateways

Distributed Voice Gateways

Centralized Voice Gateways

If an enterprise has small remote sites or offices in a metropolitan area where it is not efficient to place call processing servers or voice gateways, then this model is most appropriate. As sites become larger or more geographically dispersed, use of distributed voice gateways might be a better option.

Figure 2-2 illustrates this model.

Figure 2-2 Multi-Site Deployment with Centralized Call Processing and Centralized Voice Gateways

Advantages

Only a small data switch and router, IP Phones, and agent desktops are needed at remote sites where only a few agents exist, and only limited system and network management skills are required at remote sites.

No PSTN trunks are required directly into these small remote sites and offices, except for local POTS lines for emergency services (911) in the event of a loss of the WAN link.

PSTN trunks are used more efficiently because the trunks for small remote sites are aggregated.

IPCC Queue Points (IP IVR or ISN) are used more efficiently because all Queue Points are aggregated.

No VoIP WAN bandwidth is used while calls are queuing (initial or subsequent).

As with the single-site deployment model, all the same variations exist. For example, multi-site deployments can run the ICM software all on the same server or on multiple servers. The ICM software can be installed as redundant or simplex. The number of Cisco CallManager and IP IVR or ISN servers is not specified by the deployment model, nor are the LAN/WAN infrastructure, voice gateways, or PSTN connectivity. For other variations, see Single Site.

Best Practices

VoIP WAN connectivity is required for RTP traffic to agent phones at remote sites.

RTP traffic to agent phones at remote sites may require compression to reduce VoIP WAN bandwidth usage. It may be desirable for calls within a site to be uncompressed, so transcoding might also be required depending upon how the IP Telephony deployment is designed.

Skinny Client Control Protocol (SCCP) call control traffic from IP Phones to the Cisco CallManager cluster flows over the WAN.

CTI data to and from the IPCC Agent Desktop flows over the WAN. Adequate bandwidth and QoS provisioning are critical for these links.

Because there are no voice gateways at the remote sites, customers might be required to dial a long-distance number to reach what would normally be a local PSTN phone call if voice gateways with trunks were present at the remote site. This situation could be mitigated if the business requirements are to dial 1-800 numbers at the central site. An alternative is to offer customers a toll-free number to dial, and have those calls all routed to the centralized voice gateway location. However, this requires the call center to incur toll-free charges that could be avoided if customers had a local PSTN number to dial.

The lack of local voice gateways with local PSTN trunks can also impact access to 911 emergency services, and this must be managed via the Cisco CallManager dial plan. In most cases, local trunks are configured to dial out locally and for 911 emergency calls.

Cisco CallManager locations-based call admission control failure will result in a routed call being disconnected. Therefore, it is important to provision adequate bandwidth to the remote sites. Also, an appropriately designed QoS WAN is critical.

Treatment and Queuing with IP IVR

As in the single-site deployment, all call queuing is done on the IP IVR at a single central site. While calls are queuing, no RTP traffic flows over the WAN. If requeuing is required during a transfer or reroute on ring-no-answer, the RTP traffic flow during the queue treatment also does not flow over the WAN. This reduces the amount of WAN bandwidth required to the remote sites.

Treatment and Queuing with ISN

In this model, ISN is used in the same way as IP IVR.

Transfers

In this scenario, the transferring agent and target agent are on the same Cisco CallManager cluster and Cisco CallManager PIM. Therefore, the same call and message flows will occur as in the single-site model, whether the transferring agent is on the same LAN as the target or on a different LAN. The only differences are that QoS must be enabled and that appropriate LAN/WAN routing must be established. For details on provisioning your WAN with QoS, refer to the Cisco Network Infrastructure Quality of Service Design guide, available at

http://www.cisco.com/go/srnd

During consultative transfers where the agent (not the caller) is routed to an IP IVR port for queuing treatment, transcoding is required because the IP IVR can generate only G.711 media streams.

Distributed Voice Gateways

A variation of the centralized call processing model can include multiple voice gateway locations. This distributed voice gateway model may be appropriate for a company with many small sites, each requiring local PSTN trunks for incoming calls. This model provides local PSTN connectivity for local calling and access to local emergency services. Figure 2-3 illustrates this model.

Figure 2-3 Multi-Site Deployment with Centralized Call Processing and Distributed Voice Gateways with IP IVR

In this deployment model, shown with IP IVR for queuing and treatment, it might be desirable to restrict calls arriving at a site to be handled by an agent within that site, but this is not required. By restricting calls to the site where it arrived:

VoIP WAN bandwidth is reduced for calls going to agents.

Customer service levels for calls arriving into that site might suffer due to longer queue times and handle times.

Longer queue times can occur because, even though an agent at another site is available, the IPCC configuration may continue to queue for an agent at the local site only.

Longer handle times can occur because, even though a more qualified agent exists at another site, the call may be routed to a local agent to reduce WAN bandwidth usage.

It is important for deployment teams to carefully assess the trade-offs between operational costs and customer satisfaction levels to establish the right balance on a customer-by-customer basis. For example, it may be desirable to route a specific high-profile customer to an agent at another site to reduce their queue time and allow the call to be handled by a more experienced representative, while another customer may be restricted to an agent within the site where the call arrived.

An IPCC deployment may actually use a combination of centralized and distributed voice gateways. The centralized voice gateways can be connected to one PSTN carrier providing toll-free services, while the distributed voice gateways can be connected to another PSTN carrier providing local phone services.

Inbound calls from the local PSTN could be both direct inward dial (DID) and contact center calls. It is important to understand the requirements for all inbound and outbound calling to determine the most efficient location for voice gateways. Identify who is calling, why they are calling, where they are calling from, and how they are calling.

In multi-site deployments with distributed voice gateways, the ICM's pre-routing capability can also be used to load-balance calls dynamically across the multiple sites. A list of PSTN carriers that offer ICM pre-routing services can be found in the ICM product documentation available at

http://www.cisco.com/univercd/cc/td/doc/product/icm/

In multi-site environments where the voice gateways have both local PSTN trunks and separate toll-free trunks delivering contact center calls, the ICM pre-routing software can load-balance the toll-free contact center calls around the local contact center calls. For example, suppose you have a two-site deployment where Site 1 currently has all agents busy and many calls in queue from locally originated calls, and Site 2 has only a few calls in queue or maybe even a few agents currently available. In that scenario, you could have the ICM instruct the toll-free provider to route most or all of the toll-free calls to Site 2. This type of multi-site load balancing provided by the ICM is dynamic and automatically adjusts as call volumes change at all sites.

Just as in the two previous deployment models, much variation exists in the number and type of ICM, Cisco CallManager, and IP IVR or ISN servers; LAN/WAN infrastructure; voice gateways; PSTN connectivity; and so forth.

Advantages

Only limited systems management skills are needed for the remote sites because most servers, equipment, and system configurations are managed from a centralized location.

The ICM pre-routing option can be used to load-balance calls across sites, including sites with local PSTN trunks in addition to toll-free PSTN trunks.

No WAN RTP traffic is required for calls arriving at each remote site that are handled by agents at that remote site.

Best Practices

The IP IVR or ISN, Cisco CallManager, and PGs (for both Cisco CallManager and IVR/ISN) are co-located. In this model, the only IPCC communications that can be separated across a WAN are the following:

ICM Central Controller to ICM PG

ICM PG to IPCC Agent Desktops

Cisco CallManager to voice gateways

Cisco CallManager to IP Phones

If calls are not going to be restricted to the site where calls arrive, or if calls will be made between sites, more RTP traffic will flow across the WAN. It is important to determine the maximum number of calls that will flow between sites or locations. Cisco CallManager locations-based call admission control failure will result in a routed call being disconnected (rerouting within Cisco CallManager is not currently supported). Therefore, it is important to provision adequate bandwidth to the remote sites, and appropriately designed QoS for the WAN is critical.

H.323 or MGCP signaling traffic between the voice gateways and the centralized Cisco CallManager servers will flow over the WAN. Proper QoS implementation on the WAN is critical, and signaling delays must be within tolerances listed in the Cisco IP Telephony Solution Reference Network Design (SRND) guide, available at

http://www.cisco.com/go/srnd

Treatment and Queuing with IP IVR

WAN bandwidth must be provisioned to support all calls that will be treated and queued at the central site.

Centralized IP IVRs provide efficiency of IP IVR ports when compared with smaller deployments of IP IVRs at each remote site.

Treatment and Queuing with ISN

Using ISN for treatment and queuing allows you to reduce the amount of voice bearer traffic traveling across the WAN. ISN queues and treats calls on the remote gateways, eliminating the need to terminate the voice bearer traffic at the central site. WAN bandwidth must still be provisioned for transfers and conferences that involve agents at other locations.

Transfers

Intra-site or inter-site transfers using the VoIP WAN to send the RTP stream from one site to another will occur basically the same way as a single-site transfer or a transfer in a deployment with centralized voice gateways.

An alternative to using the VoIP WAN for routing calls between sites is to use a carrier-based PSTN transfer service. These services allow the IPCC voice gateways to outpulse DTMF tones to instruct the PSTN to reroute (transfer) the call to another voice gateway location. Each site can be configured within the ICM as a separate peripheral. The label then indicates whether a transfer is intra-site or inter-site, using Takeback N Transfer (TNT).

Multi-Site with Distributed Call Processing

Enterprises with multiple medium to large sites separated by large distances tend to prefer a distributed call processing model. In this model, each site has its own Cisco CallManager cluster, treatment and queue points, PGs, and CTI Server. However, as with the centralized call processing model, sites could be deployed with or without local voice gateways. Some deployments may also contain a combination of distributed voice gateways (possibly for locally dialed calls) and centralized voice gateways (possibly for toll-free calls) as well as centralized or distributed treatment and queue points.

Regardless of how many sites are being deployed, there will still be only one logical ICM Central Controller. If the ICM Central Controller is deployed with redundancy, side A and B can be deployed side-by-side or geographically separated (remote redundancy). For details on remote redundancy, refer to the ICM product documentation available at

http://www.cisco.com/univercd/cc/td/doc/product/icm/

Distributed Voice Gateways with Treatment and Queuing Using IP IVR

This deployment model is a good choice if the company has multiple medium to large sites. In this model, voice gateways with PSTN trunks terminate into each site. Just as in the centralized call processing model with distributed voice gateways, it may be desirable to limit the routing of calls to agents within the site where the call arrived (to reduce WAN bandwidth). An analysis of benefits from customer service levels versus WAN costs is required to determine whether limiting calls within a site is recommended. Figure 2-4 illustrates this model.

Figure 2-4 Multi-Site Deployment with Distributed Call Processing and Distributed Voice Gateways with IP IVR

As with the previous models, many variations are possible. The number and type of ICM Servers, Cisco CallManager servers, and IP IVR servers can vary. LAN/WAN infrastructure, voice gateways, PSTN trunks, redundancy, and so forth are also variable within this deployment model. Central processing and gateways may be added for self-service, toll-free calls, and support for smaller sites. In addition, the use of a pre-routing PSTN Network Interface Controller (NIC) is also an option.

Advantages

Each independent site can scale to support up to 2000 agents per Cisco CallManager cluster, and there is no software limit (you can have up to 80 PGs) to the number of sites that can be combined by the ICM Central Controller to produce a single enterprise-wide contact center.

All or most VoIP traffic can be contained within the LAN of each site, if desired. The QoS WAN shown in Figure 2-4 would be required for voice calls to be transferred across sites. Use of a PSTN transfer service (for example, Takeback N Transfer) could eliminate that need. If desired, a small portion of calls arriving at a particular site can be queued for agent resources at other sites to improve customer service levels.

ICM pre-routing can be used to load-balance calls to the best site to reduce WAN usage for VoIP traffic.

Failure at any one site has no impact on operations at another site.

Each site can be sized according to the requirements for that site

The ICM Central Controller provides centralized management for configuration of routing for all calls within the enterprise.

The ICM Central Controller provides the capability to create a single enterprise-wide queue.

The ICM Central Controller provides consolidated reporting for all sites.

Best Practices

The PG, Cisco CallManager cluster, and IP IVR must be co-located.

The communication link from the ICM Central Controller to the PG must be sized properly and provisioned for bandwidth and QoS. (For details, refer to the chapter on Bandwidth Provisioning and QoS Considerations, page 8-1.)

Gatekeeper-based call admission control could be used to reroute calls between sites over the PSTN when WAN bandwidth is not available. It is best to ensure that adequate WAN bandwidth exists between sites for the maximum amount of calling that can occur.

If the communication link between the PG and the ICM Central Controller is lost, then all contact center routing for calls at that site is also lost. Therefore, it is important to implement a fault-tolerant WAN. Even when a fault-tolerant WAN is implemented, it is important to identify contingency plans for call treatment and routing when communication is lost between the ICM Central Controller and PG. For example, in the event of a lost ICM Central Controller connection, the Cisco CallManager CTI route points could send the calls to IP IVR ports to provide basic announcement treatment or to invoke a PSTN transfer to another site. Another alternative is for the Cisco CallManager cluster to route the call to another Cisco CallManager cluster that may have a PG with an active connection to the ICM Central Controller.

While two inter-cluster call legs for the same call will not cause unnecessary RTP streams, two separate call signaling control paths will remain intact between the two clusters (producing a logical hair-pinning and reducing the number of inter-cluster trunks by two).

Latency between ICM Central Controllers and remote PGs cannot exceed 200 ms one way (400 ms round-trip).

Treatment and Queuing

Initial call queuing is done on an IP IVR co-located with the voice gateways, so no transcoding is required. When a call is transferred and subsequent queuing is required, the queuing should be done on an IP IVR at the site where the call is currently being processed. For example, if a call comes into Site 1 and gets routed to an agent at Site 2, but that agent needs to transfer the call to another agent whose location is unknown, the call should be queued to an IP IVR at Site 2 to avoid generating another inter-cluster call. A second inter-cluster call would be made only if an agent at Site 1 was selected for the transfer. The RTP flow at this point would be directly from the voice gateway at Site 1 to the agent's IP Phone at Site 1. However, the two Cisco CallManager clusters would still logically see two calls in progress between the two clusters.

Transfers

Transfers within a site function just like a single-site transfer. Transfers between Cisco CallManager clusters use either the VoIP WAN or a PSTN service.

If the VoIP WAN is used, sufficient inter-cluster trunks must be configured. An alternative to using the VoIP WAN for routing calls between sites is to use a PSTN transfer service. These services allow the IPCC voice gateways to outpulse DTMF tones to instruct the PSTN to reroute (transfer) the call to another voice gateway location. Another alternative is to have the Cisco CallManager cluster at Site 1 make an outbound call back to the PSTN. The PSTN would then route the call to Site 2, but the call would use two voice gateway ports at Site 1 for the remainder of the call.

Distributed Voice Gateways with Treatment and Queuing Using ISN

This deployment model is the same as the previous model, except that ISN is used instead of IP IVR for call treatment and queuing. In this model, voice gateways with PSTN trunks terminate into each site. Just as in the centralized call processing model with distributed voice gateways, it may be desirable to limit the routing of calls to agents within the site where the call arrived (to reduce WAN bandwidth). Call treatment and queuing may also be achieved at the site where the call arrived, further reducing the WAN bandwidth needs. Figure 2-5 illustrates this model.

Figure 2-5 Multi-Site Deployment with Distributed Call Processing and Distributed Voice Gateways with ISN

As with the previous models, many variations are possible. The number and type of ICM Servers, Cisco CallManager servers, and ISN servers can vary. LAN/WAN infrastructure, voice gateways, PSTN trunks, redundancy, and so forth are also variable within this deployment model. Central processing and gateways may be added for self-service, toll-free calls, and support for smaller sites. In addition, the use of a pre-routing PSTN Network Interface Controller (NIC) is also an option.

Advantages

ISN Servers can be located either centrally or remotely. Call treatment and queuing will still be distributed, executing on the local gateway, regardless of ISN server location. ISN is shown centrally located in Figure 2-5.

Each independent site can scale to support up to 2000 agents per Cisco CallManager cluster, and there is no software limit to the number of sites that can be combined by the ICM Central Controller to produce a single enterprise-wide contact center.

All or most VoIP traffic can be contained within the LAN of each site, if desired. The QoS WAN would be required for voice calls to be transferred across sites. Usage of a PSTN transfer service (for example, Takeback N Transfer) could eliminate that need. If desired, a small portion of calls arriving at a particular site can be queued for agent resources at other sites to improve customer service levels.

ICM pre-routing can be used to load-balance calls to the best site to reduce WAN usage for VoIP traffic.

Failure at any one site has no impact on operations at another site.

Each site can be sized according to the requirements for that site.

The ICM Central Controller provides centralized management for configuration of routing for all calls within the enterprise.

The ICM Central Controller provides the capability to create a single enterprise-wide queue.

The ICM Central Controller provides consolidated reporting for all sites.

Best Practices

The Cisco CallManager PG and Cisco CallManager cluster must be co-located. The ISN PG and ISN servers must be co-located.

The communication link from the ICM Central Controller to PG must be properly sized and provisioned for bandwidth and QoS. Cisco provides a partner tool called the VRU Peripheral Gateway to ICM Central Controller Bandwidth Calculator to assist in calculating the VRU PG-to-ICM bandwidth requirement. This tool is available online at

http://www.cisco.com/partner/WWChannels/technologies/resources/IPCC_resources.html

If the communication link between the PG and the ICM Central Controller is lost, then all contact center routing for calls at that site is lost. Therefore, it is important that a fault-tolerant WAN is implemented. Even when a fault-tolerant WAN is implemented, it is important to identify contingency plans for call treatment and routing when communication is lost between the ICM Central Controller and PG.

Latency between ICM Central Controllers and remote PGs cannot exceed 200 ms one way (400 ms round-trip)

Treatment and Queuing

ISN queues and treats calls on the remote gateways, eliminating the need to terminate the voice bearer traffic at the central site. ISN servers may be located at the central site or distributed to remote sites. WAN bandwidth must still be provisioned for transfers and conferences that involve agents at other locations.

Unlike IP IVR, with ISN the call legs are torn down and reconnected, avoiding signaling hairpins. With IP IVR, two separate call signaling control paths will remain intact between the two clusters (producing a logical hairpinning and reducing the number of intercluster trunks by two).

Transfers

Transfers within a site function just like a single-site transfer. Transfers between Cisco CallManager clusters use either the VoIP WAN or a PSTN service.

If the VoIP WAN is used, sufficient intercluster trunks must be configured. An alternative to using the VoIP WAN for routing calls between sites is to use a PSTN transfer service. These services allow the IPCC voice gateways to outpulse DTMF tones to instruct the PSTN to reroute (transfer) the call to another voice gateway location. Another alternative is to have the Cisco CallManager cluster at Site 1 make an outbound call back to the PSTN. The PSTN would then route the call to Site 2, but the call would use two voice gateway ports at Site 1 for the remainder of the call.

Distributed ICM Option with Distributed Call Processing Model

Figure 2-6 illustrates this deployment model.

Figure 2-6 Distributed ICM Option Shown with IP-IVR

Advantages

The primary advantage of the distributed ICM option is the redundancy gained from splitting the ICM Central Controller between two redundant sites.

Best Practices

ICM Central Controllers (Routers and Loggers) must have a dedicated link to carry the private communication between the two redundant sites. In a non-distributed ICM model, the private traffic usually traverses an Ethernet crossover cable or LAN connected directly between the side A and side B ICM Central Controller components. In the distributed ICM model, the private communication between the A and B ICM components must travel across a dedicated link such as a T1.

Latency across the private dedicated link cannot exceed 100 ms one way (200 ms round-trip).

Latency between ICM Central Controllers and remote PGs cannot exceed 200 ms one way (400 ms round-trip).

The private link cannot traverse the same path as public traffic. The private link must have path diversity and must reside on a link that is completely path-independent from ICM public traffic.

The redundant centralized model is explored in the next section on Clustering over the WAN

Clustering Over the WAN

Clustering over the WAN for IPCC allows full agent redundancy in the case of a central-site outage. Implementation of clustering over the WAN for IPCC does have several strict requirements that differ from other models. Bandwidth between central sites for ICM public and private traffic, Cisco CallManager intra-cluster communications (ICC), and all other voice-related media and signaling must be properly provisioned with QoS enabled. The WAN between central sites must be highly available (HA) with separate ICM (PG and Central Controller) private links.

Advantages

No single point of failure, including loss of an entire central site

Remote agents require no reconfiguration to remain fully operational in case of site or link outage. When outages occur, agents and agent devices dynamically switch to the redundant site.

Central administration for both ICM and Cisco CallManager

Reduction of servers for distributed deployment

Best Practices

The highly available (HA) WAN between the central sites must be fully redundant with no single point of failure. (For information regarding site-to-site redundancy options, refer to the WAN infrastructure and QoS design guides available at http://www.cisco.com/go/srnd.) In case of partial failure of the highly available WAN, the redundant link must be capable of handling the full central-site load with all QoS parameters. For more information, see the section on Bandwidth and QoS Requirements for IPCC Clustering Over the WAN.

A highly available (HA) WAN using point-to-point technology is best implemented across two separate carriers, but this is not necessary when using a ring technology.

Latency requirements across the highly available (HA) WAN must meet the current Cisco IP Telephony requirements for clustering over the WAN. Currently a maximum latency of 20 ms one way (40 ms round-trip) is allowed. This equates to a transmission distance of approximately 1860 miles (3000 km) under ideal conditions. The transmission distance will be lessened by network conditions that cause additional latency. For full specifications, refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide, available at

http://www.cisco.com/go/srnd

IPCC latency requirements can be met by conforming to IP Telephony requirements. However, the bandwidth requirements for Cisco CallManager intra-cluster communications differ between IPCC and IP Telephony. For more information, see the section on Bandwidth and QoS Requirements for IPCC Clustering Over the WAN.

Bandwidth requirements across the highly available (HA) WAN include bandwidth and QoS provisioning for (see Bandwidth and QoS Requirements for IPCC Clustering Over the WAN):

Cisco CallManager intra-cluster communications (ICC)

Communications between Central Controllers

Communications between Central Controller and PG

Communications between CTI Object Server (CTI OS) and CTI Server, if using CTI OS

Separate dedicated link(s) for ICM private communications are required between ICM Central Controllers Side A and Side B and between PGs Side A and Side B to ensure path diversity. Path diversity is required due to the architecture of ICM. Without path diversity, the possibility of a dual (public communication and private communication) failure exists. If a dual failure occurs even for a moment, ICM instability and data loss may occur, including the corruption of one logger database.

Dedicated private link(s) may be two separate dedicated links, one for Central Controller private and one for Cisco CallManager PG private, or one converged dedicated link containing Central Controller and PG private. See Site-to-Site ICM Private Communications Options, for more information.

Separate paths must exist from agent sites to each central site. Both paths must be capable of handling the full load of signaling, media, and other traffic if one path fails. These paths may reside on the same physical link from the agent site, with a WAN technology such as Frame Relay using multiple permanent virtual circuits (PVCs).

The minimum cluster size using IP IVR as the treatment and queuing platform is 5 nodes (publisher plus 4 subscribers). This minimum is required to allow IP IVR at each site to have redundant connections locally to the cluster without traversing the WAN. JTAPI connectivity between Cisco CallManager and IP IVR is not supported across the WAN. Local gateways also will need local redundant connections to Cisco CallManager.

The minimum cluster size using ISN as the treatment and queuing platform is 3 nodes (publisher plus 2 subscribers). However, Cisco recommends 5 nodes, especially if there are IP Phones (either contact center or non-contact center) local to the central sites, central gateways, or central media resources that would require local failover capabilities.

Centralized Voice Gateways with Centralized Call Treatment and Queuing Using IP IVR

In this model, the voice gateways are located in the central sites. IP IVR is centrally located and used for treatment and queuing on each side. Figure 2-7 illustrates this model.

Figure 2-7 Centralized Voice Gateways with Centralized Call Treatment and Queuing Using IP IVR

Advantages

Component location and administration are centralized.

Calls are treated and queued locally, eliminating the need for queuing across a WAN connection.

Best Practices

WAN connections to agent sites must be provisioned with bandwidth for voice as well as control and CTI. See Bandwidth and QoS Requirements for IPCC Clustering Over the WAN, for more information.

Local voice gateway may be needed at remote sites for local out-calling and 911. For more information, refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide, available at

http://www.cisco.com/go/srnd

Central site outages would include loss of half of the ingress gateways, assuming a balanced deployment. Gateways and IVRs must be scaled to handle the full load in both sites if one site fails.

Carrier call routing must be able to route calls to the alternate site in the case of a site or gateway loss. Pre-routing may be used to balance the load, but it will not be able to prevent calls from being routed to a failed central site. Pre-routing is not recommended.

Centralized Voice Gateways with Centralized Call Treatment and Queuing Using ISN

In this model, the voice gateways are Voice XML (VXML) gateways located in the central sites. ISN is centrally located and used for treatment and queuing. Figure 2-8 illustrates this model.

Figure 2-8 Centralized Voice Gateways with Centralized Call Treatment and Queuing Using ISN

Advantages

Component location and administration are centralized.

Calls are treated and queued locally, eliminating the need for queuing across a WAN connection.

There is less load on Cisco CallManager because ISN is the primary routing point. This allows higher scalability per cluster compared to IP IVR implementations. See Sizing IPCC Components and Servers, page 5-1, for more information.

Best Practices

WAN connections to agent sites must be provisioned with bandwidth for voice as well as control and CTI. See Bandwidth and QoS Requirements for IPCC Clustering Over the WAN, for more information.

A local voice gateway might be needed at remote sites for local out-calling and 911.

Distributed Voice Gateways with Distributed Call Treatment and Queuing Using ISN

In this model, the voice gateways are VXML gateways distributed to agent locations. ISN is centrally located and used for treatment and queuing on the remote gateways. Figure 2-9 illustrates this model.

Figure 2-9 Distributed Voice Gateways with Distributed Call Treatment and Queuing Using ISN

Advantages

No or minimal voice RTP traffic across WAN links if ingress calls and gateways are provisioned to support primarily their local agents. Transfers and conferences to other sites would traverse the WAN.

Calls are treated and queued at the agent site, eliminating the need for queuing across a WAN connection.

Local calls incoming and outgoing, including 911, can share the local VXML gateway.

There is less load on Cisco CallManager because ISN is the primary routing point. This allows higher scalability per cluster compared to IP IVR implementations. See Sizing IPCC Components and Servers, page 5-1, for more information.

Best Practices

Distributed gateways require minimal additional remote maintenance and administration over centralized gateways.

The media server for ISN may be centrally located or located at the agent site. Media may also be run from gateway flash. Locating the media server at the agent site reduces bandwidth requirements but adds to the decentralized model.

Site-to-Site ICM Private Communications Options

ICM private communications must travel on a separate path from the public communications between ICM components. There are two options for achieving this path separation: dual and single links.

ICM Central Controller Private and Cisco CallManager PG Private Across Dual Links

Dual links, shown in Figure 2-10, separate ICM Central Controller Private traffic from VRU/CM PG Private traffic.

Figure 2-10 ICM Central Controller Private and Cisco CallManager PG Private Across Dual Links

Advantages

Failure of one link does not cause both the ICM Central Controller and PG to enter simplex mode, thus reducing the possibility of an outage due to a double failure.

The QoS configuration is limited to two classifications across each link, therefore links are simpler to configure and maintain.

Resizing or alterations of the deployment model and call flow may affect only one link, thus reducing the QoS and sizing changes needed to ensure proper functionality.

Unanticipated changes to the call flow or configuration (including misconfiguration) are less likely to cause issues across separate private links.

Best Practices

The links must be across separate dedicated circuits. The links, however, do not have to be redundant and must not be redundant against each other.

Link sizing and configuration must be examined before any major change to call load, call flow, or deployment configuration

The link must be a dedicated circuit and not be tunneled across the highly available (HA) WAN. See Best Practices, at the beginning of the section on Clustering Over the WAN, for more information on path diversity.

ICM Central Controller Private and Cisco CallManager PG Private Across Single Link

A single link, shown in Figure 2-11, carries both ICM Central Controller Private traffic and VRU/CM PG Private traffic. Single-link implementations are more common and less costly than dual-link implementations.

Figure 2-11 ICM Central Controller Private and Cisco CallManager PG Private Across Single Link

Advantages

Less costly than separate-link model

Fewer links to maintain, but more complex

Best Practices

The link does not have to be redundant. If a redundant link is used, however, latency on failover must not exceed 500 ms.

Separate QoS classifications and reserved bandwidth are required for Central Controller high-priority and PG high-priority communications. For details, see Bandwidth Provisioning and QoS Considerations, page 8-1.

Link sizing and configuration must be examined before any major change to call load, call flow, or deployment configuration. This is especially important in the single link model.

Link must be a dedicated circuit fully isolated from, and not tunneled across, the highly available (HA) WAN. See Best Practices, at the beginning of the section on Clustering Over the WAN, for more information on path diversity.

Bandwidth and QoS Requirements for IPCC Clustering Over the WAN

Bandwidth must be provisioned to properly size links and set reservations within those links. The following sections detail bandwidth requirements for ICM Private, ICM Public, Cisco CallManager, and CTI traffic.

Highly Available WAN

Bandwidth must be guaranteed across the highly available (HA) WAN for all ICM public, CTI, and Cisco CallManager intra-cluster communications (ICC). Additionally, bandwidth must be guaranteed for any calls going across the highly available WAN. Minimum total bandwidth required across the highly available WAN for all IPCC signaling is 2 Mbps.

Additional information regarding QoS design and provisioning can be found in the QoS design guides available at

http://www.cisco.com/go/srnd

Signaling communication must be guaranteed for the following connections:

ICM Central Controller to Cisco CallManager PG

ICM Central Controller to IP IVR or ISN PG

IP IVR or ISN PG to IP IVR or ISN

PG to PG Test Other Side

CTI Server to CTI OS

Cisco CallManager Intra-Cluster Communications (ICC)

ICM Central Controller to Cisco CallManager PG

Cisco provides a partner tool called the ACD/CallManager Peripheral Gateway to ICM Central Controller Bandwidth Calculator to assist in calculating the Cisco CallManager PG-to-ICM bandwidth requirement. This tool is available online at

http://www.cisco.com/partner/WWChannels/technologies/resources/IPCC_resources.html

ICM Central Controller to IP IVR or ISN PG

Cisco also provides a partner tool to compute bandwidth needed between ICM Central Controller and the IP IVR PG. This tool is available to Cisco partners and Cisco employees at the following link:

http://www.cisco.com/partner/WWChannels/technologies/resources/IPCC_resources.html

At this time, no tool exists that specifically addresses communication between the ICM Central Controller and the ISN PG. Testing has shown, however, that using the tool for the link between the ICM Central Controller and IP IVR will produce accurate measurements. To achieve accurate measurements, you have to make a substitution in one field: the field "Average number of RUN VRU script nodes" should be treated as "Number of ICM script nodes that interact with ISN."

IP IVR or ISN PG to IP IVR or ISN

At this time, no tool exists that specifically addresses communication between the IP IVR or ISN PG and the IP IVR or ISN. However, the tool mentioned in the two previous sections produces a fairly accurate measurement of bandwidth needed for this communication. Bandwidth consumed between the ICM Central Controller and IP IVR or ISN PG is very similar to the bandwidth consumed between the IP IVR or ISN PG and the IP IVR or ISN.

The tool is available to Cisco partners and Cisco employees at

http://www.cisco.com/partner/WWChannels/technologies/resources/IPCC_resources.html

If the IP IVR or ISN PGs are split across the WAN, total bandwidth required would be double what the tool reports: once for ICM Central Controller to IP IVR or ISN PG and once for IP IVR or ISN PG to IP IVR ISN.

PG to PG Test Other Side

PG-to-PG public communication consists of minimal "Test other Side" messages and consumes approximately 10 kbps of bandwidth per PG pair.

CTI Server to CTI OS

The worst case for bandwidth utilization across the WAN link between the CTI OS and CTI Server occurs when the CTI OS is remote from the CTI Server. A bandwidth queue should be used to guarantee availability for this worst case.

For this model, the following simple formula can be used to compute worst-case bandwidth requirements:

With no Extended Call Context (ECC) or Call Variables:

BHCA * 20 = bps

With ECC and/or Call Variables

BHCA * (20 + ((Number of Variables * Average Variable Length) / 40) = bps

Example: With 10,000 BHCA and 20 ECC variables of average length 40:

10,000 * (20 + ((20 * 40) / 40) = 10,000 * 40 = 400,000 bps = 400 kbps

Cisco CallManager Intra-Cluster Communications (ICC)

The Cisco IP Telephony Solution Reference Network Design (SRND) guide states that 900 kbps must be reserved for every 10,000 BHCA. This amount is significantly higher with IPCC due to the number of call redirects and additional CTI/JTAPI communications encompassed in the intra-cluster communications.

The bandwidth that must be reserved is approximately 2,000 kbps (2 Mbps) per 10,000 BHCA. This requirement assumes proper design and deployment based on the recommendations in this IPCC design guide. Inefficient design (such as "ingress calls to Site 1 are treated in Site 2") will cause additional intra-cluster communications, possibly exceeding the defined requirements.

More specifically, you can use the following formula to calculate the required bandwidth:

Link Size BHCA * 200 = bps

ICM Private WAN

Table 2-1 is a worksheet to assist with computing the link and queue sizes. Definitions and examples follow the table.


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


Table 2-1 Worksheet for Calculating Private Bandwidth 

Component
Effective BHCA
Multiplication Factor
Recommended Link
Multiplication Factor
Recommended Queue
 

Router + Logger

 

* 30

 

* 0.8

 

Total Router+Logger High-Priority Queue Size

Cisco CallManager PG

 

* 100

 

* 0.9

 

Add these three numbers together and total in the shaded box below to get the PG High-Priority Queue size.

IP IVR PG

 

* 60

 

* 0.9

 

ISN PG

 

* 120

 

* 0.9

 

IP IVR or ISN Variables

 

* ((Number of Variables * Average Variable Length) / 40)

 

* 0.9

 

 

 

Total Link Size

 

 

 

Total PG High-Priority Queue Size

If one dedicated link is used between sites for private communication, add all link sizes together and use the Total Link Size at the bottom of Table 2-1. 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 would be 11,000 Effective BHCA.

Cisco CallManager PG

This value includes all calls that come through ICM Route Points controlled by Cisco CallManager 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, would be 11,000 effective BHCA.

IP IVR PG

This value is the total BHCA for call treatment and queuing. For example, 10,000 BHCA ingress calls, with all of them receiving treatment and 40% being queued, would be 14,000 effective BHCA.

ISN PG

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

IP IVR or ISN Variables

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

Example of a Private Bandwidth Calculation

Table 2-2 shows an example calculation for a combined dedicated private link with the following characteristics:

BHCA coming into the contact center is 10,000.

100% of calls are treated by IP IVR and 40% are queued.

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

There are four IP IVRs used to treat and queue the calls, with one PG pair supporting them.

There is one Cisco CallManager PG pair for a total of 900 agents.

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

Table 2-2 Example Calculation for a Combined Dedicated Private Link 

Component
Effective BHCA
Multiplication Factor
Recommended Link
Multiplication Factor
Recommended Queue
 

Router + Logger

11,000

* 30

330,000

* 0.8

297,000

Total Router+Logger High-Priority Queue Size

Cisco CallManager PG

11,000

* 100

1,100,000

* 0.9

880,000

Add these three numbers together and total in the shaded box below to get the PG High-Priority Queue size.

IP IVR PG

14,000

* 60

840,000

* 0.9

756,000

ISN PG

0

* 120

0

* 0.9

0

IP IVR or ISN Variables

14,000

* ((Number of Variables * Average Variable Length) / 40)

280,000

* 0.9

252,000

 

 

Total Link Size

2,550,000

 

1,888,000

Total PG High-Priority Queue Size

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

Total Link = 2,550,000 bps

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

PG high-priority bandwidth queue of 1,888,000 bps

If this example were implemented with two separate links, Router/Logger private and PG private, the link sizes and queues would be 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 297,000 bps

PG link of 2,220,000 bps, with high-priority bandwidth queue of 1,888,000 bps

Failure Analysis of IPCC Clustering Over the WAN

This section describes the behavior of clustering over the WAN for IPCC during certain failure situations. The stability of the highly available (HA) WAN is extremely critical in this deployment model, and failure of the highly available WAN is considered outside the bounds of what would normally happen.

For illustrations of the deployment models described in this section, refer to the figures shown previously for Clustering Over the WAN.

Entire Central Site Loss

Loss of the entire central site is defined as the loss of all communications with a central site, as if the site were switched off. This can result from natural disasters, power issues, major connectivity issues, and human error, among other things. If a central site retains some but not all connectivity, it is not considered a site loss but rather a partial connectivity loss, and this scenario is covered in subsequent sections.

When an entire central site has completely lost IPCC clustering over the WAN, remote agents will fail-over properly to the redundant site. Failover times can range from 1 to 60 seconds for agents. Variations are due to agent count, phone registration location, and agent desktop server used.

When using distributed VXML gateways and ISN, the gateways must fail-over from one site to another if their primary site is lost. This failover takes approximately 30 seconds, and calls coming in to the remote gateways during those 30 seconds will be lost.

Private Connection Between Site 1 and Site 2

If the private connection between ICM Central Controller sides A and B should fail, one ICM Router will go out-of-service and the other ICM Router will then be running in simplex mode until the link is reinstated. This situation will not cause any call loss or failure.

If the private connection between PG side A and PG side B should fail, the non-active PG will go out-of-service, causing the active PG to run in simplex mode until the link is reinstated. This situation will not cause any call loss or failure.

When using a combined private link, ICM Central Controller and PG private connections will be lost if the link is lost. This will cause both components to switch to simplex mode as described above. This situation will not cause any call loss or failure.

Connectivity to Central Site from Remote Agent Site

If connectivity to one of the central sites is lost from a remote agent site, all phones and agent desktops will immediately switch to the second central site and begin processing calls. Failover typically takes between 1 and 60 seconds.

Highly Available WAN Failure

By definition, a highly available (HA) WAN should not fail under normal circumstances. If the HA WAN is dual-path and fully redundant, as it should be, a failure of this type would be highly unusual. This section discusses what happens in this unlikely scenario.

If the HA WAN is lost for any reason, the Cisco CallManager cluster becomes split. The primary result from this occurrence is that ICM loses contact with half of the agent phones. ICM is in communication with only half of the cluster and cannot communicate with or see any phones registered on the other half. This causes ICM to immediately log out all agents with phones that are no longer visible. These agents cannot log back in until the highly available WAN is restored or their phones are forced to switch cluster sides.

Remote Agent Over Broadband

An IPCC enterprise might want to deploy their network with support for remote at-home agents using a Cisco IP Phone. This section outlines the IPCC Remote Agent solution that can be deployed using a desktop broadband asymmetric digital subscriber line (ADSL) or Cable connection as the remote network.

The Cisco Voice and Video Enabled IPSec VPN (V3PN) ADSL or Cable connection uses a Cisco 830 Series router as an edge router to the broadband network. The Cisco 830 Series router provides the remote agent with V3PN, Encryption, Network Address Translation (NAT), Firewall, IOS Intrusion Detection System (IDS), and QoS on the broadband network link to the IPCC campus. Remote agent V3PN aggregation on the campus is provided via LAN to LAN VPN routers.

Advantages

Remote agent deployment results in money saved for a contact center enterprise, thereby increasing return on investment (ROI).

A remote agent can be deployed with standard IPCC agent desktop applications such as Cisco CTI OS, Cisco Agent Desktop, or customer relationship management (CRM) desktops.

This model works with ADSL or Cable broadband networks.

The Broadband Agent Desktop "Always on" connection is a secure extension of the corporate LAN in the home office.

At-home agents have access to the same IPCC applications and most IPCC features in their home office as when they are working at the IPCC Enterprise contact center, and they can access those features in exactly the same way

This model provides high-quality voice using IP phones, with simultaneous data to the agent desktop via existing broadband service.

IPCC home agents and home family users can securely share broadband Cable and DSL connections, with authentication of IPCC corporate users providing access to the VPN tunnel.

The home agent solution utilizes the low-cost Cisco 831 Series router.

This model supports dynamic IP addressing via Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol over Ethernet (PPPoE).

The Cisco 831 Series router provides VPN tunnel origination, Quality of Service (QoS) to the edge, and Firewall (and other security functions), thus reducing the number of devices to be managed.

The Remote Agent router can be centrally managed by the enterprise using a highly scalable and flexible management product such as CiscoWorks.

The remote agent solution is based on Cisco IOS VPN Routers for resiliency, high availability, and a building-block approach to high scalability that can support thousands of home agents.

All traffic, including data and voice, is encrypted with the Triple Data Encryption Standard (3DES).

This model can be deployed as part of an existing Cisco CallManager installation.

Home agents can have the same extension type as campus agents.

Best Practices

Follow all applicable V3PN and Business Ready Teleworker design guidelines outlined in the documentation available at:

http://www.cisco.com/go/teleworker

http://www.cisco.com/go/v3pn

http://www.cisco.com/go/srnd

Configure remote agent IP phones to use G.729 with minimum bandwidth limits. Higher quality voice can be achieved with the G.711 codec. The minimum bandwidth to support G.711 is 512 kbps upload speed.

Implement fault and performance management tools such as NetFlow, Service Assurance Agent (SAA), and Internetwork Performance Monitor (IPM).

Wireless access points are supported; however, their use is determined by the enterprise security polices for remote agents.

Only one remote agent per household is supported.

Cisco recommends that you configure the conference bridge on a DSP hardware device. There is no loss of conference voice quality using a DSP conference bridge. This is the recommended solution even for pure IP Telephony deployments.

The Remote Agent over Broadband solution is supported only with centralized IPCC and Cisco CallManager clusters.

There might be times when the ADSL or Cable link goes down. When the link is back up, you might have to reset your ADSL or Cable modem, Cisco 831 Series router, and IP phone. This task will require remote agent training.

Only unicast Music on Hold (MoH) streams are supported.

There must be a Domain Name System (DNS) entry for the remote agent desktop, otherwise the agent will not be able to connect to a CTI OS server. DNS entries can be dynamically updated or entered as static updates.

The remote agent's workstation and IP phone must be set up to use Dynamic Host Configuration Protocol (DHCP).

The remote agent's PC requires Windows XP Pro for the operating system. In addition, XP Remote Desktop Control must be installed.

The Cisco 7960 IP Phone requires a power supply. The Cisco 831 Series router does not supply power to the IP Phone.

Home agent broadband bandwidth requires a minimum of 256 kbps upload speed and 1.4 Mbps download speed for ADSL, and 1 Mbps download for Cable. Before actual deployment, make sure that the bandwidth is correct. If you are deploying Cable, then take into account peak usage times. If link speeds fall below the specified bandwidth, the home agent can encounter voice quality problems such as clipping.

Remote agent round-trip delay to the IPCC campus is not to exceed 180 ms for ADSL or 60 ms for Cable. Longer delay times can result in voice jitter, conference bridge problems, and delayed agent desktop screen pops.

If the Music on Hold server is not set up to stream using a G.729 codec, then a transcoder must be set up to enable outside callers to receive MoH.

For Cisco Supervisor Desktop, there are supervisor limitations to silent monitoring, barge-in, intercept, and voice recording with regard to home agent IP phones. Cisco Agent Desktop (Enterprise and Express) home and campus supervisors cannot voice-monitor home agents. Supervisors are capable of sending and receiving only text messages, and they can see which home agents are online and can log them out.

Desktop-based monitoring is not supported for IPCC Express with Cisco Agent Desktop. Desktop-based monitoring is applicable only with IPCC Enterprise edition.

CTI OS Supervisor home and campus supervisors can silently monitor, barge in, and intercept, but not record home agents. CTI OS home and campus supervisors can send and receive text messages, make an agent "ready," and also log out home agents.

Connect the agent desktop to the RJ45 port on the back of the IP phone. Otherwise, CTI OS Supervisor will not be able to voice-monitor the agent phone.

Only IP phones that are compatible with Cisco IPCC are supported. For compatibility information, refer to the following documentation:

Bill of Materials at

http://www.cisco.com/univercd/cc/td/doc/product/icm/ccbubom/index.htm

Compatibility Matrix at

http://www.cisco.com/application/pdf/en/us/guest/products/ps1844/c1609/ccmigration_09186a008031a0a7.pdf

Release Notes for IPCC Express at

http://www.cisco.com/univercd/cc/td/doc/product/voice/sw_ap_to/apps_3_5/english/admn_app/rn35_2.pdf

You can find a test for the broadband line speed at http://www.Broadbandreports.com. From this website, you can execute a test that will benchmark the home agent's line speed (both upload and download) from a test server.

The email alias for V3PN questions is: ask-ese-vpn@cisco.com.

Remote Agent with IP Phone Deployed via the Business Ready Teleworker Solution

In this model, the remote agent's IP phone and workstation are connected via the VPN tunnel to the main IPCC campus. Customer calls routed to the remote agent are handled in the same manner as campus agents. (See Figure 2-12.)

Figure 2-12 Remote Agent with IP Phone Deployed via the Business Ready Teleworker Solution

Advantages

High-speed broadband enables cost-effective office applications

Site-to-site "always on" VPN connection

Advanced security functions allow extension of the corporate LAN to the home office

Supports full range of converged desktop applications, including CTI data and high-quality voice

Best Practices

Minimum broadband speed supported is 256 kbps upload and 1.0 Mbps download for cable.

Minimum broadband speed supported is 256 kbps upload and 1.4 Mbps download for ADSL.

Agent workstation must have 500 MHz, 512 MB RAM or greater.

IP phone must be configured to use G.711 on minimum broadband speeds.

QoS is enabled only at the Cisco 831 Router edge. Currently, service providers are not providing QoS.

Enable security features on the Cisco 831 Series router.

The Cisco 7200 VXR and Catalyst 6500 IPSec VPN Services Module (VPNSM) offer the best LAN-to-LAN performance for agents.

The remote agent's home phone must be used for 911 calls.

Redirect on no answer (RONA) should be used when a remote agent is logged in and ready but is unavailable to pick up a call.

IPCC Outbound (Blended Agent) Option

The ability for agents to handle both inbound and outbound contacts offers a way to optimize contact center resources. The Cisco Outbound Option enables the multi-functional contact center to take advantage of the ICM enterprise management, allowing contact center managers in need of outbound campaign solutions to take advantage of the enterprise view that Cisco ICM Enterprise and Cisco IPCC Enterprise maintain over agent resources.

Description and Characteristics

The IP Dialer uses virtual IP phones to place outbound calls through a voice gateway via the Cisco CallManager. The Dialer is a pure software solution that does not require telephony cards.

The Outbound Option solution consists of three main processes:

The Campaign Manager process resides on the Side-A Logger and is responsible for sending configuration and customer records to all the Dialers in the enterprise.

The Import process is responsible for importing customer records and Do Not Call records into the system.

The Dialer processes. Multiple Dialer processes may be connected to the Campaign Manager server at multiple sites.

A Media Routing PIM is required for each Dialer to reserve agents for outbound use.

Outbound Option dialers maintain connections to the CTI Server (for agent CTI control), the Campaign Manager (for configuration and customer records), Cisco CallManager (Skinny Client Control Protocol connection for placing and transferring calls), and the Media Routing PG (to reserve agents).

Sizing Information

Maximum of 200 agents (any mixture of inbound and outbound agents) on a fully coresident configuration (Outbound Option Dialer, IPCC PG, CTI Server, and CTI OS on a single server).

Maximum of 300 agents (any mixture of inbound and outbound agents) on a PG when the CTI OS on the PG server is configured for no more than 200 agents.

Figure 2-13 illustrates the model for the IPCC Outbound Option with more than 200 agents.

Figure 2-13 IPCC Outbound Option with More Than 200 Agents

Advantages

The Cisco Outbound Option Dialer solution allows an agent to participate in outbound campaigns as well as inbound calls by utilizing a pure software IP-based dialer.

In summary, the main benefits of the IPCC Outbound Option are:

IPCC Outbound Option has enterprise-wide dialing capability, with IP Dialers placed at multiple call center sites. The Campaign Manager server is located at the central site.

This option provides centralized management and configuration via the ICM Admin workstation.

IPCC Release 6.0 and later provide the Enhanced Call Progress Analysis feature, including answering machine detection.

This option provides true call-by-call blending of inbound and outbound calls.

This option incorporates flexible outbound mode control by using the ICM script editor to control type of outbound mode and percentage of agents within a skill to use for outbound activity.

Transfer to IVR mode (agent-less campaigns) and Direct Preview mode are available in IPCC Release 6.0 and later.

This option provides integrated webview reporting with outbound specific reporting templates.

Best Practices

Follow these guidelines and best practices when implementing the IPCC Outbound Option:

A media routing PG is required, and a media routing PIM is required for each Dialer.

An IP Dialer may be installed on an IPCC PG server for a total blended agent count of 200 (either inbound, outbound, or blended). Multiple Dialers located at a single peripheral do provide some fault tolerance but are not a true hot-standby model.

IP Dialers support only the G.711 audio codec for customer calls. Although outbound agents may be placed within a region that uses the G.729 codec, the codec switchover can add up to 1.5 seconds to the transfer time between customer and agent and is therefore not recommended.

IP Dialers should be located in close proximity to the Cisco CallManager cluster where the Dialers are registered.

Using the Cisco Media Termination phones with the outbound option might introduce an additional 0.5 second delay in transferring customer calls to the agent.

The following gateways have been tested with IPCC Outbound Option Dialers:

Cisco AS5300, AS5350, and AS5400 Series

Cisco 6608

All Outbound option dialers at a particular peripheral should have the same number of configured ports.

Outbound Option dialers perform a large number of call transfers, which increases the performance load on the Cisco CallManager server. Ensure proper Cisco CallManager server sizing when installing Outbound Option dialers. Also, proper Dialer call throttling should be enabled to prevent overloading the Cisco CallManager server. For proper throttling values for your particular Cisco CallManager server, refer to the Outbound Option Setup and Configuration Guide, available at

http://www.cisco.com/univercd/cc/td/doc/product/icm/icmentpr/icm60doc/icm6out/

For complete information on installing and configuring the Outbound software, see:

Cisco ICM/IP Contact Center Enterprise Edition Outbound Option Setup and Configuration Guide

Cisco ICM/IP Contact Center Enterprise Edition Outbound Option User Guide

Both of these documents are available online at

http://www.cisco.com/univercd/cc/td/doc/product/icm/icmentpr/icm60doc/icm6out/

Traditional ACD Integration

For enterprises that want to integrate traditional ACDs with their IPCC deployment, several options exist. For enterprises that want to load-balance calls between a traditional ACD site and an IPCC site, a pre-routing Network Interface Controller (NIC) could be added. (See Figure 2-14.) This requires that the ICM have a NIC that supports the PSTN service provider. In this scenario, the PSTN will query the ICM Central Controller (via the NIC) to determine which site is best, and the ICM response back to the PSTN will instruct the PSTN where (which site) to deliver the call. Any call data provided by the PSTN to the ICM will be passed to the agent desktop (traditional ACD or IPCC).

In order to transfer calls between the two sites (ACD site and IPCC site), a PSTN transfer service could be used. Use of a PSTN transfer service avoids any double trunking of calls at either site. An alternative to using a PSTN transfer service is to deploy TDM voice circuits between the traditional ACD and IPCC voice gateways. In that environment, any transfer of a call back to the original site will result in double trunking between the two sites. Each additional transfer between sites will result in an additional TDM voice circuit being utilized.

Figure 2-14 Integrating a Traditional ACD with an IPCC Site

An alternative to pre-routing calls from the PSTN is to have the PSTN deliver calls to just one site or to split the calls across the two sites according to some set of static rules provisioned in the PSTN. When the call arrives at either site, either the traditional ACD or the Cisco CallManager will generate a route request to the ICM to determine which site is best for this call. If the call needs to be delivered to an agent at the opposite site from where the call was originally routed, then TDM circuits between sites will be required. Determination of where calls should be routed, and if and when they should be transferred between sites, will depend upon the enterprise business environment, objectives, and cost components.

Traditional IVR Integration

There are numerous ways that traditional IVRs can be integrated into an IPCC deployment. Determination of which way is best will depend upon many factors that are discussed in the following sections. The primary consideration, though, is determining how to eliminate or reduce IVR double trunking when transferring the call from the IVR.

Using PBX Transfer

Many call centers have existing traditional IVR applications that they are not prepared to rewrite. In order to preserve these IVR applications, but yet integrate them into an IPCC environment, the IVR must have an interface to the ICM. (See Figure 2-15.)

There are two versions of the IVR interface to the ICM. One is simply a post-routing interface, which just allows the IVR to send a post-route request with call data to the ICM. The ICM will return a route response instructing the IVR to transfer the call elsewhere. In this scenario, the traditional IVR will invoke a PBX transfer to release its port and transfer the call into the IPCC environment. Any call data passed from the IVR will be passed by the ICM to the agent desktop or IP IVR.

The other IVR interface to the ICM is the serial port communications interface (SCI). The SCI allows the IVR to receive queuing instructions from the ICM. In the PBX model, the SCI is not required.

Even if the IVR has the SCI interface, Cisco still recommends that you deploy IP IVR for all call queuing because this prevents any additional utilization of the traditional IVR ports. In addition, use of the IP IVR for queuing provides a way to requeue calls on subsequent transfers or RONA treatment.

Figure 2-15 Traditional IVR Integration Using PBX Transfer

Using PSTN Transfer

This model is very similar to the previous model, except that the IVR invokes a PSTN transfer (instead of a PBX transfer) so that the traditional IVR port can be released. (See Figure 2-16.) Again, the IP IVR would be used for all queuing so that any additional occupancy of the traditional IVR ports is not required and also so that any double trunking in the IVR is avoided. Any call data collected by the traditional IVR application will be passed by the ICM to the agent desktop or IP IVR.

Figure 2-16 Traditional IVR Integration Using PSTN Transfer

Using IVR Double Trunking

If your traditional IVR application has a very high success rate, where most callers are completely self-served in the traditional IVR and only a very small percentage of callers ever need to be transferred to an agent, then it might be acceptable to double-trunk the calls in the traditional IVR for that small percentage of calls. (See Figure 2-17.) Unlike the previous model, if the traditional IVR has an SCI interface, then the initial call queuing could be done on the traditional IVR. The reason this is beneficial is that, in order to queue the call on the IP IVR, a second traditional IVR port would be used. By performing the initial queuing on the traditional IVR, only one traditional IVR port is used during the initial queuing of the call. However, any subsequent queuing as a result of transfers or RONA treatment must be done on the IP IVR to avoid any double trunking. If the traditional IVR does not have an SCI interface, then the IVR will just generate a post-route request to the ICM to determine where the call should be transferred. All queuing in that scenario would have to be done on the IP IVR.

Figure 2-17 Traditional IVR Integration Using IVR Double Trunking

Using Cisco CallManager Transfer and IVR Double Trunking

Over time, it might become desirable to migrate the traditional IVR applications to the IP IVR. However, if a small percentage of traditional IVR applications still exist for very specific scenarios, then the IVR could be connected to a second voice gateway. (See Figure 2-18.) Calls arriving at the voice gateway from the PSTN would be routed by Cisco CallManager. Cisco CallManager could route specific DNs to the traditional IVR or let the ICM or IP IVR determine when to transfer calls to the traditional IVR. If calls in the traditional IVR need to be transferred to an IPCC agent, then a second IVR port, trunk, and voice gateway port would be used for the duration of the call. Care should be taken to ensure that transfer scenarios do not allow multiple loops to be created because voice quality could suffer.

Figure 2-18 Traditional IVR Integration Using Cisco CallManager Transfer and IVR Double Trunking