Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 6.x
Cisco Unified Communications Manager Business Edition
Downloads: This chapterpdf (PDF - 498.0KB) The complete bookPDF (PDF - 17.73MB) | Feedback

Cisco Unified Communications Manager Business Edition

Table Of Contents

Cisco Unified Communications Manager Business Edition

Deployment Models

Unified CMBE Single-Site Deployment

Benefits of a Unified CMBE Single-Site Deployment

Best Practices for a Unified CMBE Single-Site Deployment

Unified CMBE Multisite WAN Deployment with Centralized Call Processing

Benefits of a Unified CMBE Multisite Deployment

Best Practices for a Unified CMBE Multisite WAN Deployment with Centralized Call Processing

Dial Plan

Survivable Remote Site Telephony (SRST)

Unified CMBE Directory Management

Capacity Planning and Scaling the System

Busy Hour Call Attempts (BHCA)

Device Calculations

Contact Center Example

Cisco Unified CM Applications

Cisco Extension Mobility (EM)

Cisco Unified Communications Manager Assistant (Unified CM Assistant)

Cisco Unified Communications Manager Attendant Console (AC)

Cisco WebDialer

Cisco Unified Mobility


Cisco Unified Communications Manager Business Edition


Last revised on: January 29, 2008

 

Cisco Unified Communications Manager Business Edition (Unified CMBE) offers mid-market customers the features and functionality of Cisco Unified Communications Manager (Unified CM) and Cisco Unity Connection on one appliance platform. This chapter presents some design and deployment considerations that should be taken into account when considering this solution.

Many of the concepts and guidelines that apply to the standalone Unified CM also apply to the Business Edition. This chapter attempts to treat only a subset of those areas that are specific to a Unified CMBE deployment.

Deployment Models

Unified CMBE supports two types of deployment models: single site and multisite WAN with centralized call processing. Unified CMBE is limited to these two deployment models because it is a single-platform deployment, running both Cisco Unified CM and Cisco Unity Connection on the same server.

Unified CMBE does not support distributed call processing deployment models with either Unified CM or Unified CMBE. In other words, Unified CMBE does not support the use of intercluster trunks to interconnect with either Unified CM deployments or other Unified CMBE deployments.

Unified CMBE Single-Site Deployment

The single-site model for Unified CMBE consists of Cisco Unified CM and Cisco Unity Connection running on the same hardware platform located at a single site or campus, with no telephony services provided over an IP WAN. Figure 27-1 illustrates some of the components of a single-site deployment with Unified CMBE.

Figure 27-1 Unified CMBE Single-Site Deployment

The the following design characteristics and considerations apply to the single-site deployment model for Unified CMBE:

Unified CMBE runs on a single hardware platform, either the Cisco Media Convergence Server (MCS) 7828-H3 or MCS 7828-I3.


Note Because Unified CMBE runs on a single hardware platform, it provides a single instance of Unified CM (a combined publisher and single subscriber instance, and a secondary subscriber instance is not configurable).


Unified CMBE supports a maximum of 500 users and up to 575 Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP) IP phones or video endpoints. (There is a firm configuration maximum of 700 devices, including all configurable phone types, CTI ports, and H.323 clients.) The busy hour call attempts (BHCA) of those devices play a big role in capacity planning. Therefore, to avoid oversubscription of system resources, see the section on Capacity Planning and Scaling the System, for rules and guidelines for planning system utilization.

Unified CMBE supports a maximum of 20 SIP, MGCP, or H323 devices (gateways, MCUs, trunks, and clients).

The PSTN is used for all external calls.

Use digital signaling processors (DSPs) for conferencing, transcoding, and media termination point (MTP) functions. Although Unified CMBE can be configured as a conference bridge or MTP, this configuration is recommended only in lab or proof-of-concept environments. Because Unified CMBE is already serving multiple critical call processing and database functions, configuring Unified CMBE as a conference bridge or MTP might have a negative impact on system performance.

Unified CMBE supports a maximum of 500 mailboxes and 16 SCCP voicemail ports. The 16 ports can be provisioned for ASR/TTS or as simple voicemail ports, as needed and licensed. Off-box ASR is not supported.

Unified CMBE supports a maximum of 100 concurrent Internet Message Access Protocol (IMAP) sessions with a maximum of 500 Cisco Unity Connection Inbox clients, or a maximum of 250 IMAP sessions with no Cisco Unity Connection Inbox clients.

Unified CMBE supports a maximum of 15,000 Voice Profile for Internet Mail (VPIM) contacts and 10 locations.

