-
Cisco IP Contact Center Enterprise Edition Releases 5.0 and 6.0 Solution Reference Network Design (SRND)
-
Preface
-
Architecture Overview
-
Deployment Models
-
Design Considerations for High Availability
-
Sizing Call Center Resources
-
Sizing IPCC Components and Servers
-
Sizing Cisco CallManager Servers For IPCC
-
Agent Desktop and Supervisor Desktop
-
Bandwidth Provisioning and QoS Considerations
-
Securing IPCC
-
Glossary
-
Index
-
Table Of Contents
Treatment and Queuing with IP IVR
Treatment and Queuing with ISN
Multi-Site with Centralized Call Processing
Treatment and Queuing with IP IVR
Treatment and Queuing with ISN
Treatment and Queuing with IP IVR
Treatment and Queuing with ISN
Multi-Site with Distributed Call Processing
Distributed Voice Gateways with Treatment and Queuing Using IP IVR
Distributed Voice Gateways with Treatment and Queuing Using ISN
Distributed ICM Option with Distributed Call Processing Model
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
Failure Analysis of IPCC Clustering Over the WAN
Private Connection Between Site 1 and Site 2
Connectivity to Central Site from Remote Agent Site
Remote Agent with IP Phone Deployed via the Business Ready Teleworker Solution
IPCC Outbound (Blended Agent) Option
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
•
•
•
Many variations or combinations of these deployment models are possible. The primary factors that cause variations within these models are as follows:
•
•
•
•
•
•
•
•
•
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
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
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:
•
•
•
•
•
•
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
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
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
•
•
•
•
•
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
•
•
•
•
•
•
•
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
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:
•
•
•
•
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
•
•
•
Best Practices
•
–
–
–
–
•
•
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
•
•
•
•
•
•
•
•
Best Practices
•
•
•
•
•
•
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
•
•
•
•
•
•
•
•
•
Best Practices
•
•
http://www.cisco.com/partner/WWChannels/technologies/resources/IPCC_resources.html
•
•
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
•
•
•
•
•
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
•
•
•
•
Best Practices
•
•
•
•
•
–
–
–
–
•
•
•
•
•
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
•
•
Best Practices
•
•
•
•
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
•
•
•
Best Practices
•
•
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
•
•
•
•
Best Practices
•
•
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
•
•
•
•
Best Practices
•
•
•
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
•
•
Best Practices
•
•
•
•
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
Signaling communication must be guaranteed for the following connections:
•
•
•
•
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:
•
BHCA * 20 = bps
•
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
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:
•
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.
•
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.
•
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.
•
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.
•
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:
•
•
•
•
•
•
For the combined dedicated link in this example, the results are as follows:
•
•
•
If this example were implemented with two separate links, Router/Logger private and PG private, the link sizes and queues would be as follows:
•
•
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
•
•
•
•
•
•
•
•
•
•
