Cisco IP Telephony System Trade-Offs

For the small standalone office, Cisco IPC Express is an excellent system. For larger networks of multiple sites, the decision to centralize or distribute call processingor, more specifically, which sites should get call processing servers and which should access services from a nearby larger hub locationis key to the fundamental design of an IP telephony network. It is also one of the important factors dictating whether Cisco IPC Express is the best fit for each individual site.

Generally, two Cisco IP telephony products should be considered for the call processing component in a standalone or multisite network or a section of that network:

• Cisco CallManager A separate Intel-based server (or multiple servers in a redundant configuration) available in a range of capacities from 1000 to 7500 IP phones. You can cluster these servers to form server farms with increased redundancy and availability to provide IP telephony to large campuses and to act as a hub for up to 500 remote sites. Although individual return on investment (ROI) varies, Cisco CallManager generally is not cost-effective at sites of fewer than approximately 500 phones. You can deploy Cisco CallManager in a centralized, distributed, or hybrid model.
• Cisco IPC Express A Cisco IOS-integrated call processing component that is coresident in the router at the site. Cisco IPC Express is cost-effective at the low end and can provide IP telephony services at sites requiring up to 240 phones. For a multisite network, Cisco IPC Express inherently represents a distributed call processing model, because the call control is built into the router at each site.

Cisco also offers other call processing components, such as the Cisco BTS 10200 Softswitch (on Cisco.com, search for "BTS 10200") and the Cisco PGW 2200 Softswitch (on Cisco.com, search for "PGW 2200"). However, these are used primarily in SP networks for residential or large-scale voice services, such as a long-distance carrier service. They are not deployed as the call processing component in a standalone business or small or medium enterprise, which is the focus of this book. Therefore, these products are not covered here in any further detail.

Considering the Cisco CallManager and Cisco IPC Express products, the network design decision at hand is not only centralized versus distributed, but also which product is the best choice for which site. The following sections explore the key trade-offs to help you determine which design might best fit your network.

Cisco Call Manager Networks

Many large enterprises comprising hundreds or thousands of sites find a centralized Cisco CallManager network the best option. Here the term centralized is used in a looser sense than in the preceding sections, meaning that most phones and sites draw their call processing services from another, larger site. But inevitably, multiple Cisco CallManager servers are distributed among several of the largest, central locations, and the network is, strictly speaking, a hybrid network. The multiple servers are required for both scalability and reliability. Thus, the core of the network is a distributed model, whereas the smaller sites follow a centralized model.

In these types of networks, voice mail is often also centralized, provided by large-scale servers with thousands or tens of thousands of users per server or server farm. Many other applications, such as e-mail and business applications (for example, product ordering systems and web servers), might also be located at the same site and concentrated in the same data center(s). Therefore, they are a centralized resource to the majority of the remote sites in the network.

Providing both call processing and voice mail services in a centralized manner requires the following network and business attributes:

• Sufficient WAN bandwidth for voice calls from the remote sites to the central site where the call processing or voice mail servers are hosted
• A quality of service (QoS)-engineered WAN to all remote locations
• Network availability (uptime) commensurate with the telephone service expectations of the remote users
• A central IT management model and strong IT expertise
• A business commitment to IP telephony rollout at all or most sites
• A strongly integrated enterprise network, in terms of both technology and management practices

Although the preceding characteristics are present in most large enterprise networks, they are often not present in the majority of small and medium businesses or in smaller enterprise networks.

Cisco IPC Express Networks

At the other end of the spectrum are small standalone businesses with a single office, or small or medium businesses with a handful of sites. A Cisco CallManager server is usually oversized and not cost-effective for the former category of business. It may or may not be a reasonable choice for the latter category, partly depending on how many employees the business has.

Businesses for which a Cisco IPC Express system is a good system have some, or all, of the following attributes:

• Standalone single-site business
• Provided that a WAN is present, it often has insufficient bandwidth to carry voice calls between sites, or there are other logistical reasons for not using the WAN to carry voice traffic
• Provided that a WAN is present, QoS has not been deployed in the network and isn't yet a cost-effective proposition, or the WAN consists of Internet segments that inherently do not offer QoS guarantees
• An autonomous management model for remote locations, or a loosely integrated enterprise network, both in terms of technology and management practices
• No central IT organization or expertise
• Business voice call patterns that are predominantly among remote locations and their local PSTN-based customers, with very little call volume between locations of the enterprise

Although many businesses deploying Cisco IPC Express do not deploy intersite voice across their IP network, other businesses find this latter model a very good fit. Small or medium businesses with a smallish number of sites (for example, 10 or 20 sites) sometimes have a private, QoS-enabled WAN. Saving money on long-distance voice calls between sites may not be the driving business reason for deploying Cisco IPC Express, but it may still be a nice additional benefit.

It is possible to network different Cisco IPC Express sites across an IP infrastructure and leverage that network for voice over IP (VoIP) calls. The considerations with Cisco CallManager and Cisco IPC Express, in this case, often hinge on the following:

• The technology and features available from each product. (For example, Cisco IPC Express can do paging but Cisco CallManager can't, so if this feature is required, Cisco IPC Express is the best fit.)
• The VoIP rollout strategy may be to start with three or five networked sites (which would mean that Cisco IPC Express is a very good fit) and only much later migrate the whole network to a centralized Cisco CallManager solution.
• No clear central site or central organization that could reasonably host the call processing and, therefore, local call processing in each site is more in line with the architecture of your business. (This is often the case in the retail segment.)
• Your remote sites have considerable local autonomy (for example, a franchised business). Therefore, they prefer to run and manage their own IP phones, call processing, and voice mail services.

Hybrid Cisco Call Manager and Cisco IPC Express Networks

Like most decisions, whether to deploy only Cisco IPC Express or only Cisco CallManager in a network isn't entirely clear-cut. A hybrid network design with a centralized (again, in the looser sense of the term) Cisco CallManager servicing a number of sites and Cisco IPC Express (representing a distributed design) at a number of other sites makes sense for some networks.

Certain attributes may suggest that a hybrid approach is a good solution:

• WAN readiness
• IP telephony rollout strategy
• Varying business practices

WAN Readiness

Segments of the WAN are bandwidth- and QoS-enabled for voice traffic, but other sites are not. These sites may be connected with technology where it does not yet make economic sense to increase the bandwidth or engineer the WAN access for QoS. Or these sites may be connected such that it is not cost-effective (based on the connectivity services offered in the area) to change their WAN connectivity or bandwidth.

IP Telephony Rollout Strategy

A situation might exist where there is a desire to start an IP telephony pilot in one or more sites for a small number of users, while corporate commitment to roll out IP telephony to the entire network is a future, multiphased, multiyear strategy.

Depending on the number of users in the pilot, a Cisco CallManager may be too expensive or too large in scale for the pilot. Using Cisco IPC Express as the IP telephony entry point is an attractive option. All the phones, routers, switches, seat licenses, and other voice components can be directly reused when Cisco CallManager is later rolled out in a centralized manner to serve the users who were in the pilot.

The call processing for Cisco IPC Express is hosted inside the Cisco IOS router that is already present at the site. If it is newly purchased, it can be reused as the WAN router when the site migrates to a centralized Cisco CallManager model. This same router at that point also migrates from being the Cisco IPC Express router to becoming the Survivable Remote Site Telephony (SRST) router for the office. You can migrate from Cisco IPC Express to Cisco CallManager/SRST at your own pace, and you can make the decision independently for each site. Cisco IPC Express and Cisco CallManager sites can coexist in the network for any length of time you choose.

Varying Business Practices

A company's business may be such that some sites are tightly coupled to each other, often call each other, and are under the management of an IT organization. Other sites may be much more autonomous and loosely coupled to the rest of the enterprise based on the type of business they conduct for the enterprise. IT management for these sites may be largely left up to the sites themselves.

This situation may arise from the acquisition of a company with a different management philosophy, a larger enterprise that spins off certain parts of the business to be more autonomous, or a core parent business that franchises its agencies (which is sometimes done in the insurance industry).