H.323 clients, MCUs, and H.323/H.320 gateways that require a gatekeeper to place calls must register with a Cisco IOS Gatekeeper (Cisco IOS Release 12.3(8)T or greater). Unified CM then uses an H.323 trunk to integrate with the gatekeeper and provide call routing and bandwidth management services for the H.323 devices registered to it. Multiple Cisco IOS Gatekeepers may be used to provide redundancy.

MCU resources are required for multipoint video conferencing. Depending on conferencing requirements, these resources may be either SCCP or H.323, or both.

H.323/H.320 video gateways are needed to communicate with H.320 videoconferencing devices on the public ISDN network.

Unified CMBE supports high-bandwidth audio (for example, G.711, G.722, or Cisco Wideband Audio) between devices within the site.

Unified CMBE supports high-bandwidth video (for example, 384 kbps or greater) between devices within the site. The Cisco Unified Video Advantage Wideband Codec, operating at 7 Mbps, is also supported.


Note Stay within the limits specified above, and be careful not to oversubscribe the system. When planning your system, if you reach those limits or surpass them, consider deploying standalone Cisco Unified CM and Cisco Unity Connection solutions instead. See Capacity Planning and Scaling the System, for further details.


Benefits of a Unified CMBE Single-Site Deployment

A single hardware platform for a converged network solution provides significant cost benefits and complexity reduction, and it enables mid-market customers to take advantage of the many IP-based applications for IP telephony. A single-site deployment also allows each site to be completely self-contained. There is no dependency for service in the event of an IP WAN failure or insufficient bandwidth.

A Unified CMBE single-site deployment has the following benefits:

Ease of deployment

Single platform for call processing, Cisco Unified Mobility, and integrated messaging

Single point of administration for both call processing and integrated messaging, providing single sign-on capabilities for administration users as well as end users

A common infrastructure for a converged solution

Simplified and unified dial plan

No transcoding resources required, due to the use of only G.711 codec

Best Practices for a Unified CMBE Single-Site Deployment

When implementing a Unified CMBE single-site deployment, follow the guidelines, benefits, and best practices of the Unified CM single-site deployment model. (See the chapter on Unified Communications Deployment Models, page 2-1, for general information.)

In addition, Cisco Unified Survivable Remote Site Telephony (SRST), as the name suggests, has typically been deployed in remote sites for backup call processing at the remote sites in the event of a WAN outage. In a Unified CMBE single-site deployment, SRST can be used at the central site.


Note Unified CMBE can be used with Cisco Unified Presence 6.x; however, Unified CMBE 6.x does not currently support LDAP synchronization or authentication. Unified CMBE users must be configured to match the users configured in LDAP (first and last name, user ID, and directory number) to avoid any potential mismatch of user information when using Cisco Unified Personal Communicator. For more information, see the chapter on Cisco Unified Presence, page 23-1.


Unified CMBE Multisite WAN Deployment with Centralized Call Processing

The Unified CMBE multisite WAN deployment model with centralized call processing consists of a single call processing appliance that provides services for up to 20 sites (one central site and 19 remote sites), and this model uses the IP WAN to transport IP telephony traffic between the sites. The IP WAN also carries call control signaling between the central site and the remote sites. Figure 27-2 illustrates a typical centralized call processing deployment, with Unified CMBE as the call processing and voicemail server at the central site and an IP WAN with QoS enabled to connect all of the remote sites. The remote sites rely on the centralized Unified CMBE to handle their call processing and integrated messaging. Other applications such as interactive voice response (IVR) systems are typically centralized as well to reduce the overall costs of administration and maintenance.

This deployment model is similar to the Unified CM multisite WAN deployment model with centralized call processing; however, in the Unified CMBE deployment models, a single hardware platform provides the call processing. (See Multiple Sites with Centralized Call Processing, page 2-4, for general multisite design characteristics.)


Note In each solution for the centralized call processing model presented in this document, the various sites connect to an IP WAN with QoS enabled.


Figure 27-2 Unified CMBE Multisite WAN Deployment with Centralized Call Processing

The the following design characteristics and considerations apply to the Unified CMBE multisite WAN deployment model with centralized call processing:

Unified CMBE runs on a single hardware platform, either the Cisco Media Convergence Server (MCS) 7828-H3 or MCS 7828-I3.


Note Because Unified CMBE runs on a single hardware platform, it provides a single instance of Unified CM (a combined publisher and single subscriber instance, and a secondary subscriber instance is not configurable).


Unified CMBE supports a maximum of 500 users and up to 575 Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP) IP phones or video endpoints. (There is a firm configuration maximum of 700 devices, including all configurable phone types, CTI ports, and H.323 clients.) The busy hour call attempts (BHCA) of those devices play a big role in capacity planning. Therefore, to avoid oversubscription of system resources, see the section on Capacity Planning and Scaling the System, for rules and guidelines for planning system utilization.

