Implementing VoIP Support in an Enterprise Network (Cisco VoIP Implementations)

This section is intended to give you an overview of telephony deployment models and their necessary elements and components in an enterprise network. It briefly introduces Cisco Unified CallManager, and it discusses a few different implementation options for CallManager clusters. The last part of this section includes a simple configuration for a Cisco voice gateway and concludes with a brief discussion of CAC.

Enterprise Voice Implementations

The main telephony elements of an enterprise Cisco VoIP implementation are gateway, gatekeeper, Cisco Unified CallManager, and Cisco IP phones. Cisco IP phones need CallManager, because it acts as an IP PBX for the Cisco IP phones. The gateways provide connectivity between analog, digital, and IP-based telephony devices and circuits. Gatekeeper is an H.323 device that provides call routing or CAC services.

Enterprise voice implementations can vary based on many factors. One of those factors is the number of sites, and the preferred method of data and voice connectivity (primary and backup) between the sites. Some sites might not have VoIP implemented; other sites might have VoIP connectivity but no IP phones or other IP Telephony services. The sites with IP phones and services might have the control components, such as Cisco Unified CallManager cluster, locally present, or they might have to communicate with the control devices that reside at another branch or site. Figure 1-15 displays an enterprise with three branches: Branch A, Branch B, and Branch C.

Figure 1-15 VoIP Implementation Within an Enterprise

 VoIP Implementation Within an Enterprise

At Branch A, IP Telephony services and IP phones have been deployed. Branch A has a Cisco Unified CallManager cluster, and all employees use IP phones. Branch A is connected to Branch B using a metropolitan-area network (MAN) connection such as Metro Ethernet; voice calls between Branch A and Branch B must use this path. The Branch A connection to Branch C is over a WAN, such as legacy Frame Relay or ATM (a modern connection would be an MPLS VPN connection); voice calls between Branch A and Branch C must use this path. If WAN or MAN connections are down, voice calls must be rerouted via PSTN; if there is congestion, using the automated alternate routing (AAR) feature, voice calls are again rerouted via PSTN. Note that at Branch A, voice calls to and from people outside the enterprise are naturally through PSTN.

At Branch C, on the other hand, the old PBX system and phones are still in use. A voice gateway at Branch C provides connectivity between the Branch C PBX system (and phones) to the PSTN and all other branch phones over the WAN connection. Again, the preferred path for voice calls between Branch C and the other branches is over the WAN connection; however, when the WAN connection is down or is utilized at full capacity, voice calls are rerouted over the PSTN. All outside calls to and from Branch C are through the PSTN. The enterprise is planning to deploy IP phones in Branch C, but they are planning to buy a voice gateway with Cisco CallManager Express instead of installing a full Cisco Unified CallManager cluster at that branch. Cisco CallManager Express runs on a Cisco gateway instead of a server, and it is ideal for smaller branches that want IP Telephony without dependence on another branch over a WAN connection.

Branch B is connected to Branch A over a high-speed MAN. IP phones at Branch B are under control of the Cisco Unified CallManager cluster at Branch A. Voice calls between Branch B and Branch A must go over the MAN connection. Voice calls between Branch B and Branch C go over MAN to get to Branch A and then over the WAN to get to Branch C. Voice calls from Branch C to Branch B take the reverse path. If the MAN connection goes down, survivable remote site telephony (SRST) deployed on the Branch B gateway allows Branch B IP phones to call each other, but calls to anywhere else are limited to one at a time and are sent over PSTN. That is because the gateway at Branch B has two FXO interfaces, which are connected using two analog phone lines to the PSTN. One of the analog lines is reserved exclusively for 911 emergency calls; that leaves only one line for any other out-of-branch call (when MAN is down). When the MAN connection between Branch B and Branch A is up, all of the Branch B outside calls, except the 911 emergency calls, are sent over the MAN connection to Branch A and then through the Branch A gateway to PSTN.

Voice Gateway Functions on a Cisco Router

The Cisco family of voice gateways, including integrated services routers (ISR), provide connectivity between analog interfaces, digital interfaces, and IP Telephony devices. Examples of analog interfaces are FXS and FXO. Examples of analog devices are analog phones, fax machines, and modems. T1/E1 and BRI are examples of digital interfaces. A PBX is usually connected to a gateway using T1/E1 interfaces, even though using an E&M interface is also possible. You can set up a gateway connection to the PSTN CO switch over a T1/E1 or an E&M connection. You can configure a gateway T1/E1 for CCS, where one channel is dedicated to signaling such as ISDN Q.931 or QSIG, and the rest of the channels are available for data or digital voice signals. You can also configure a gateway T1/E1 as CAS. When configured for CAS, a T1 interface can have all 24 channels available for data/digital voice, but each channel loses a few bits to signaling; for this reason, CAS is also referred to as robbed bit signaling (RBS). A gateway can have one or more LAN and WAN interfaces, such as Fast Ethernet, synchronous Serial interface, and ATM.

