Did Someone Say Unified?: Cisco is moving full-steam ahead with an initiative to unify voice, video, and data networks into a single infrastructure. This section overviews the core four Cisco unified applications to support VoIP networks.
• Understanding Cisco Unified Communications Manager Express: Communications Manager Express (CME) breaks the typical “data device” paradigm by allowing you to run an entire VoIP system using a Cisco router. This section discusses the target market segment for CME, key CME features, and communication between CME and Cisco IP Phones.
• Understanding Cisco Unified Communications Manager: Cisco Unified Communications Manager (CUCM), Cisco’s flagship call management application, is used in thousands of businesses worldwide. This section details key CUCM features, CUCM database architecture, and CUCM-to-Cisco IP Phone interaction.
• Understanding Cisco Unity Connection: A telephony network just isn’t complete without voicemail! Cisco Unity Connection provides this voicemail functionality along with many other capabilities discussed in this section.
• Understanding Cisco Unified Presence: Unified Presence truly blends the voice and data realms by giving visibility to a telephony user’s status and supporting enterprise instant messaging applications (such as Cisco Unified Personal Communicator). This section highlights key features and placement of Cisco Unified Presence.
The Cisco Unified Communications products break down into four core solutions:
• Cisco Unified Communications Manager Express
• Cisco Unified Communications Manager
• Cisco Unity Connection
• Cisco Unified Presence
Keep in mind that these are the “core” solutions, because you can add many additional applications to expand the features and functionalities of the system. For example, the Cisco Unified Contact Center platforms allows you to add call-center capabilities to your network, such as skills-based call routing, call queuing, live monitoring of conversations, and so on. Cisco Unified MeetingPlace adds enhanced conference-call capabilities, document collaboration, and training platforms. The list goes on and on; it’s all impressive technology, but not core to the system.
The amount a Cisco router is able to accomplish is simply amazing: routing tables, routing protocols, security with access lists, Network Address Translation (NAT)…the list goes on and on. But, what if someone told you that the Cisco router you’ve been using for years could also support your IP telephony network? That was the goal with the Cisco Unified Communications Manager Express (CME) platform. Your Cisco Integrated Service Router (ISR) platform not only routes data, but terminates analog and digital voice circuits (such as FXO, FXS, and T1 ports, which are discussed later), supports VoIP endpoints (such as Cisco IP Phones), and even handles the more advanced features, such as conference calling, video telephony, and automatic call distribution (ACD). Depending on the platform you use, CME can scale to support up to 450 IP Phones, which makes it a good solution for small and even some midsize businesses.
Although Cisco designed CME 8.X to operate on the ISR Generation 2 (G2) platforms, you can also run it on the original ISR platforms (such as the 1800, 2800, or 3800 series), provided you have the proper IOS upgrade. Cisco integrates CME into the IOS software itself, based on the feature set you download. Since the release of IOS 15, a Product Authorization Key (PAK) is needed to activate the CME feature set.
The following are the key features supported by CME:
• Call processing and device control: As mentioned previously, CME acts as the all-in-one call control device. It handles the signaling to the endpoints, call routing, call termination, and call features.
• Command-line or GUI-based configuration: Because Cisco integrated CME directly into the IOS, you have the full flexibility of command-line configuration. You can also use a GUI utility, such as the Cisco Configuration Professional (CCP), to interface with a point-and-click style of configuration.
• Local directory service: The CME router can house a local database of users you can use for authentication in the IP Telephony (IPT) network.
• Computer Telephony Integration (CTI) support: CTI allows the IPT network to integrate with the applications running on the data network. For example, you could use the Cisco Unified CallConnector to make calls directly from your Microsoft Outlook contact list.
• Trunking to other VoIP systems: Although CME can run as a standalone deployment interfacing directly with the PSTN, it can also integrate with other VoIP deployments. For example, you could use CME for a small, 40-user office and have it connect directly over your data network to the corporate headquarters supported by a full Cisco Unified Communications Manager (CUCM) cluster of servers.
• Direct integration with Cisco Unity Express (CUE): CUE, which runs through a module installed in a Cisco router, can provide voicemail services to the IP Phones supported by CME.
Essentially, the relationship between CME and the Cisco IP Phones is similar to the relationship between a mainframe and dumb terminals. CME controls virtually every action performed at the Cisco IP Phones. For example, if a user picks up the handset, an off-hook state is sent from the Cisco IP Phone to the CME router using either the Skinny Client Control Protocol (SCCP) or the Session Initiation Protocol (SIP). We discuss the differences between these protocols in Chapter 3, but in a nutshell, SCCP and SIP are both signaling protocols that allow the call-management platform (CME, in this case) to communicate with and control an IP Phone. As the user begins to dial digits, each digit is sent to the CME router (again, via SCCP or SIP). After the user completely dials the phone number of the other Cisco IP Phone shown in Figure 2-1, CME sends some signaling messages causing the phone to ring. After the user answers the ringing phone, CME connects the IP Phones directly and steps out of the communication stream. The phones now communicate directly using the Real-time Transport Protocol (RTP), which handles the actual audio stream between the devices.
All the phone features (such as hold, transfer, conference, and so on) are still managed using SCCP or SIP, so those would not be available until the CME router came back online. Likewise, after the users disconnect from the call, the phone would not be available to place or receive any calls until the CME router returned online.
CME now assumes the role of voice gateway and signals to the PSTN to establish the call on behalf of the Cisco IP Phone. Keep in mind that this is the “old school” signaling discussed in Chapter 1 since the CME router is attached to the PSTN using a digital (T1/E1) or analog (FXO) trunk. Once the audio for the call connects, the CME router assumes the role of converting between VoIP audio and PSTN audio. Because this conversion is processor intensive, the CME router is equipped with Digital Signal Processors (DSP), which are simply additional “mini processors” dedicated to voice functions.
Many VoIP deployments now connect to the PSTN using an Internet Telephony Service Provider (ITSP) rather than a traditional TSP. In this case, the CME router relays the voice call over a SIP trunk rather than an analog or digital circuit.
CME is a fantastic, all-in-one call processing device, provided someone is there to answer the phone. However, just like the full-blown CUCM, there are no built-in voicemail capabilities. All that changes when CUE steps onto the stage. CUE is a voicemail system that you can install into your CME router in one of two form factors: Internal Services Module (ISM) or Service Module (SM). The ISM form factor installs internal to the CME router and uses solely flash memory for storage. The full SM form factor installs externally to the router and uses a hard disk for storage. Because of this, it can hold roughly ten times as much voicemail as the ISM form factor.
Cisco designed ISM and SM for the ISR G2 series of routers (1900, 2900, and 3900). They are upgrades from the previous Advanced Integration Modules (AIM) and Network Modules (NM), shown in Figure 2-3 and Figure 2-4, which were used in the first-generation ISR routers (1800, 2800, and 3800).
Each module runs its own Linux-based operating system (OS) that you can access and manage from the Cisco IOS of the CME router.
Despite the small size of CUE, it has some powerful features to support your IPT network:
• Voicemail: The core feature provided by CUE. The type of CUE module you choose sets the maximum mailboxes and storage space used for this feature (refer to Table 2-2).
• Auto-attendant: The automated voice everyone loves to hear! An auto-attendant might replace an organization’s operator and allows dial by name, dial by extension, and some basic menu capabilities.
• Interactive voice response (IVR) system: CUE includes basic IVR capabilities that allow callers to move through a menu system, providing more features than the auto-attendant. For example, a user can query a corporate database for a bank account balance or the date of a last payment received.
• Native T.37 fax processing: CME supports the T.37 fax standard that allows it to receive and process faxes as TIFF e-mail attachments. CUE can then distribute the fax to a user’s mailbox.
• Survivable Remote Site Voicemail (SRSV): Allows the CUE module to act as a backup to a primary voicemail server (perhaps running the full Unity Connection) if the IP phones are not able to reach the primary voicemail server. This feature integrates with Survivable Remote Site Telephony (SRST), which allows the CME router to act as a backup to a primary call-management system (perhaps CUCM).
• Standards-based: All signaling between the CME router and CUE module use the SIP protocol, which is becoming the universal standard for voice signaling.
Understanding Cisco Unified Communications Manager
It now runs as a Linux appliance on certified hardware platforms and acts as the powerful call processing component of the Cisco Unified Communications solution. Think of CUCM as the “director” behind any large organization’s Cisco IPT solution. It provides the core device control, call routing, permissions, features, and connectivity to outside applications. The scope of control handled by CUCM is so large, Cisco created two certification exams for it in the CCNP Voice certification track (CIPT1 and CIPT2). In a nutshell, the importance of CUCM to Cisco VoIP is monumental. With that being said, don’t let the massive size of CUCM to overwhelm you. Cisco has done a fantastic job at allowing you to manage nearly every CUCM option through a crisp, well-designed web-based GUI.
Cisco does produce a single-server CUCM solution known as CUCM Business Edition. This single server provides CUCM, Unified Mobility, and Unity Connection for up to 500 IP Phones at an aggressive price. The catch? CUCM Business Edition does not support clustering (server redundancy).
Although CUCM supports numerous capabilities, here are some of the most important:
• Full support for audio and video telephony: The core feature provided by CUCM. In the same way CME acts as the director of a small organization, CUCM supports audio and video calls for midsize to enterprise class corporations.
• Appliance-based operation: Modern CUCM versions run as an appliance, which means the underlying operating system is hardened (secured) and inaccessible.
• Redundant server cluster: As the saying goes, “One is none, two is one.” CUCM supports redundant servers configured in a cluster relationship. The clustering capabilities replicate both database information (containing static data such as directory numbers and route plans) and real-time information (containing dynamic data, such as active calls). CUCM clusters can scale to 30,000 IP phones (SCCP or SIP in unsecure mode) or 27,000 IP phones (SCCP or SIP in secure mode).
• Intercluster and voice gateway control and communication: Even though a CUCM cluster has a limit of 30,000 IP phones, you can create as many clusters as you like (with up to 30,000 IP phones each) and connect them together using intercluster trunk connections. In addition to using Intercluster trunk links to call outside of your own cluster, CUCM can also connect to voice gateways (such as a Cisco router), which can connect to various other voice networks (such as the PSTN or legacy PBX systems).
• Built-in Disaster Recovery System (DRS): As a built-in feature, the CUCM DRS service allows you to back up the CUCM database (and any additional files you’d prefer) to a network device or over Secure FTP (SFTP).
• VMWare Virtualization Support: If you love VMWare, you’ll love the fact that CUCM 8.0 is supported in a VMWare ESXi environment. This brings all the high availability and scalability benefits of virtualization to your CUCM deployment.
• Directory service support or integration: VoIP networks can use network user accounts for a variety of purposes (phone control, attendant console control, and so on). CUCM has the capability to be its own directory server to hold user accounts or it can integrate into an existing corporate directory structure (such as Microsoft Active Directory) and pull user account information from there.
When most people think of a server cluster, they think of multiple servers with mirrored configurations that assume the identity of each other in the case of failure. That is not the functionality of a CUCM server cluster. Instead, think of a CUCM server cluster as multiple, individual servers with their own, unique configuration working for the common good of the IP Phones. The CUCM cluster relationship includes two types of communication:
• CUCM Database Relationship: The CUCM IBM Informix database includes all the “static” data of the cluster (directory numbers, route plan, calling permissions, and so on). This data replicates to all the servers in the cluster.
• CUCM Runtime Data: Just like the name sounds, the runtime data encompasses anything that happens in “real time” in the CUCM cluster. For example, when a device registers with a CUCM server, it communicates to all the other servers that it now “owns” that IP phone. CUCM uses a method designed specifically by Cisco for this type of communication: Intracluster Communication Signaling (ICCS).
Although the CUCM runtime data is important for functionality, there’s simply not too much to it. All the servers in the CUCM cluster form TCP sessions to each other for ICCS communication (TCP ports 8002 to 8004). Then, anytime something of interest happens (such as a phone registering, a call initiation, a call disconnect, and so on), the servers inform each other of the event. All this ICCS communication takes virtually no additional configuration on your part (other than adding the CUCM server to the cluster).
On the other hand, the CUCM database relationship has a little more substance to it. It is not any more difficult to manage than ICCS (it just works behind the scenes), but it does have some key concepts you’ll want to know. First off, the CUCM IBM Informix database uses a one-way replication method where a server known as the Publisher holds the master copy of the database. All changes to the database (with some minor exceptions) occur on the Publisher server and replicate to the Subscribers. Figure 2-5 illustrates this relationship.
Each CUCM cluster supports a single Publisher and up to eight Subscribers. Think of the Subscribers as the “workhorses” of the IPT network. These servers are providing dial tone, receiving digits, routing calls, and streaming music on hold. However, the Publisher typically performs only two primary functions: It maintains the database and serves TFTP requests. Because the Publisher serves such a critical role in maintaining the only writable copy of the CUCM database, it is usually kept from all the heavier work. The TFTP requests come from the Cisco IP Phones during their boot process
In smaller environments (500 IP phones or less), it’s perfectly fine to use the Publisher for call processing and database management. However, once you exceed that number, it’s generally a best practice to pull the Publisher out of call processing and leave that work to the Subscribers. Likewise, once you exceed 1,250 users, Cisco recommends moving the TFTP server role to a dedicated server.
One difference is that the IP phones can now use redundant servers (as opposed to the single CME router). Based on your configuration, a phone can use a list of up to three redundant CUCM servers for failover purposes. If the primary server is down, it uses the secondary. If the secondary is down, it uses the tertiary. Because your CUCM cluster can support up to nine call processing servers (one Publisher, up to eight Subscribers), you can manually load balance the IP phones by assigning different primary, secondary, and tertiary CUCM servers to different groups of phones.
A common mistake when first learning CUCM functions is to confuse the primary server with the Publisher database role. Remember, the main goal of the Publisher is to maintain the writable copy of the database. It will most likely not be the primary server of an IP phone (except in very small environments). One of the Subscribers will be the IP phone’s primary server.
The term “Unity” related to messages: voice messages for sure, but also e-mail messages, fax messages, instant messages…you get the idea. The goal of Unity was to make any message retrievable from any voice-enabled device or application. For example, a caller could leave a voicemail that you could retrieve from an e-mail client inbox. You could listen to your e-mails from a mobile device or have them faxed to an offsite fax machine. Essentially, regardless of how a message was left, you could retrieve it using a variety of clients.
In addition to supporting more mailboxes, Cisco Unity Connection now supports features (such as personal call transfer rules and speech recognition) that are not available in the other Cisco voice-messaging products.!
Cisco Unity Connection Key Features
The following are some of the notable features of Cisco Unity Connection:
• Proven appliance-based platform: Cisco Unity Connection is built on top of the same stable, hardened, appliance-based operating system as CUCM. (These two software products even use the same installation DVD.)
• Up to 20,000 mailboxes per server: Cisco Unity Connection scales to a massive size per server. Even though Unity Connection supports a single-server configuration, most organizations will opt for a high availability pair of servers.
• Access voicemails from anywhere: Carrying on the original dream of Cisco Unity, Cisco Unity Connection allows voicemail retrieval from phone, e-mail, web browser, mobile devices, and instant-messenger platforms.
• LDAP directory server integration: Similar to CUCM, Cisco Unity Connection can integrate with an existing corporate directory (such as Microsoft Active Directory) to avoid creating a duplicate user database.
• Microsoft Exchange support: Cisco Unity Connection can integrate with an existing Microsoft Exchange deployment to enable fantastic features, such as different call treatment based on your Exchange calendar, e-mail text-to-speech (hear your emails read to you from a phone), manage Exchange calendar (accept, decline, cancel, and so on) from a phone, and so on.
• Voice Profile for Internet Mail (VPIM) support: VPIM is a standard allowing voicemail servers to integrate together to exchanging voicemails (and other messaging).
• Active/active high availability: Cisco Unity Connection uses a Publisher/Subscriber IBM Informix database scheme just like CUCM between a pair of servers. The pair of servers can support up to 20,000 mailboxes in a redundant fashion. Both servers can accept client requests (giving it the active/active redundancy). Typically, the largest Cisco Unity Connection server can support up to 250 voicemail ports (essentially allowing 250 people to check their voicemail at a time). By creating a high-availability pair, you can now support 500 voicemail ports.
Outside of CUCM Business Edition, where CUCM and Unity Connection reside on a single server, Cisco Unity Connection operates independently from CUCM. As a matter of fact, you can run Cisco Unity Connection as a voicemail server for other non-Cisco VoIP deployments or even PBX systems; it is not tied to only the CUCM product. Because of this, there is not a simple “click this button in CUCM to magically integrate with Cisco Unity Connection.” Instead, you set up Cisco Unity Connection as an outside system that CUCM can communicate with using the SCCP or SIP signaling protocols.
1. An incoming call from the PSTN arrives at the voice router. The dial-plan on the voice router causes it to route the incoming call to the CUCM server.
2. CUCM receives the call and directs it to the appropriate IP phone (using SCCP or SIP). If someone does not answer the IP phone or diverts the call to voicemail, CUCM forwards the call to the preconfigured extension that reaches the Unity Connection server.
3. CUCM transfers the call (once again using SCCP or SIP) to the Unity Connection server. The extension of the originally called phone is contained in the signaling messages, which allows Unity Connection to send the call to the correct voicemail box.
After the caller leaves a message on the voicemail server, Cisco Unity Connection then “makes a call” (via SCCP or SIP) back to a Message Waiting Indicator (MWI) extension on the CUCM server. CUCM then lights the voicemail indicator on the Cisco IP Phone, alerting the user that they have a voice message waiting. All this interaction between CUCM and Unity Connection is done using voicemail ports, which are licensed features. The more voicemail port licenses you purchase for the Unity Connection server, the more concurrent communication it supports. Be sure to purchase enough licenses! You should consider calls to the auto-attendant, checking voicemail, leaving voicemail, and MWI communication in the number of supported voicemail ports.
Understanding Cisco Unified Presence
Cisco Unified Presence promotes an awareness of the VoIP and data networks. Many folks commonly use Instant Messenger (IM) clients to communicate. In these applications, you are able to see the status of a user, gauging whether they are available, busy, or offline before you begin to chat with them. Cisco Unified Presence stretches this capability to the voice network, allowing you to see the status of a user (are they on the phone, off the phone, not available, and so on) before you pick up the phone to dial. In addition to this core functionality, Cisco Unified Presence adds the following capabilities to your voice network:
• Enterprise instant messaging: Unified Presence incorporates the Jabber Extensible Communication Platform (XCP), which is an industry standard method of communicating between different IM clients.
• Message compliance: Many industries require strict compliance guidelines on instant messenger communication. Cisco Presence supports logging functionality for all types of IM communication (even conversations encrypted with Transport Layer Security [TLS]).
• Interdomain federation: Unfortunately, this feature has nothing to do with Star Trek; however, it has everything to do with connectivity. Using Interdomain federation connections from Unified Presence, you can connect your organization to other domains, such as Google Talk or WebEx Connect, thus giving you worldwide reach.
• Jabber XCP extensibility: XCP allows you to extend Unified Presence into virtually any area of the data or voice network. XCP can allow features such as peer-to-peer file sharing, application sharing, video-conference systems, and so on. XCP integrates with nearly any infrastructure, such as directory services, databases, and web portals.
• Secure messaging: Applications integrating into Unified Presence can use IPSec or TLS standards to encrypt and secure all communication.
Cisco Unified Personal Communicator
You’ll hardly find any documentation available about Cisco Unified Presence without seeing a mention of Cisco Unified Personal Communicator. Once you understand the purpose of Personal Communicator, you’ll understand why. This single-software application brings together frequently used services in a single location: soft phone, presence, instant messaging, visual voicemail, employee directory, communication history, video, and web conferencing. When you initially see Cisco Unified Personal Communicator, it looks like another IM client
Chapter 2 – CCNA VOICE
Did Someone Say Unified?: Cisco is moving full-steam ahead with an initiative to unify voice, video, and data networks into a single infrastructure. This section overviews the core four Cisco unified applications to support VoIP networks.