Unified CMBE supports up to 20 SRST-capable sites (one central site and 19 remote sites), as is consistent with the maximum number of voice gateways (20).

Unified CMBE supports a maximum of 20 SIP, MGCP, or H323 devices (gateways, MCUs, trunks, and clients).

Use digital signaling processors (DSPs) for conferencing, transcoding, and media termination point (MTP) functions. Although Unified CMBE can be configured as a conference bridge or MTP, this configuration is recommended only in lab or proof-of-concept environments. Because Unified CMBE is already serving multiple critical call processing and database functions, configuring Unified CMBE as a conference bridge or MTP can have a negative impact on system performance.

Unified CMBE supports a maximum of 500 mailboxes and 16 SCCP voicemail ports. The 16 ports can be provisioned for ASR/TTS or as simple voicemail ports, as needed and licensed. Off-box ASR is not supported.

Unified CMBE supports a maximum of 100 concurrent Internet Message Access Protocol (IMAP) sessions with a maximum of 500 Cisco Unity Connection Inbox clients, or a maximum of 250 IMAP sessions with no Cisco Unity Connection Inbox clients.

Unified CMBE supports a maximum of 15,000 Voice Profile for Internet Mail (VPIM) contacts and 10 locations.

Cisco Unified Survivable Remote Site Telephony (SRST), as the name suggests, has typically been deployed in remote sites for backup call processing at the remote sites in the event of a WAN outage. In a Unified CMBE multisite deployment, SRST can be used at the central site as well as the remote sites. (See Survivable Remote Site Telephony (SRST), for further details.)


Note Stay within the limits specified above, and be careful not to oversubscribe the system. When planning your system, if you reach those limits or surpass them, consider deploying standalone Cisco Unified CM and Cisco Unity Connection solutions instead. (See Capacity Planning and Scaling the System, for further details.)


Connectivity options for the IP WAN include:

Leased lines

Frame Relay

Asynchronous Transfer Mode (ATM)

ATM and Frame Relay Service Inter-Working (SIW)

Multi-Protocol Label Switching (MPLS) Virtual Private Network (VPN)

Voice and Video Enabled IP Security Protocol (IPSec) VPN (V3PN)

Routers that reside at the WAN edges require Quality of Service (QoS) mechanisms such as priority queuing and traffic shaping to protect the voice traffic from the data traffic across the WAN, where bandwidth is typically scarce. In addition, a call admission control scheme is needed to avoid oversubscribing the WAN links with voice traffic and deteriorating the quality of established calls. For centralized call processing deployments, the locations construct within Unified CM provides call admission control. (Refer to the section on Unified CM Static Locations, page 9-13, for more information on locations.)

A variety of Cisco gateways can provide the remote sites with PSTN access. When the IP WAN is down, or if all the available bandwidth on the IP WAN has been consumed, users at the remote sites can dial the PSTN access code and place their calls through the PSTN. The Survivable Remote Site Telephony (SRST) feature, available for SCCP and SIP phones on Cisco IOS gateways, provides call processing at the branch offices in the event of a WAN failure.

Benefits of a Unified CMBE Multisite Deployment

A single hardware platform for a converged network solution provides significant cost benefits and complexity reduction, and it enables mid-market customers to take advantage of the many IP-based applications for IP telephony.

A Unified CMBE multisite deployment has the following benefits:

Single platform for call processing, Cisco Unified Mobility, and integrated messaging

Single point of administration for both call processing and integrated messaging, providing single sign-on capabilities for administration users as well as end users

A common infrastructure for a converged solution

Best Practices for a Unified CMBE Multisite WAN Deployment with Centralized Call Processing

When implementing a Unified CMBE multisite deployment, follow the guidelines, benefits, and best practices of the model for a Unified CM multisite WAN deployment with centralized call processing. (See the chapter on Unified Communications Deployment Models, page 2-1, for general information.)

In addition, take the following guidelines into consideration:

When possible, use the locations mechanism in Unified CM to provide call admission control into and out of remote branches. See the chapter on Call Admission Control, page 9-1, for details on how to apply this mechanism to the various WAN topologies. Unified CMBE supports all call admission control mechanisms.

Take care to minimize delay between Unified CM and the remote locations in order reduce voice cut-through delays (also known as clipping).

In cases where the WAN bandwidth for bearer traffic has yet to be provisioned, the centralized call processing deployment model can be adapted so that inter-site voice media is sent over the PSTN instead of the WAN. (For further details, see Voice Over the PSTN as a Variant of Centralized Call Processing, page 2-12.)


