Designing Voicemail Systems with Cisco Unity Connection

This chapter focuses on the Cisco Unity Connection product design and capabilities as they pertain to its various systems, database, and networking.

This chapter covers the following subjects:

• Design Considerations: Understand the capability of Cisco Unity Connection as it pertains to current users, network design, codecs, voicemail ports, and projected growth.
• Active-Active Cluster Pair: Explore the high availability and redundancy feature of Cisco Unity Connection using the active-active cluster pair configuration.
• Voice-Messaging Design: Design the voice-messaging system using Cisco Unity Connection platform overlays by determining the proper server sizing, equipment, codec, feature, and capabilities.
• Voice-Messaging Networking: Understand the various networking options available in Cisco Unity Connection version 8.x software.

After you understand your current voice-messaging environment, users' needs, and projected growth within the planning stages, you can develop a preliminary design based on this information. This preliminary design can help the business to understand and review the designed solution that meets the needs defined during the planning stage. Good communication within the organization is vital for all stages of the deployment, but especially important for the design. After the preliminary design has been reviewed, modified, and adjusted according to the business model, you can develop the final design and scope of work.

This procedure must be completed before any product is ordered and the implementation begins. The planning and design phase determines the actual product and implementation, and ensures that the user requirements are met. As stated previously, good planning and design that closely matches the final implementation helps to avoid unforeseen project delays and over-budget issues.

This chapter takes your project plan to the next phase of the Planning, Design, Implementation, and Operation (PDIO) model, the design phase. You need to collect all information assembled from the planning phase and determine a preliminary design. A properly crafted preliminary design can consist of input from reviewers, management, and users to allow for modifications and collaboration. The end result in this phase will be a final design that will be ready for implementation. Part of this phase also involves features, capabilities, and configurations to ensure that all requirements are met as determined according to the project plan. Therefore, you need to understand the interworking, features, and capabilities of Cisco Unity Connection.

The focus in this chapter is on the Cisco Unity Connection product design and capabilities as they pertain to its various systems, database, and networking. You need to understand the following:

• How to determine the server sizing to be used when implementing Cisco Unity Connection version 8.x software.
• Understand codecs, users, Internet Message Access Protocol (IMAP) client, voicemail storage, and ports. Explore how this information can influence your server sizing and voice-messaging design.
• Understand the various IMAP clients that can be used with Cisco Unity Connection and investigate the differences between IMAP non-Idle and Idle mode.
• Learn the Cisco Unity Connection database design and how active-active cluster pairs deliver redundancy and high availability.
• Determine the preliminary design based on geography, function, and client types to be used for voice messaging.
• Create a finalized design from the elements of the planning phase and the discussions and feedback from the design phase.

Determining Server Sizing

Cisco Unity Connection enables organizations to build and configure their voice-messaging system according to their business needs. These needs can involve the decisions based on the number of users, voicemail ports, codec, and even what type of clients will be used to retrieve voice messages. At this point in the process, many of these needs should have been identified and determined in the earlier planning phase.

The first goal is to determine the proper server sizing to meet the current user requirements and future growth. Server sizing refers to the proper platform hardware to be purchased. It is important for not only budgets, but also user requirements to purchase the correct server platform to meet the users' current and future requirements.

Scalability defines the capability of an organization to adapt to growth and changes. The voice-messaging design needs to include considerations for scalability in providing the required operations and services as the organization continues to grow and expand over time. Cisco Unity Connection enables this scalability with its current software and the capabilities provided with digital and Voice Profile for Internet Mail (VPIM) networking services.

You must identify a number of elements in this stage about the server sizing because these decisions can influence an organization's choice of hardware. These elements consist of the following:

• Audio codecs
• Voice-messaging storage capacity
• Voicemail ports
• Current and future users
• Voicemail users
• IMAP clients

The next sections review these requirements and the best practices related to server sizing.

Understanding Codecs and Voicemail Storage