Gateways convert analog signals to digital and digital signals to analog. They might also be able to handle several different types of codecs. These capabilities depend on the DSPs installed in that gateway and its IOS feature set. DSPs also allow gateways to provide transcoding and conferencing services. Cisco IOS routers (gateways) support the most common VoIP gateway signaling protocols, namely H.323, SIP, and MGCP.

SRST is a useful IOS feature on gateways at remote sites with no CallManager servers. The IP phones at these types of sites communicate with and receive services from CallManager servers at another branch, such as a central branch. If the IP connectivity between the central and remote branch is lost, the IP phones at the remote branch are dysfunctional, unless the gateway of the remote site has the SRST feature. With SRST, the IP phones at the remote site survive, can call among themselves, and have limited features such as hold and transfer. However, the gateway with SRST has to route all other calls to the PSTN.

The IOS on certain Cisco routers and switches has the Cisco Unified CallManager Express feature. This feature allows the gateway to act as a complete CA (CallManager) for the IP phones at a branch. This is not disaster recovery, but a permanent solution or option for smaller branches.

In addition to the features listed, the Cisco gateways offer fax relay, modem relay, and DTMF relay services. Other features such as Hot Standby Routing Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), and Gateway Load Balancing Protocol (GLBP) provide fault tolerance and load sharing among redundant gateways.

Cisco Unified CallManager Functions

Cisco CallManager (CCM) is call processing software; it is the main component of the Cisco Unified Communication System. CCM supports the MGCP, H.323, SIP, and SCCP IP Telephony signaling protocols. Within the MGCP context, CCM acts as the CA and controls MGCP gateways, and within the SCCP context, it controls the IP phones (Skinny Clients). CCM interacts with H.323 and SIP devices. Cisco CallManager version 5.0 supports SIP clients, such as SIP-based IP phones. CallManager servers form a cluster that provides the means for load sharing and fault tolerance through redundancy. Some of the important services and functions that Cisco Unified CallManager provides are these:

■ Call processing—CCM performs call routing, signaling, and accounting; furthermore, it has bandwidth management and class of service (CoS) capabilities. (Class of service in this context means enforcing call restrictions.)

■ Dial plan administration—CCM acts as the CA for MGCP gateways and IP phones; therefore, the dial plan is administered, implemented, and enforced on CCM, and its clients do not and need not have that information or capability.

■ Signaling and device control—Acting as the CA for MGCP gateways and IP phones, CCM performs signaling for these devices and fully controls their configuration and behavior. When an event occurs, the device informs CCM (the CA), and CCM in turn instructs the device as to the action it should take in response to that event.

■ Phone feature administration—IP phone configuration files are stored on the Cisco CallManager server; therefore, IP phone administration is centralized. At the time of bootup or when it is manually reset, an IP phone loads its configuration file from its own CallManager server.

■ Directory and XML services—Directory services can be made available on Cisco CallManager; IP phones can then perform lookup on the available directories. XML applications can be administered as IP phone services on CCM.

■ Programming interface to external applications—Cisco Systems provides an application programming interface (API) so that applications software can be written to work and communicate with Cisco Unified CallManager. Examples of such applications already developed are Cisco IP Communicator (a computer-based soft IP phone), Cisco Interactive Voice Response System (IVR), Cisco Attendant Console, and Cisco Personal Assistant.

Enterprise IP Telephony Deployment Models

Many IP Telephony deployment options, utilizing Cisco Unified CallManager, are available. The option that is suitable for an enterprise depends on the organization of that enterprise, its business strategy, budget, and objectives. You can deploy the options presented here in combination (hybrid models) or slightly differently. The four main options are as follows:

■ Single site

■ Multisite with centralized call processing

■ Multisite with distributed call processing

■ Clustering over WAN

Single-Site Model

In the single-site model, as the name implies, the enterprise has one site, and within that site it has a Cisco CallManager cluster deployed. The local IP phones and perhaps MGCP gateways are under the control of CCM, and CCM can communicate with H.323 and SIP devices. Calls that are external to and from the site are routed through a gateway to the PSTN. The gateway DSPs can provide codec, compression, transcoding, or conferencing resources. If the site has a WAN connection to another place, the WAN connection is not used for IP Telephony purposes in this model.

Multisite with Centralized Call Processing Model

In the multisite with centralized call processing model, the Cisco Unified CallManager (CCM) cluster and application servers are placed at one of the sites—usually a main or central site. This

IP Telephony solution spans multiple sites; in other words, all devices such as IP phones and MGCP gateways at all sites are under the control of the CCM cluster at the central site. Notice that even though call processing is centralized, DSP resources can be distributed.