Note Unified CMBE can be used with Cisco Unified Presence 6.x; however, Unified CMBE 6.x does not currently support LDAP synchronization or authentication. Unified CMBE users must be configured to match the users configured in LDAP (first and last name, user ID, and directory number) to avoid any potential mismatch of user information when using Cisco Unified Personal Communicator. For more information, see the chapter on Cisco Unified Presence, page 23-1.


Dial Plan

Cisco Unified CMBE is best suited for mid-market customers with up to 500 users and 20 or fewer total sites, and it provides a cost-effective solution that integrates the benefits of voice, video, mobility, and messaging on a single hardware platform. When provisioning the dial plan for this type of a deployment, it is best to keep the dial plan simple and easy to administer. A uniform four-digit abbreviated dial plan achieves this goal, but this type of dial plan will not fit all customers and all deployments. For a complete discussion of dial plans, refer to the chapter on Dial Plan, page 10-1.

Typically, a single-site deployment of fewer than 500 users is quite easy to provision with a four-digit abbreviated dial plan for on-net dialing. The dial plan should have the following characteristics:

The dial plan should be uniform. To make it easier, delineate your dial plan boundary based on overlap. For example, if there is overlap at four digits, then move to five digits, and so forth, until there is no overlap. (See Avoiding Overlap of Extension Dialing, page 10-4.)

The dial plan should be abbreviated (for example, four digit).

Use site codes only if required. (See the use of access and site codes in the section on Variable Length On-Net Dial Plan, page 10-6.) Site codes add complexity to the dial plan and, although they are useful for deployments with a large number of sites, they should be avoided where possible in a deployment with few sites.

Use the @ wildcard macro for simple route plan configuration (see Route Patterns, page 10-17). Be aware that, when using the @ wildcard, you might have to use route filters if you want to achieve blocking of specific patterns such as 900 numbers for premium services. For a more scalable Class of Service approach, see the section on Calling Privileges in Unified CM, page 10-21.

Table 27-1 shows an example of a four-digit abbreviated dial plan.

 

Table 27-1 Distribution of Digits in a Typical Four-Digit Uniform Dial Plan 

Range
Use
DID Ranges
Non-DID Ranges

0XXX

Excluded; 0 is used as off-net access code

 

 

1XXX

Site A extensions

206 256 1XXX

N/A

2XXX

Site B extensions

775 789 2XXX

N/A

3XXX

Site C extensions

208 424 30XX

3[1-9]XX

4[0-4]XX

Site D extensions

503 321 4[0-4]XX

N/A

4[5-9]XX

Site E extensions

450 555 4[5-9]XX

N/A

5XXX

Site A extensions

418 555 5XXX

N/A

6XXX

Site F extensions

514 555 6[0-8]XX

69XX

7XXX

Future (features)1

XXX XXX 7XXX

7XXX

8XXX

Future (features)*

XXX XXX 8XXX

8XXX

9XXX

Excluded; 9 is used as off-net access code

 

 

1 Leftover ranges can be used for various features such as IP telephony applications, numbers for meet-me conferencing, or voicemail integration numbers.


Deploying Uniform On-Net Dial Plans

You can implement a uniform on-net dial plan by following these guidelines:

Uniquely identify all phones with an abbreviated extension.

Place all phone directory numbers in a single partition.

At each site, place PSTN route patterns in one or more site-specific partitions, according to the chosen class-of-service approach. (See Calling Privileges in Unified CM, page 10-21.)

Figure 27-3 shows an example implementation for a single Unified CM deployment. Use this approach if the DID ranges available do not overlap when considering the number of digits chosen to identify internal extensions.

Figure 27-3 Example of a Uniform On-Net Dial Plan Deployment

Survivable Remote Site Telephony (SRST)

Because Unified CMBE runs on a single hardware platform with a single instance of Unified CM, devices do not have the ability to fail over to a secondary or tertiary Unified CM for call control. Therefore, the way to achieve high availability of call control functions for the IP phones is to use Cisco Unified Survivable Remote Site Telephony (SRST), which is available on Cisco IOS routers.

As the name suggests, SRST has typically been used in the remote sites of centralized call processing deployments to provide high availability in the event of a WAN outage where the IP phones lose connectivity to their primary, secondary and/or tertiary Unified CM. In Unified CMBE deployments, SRST can be used to provide high availability to both remote site and central site IP phones.

The ability to keep basic call features and functionality available at all times is an important aspect of designing an IP telephony deployment, and it is also important to ensure that the IP phones have call-handling support when they lose connectivity to Unified CMBE, whether it is over a WAN connection or at the central site due to an outage or an appliance reboot after an upgrade.

Best Practices and Guidelines

When choosing a gateway call control protocol, observe the following recommendations:

If you are not using SRST, use Media Gateway Control Protocol (MGCP) gateways for the PSTN if you do not require H.323 or SIP functionality. This practice simplifies the dial plan configuration and administration.