You must understand the basic differences of the various codecs before understanding how Cisco Unity Connection handles these codecs. This discussion is not meant to be an in-depth study of codecs, but a general overview to provide a proper understanding of codecs as they are implemented in Cisco Unity Connection.

Codecs are defined as the encoding and decoding of the audio signal. An audio signal needs to be converted to a digital format before it can be sent over the IP network. This is referred to as encoding. This digitally encoded signal takes the form of a real-time transport protocol (RTP), which uses User Datagram Protocol (UDP) as the transport layer. Likewise, at the remote location, this encoded digital signal needs to be converted back into an audio stream. This process is called decoding. Together, the encoding and decoding determines the codec used to send an audio signal across the IP network.

The process of encoding an audio signal into a digital signal use is referred to as sampling. The sampling rate is determined by the amount of samples per second. Each sample is analogous to a snapshot in time. The accepted sampling rate was determined from work performed by Harry Nyquist and Claude Shannon in the 1920s surrounding the telegraph. Their research determined that the amount of information sent into a telegraph channel should be twice the amount of its highest frequency. In actuality, the theorem determines that a sampled analog signal can be correctly reconstructed if the sampling rate exceeds twice the highest frequency of the original signal. This theory referred to as Nyquist-Shannon Theorem, or simply Nyquist's sampling theorem. Since this time, the basic theory of telegraphs has been applied to digital networking.

The human voice can produce sound from approximately 300 Hz to 4000 Hz. Keeping with the same logic that Nyquist used for the telegraph, you can determine a sampling rate for voice communications to be 8000 Hz (4000 Hz * 2), or 8000 samples per second. Each sample would consist of a single byte. Therefore, the information consisting of this sample would be 8 bits * 8000 samples, or 64,000 bits per second. This is the basis for an uncompressed digitized audio signal in IP telephony, which is called the G.711 codec. This is also the calculation used for a DS-0 or voice channel within a T1/PRI digital circuit. This bandwidth is defined as the payload, not including Layer 2 and Layer 3 overhead. This overhead on an Ethernet network accounts for approximately 25 percent of the overhead of an uncompressed voice payload, or 16 k (or 80 k). This includes IP, RTP, and UDP headers.

Cisco Unity Connection supports a number of different codecs, as described in the following sections.

G.711 Codec

The G.711 codec is the most used and supported codec in IP telephony. It is produced using pulse code modulation at an uncompressed sampling rate of 8000 samples per second. The bandwidth required for the G.711 codec is 64,000 bits per second. This is the bandwidth of the payload (not including IP, RTP, and UDP headers). As stated in the previous section, on an Ethernet network, this accounts for approximately 25 percent of the overhead of an uncompressed voice payload, or 16 k (or 80 k).

There are two versions or formats of the G.711 codec. G.711 m-Law is the codec used in North America. The G.711 a-Law is used outside North America. Even though both codecs have the same bit rate of 64,000 bits per second, they perform a completely different sampling of pulse code modulation to arrive at their respective digitized samples. Therefore, the codecs are not directly compatible and require transcoding between G.711 m-Law and G.711 a-Law. However, both of these codecs produce a high-quality audio steam.

G.729 Codec

The G.729 codec is also used extensively in IP telephony and also widely supported. This codec uses a compression algorithm to attain a payload bandwidth of 8000 bits per second. Because of bandwidth conservation, this codec is used for remote IP telephony communications and where bandwidth oversubscription is a concern. A number of versions of the G.729 codec exist. Two of these codecs, G.729a and G.729b, incorporate additional options and features. The sound quality produced using G.729 is not as high quality as G.711 but is still considered to be toll quality (similar to a residential phone service or traditional landline services). These lower bandwidth codecs are used primarily to save the bandwidth for lower speed WAN circuits. In these cases, the overhead calculation is still approximately 16 k, providing a total bandwidth calculation of 24 k.

G.722 Codec