If network connectivity, such as IP WAN, exists between sites, it carries signaling messages to and from remote sites. Even if a device in a remote site calls another device within the same site, signaling traffic must go through the WAN connection. However, VoIP packets (not signaling) go through the WAN connection only for intersite calls.

Usually, each site has a PSTN connection that serves two purposes: It allows the site to make outside calls, and it can act as an alternate route for when the WAN is down or is utilized to its limit. CAC is used to prohibit too many active intersite calls from hindering data communications or making the quality of calls drop. Administrators decide how many concurrent intersite calls over the WAN connection are viable and configure CAC to deny permission to any new calls over the WAN when the number of active intersite calls reaches that level. In those situations, a new intersite call can either fail (reorder tone or annunciator message), or it can be transparently rerouted through PSTN by means of automated alternate routing (AAR).

If a remote site temporarily loses its WAN connection to the central site, rendering its IP phones useless, SRST is utilized on the gateway of that site. SRST is a feature available on Cisco gateways that allows the IP phones at the remote site to stay active (in the absence of a path to their CCM server) and be able to call each other within the site. SRST routes all calls through the PSTN when the WAN connection is down.

Multisite with Distributed Call Processing Model

In the multisite with distributed call processing model, each site has its own Cisco Unified CallManager cluster controlling all call processing aspects of that site—hence the term distributed call processing. Application servers and DSP resources are also distributed at all sites. Sites, in this case, do not depend on the call processing offered at another site. In distributed call processing, each site has a CallManager cluster. Please note that the other resources (voice mail, IPCC, IVR, DSP resources, etc.) can be centralized or distributed; while they’re normally distributed, they do not have to be.

The WAN connection between the sites carries intersite data exchange, signaling, and VoIP packets. However, when a device calls another device within its own site, no traffic is sent over the WAN. CAC is still necessary to prohibit too many calls from going through the WAN connection. Each site has PSTN connectivity, which serves two purposes: it allows outside enterprise calls for each site, and it allows rerouting of intersite calls that cannot go through the WAN connection (either due to CAC denial or WAN outage).

This model is comparable to a legacy telephony model, where an enterprise would have a PBX system at each site and, using telco services, the enterprise would connect each pair of PBX systems at remote sites using tie-lines or trunks. In the distributed call processing model, an IP Telephony trunk must be configured between each pair of CallManager clusters (IP PBX) to make intersite calls possible. Examples of IP Telephony trunks that CCM supports are intercluster trunks, H.323 trunks, and SIP trunks.

Clustering over WAN Model

This model uses only one Cisco CallManager cluster for all sites. However, not all servers of the cluster are put in a single site together. Instead, the CCM servers, application servers, and DSP resources are distributed to different locations to provide local service to their clients (such as IP phones and gateways). The CCM servers need to communicate over the intersite IP WAN connection to perform database synchronization and replication. For clustering over WAN to work properly, the maximum round trip delay between each pair of servers within the cluster must be less than 40 ms.

In this model, IP phones acquire services and are controlled by servers in the same site. IP WAN carries signaling and voice packets only for intersite calls. CAC is needed to control the number of calls utilizing the WAN connection. PSTN connection at each site is necessary for outside calls and for AAR purposes.

Identifying Voice Commands in IOS Configurations

Cisco routers that have proper interfaces can be configured to provide connectivity between analog or digital telephony devices over an IP network; they are called voice gateways in those circumstances. Figure 1-16 shows two voice gateways, R1 and R2, each with an analog phone connected to its FXS interface. To provide connectivity between the two phones over the IP network, in addition to basic configurations, each of the routers (gateways) needs one plain old telephone service (POTS) and one VoIP dial peer configured.

Figure 1-16 Two Sample Voice Gateways with Analog Phones Connected to Their FXS Interfaces

Two Sample Voice Gateways with Analog Phones Connected to Their FXS Interfaces

A dial peer is a Cisco IOS configuration that links or binds a telephone number to a local POTS interface such as FXS or to a remote IP address; therefore, one POTS dial peer and one VoIP dial peer exist. The series of dial peers configured on a gateway together form its VoIP call routing table. The configurations of R1 and R2 shown in Example 1-1 and Example 1-2 take advantage of the default VoIP signaling protocol on Cisco gateways (H.323). If the phone on R1 goes off-hook and, after receiving the dial tone, number 22 is dialed, R1 sends H.323 signaling (call setup) messages to the R2 IP address After the message from R1 is received and processed, based on the dialed number 22, R2 sends a ring signal to interface 2/0/0 (the FXS port), and the phone on R2 rings.

Example 1-1 R1 VoIP Configuration

R1 VoIP Configuration