If you are using SRST, use a state-less or peer-to-peer gateway call control protocol such as H.323 or SIP. MGCP is a state-full, master/slave gateway call control protocol that is robust and easy to configure, but it has the following drawbacks when deployed with SRST:

MGCP gateway fallback transitions to a default H.323 or SIP session application. Therefore, an H.323 or SIP configuration is still required for external calls in SRST mode.

There is no call preservation when MGCP fallback occurs for T1 and E1 PRI (only for MGCP analog and T1 CAS). Instead, all active calls are dropped when MGCP fallback occurs for PRI. With H.323 and SIP, you can achieve call preservation on T1 and E1 PRI with failover to SRST mode. Phones in SRST mode can dial out to the PSTN, and previously active calls are still preserved.

Conversely, the same process occurs when connectivity to Unified CMBE becomes available. The MGCP PRI re-homes to Unified CM, and all active calls on the PRI are dropped. With SIP and H.323, call preservation is maintained.

For further details on SRST, see Remote Site Survivability, page 2-7.

Observe the following guidelines when using SRST as a backup call processing agent:

In SRST mode, Cisco recommends using the PSTN for all calls, whether they are inter-site or external calls. If the WAN links are still up to the various sites but not to Unified CM, it could be beneficial to use those links for inter-site calling. However, without a mechanism for call admission control or automated alternate routing, calls can oversubscribe the IP WAN. Therefore, using the PSTN for all calls during SRST mode alleviates any further configuration of devices such as a gatekeeper for call admission control concerns.

Failover and failback should be made as transparent as possible to the end users. Try to provide the same or equivalent dial-plan functionality in SRST mode as the users have with Unified CM call processing, so that users do not have a new set of dialing patterns and rules to learn when in failover mode. The following recommendations can help improve the user experience during failover:

If you are using an abbreviated dial plan, in order for the phones to reach the same numbers via abbreviated dialing, you can use voice translation profiles and rules to convert the abbreviated dialed numbers to E.164 numbers in order to pass them correctly to the PSTN. For more details, refer to Number Translation using Voice Translation Profiles, available at

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_example09186a00803f818a.shtml

Configure dial-peers with an exact match to avoid any inter-digit timeout. In most North American voice configurations, fixed-length dial plans, in which all the dial-peer destination patterns have the same length, are sufficient because the telephone number strings are all the same length. However, in some voice network configurations, variable-length dial plans are required (for example, for international dialing).

The inter-digit timeout timer can be terminated immediately by dialing the # character. If a user dials the # character while the SRST gateway is waiting for additional digits, the # character is treated as an end-of-dialing accelerator. The # character is not treated as an actual digit in the destination pattern and is not sent across the network as part of the dialed string.

Under normal conditions in Unified CM multisite deployments with centralized call processing, classes of service are implemented using partitions and calling search spaces within Unified CM. (See Building Classes of Service for Unified CM with the Traditional Approach, page 10-87, and Building Classes of Service for Unified CM with the Line/Device Approach, page 10-91.) However, when IP WAN connectivity is lost between a branch site and the central site, Cisco Unified SRST takes control of the branch IP phones, and the entire configuration related to partitions and calling search spaces is unavailable until IP WAN connectivity is restored. Therefore, it can be beneficial to implement classes of service within the branch router when running in SRST mode. (See Building Classes of Service in Cisco IOS with H.323, page 10-98.)

Unified CMBE Directory Management

Cisco Unified CMBE provides single sign-on functionality for end users and application users to access the Cisco Unified CM and Cisco Unity Connection User and Administration web pages. This functionality allows the Unified CM administrator to log in to the Unified CM Administration pages and also administer the Unity Connection Administration pages without further authentication.

In Unified CMBE the Unified CM database is the authoritative source for users, which means user creation and deletion is possible only from the Unified CM Administration web pages. Once users are created, the properties specific to Cisco Unity Connection are configurable from the Unity Connection Administration pages. Similarly, Unified CM Administration pages are the authoritative source for telephone integration, so the telephone integration is configured on Unified CM and imported into Cisco Unity Connection.

The following points summarize the functionality of the Unified CMBE directory:

Application users and end users are imported into Cisco Unity Connection from Unified CM.

Unified CM application users are imported as Cisco Unity Connection administrative users.

Unified CM end users are imported as Cisco Unity Connection voicemail users. (Users must have a primary directory number associated with them or they will not be visible to import into Unity Connection.)

Users cannot be created or deleted within the Cisco Unity Connection application.

Common user properties are treated as read-only in Unity Connection Administration pages.

Cisco Unity Connection users cannot exist without a corresponding Unified CM user.

The Bulk Administration Tool (BAT) is available in both Cisco Unity Connection and Cisco Unified CM to administer users in batch mode.

Telephone integration is imported into Cisco Unity Connection from Unified CM.

Only one integration exists.

Port group and ports are imported from Unified CM.

PINs and passwords are kept in a centralized data store, which is the Unified CM database. This allows for single sign-on functionality.

Changes made to common user properties in the Unified CM Administration web pages are synchronized immediately with the Unity Connection database.

Orphaned Unity Connection users can be reassociated or deleted.

Single sign-on (SSO) enables a system administrator to log in to all administrative web interfaces simultaneously, including Unified CM Administration, Unified CM Serviceability, Unity Connection Administration, and Unity Connection Serviceability. SSO also enables an end user to log in to both Unified CM User pages and Unity's Cisco Personal Communications Assistant simultaneously.

Single sign-on (SSO) does not apply to the platform OS administration or disaster recovery web applications.

Unified CMBE does not support LDAP integration, and you will get an error if you try to enable synchronization.

Third-party LDAP synchronization is not supported.

Third-party LDAP authentication is not supported.

Capacity Planning and Scaling the System

This section discusses some rules and guidelines for planning system utilization to avoid oversubscribing Unified CMBE. This section also presents some of the supported system limits for the integrated applications as well as some of the calculations that can assist in determining capacity planning for the Unified CMBE system.

Many types of devices can register with Unified CM (for example, IP phones, voicemail ports, CTI devices, gateways, and DSP resources such as transcoding and conferencing). Each of these devices requires resources from the appliance platform with which it is registered. The required resources can include memory, processor usage, and disk I/O. Each device then consumes additional system resources during transactions, which are normally in the form of calls. For example, a device that makes only 6 calls per hour consumes fewer resources than a device making 12 calls per hour.

This section discusses busy hour call attempts (BHCA) as a facet in planning the deployment to ensure that the system will not be oversubscribed. If you plan to use any other Cisco Unified Communications applications with Unified CMBE, such as Cisco Unified Presence or Cisco Unified MeetingPlace Express on separate servers, remember to factor in their impact on Unified CMBE performance and capacity. (See the chapters on Cisco Unified Presence, page 23-1, and Cisco Unified MeetingPlace Express, page 16-1.) Factors such as BHCA and CTI ports are just a few of the components to be considered.

Busy Hour Call Attempts (BHCA)

The BHCA is the average number of calls per hour per device during the busy hour. (For example, the busy hour for many systems is from 10:00 AM to 11:00 AM or from 2:00 PM to 3:00 PM.) Unified CMBE supports a maximum of 3,600 BHCA. When calculating your system usage, stay within the 3,600 BHCA maximum to avoid oversubscribing Unified CMBE.

The BHCA consideration becomes significant when the BHCA for any phone is above 4. A true BHCA value can be determined only by taking a baseline measurement of usage for the phone during the busy hour. Extra care is needed when estimating this usage without a baseline.

Device Calculations

Device calculations can be grouped into two main categories for the purpose of this calculation, phone devices and trunk devices.

A phone device is a single callable endpoint. It can be any single client device such as a Cisco Unified IP Phone 7900 Series, a software client such as Cisco IP Communicator or Cisco Unified Presence Client, or an FXS/FXO port or H.323 client.

A trunk device carries multiple calls to more than one endpoint. It can be any device such as a SIP trunk, an H323 trunk to a gateway, an MGCP backhauled BRI or PRI trunk, or even a gatekeeper-controlled H323 trunk. The method for calculating BHCA is much the same for both type of devices, but trunk devices typically have a much higher BHCA because a larger group of endpoints are using them to access an external group of users (PSTN or PBX extensions).

You can define groups of devices (phone devices or trunk devices) with usage characteristics based on BHCA, then you can add the BHCA for each device group to get the total BHCA for the system, always ensuring that you are within the 3,600 BHCA maximum. For example, you can calculate the total BHCA for 100 phones at 4 BHCA and 80 phones at 12 BHCA as follows:

100 phones at 4 BHCA is 100*4 = 400

80 phones at 12 BHCA is 80*12 = 960

Total phone BHCA = (100*4) + (80*12) = 1360 BHCA for phones

For trunk devices, you can calculate the BHCA on the trunks if you know the percentage of calls made by the devices that are originating or terminating on the PSTN. For this example, if 50% of all device calls originate or terminate at the PSTN, then the net effect that the device BHCA (1360 in this case) would have on the gateways would be 50% of 1360, or 680. Therefore, the total system BHCA for phone devices and trunk devices in this example would be:

Total system BHCA = 1360 + 680 = 2040 BHCA

