Server Sizing and Platform Overlays
When you understand the business requirements within your specific organization, you can decide on the specific platform overlay to meet these design requirements. This decision should be carefully considered given the design requirements and need for scalability. Then, you can determine the proper platform overlay and procure the correct product for implementation. Considerations should also be given to product lead times in the ordering process.
Cisco System enables users to use a number of physical platforms according to their needs and business requirements. As of Cisco Unity Connection version 8.x, virtualization is now supported according to two specific overlays.
Table 2-2 and Table 2-3 (covered in the next section) provide an overview of these overlays, whether you use physical or virtual platforms in the voice-messaging solution. For the latest information regarding product models, consult Cisco.com. The following tables are provided here to demonstrate only an overview of these overlays. The supported platforms are based on the IBM equivalents.
Table 2-2. Physical Platform Overlay Overview
Option |
Platform Overlay 1 |
Platform Overlay 2 |
Platform Overlay 3 |
Processors |
1 |
2 |
2 |
Hard disk |
2–250 GB |
2–300 GB |
4–300 GB |
Total ports/server |
48 |
150 |
250 |
Total ports/cluster |
96 |
300 |
500 |
Total users |
2000 |
4000 |
20,000 |
Platform |
MCS7825-I4 |
MCS7835-I3 |
MCS7845-I3 |
Table 2-3. Overview of Virtual Platform Overlay
Option |
Platform Overlay (500 Users) |
Platform Overlay 2 (1000 Users) |
Platform Overlay (5000 Users) |
Platform Overlay (10,000 Users) |
Platform Overlay (20,000 Users) |
vCPU |
1 |
1 |
2 |
4 |
7 |
vRAM |
2 Gig |
4 Gig |
4 Gig |
4 Gig |
8 Gig |
vDisk |
1–160 GB |
1–160 GB |
1–200 GB |
2–146 GB |
2–300 GB 2–500 GB |
Total ports/server |
16 |
24 |
100 |
150 |
250 |
Total ports/cluster |
32 |
48 |
200 |
300 |
500 |
Total users |
500 |
1000 |
5000 |
10,000 |
20,000 |
The Cisco MCS 7828 series platform can be deployed for the Cisco Unified Communication Manager Business Edition to support up to 500 users and phones and 24 voicemail ports providing for Cisco Unity Connection voicemail and CUCM integrated within a single platform.
Virtualization
Virtualization has gained greater acceptance for business applications throughout the past number of years and is now supported using VMware with specific platform overlays. Some types of virtualization include memory, data, storage, and software. From the perspective of Cisco Unity Connection and the platform overlays, you can refer to operating system-level virtualization, in which a single OS can host a number of different operating systems and applications concurrently, which are referred to as guests. Virtualization provides a cost savings to companies and assists in energy efficiency.
Years ago, I worked at an enterprise company that had a large room filled with servers, each of which performed a specific application that was vital to its business operations. Virtualization was introduced in the company, and over the course of a couple months; they virtualized all existing applications from approximately 50 to 60 servers down to 4 servers, using a single rack. This provided for easier administration, centralized management, and greater efficiency at an extraordinary cost savings to its business.
Cisco now supports implementations using virtualization. Two platform overlays are currently supported. Table 2-3 lists the supported overlays for virtualization (at press time). Again, this is provided as an overview. Therefore, consult Cisco.com for further details and updates to these overlays.
For both the physical and virtual platform overlays, you need to consult the current documentation and release notes for your specific release of Cisco Unity Connection version 8.x software because this information might vary with future releases and updates.
User Location, Geography, and Digital Networking
The next area to consider in the voice-messaging design has to do with the location of users and current network design. You must understand the current location of users, how users need to access their voice messages, and the current network topology for IP telephony and voice messaging. An organization might have one or two locations with a single phone system in which all users have IP Phones and access emails directly from Cisco Unity Connection using its phone, IMAP client, or Microsoft Outlook with ViewMail. In these cases, you can consider a design that is either a single server or an active-active cluster-pair to supply load balancing and high-availability (refer to Figure 2-2).
Some organizations might have remote users and a number of remote locations with multiple phone systems. This being the case, the decisions might be a bit more complex concerning server sizing, multiple servers, and server placement within the design equation.
Case Study: Voicemail Design
Tamicka-Peg Corporation is looking to implement a voicemail solution. This company is a large service corporation with 7000 users located at its corporate office on the east coast and another 5000 users located at a single regional branch office on the west coast. Each location has its own Cisco Unified Communications Manager 8.x cluster to support the required number of IP phones. Given this scenario, some design questions need to be considered. The questions discussed earlier concerning voice-messaging traffic and voicemail ports must first be answered. Then, additional questions concerning location and geography must be answered before a preliminary design can be considered. These questions consist of the following:
- Do users need to send, forward, and reply to users at the remote location?
- Do users need to log in to their voicemail from the remote location?
- What voice messaging currently exists at the remote location?
- Where is the call processing equipment (CUCM or PBX) located?
- Concerning call processing and PBXs: Are there multiple PBX/Cisco Unified Communications Manager servers existing in the organization? At remote locations?
- What capabilities exist with any non-Cisco call processing equipment? IP, Analog, or digital ports?
In the next section, you discover the answers to these questions concerning the integration of Cisco Unity Connection.
Introduction to Integration
In most cases, Cisco Unity Connection needs to be integrated with a new or existing PBX or Cisco Unified Communications Manager (CUCM) server or cluster. This is what is referred to as integration. For integrations with CUCM, the IP integrations can be accomplished using Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP). For legacy PBXs that support only analog or digital integrations, another device is required depending on the support provided by the PBX. There are currently two solutions for legacy integrations: PBX IP Media Gateway (PIMG) and T1 IP Media Gateway (TIMG). Both products use SIP for communications between the PIMG/TIMG unit and Cisco Unity Connection. Dialogic Corporation is a key manufacturer of PIMG/TIMG units, though some of the PIMG/TIMG products might be End of Sale (EOS).
As an integration is defined as the communications from the voice-messaging system to the call processing system (Cisco Unity Connection to CUCM), voicemail networking describes communications between voice-messaging systems.
Introduction to Voicemail Networking
Within most organizations, users need to send, forward, and reply to users at the remote locations. Also, as more users travel, they need access to their voicemail from other locations. If this is the case, networking between voicemail systems need to be considered. This can be easily done with Cisco Unity Connection version 7.x and 8.x. However, if a different non-Cisco voice-messaging system is to remain, a different networking method needs to be investigated, depending on the support provided by the existing voice-messaging system. You explore these various networking technologies and configuration in the next chapter. However, you first need to understand the networking concepts, terminology, and fundamental mechanics of each option to create a voice-messaging design that meets the business requirements.
Intrasite Networking
Each server platform overlay has limitations on the number of users supported. If an organization has user requirements beyond these limitations, or if users are located at remote locations with a different call processing system, intrasite networking is required. In previous versions of Cisco Unity Connection, this was referred to as digital networking. With the current version of Cisco Unity Connection, up to ten servers can be joined together to form single voice-messaging network. This network is referred to as a connection site. Each server or cluster-pair in the connection site is called a location. Up to ten locations, consisting of single servers or active-active cluster pairs can connect via intrasite links to form a single connection site.
As you learned earlier, a server or cluster pair using Cisco Unity Connection version 8.x software can provide voice messaging for up to 20,000 users. Using intrasite links to form a connection site, this limitation can be exceeded to provide voice messaging for up 200,000 users—though the global directory is limited to 100,000 users and contacts.
Users can have IP phones registered to a single CUCM or PBX. Cisco Unity Connection system can support multiple integrations while being part of a connection site with multiple intrasite links. An organization might decide to keep its existing PBX along with CUCM and transition users and phones to the new system over a period of time. This feature affords the flexibility to use intrasite networking to meet current business needs and transition to the new system using a phased approach.
Figure 2-3 illustrates this option using a single or multiple call processing systems within a connection site.
Figure 2-3 Single and Multiple Call Processing Within a Connection Site
Intrasite links can be formed using active-active cluster-pairs if load sharing and high availability is a requirement. Figure 2-4 depicts the intrasite links used in a cluster-pair configuration. As displayed, single server configuration and active-active cluster-pair configuration can be combined with the connection site.
Figure 2-4 Single Server and Active-Active Cluster-Pairs Used Within a Connection Site
The important aspect of intrasite links between servers is that all communication, transfer, and sending of messages is accomplished using Multipurpose Internet Mail Extensions (MIME) over Simple Mail Transfer Protocol (SMTP). Both protocols are Internet standards, so the transfer and sending of voicemail can be easily accomplished over the WAN or Internet. In this way, each remote location can have a Cisco Unity Connection server along with its own CUCM or PBX. The Cisco Unity Connection servers can then be joined together using intrasite links to form a single connection site, allowing users the ability to send, forward, and reply to messages from users at the other locations.
Now that you know the various implications of intrasite network, refer to the case study and the voice-messaging solution for Tamicka-Peg Corporation. Tamicka-Peg Corporation has 7000 users at the east coast location and 5000 users at the west coast location. Each site has its own Cisco Unified Communications Manager cluster to support the required phones. After further discussion, it was determined that the organization required high availability at both locations, and users need to have the ability to send, forward, and reply to messages at the other remote location, regardless of their locale.
Given the voice-messaging requirements, the decision was made to create a preliminary design based on active-active cluster pairs integrated to the CUCM cluster at each location and create an intrasite link between each active-active cluster pair to form a connection site.
Figure 2-5 illustrates this preliminary design. The single connection site with intrasite links using cluster-pairs provides high availability and load sharing using the cluster pair. In this case, an intrasite link creates a single connection site between the two locations. The design enables users to send, forward, and reply to messages at either location. If a user travels to either remote location, they can access their voicemail by logging through the local Cisco Unity Connection system. This is accomplished by using what the cross-server login feature. Additionally, callers at one location can address messages and be transferred to users who have a mailbox at the remote location. This is attained through the use of the cross-server transfer feature. The cross-server login and transfer features and configuration are explored in the next section.
Figure 2-5 Intrasite Links over the WAN Form a Connection Site
Another feature available in Cisco Unity Connection version 8.x enables users to perform a Live Reply between locations within a connection site. The Live Reply feature enables users to reply directly to a user located on another Cisco Unity Connection version 8.x server by transferring directly to a caller who left the message as they are in the process of listening to the voice message. Users can also use live reply to callers that leave messages from external phones through a gateway.
These features combine to provide the connectivity required from most voicemail users within a Cisco Unity Connection network.
Introduction to Intersite Networking
Intrasite links connect Cisco Unity Connection locations to form a single connection site for voice messaging. Up to ten locations can be connected using intrasite links. Additionally, two connection sites can be linked together using an intersite link. An intersite link extends the networking limitation of 10 servers to enable up to 20 servers to form a voicemail organization. A voicemail organization is two connection sites interconnected with a single intersite link between a pair of Cisco Unity Connection servers acting as the gateway to the remote connection site. This design has the limitation of allowing only one intersite link per connection site.
All voice-messaging and directory-synchronization traffic can directly pass between the Cisco Unity Connection servers configured with the intersite link, and therefore, act as the gateway to the remote connection site.
The advantage of the intersite link provides an organization with the capability to limit traffic, updates, and message transfer to a single intersite link between the two Cisco Unity Connection servers acting as the gateways for the voicemail organization. Only two connection sites can be linked together using the intersite link. When these two connection sites are linked together to form a voicemail organization, SMTP is used for message transfer between connection site gateway, and HTTP/HTTPS is used for directory synchronization. Therefore, the designer must ensure that a connectivity between connection site gateways exists. For SMTP connectivity, a SMTP smart host can be employed if this connectivity is not possible. Chapter 3, "Installing and Upgrading Cisco Unity Connection," explores this scenario and its configuration in more depth.
Figure 2-6 illustrates the use of an intersite link between connection sites to form a voicemail organization.
Figure 2-6 Intersite Link Used to Network Two Connection Sites to Form a Single Voicemail Organization
Intrasite Versus Intersite Networking
Intrasite and intersite links each have their advantages and disadvantages; however, they both provide networking between Cisco Unity Connection voice-messaging servers within the organization. For example, if an organization has a combination of existing Cisco Unity Connection version 7.x servers to be networked with Cisco Unity Connection version 8.x servers, they are limited to intrasite links. Only Cisco Unity Connection version 8.x software can support the intersite links. Intrasite links are limited to 10 locations. However, an intersite link extends the network to support up to 20 locations.
The replication and synchronization is different between the intrasite and intersite links. Within a connection site, locations connect with intrasite links. In this case, all system information (users, contacts, distribution lists, and so on) is replicated throughout the connection site, including membership of all system distribution lists.
Replication across intersite links is performed only once and is scheduled. This replication takes place only between the gateways that have the configured intersite link. Also, the system distribution lists are replicated to the remote gateway across this intersite link, but distribution list membership is not replicated. Because all information is replicated and synchronized to all other location in a connection site using intrasite links, the bandwidth requirement is greater. With intersite links, replication and synchronization takes place only between the gateways, thereby reducing the required bandwidth.
Administratively, the intrasite links are easier to manage than intersite site links and affords the flexibility to add locations to the connection site as the organization experiences growth. Intersite links are limited in scalability because only a single intersite link can be configured to network two connection sites.
Intrasite links enable the configuration of a Cisco Unity Connection version 8.x server to be networked to Cisco Unity Connection version 7.x servers, as long as the intersite link is not used. (Version 7.x does not support intersite links.) The use of intersite links forbids this and requires only Cisco Unity Connection version 8.x servers throughout both connection sites that use an intersite link; however, a Cisco Unity Connection version 8.x site can be networked with a Cisco Unity version 8.x server using an intersite link.
Intersite links can connect a Cisco Unity Connection site with a Cisco Unity site; however, all Cisco Unity Connection servers must be version 8.x. Also, the gateway server on the Cisco Unity site must be version 8.x software. All other Cisco Unity servers must be a minimum of version 5.x software. When the intersite link is used in this manner, a user is added to the Cisco Unity Connection site directory for all Cisco Unity subscribers. Likewise, an Internet subscriber is added to Cisco Unity for every Cisco Unity Connection user. However, VPIM, AMIS, Bridge, and Internet subscribers from Cisco Unity are not replicated across the intersite link to the Cisco Unity Connection site gateway.
Cisco Unity Connection does not support AMIS and Bridge networking; however, VPIM is supported and you must explore a number of considerations if intersite links are employed in the network. Chapter 5 looks at these considerations in more detail.
Case Study: Voicemail Network Design
After the preliminary design was presented to Tamicka-Peg Corporation, it was discovered that management was in the process of buying a division of Tiferam Corporation in the Midwest, which has a growing connection site consisting of five Cisco Unity Connection servers. Management of both organizations determined that they require voice-messaging connectivity between the two companies. It was determined that most of the voice messaging will occur between the Tiferam and the management team at Tamicka-Peg Corporation, which is located in their east coast location. Both companies decided that conserving bandwidth on the link between their two companies was an important consideration in the final design.
After further review, the finalized design (based on the original preliminary design) was approved to provide the proper voice messaging between Tamicka-Peg's east and west locations and with the newly acquired division of Tiferam Corporation in the Midwest.
Figure 2-7 illustrates this final design, in which an intersite link is used between the two companies to create a voicemail organization between connection sites located at each company.
Figure 2-7 Final Design of Tiferam and Tamicka-Peg Using an Intersite Link
Other Voicemail Networking Options
Intrasite and intersite links are excellent networking options for multiple Cisco Unity Connection version 8.x servers to network connection sites together forming a single voicemail organization. However, there might be cases in which a company does not have the capability to replace existing voice-messaging systems entirely because of technical, organizational, or budget reasons. In this case, Cisco Unity Connection might need to coexist with a completely different, disparate voice-messaging system. Even though this system might be a different system, there is another option that exists to enable networking with Cisco Unity Connection. This solution uses an industry-standard protocol called Voice Profile for Internet Mail (VPIM).
VPIM is an Internet-standard protocol for transfer of voice messages between voice processing systems. The VPIM specification defines the encoding of the voice messages using a MIME-type message and sending to a remote VPIM location using an SMTP transport. This procedure is similar to what is accomplished using the intrasite links but is mainly used when networking dissimilar voice-messaging systems. The VPIM protocol was defined in RFC 3801 as the VPIMv2 standard and dictates the use of a similar addressing format to that used with email system (myEmailAddress@myDomain.com). The main purpose of the VPIM is to enable voice messaging between disparate systems. These systems could be similar or dissimilar between the same or different manufacturers, as long as they support the VPIM standards. VPIM is also supported between Cisco Unity, Cisco Unity Connection, Cisco Unity Express, and various other non-Cisco voice-messaging systems that support the VPIM protocol.
Case Study: VPIM Voicemail Design
Jensen Industries, a mid-sized manufacturing firm in North America, has an existing Cisco Unity version 5.x server and Cisco Unity Express voicemail system in two different locations. These systems need to be networked with their new Cisco Unity Connection version 8.x server, which will be located in their main headquarters. Also, Andres Consultants is a contract service company that provides networking service to Jensen. There is also a requirement to enable addressing of messages between the Jensen and Andres Consultants.
Because you will be networking completely dissimilar systems, VPIM might be the perfect solution to provide networking between all three Jensen Industries sites and Andres Consultants. Figure 2-8 depicts this solution using VPIM networking.
Figure 2-8 VPIM Networking Solution to Provide Networking Between Disparate Voice-Messaging Solutions
VPIM networking enables various addressing methods between locations. In the next chapter, you investigate the in-depth details and configuration of VPIM networking, contact creation, and addressing.
Intersite Links and VPIM Networking
As was pointed out in the discussion of intersite links, VPIM, AMIS, Bridge, and Internet subscribers are not replicated across an intersite link to the Cisco Unity Connection site gateway. Therefore, if VPM networking is a requirement, each connection site gateway needs to include a VPIM connection. The site gateway for the intersite link can also act as the VPIM connection gateway, or bridgehead server. Or the VPIM connection can be hosted on another server in the connection site.
Figure 2-9 illustrates the use of multiple VPIM connections to a server to enable connectivity between multiple connection sites with an intersite link.
Figure 2-9 Multiple VPIM Connections Using an Intersite Link Between Connection Sites
In Chapters 3 and 4, you investigate the installation, integration, networking of Cisco Unity Connection. The discussion also includes important features required to provide users with the necessary options and connectivity to perform voice messaging according their business needs.
Case Study: Multisite Voicemail Design
LMN Corporation, a large enterprise in Dallas and Orlando is in need of a new voice-messaging solution. It has a subsidiary in London that has an existing legacy voicemail and phone system supporting 100 users at that location. Dallas is its main headquarters with 3500 users. The Orlando location is a smaller division with 150 users. All IP Phones in the U.S. network need to be supported using a CUCM at the Dallas location.
London plans to upgrade to Cisco Unity Connection in the future but because of budget constraints, this has been postponed to a future date. However, users still need the ability to send and forward messages between the U.S. locations and its London office. After researching the currently network design and meeting with management and users at all locations, the following information was determined from the planning stage:
- In Dallas, there are 3500 users (with voicemail) with a projected growth to 5000 over the next 2 years.
- The Orlando location is a sales division, where users will be using a variety of mobile clients that are capable of only the IMAP Non-Idle mode. Projected growth at this division might increase to 200 users over the next couple years.
- The London location will eventually migrate to Cisco Unity Connection but at a later time. The current voice messaging is a legacy system, but further documentation research discovered that this system does support the VPIM protocol.
- Users within the U.S. offices will be required to have access to voicemail at all times (high availability) and will use their phone and Outlook to retrieve voicemails.
- During the peak hours, there have been measurements indicating up to 90 concurrent voicemail sessions at any particular time within all U.S. locations combined.
From the information discovered in the planning phase, a preliminary design was constructed using the centralized IP telephony design already in place between Dallas and Orlando. It was decided that an active-active cluster pair would be located in the Dallas headquarters because the CUCM cluster is located at this location to support all IP Phones at both U.S. offices, and high availability is a design requirement.
The voice-message implementation needs to support 5200 users between Dallas and Orlando; however, because the Orlando division is going to use IMAP non-Idle clients, you need to allow for the additional requirements of IMAP non-Idle. As you learned in this chapter, an IMAP non-Idle client counts as four IMAP Idle clients. Therefore, the calculation for Orlando will be (based on the projected growth) 200 clients * 4 = 800 users. Therefore, the total calculation should be 800 users (Orlando) + 5000 users (Dallas) for a total user count of 5800 users.
Based on these calculations, a physical platform has been decided on using the MCS7845 platform with a minimum of 96 ports purchased initially. This means that two servers with identical software can be configured as an active-active cluster pair to provide high availability for the U.S. locations. VPIM networking will be configured between the Dallas and London locations to support the sending, forwarding, replies to messages between the London, Dallas, and Orlando locations, as illustrated in Figure 2-10.
Figure 2-10 LMN Corporation Voice-Messaging Solution