The G.722 codec produces is a high quality audio signal and is supported on many of the newer IP telephony devices and IP phones. G.722 uses its own compression algorithm called Sub-Band Adaptive Differential Pulse Code Modulation (SB-ADPCM) and can produce a digital signal using a number of bandwidths (48 k, 56 k, and 64 k). The G.722 codec requires 64,000 bits per second as the payload bandwidth for this codec; although it can adapt the compression algorithm based on changes in the network. This codec is used with the newer Cisco 79X2 and 79X5 IP Phones.

G.726 Codec

The G.726 codec uses Adaptive Differential Pulse Code Modulation (ADPCM) to produce a payload bandwidth of 16 k, 24 k, 32 k, or 40 k bits per second, although the most widely supported codec used is 32 kbps. Using half the bandwidth of G.711, this codec is used for many phone service providers, VPIM networking, and Simple Mail Transfer Protocol (SMTP) communications. You examine the use of this codec in Chapter 5, "Cisco Unity Connection Users and Contacts," in the discussion of VPIM and SMTP protocols.

iLBC

Internet Low Bitrate Codec (iLBC) is defined in RFC 3951 as a narrowband speech codec, suitable for Voip application and streaming audio. This algorithm used for iLBC is much more resilient to the lost frames when degraded networks are encountered. iLBC uses a bandwidth of 13.3kbps, with a slightly higher quality than G.729.

PCM Linear Codec

The PCM Linear codec uses pulse code modulation (PCM) to digitize samples based on a variable sampling rate of 8 k to 48 k. This format is used in DVD technology to encode WAV and AU type sound files because this codec produces the highest quality audio; however, this quality is produced as the expense of increased bandwidth. For example, a sampling rate of 8 k for a 16-bit samples requires 128 kbps for the payload bandwidth (16 bits * 8000 samples / sec = 128 kbps).

Transcoding in Cisco Unity Connection

Voice calls arriving to Cisco Unity Connection enter the system using a negotiated line codec. The administrator can choose to support a certain codec based on its advertisement.

When callers leaves message for users with a mailbox, they reach Cisco Unity Connection via an available voicemail port. The audio stream is received as a digitized signal in one codec (called the line codec). This digitized signal needs to be converted before it is recorded to the users' voice mail. Transcoding is the process to convert a digitized signal from one codec to another codec. Cisco Unity Connection performs transcoding with every call as it is received and recorded in the users' voice mailbox.

Cisco Unity Connection supports a number of codecs on the line side. These codecs are used on the line side, as the digitized signal is received by Cisco Unity Connection. Also, as stated previously, the administrator can influence which codecs are used, or not used, by changing the advertising of these codecs to external devices. The codecs supported on the line side follows:

• G.711 m-Law
• G.711 a-Law
• G.722
• G.729
• iLBC

The audio stream received on one of these line codecs is then transcoded to the system codec, which is always PCM Linear. As per the discussion of codecs, this codec produces the highest quality audio and is therefore the system codec. The system codec cannot be changed and is always used with every call and recording. The system codec receives the call from the line codec. The recording codec receives the call from the system coded (PCM Linear).

Finally, the PCM Linear stream (system codec) is then transcoded to the system recording codec. The supported system recording codecs in Cisco Unity Connection follows:

• PCM Linear
• G.711 m-Law (default)
• G.711 a-Law
• G.729a
• G.726
• GSM 6.10

The default recording codec is G.711 m-Law. It is advisable to keep the system recording codec at this default because this produces a good quality audio signal with acceptable disk space utilization (8 KB/sec).

All transcoding here is done directly within the Cisco Unity Connection system. If calls and recorded messages are transferred to the integrated phone system or Cisco Unity Connection, transcoding resources might be required.

Figure 2-1 illustrates the relationship between the line, system, and recording codec as they are implemented in Cisco Unity Connection.

The System recording codec can be changed to G.729a, G.726, or GSM 6.10 to conserve disk space for message storage. These codecs require from 1 KB/sec to 4 KB/sec, half the amount of disk space required for the same recording using the default system recording codec of G.711. However, the audio quality produced with these codecs will be much lower. Changing the system recording codec to one of these codecs should be done only if there is a real need to conserve disk space. You must understand and decide if this should be done to sacrifice recording quality. Also, changing the default system recording codec can affect playback of messages on specific mobile devices and cell phones that might not support the specific codec using IMAP.

On the other hand, you can use the PCM Linear codec for the system recording codec to increase the audio quality. This codec produces the highest quality of audio stream, but at the expense of disk space. The PCM Linear codec uses twice the bandwidth required by the G.711 default recording codec. This should be done only if there is no consideration to conserve disk spaces, and when G.722 is used as the line codec. Using PCM Linear as the system recording codec when the line codec is G.711 cannot increase the quality of the audio stream and only use more disk space. For most installations, Cisco Unity Connection uses G.711 as the line codec. Therefore, it is best to leave the system recording codec at the default, G.711.

You need to keep the system level recording at G.711 because most endpoints use this codec as their audio format to Cisco Unity Connection. This determination is made only to preserve the audio quality, not avoid transcoding. As Figure 2-1 illustrates, transcoding is done for every call received by Cisco Unity Connection. There is little system performance impact from a different codec on the line, as compared to using a specific recording codec. Certain codecs do require additional resources and computation because of their complexity. The codecs defined here that require more resources to transcode are the line codecs, G.722 and iLBC. Limit the use of these codecs for this reason. Because of these resource requirements, Cisco Unity Connection can support only half the amount of simultaneous connections using these line codecs, as compared with the other line codecs. You must consider this calculation when determining the platform sizing and the number of voicemail ports.

Table 2-1 provides an overview of the various codecs supported by Cisco Unity Connection for their audio quality, sample size, bandwidth, and disk space using an 8 kHz/sec sampling rate.

Table 2-1. Recording Codecs Relationship and Limitations (Based on 8 KHz/sec Sampling Rate)

Recording Codec	Characteristics
PCM Linear	Excellent Audio Quality Requires 16 KB/sec disk space 16 bit samples * Used for system codec
G.711 u-Law * G.711 a-Law	Good Audio Quality Requires 8 KB/sec disk space 8 bit samples * Default Recording Codec
G.726	Good Audio Quality Requires 4 KB/sec disk space 16 bit samples
G.729a	Fair Audio Quality (Toll Quality) Requires 1 KB/sec disk space
GSM 6.10	Good Audio Quality Requires 1.6 KB/sec disk space

Users, Codecs, and Message Storage Considerations

Now that you understand the implications of the codecs as they apply to system performance, audio quality, and disk storage space, you must use this information along with the current and future projected users to determine the server sizing. The message storage is designed to handle between 20 minutes to 30 minutes of message storage (using the G.711 system recording codec) for each user configured according to the supported message platform. In most cases, this might be more than sufficient for most organizations. You need to consider emails sent to the users' voice mailbox for replies, forwards, and faxes in the message storage calculation.

The server sizing should be based on projected growth of users to ensure scalability; the codecs to be used; and the total amount of voice mails, replies, forwards, and faxes that need to be available per user. If this is a new installation, it would be advisable to investigate the current voice message stores to gain a benchmark to determine the Cisco Unity Connection server sizing for the message stores.

Finally, you must also understand the clients that might be used to retrieve voice messages and emails because this might influence the number of users supported. The type of clients supported in Cisco Unity Connection can be any of the following types:

• Telephone user interface (phone users)
• Voice user interface (voice recognition users)
• IMAP clients
• Messaging inbox clients using Personal Communications Assistant (PCA)
• IBM Lotus Sametime clients
• RSS reader clients

IMAP Clients and Voice Ports

Cisco has made some marked improvements in the latest 8.x software release of Cisco Unity Connection for its handling of IMAP clients. If users are using clients that support IMAP Idle, there is no increased impact on the load to Cisco Unity Connection. This was not the case in previous versions; however, the clients must be IMAP Idle-mode instead of non-Idle. IMAP Idle is defined as the ability of the client to indicate to the server that is ready to accept messages, without having to click a refresh button or repeatedly make requests to the server. In this case, the same amount of users and ports are supported, whether the users use their phone or IMAP Idle clients. Most IMAP clients support Idle-mode, with a few exceptions.

The Internet Message Access Protocol (IMAP), formerly called Internet Mail Access Protocol, supports both online (non-Idle) and offline (Idle) modes. The mode used depends entirely on the specific client. Cisco Unity Connection supports both non-Idle and Idle-mode clients. However, non-Idle-mode places a significant load on the server and the number of total clients supported is reduced significantly. A single non-Idle IMAP client is counted as four Idle IMAP clients.

The products that support the IMAP Idle-mode consist of the following:

• Microsoft Outlook
• Microsoft Outlook Express
• Microsoft Windows Mail
• Lotus Notes
• Cisco Unified Personal Communicator (CUPC) version 8.x and later
• IBM Lotus Sametime version 7.xx and later

The following Cisco products support only Non-Idle mode:

• Cisco Unified Personal Communicator version 7.x and earlier
• Cisco Unified Mobile Communicator
• Cisco Unified Mobility Advantage
• IBM Lotus Sametime plugin

If you use other clients not listed here, consult the documentation for your specific product or software. Of course, you can use non-Idle clients with Cisco Unity Connection, but the amount of users supported is reduced. As stated previously, a single non-Idle IMAP client should be considered as four IMAP Idle clients when calculating users to determine the server sizing.

Cisco Unity Connection version 8.x software enables organizations to mix non-Idle and Idle IMAP clients on the same server. However, for accounting purposes, it might be advisable to put them on separate servers, or at least create a completely different class of service to account for the number of each type of client on each server. Whether the clients are on separate servers or the same server, the calculations are still the same—meaning, a non-Idle IMAP client still counts as four IMAP Idle clients.

The IMAP non-Idle clients are the only clients that affect the amount of the users in the Cisco Unity Connection version 8.x software. This must be accounted for with current and future users when considering server sizing to allow for scalability.

Determining Voicemail Port Requirements

The number of voicemail ports required is another factor you need to consider in server sizing calculations. To ensure that callers get their calls answered by Cisco Unity Connection and never receive a fast busy, it is imperative that ports are available at all times. The information collected to make the initial calculation can be gathered from the current voice-messaging system to gather traffic volume statistics during the specific busy hours.

The main purpose of a voicemail port in Cisco Unity Connection is to answer calls to Cisco Unity Connection, enabling callers to leave voice messages and for users to retrieve these messages. If you look at only the current voicemail traffic and volume, however, you will be missing many vital factors that must be determined to calculate the correct number of ports. To understand voicemail ports, you must first explore their functions, beyond leaving and retrieving messages. Voicemail ports supply the following functions to Cisco Unity Connection:

• Answer calls for incoming callers
• Recording messages
• Retrieving messages
• Message notification
• Telephony Record and Playback (TRaP)
• Message waiting indicator (MWI)

To determine the actual number of ports to install, the designer must research answers to the following questions:

• How many users need to be configured on the server for voice messaging?
• What is the expected and projected message activity for these users?
• How can the users retrieve messages?
• Can the organization use call handlers within an audiotext application that to answer all or some of the calls to the organization?
• What features are required for voice-messaging users? Voice recognition? SpeechView? TRaP?
• Is message notification required?
• Is high availability a requirement?

The number of users can help the designer to clearly understand the server sizing. Likewise, the amount of voice messages received and retrieved can help clarify the voicemail port requirements. If users use the phone to retrieve their voicemails, a port is required; however, if they use an IMAP client, a port is not required. Users retrieving their messages using the Cisco Messaging Inbox and Microsoft Outlook with the ViewMail have the ability to listen their message through the PC speakers or their IP Phone. The clients themselves do not require a voicemail, but if the users decide to direct their messages to the IP Phone, a port is required. This is referred to as Telephony Record and Playback (TRaP). Users might decide to use their IP Phone if they do not have a workstation capable of audio, or to maintain a level of privacy in the workplace.

When a user receives a message, Cisco Unity Connection notifies the user by sending specific digits to the phone to turn on the message waiting indicator (MWI) light on the user's phone. When the last message is retrieved by the user, Cisco Unity Connection then sends a different set of digits to the phone to turn the MWI light off.

Other than voice messaging, Cisco Unity Connection enables an organization to create call-handlers to be used within custom audiotext applications. Part II explores call-handlers and audiotext applications in depth. Many companies choose to use this application as an auto-attendant for incoming calls, thereby allowing callers to be quickly directed to the proper person, department, or application, thereby decreasing the length of time that users use a specific port. If the audiotext application is used in this means, the call volume to Cisco Unity Connection can greatly increase because a voicemail port is used for every incoming call.

Certain other features employed by users can increase the port usage. For example, if users are configured for message notification, an outgoing call is made from Cisco Unity Connection for every configured message notification attempt, which uses an existing voicemail port. Also, users can choose to be notified of urgent, some, or all messages according to a defined time period. After they receive a notification, the user can choose to listen to the message. The message notification and message retrieval uses an available voicemail port.

Finally, if high availability is a requirement, two servers are required to be configured in a cluster-pair. A single server uses the IBM Informix database for the configuration database and message store. This single server can support up to 250 ports, depending on the server platform, with Cisco Unity Connection version 8.x software. The issue with having the single server configuration is that there is no redundancy if a server failure occurs and no available load sharing, meaning that a single server is responsible for database configuration, message stores and voicemail port activity. The loss of the server can cause a voice-messaging outage until the server is restored.

High-Availability and Redundancy

As of version 7.x software, Cisco Unity Connection supports the active-active cluster pair configuration. This configuration is defined as active-active because both servers actively process calls. In the active-active cluster pair configuration, the active-active cluster pair can support up to 500 ports (250 ports/server) simultaneously, depending on the server platform. If one server in a cluster pair is unavailable, the other server can handle all voice messaging, but with a decreased number of ports (maximum of 250 ports). Therefore, if high availability is a requirement, the total number of ports considered in the design should be kept at a maximum of 250 ports to ensure port availability during an outage. In this way, a server failure can still maintain the required number of ports.

The active-active cluster pair requires two servers with the same software level. The two servers are actively processing calls, even though a single database is still actively performing load sharing and providing redundancy in case of server failure. You can explore the active-active cluster pair design and configuration in the next chapter. At this time, you need to consider this model in your design if high availability is a requirement in tour voice-messaging solution.

Figure 2-2 illustrates the single server and active-active cluster pair design.

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.

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.

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.

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.

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.

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.

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.

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.

Summary

This chapter provided an overview of Cisco Unity Connection software and the necessary elements to consider when designing a voice-messaging system. You learned how to

• Determine the specific server sizing based on users, codec, ports, and client applications.
• Understand the basics of how Cisco Unity Connections version 8.x handles codecs and transcoding for voice messaging.
• Understand the differences between IMAP Idle and IMAP non-Idle and how the amount of users is affected in the design considerations.
• Describe how high-availability and redundancy is accomplished using the active-active cluster-pair model with Cisco Unity Connection version 8.x servers.
• Determine the server sizing based on the physical or virtual platform overlays and the amount of ports and users supported.
• Understand intrasite and intersite networking using Cisco Unity Connection and describe the protocols, advantages, and limitations.
• Describe VPIM networking and how it is used with Cisco Unity Connection and other Cisco voice-messaging products.
• Determine the specific technology requirements based on the voice-messaging system and assemble information collected in the planning phase to create a preliminary design based on the users, location, and geography of the organization.