If you have shared lines across multiple phones, the BHCA should include one call leg (there are two call legs per each call) for each phone that shares that line. Shared lines across multiple groups of devices will affect the BHCA for that group. That is, one call to a shared line is calculated as one call leg per line instance, or half (0.5) of a call. If you have different groups of phones that generate different BHCAs, use the following method to calculate the BHCA value:

Shared line BHCA = 0.5 * (Number of shared lines) * (BHCA per line)

For example, assume there are two classes of users with the following characteristics:

100 phones at 8 BHCA = 800 BHCA

150 phones at 4 BHCA = 600 BHCA

Also assume 10 shared lines for each group, which would add the following BHCA values:

10 shared lines in the group at 8 BHCA = 0.5 * 10 * 8 = 40 BHCA

10 shared lines in the group at 4 BHCA = 0.5 * 10 * 4 = 20 BHCA

The total BHCA for all phone devices in this case is the sum of the BHCA for each phone group added to the sum of the BHCA for the shared lines:

800 + 600 + 40 + 20 = 2,720 total BHCA

This usage level is acceptable because it is below the system maximum of 3,600 BHCA.

If you are using Cisco Unified Mobility for Single Number Reach (SNR), keep in mind that remote destinations affect BHCA. In order to avoid oversubscribing the appliance, you have to account for this SNR remote destination BHCA. To calculate the BHCA for the remote destinations, see the section on Cisco Unified Mobility, and add that value to your total BHCA calculation.


Note Media authentication and encryption using Secure RTP (SRTP) impacts the system resources and affects system performance. If you plan to use media authentication or encryption, keep this fact in mind and make the appropriate adjustments. Typically, 100 IP phones without security enabled cause the same system resource impact as 90 IP phones with security enabled (10:9 ratio).


Another aspect to consider is call coverage. Special groups of devices can be created to handle incoming calls for a certain service according to different rules (top-down, circular hunt, longest idle, or broadcast). This is done in the Line Group configuration of Unified CM. BHCA can also be affected by this factor, but only as it pertains to the line group distribution algorithm of broadcast (ring all members). For further details on line groups and distribution algorithms, refer to the Cisco Unified Communications Manager Administration Guide, available at http://www.cisco.com.

For Unified CMBE, Cisco recommends configuring no more than three members of a line group when a distribution algorithm of broadcast is required. Depending on the load of the system, doing so could greatly affect the BHCA of the system and possibly oversubscribe the server's resources. The number of line groups that have a distribution algorithm of broadcast should also be limited to no more than three.

Contact Center Example

For this example, assume that Cisco Unified Contact Center Express is integrated with Unified CMBE and that the system has the following characteristics:

The required specification is for 15 contact center agents with a maximum of 30 calls per hour during the busiest hour.

There are 96 non-agent users with average usage of 4 BHCA, and each user has the ability to configure one remote destination for Single Number Reach with Cisco Unified Mobility.

There are 36 non-agent users with heavy usage of 10 BHCA, and each also has the ability to configure one remote destination for Single Number Reach.

There are 20 extra shared lines, 10 of which are shared across 10 users from the average usage pool as well as 10 in the heavy usage pool.

There are 7 T1 trunks (allowing for up to 161 simultaneous calls) with a total of 1200 BHCA across all trunks.


Note This example groups the BHCA for all gateway trunks into a single total trunk BHCA value. This method would be typical for a single-site deployment; however, in a multisite deployment, the various sites' trunks could have different BHCA requirements and thus require different BHCA groupings.


The BHCA calculations for this system are as follows:

15 contact center agents at 30 BHCA = 450 BHCA

96 average-usage users at 4 BHCA = 384 BHCA

36 heavy-usage users at 10 BHCA = 360 BHCA

10 shared lines in the 4 BHCA group = 20 BHCA

10 shared lines in the 10 BHCA group = 50 BHCA

Total of 1200 BHCA for all T1 trunks = 1200 BHCA

One remote destination for Single Number Reach across each of the 96 average-usage users at 4 BHCA = 192 BHCA. (See Cisco Unified Mobility, for details on this calculation.)

One remote destination for Single Number Reach across each of the 36 heavy-usage users at 10 BHCA = 180 BHCA. (See Cisco Unified Mobility, for details on this calculation.)

Total BHCA for all endpoint devices in this case is:

(450 + 384 + 360 + 20 + 50 + 192 + 180 + 1200) = 2,836 BHCA

This level of usage is acceptable because it is below the system maximum of 3,600 BHCA, and it allows for future growth of approximately 800 BHCA.

Cisco Unified CM Applications

Cisco Unified CM applications provide numerous operational and functional enhancements to basic IP telephony. Unified CM also has a number of integrated applications that provide additional functionality. This section lists the Unified CM applications and their associated performance and capacity when used with Cisco Unified CMBE. For a complete examination of the Unified CM applications, see the chapter on Cisco Unified CM Applications, page 24-1.

Cisco Extension Mobility (EM)

Cisco Extension Mobility enables mobile users to configure a Cisco Unified IP Phone as their own, on a temporary basis, by logging in to that phone.

The EM application in Unified CMBE supports 26 sequential logins and/or logouts per minute. All users can be enabled for EM provided that they do not exceed 26 logins/logouts per minute.

Cisco Unified Communications Manager Assistant (Unified CM Assistant)

Unified CM Assistant enables assistants to handle one or more incoming phone calls for their associated managers.

The Unified CM Assistant application supports the following capacities:

Maximum of 10 assistants can be configured per manager.

Maximum of 10 managers can be configured for a single assistant (if each manager has one line controlled by Unified CM Assistant).

Maximum of 10 assistants and 10 managers can be configured per Unified CMBE system.

The Unified CM Assistant application interacts with the CTIManager for line monitoring and phone control. Each line on an assistant or manager phone generates a connection to the CTIManager. In addition, each Unified CM Assistant route point generates a connection to the CTIManager. When configuring Unified CM Assistant, you must consider the number of required CTI connections with regard to the overall limit for CTI connections (300 CTI connections for Cisco Unified CMBE). If additional CTI connections are required for other applications, they can limit the capacity of Unified CM Assistant.

Cisco Unified Communications Manager Attendant Console (AC)

The native AC application running on Unified CMBE supports the following capacities:

Maximum of 6 attendants

Maximum of 10 pilot points

The Cisco Media Convergence Server (MCS) 7828 platform supports a maximum of 50 AC devices.


Note The AC device capacity numbers can be divided among pilot points and pilot point hunt group members. For example, the maximum number of AC devices is 50. This capacity can be allocated in a number of ways, such as one pilot point with 50 members or 10 pilot points with 5 members in each pilot point hunt group.


The Cisco AC application interacts with the CTIManager for line monitoring and phone control. Each line on an Attendant phone generates a connection to the CTIManager. In addition, each AC pilot point generates a connection to the CTIManager. When you configure the AC application, the number of required CTI connections must be considered with regard to the overall limit for CTI connections (300 CTI connections for Unified CMBE). If additional CTI connections are required for other applications, they can limit the capacity of the AC application.

Two other attendant console applications, Cisco Unified Business Attendant Console and Cisco Unified Department Attendant Console, are also available on a separate application server. Follow the above AC capacity guidelines for these two separate applications, but keep in mind that they each support a maximum of two attendants. For more information on Cisco Unified Business Attendant Console and Cisco Unified Department Attendant Console, refer to the product documentation available on http://www.cisco.com.

Cisco WebDialer

WebDialer is a click-to-dial application for Unified CM that enables users to place calls easily from their PCs using any supported phone device. The WebDialer service runs on Unified CM and can support up to the maximum BHCA capacity for Unified CMBE (one call per second, or 3,600 calls per hour).

To calculate the total BHCA for WebDialer, use the following formula:

Total WebDialer BHCA = (Number of users) * (BHCA per user)

The result will typically be the same as the total user BHCA for Unified CMBE. Whether users dial from the phone itself or the WebDialer application, the expected BHCA should not change.

Cisco Unified Mobility

Cisco Unified Mobility application known as Mobile Connect, commonly called Single Number Reach (SNR), gives users the ability to redirect incoming IP calls from Unified CM to as many as four different designated client devices such as cellular phones or IP phones.

The capacity for Unified Mobility users in Unified CMBE depends on the BHCA of the phones to which SNR is associated. Thus, the number of remote destinations supported depends directly on the BHCA of those phones. The guidelines are as follows:

A maximum of 4 remote destinations can be configured per Device Profile.

Each remote destination has an associated cost to it that affects BHCA. For every remote destination, one additional call leg is used. Because each call generally consists of two call legs, one remote destination ring is equal to half (0.5) of a call. Therefore, you can use the following formula to calculate the remote destination BHCA:

Remote destination BHCA = 0.5 * (Number of users) * (User or phone BHCA)

For example:

Assuming a system of 300 users at 5 BHCA each, with each user having one remote destination (total of 300 remote destinations), the BHCA calculation for the remote destinations would be:

Remote destination BHCA = 0.5 * 300 * 5 = 750 BHCA

Total user BHCA in this example is 300*5 = 1500, and the remote destination BHCA is 750. Therefore, the total system BHCA for this example would be 1500+750 = 2250 if these were the only two BHCA variables in the deployment. (See the section on Device Calculations, for further details.)