Example 1-2 R2 VoIP Configuration

R2 VoIP Configuration

Call Admission Control (CAC)

Call admission control is a feature that is configured to limit the number of concurrent calls. Usually, because the bandwidth of the WAN link is much less than LAN links, CAC is configured so that WAN bandwidth does not get oversubscribed by VoIP calls. CAC complements QoS configurations. For instance, if a strict priority queue with enough bandwidth for three voice calls is configured on all routers between two phones, although there are fewer than four concurrent calls, all will be good quality. What would happen if ten calls went active concurrently? If all the VoIP traffic packets (RTP) must share the strict priority queue that is provisioned with enough bandwidth for three calls, routers will drop many VoIP packets when there are ten active calls. The packets that will be dropped belong to any or all active calls, indiscriminately. It is wrong to believe that only packets associated to the calls beyond the third one will be dropped. As a result, all calls can and probably will experience packet drops and, naturally, poor call quality. When there are available and reserved resources for a certain number of concurrent calls, CAC must be configured so that no more calls than the limit can go active. QoS features such as classification, marking, congestion avoidance, congestion management, and so on provide priority services to voice packets (RTP) but do not prevent their volume from exceeding the limit; for that, you need CAC.

Foundation Summary

The "Foundation Summary" is a collection of information that provides a convenient review of many key concepts in this topic. If you are already comfortable with the topics in this topic, this summary can help you recall a few details. If you just read this topic, this review should help solidify some key facts. If you are doing your final preparation before the exam, the information in this section is a convenient way to review the day before the exam.

Benefits of packet telephony networks include usage of common infrastructure for voice and data, lower transmission costs, more efficient usage of bandwidth, higher employee productivity, and access to new communication devices. Main packet telephony components are phones, video end points, gateways, MCUs, application servers, gatekeepers, and call agents. Voice gateways can have analog interfaces such as FXS, FXO, and E&M; they may have digital interfaces such as BRI, CT1/PRI, or CE1/PRI.

The main stages of a phone call are call setup, call maintenance, and call teardown. Call control has two main types: centralized call control and distributed call control. H.323 and SIP are examples of distributed VoIP call control protocol, whereas MGCP is an example of a centralized VoIP call control protocol.

The steps involved in analog-to-digital voice conversion are sampling, quantization, encoding, and compression. Digital-to-analog voice conversion steps include decompression, decoding, and reconstruction of analog signal from pulse amplitude modulation (PAM) signal. Based on the Nyquist theorem, the sampling rate must be at least twice the maximum analog audio signal frequency. Quantization is the process of expressing the amplitude of a sampled signal by a binary number. Several different ITU coding, decoding, and compression standards (called codecs) exist, each of which requires a specific amount of bandwidth per call and yields a different quality. Digital signal processors (DSP) convert analog voice signal to digital and vice versa; DSPs are also voice termination points on voice gateways and are responsible for transcoding and conferencing. Digitized voice is encapsulated in IP packets, which are routed and transported over IP networks. RTP, UDP, and IP headers are added to digitized voice, and the data link layer header is added to form a frame that is ready for transmission over media. Compressed RTP (cRTP) can reduce or compress the RTP/UDP/IP headers when configured on the router interfaces on both sides of a link; the reduction in overhead produced by cRTP is mainly beneficial and recommended on links with less than 2 Mbps bandwidth.

The factors that influence the bandwidth requirement of each VoIP call over a link are packet rate, packetization size, IP overhead, data link overhead, and tunneling overhead. The amount of voice that is encapsulated in an IP packet affects the packet size and the packet rate. Smaller IP packets mean more of them will be present, so the IP overhead elevates. Different data link layer protocols have varying amounts of header size and hence overhead. Tunneling and Security (IPsec) also add overhead and hence increase the bandwidth demand for VoIP. Computing the total bandwidth required on a link for each VoIP flow includes knowledge of the codec used, packetization period, and all the overheads that will be present. Voice activity detection (VAD) can reduce bandwidth requirements of VoIP calls and produce bandwidth savings of up to 35 percent.

The main components of enterprise voice implementations are IP phones, gateways, gatekeepers, and Cisco Unified CallManager (CCM). Gateway, call agent, and DSP are among the capabilities offered by Cisco integrated services routers (ISRs). CCM provides call processing, dial plan administration, signaling and device control, phone feature administration, and access to applications from IP phones. Enterprise IP Telephony deployment models are single site, multisite with centralized call processing, multisite with distributed call processing, and clustering over WAN. Dial peers are created with Cisco IOS commands configured on gateways to implement a local dial plan. Call admission control (CAC) is configured to limit the number of concurrent VoIP calls. It is required even in the presence of good QoS configurations so that WAN resources (bandwidth) do not become oversubscribed.

Next post:

Previous post: