Designers Challenge: Placing Cisco CallManagers in the Network

Designers' Challenge: Placing Cisco CallManagers in the Network

Some companies might only need CCM servers at one location, while other companies might have IP phones at multiple geographic locations. A major CCM design decision revolves around how to deploy CCM servers across the company's locations. Based on a company's design requirements, you can select from one of four possible design models:

• Single-Site IP phones and CCMs located at a single site

• Centralized Call Processing IP phones at multiple sites and all CCMs at a single site

• Distributed Call Processing IP phones and CCMs at multiple sites

• Clustering over the WAN IP phones and CCMs at multiple sites, with all CCMs logically assigned to the same cluster

The sections that follow review each model in a bit more detail.

Single-Site Model

An IP telephony deployment at a single location (for example, a college campus or a company headquarters), as shown in Figure 4-4, uses the high-speed LAN at that location. The public switched telephone network (PSTN) is used for all calls to the outside world. Therefore, voice bandwidth usage is not a major design consideration, and the G.711 is typically the coder decoder (CODEC) of choice.

Figure 4-4. Single-Site Model

Hopefully, the single site's existing data network already uses a high availability design, with redundant links between switches and routers. Because all IP telephony components connect to that existing data network, these added IP telephony components also enjoy high availability.

Because a single-site deployment typically consists of a single cluster, all IP phones register with this same cluster. Therefore, the dial plan is simplified.

Centralized Call Processing Model

Sometimes, companies wish to extend their IP telephony network beyond the headquarters, reaching out to remote offices. However, often times the relatively small size of these remote offices does not justify the purchase of CallManager servers. A centralized call processing model, as shown in Figure 4-5, allows IP phones located at the remote sites to register with a CallManager cluster located at a central site (that is, at the headquarters). The central site not only houses the CallManager cluster but also contains DSPs that the remote IP phones use for features including conferencing and transcoding (that is, converting back and forth between different CODECs). A centralized deployment model typically uses the G.729 CODEC, which only requires 8 kbps of bandwidth for the voice payload, over the IP WAN for bandwidth conservation.

Figure 4-5. Centralized Call Processing Model

Maintenance at the remote sites is minimized because no CallManager servers reside at these sites. However, consider what might happen if the IP WAN became inaccessible. Because the IP phones at the remotes sites rely on the CCM cluster located at the headquarters, if the IP WAN goes down, those IP phones lose connectivity with their CallManager. To accommodate for such an IP WAN failure, we can use the Cisco Survivable Remote Site Telephony (SRST) feature at these remote sites, as shown in Figure 4-6.

Figure 4-6. Survivable Remote Site Telephony (SRST)

SRST allows a Cisco IOS router to step in and take over call processing tasks for IP phones at the remote sites in the event of a WAN failure. Even though an SRST router doesn't provide all the bells and whistles available on a CCM server, an SRST router does support basic functions and allows IP phones at the remote site to not only call each other but also call out to the PSTN. The number of IP phones supported by an SRST router varies based on the router platform, but as an example, a Cisco 7200 Series router supports up to 480 IP phones.

Centralized deployments, however, suffer from low scalability when remote sites have more than 1000 users. As a company adds more and more remote offices, the added IP phones place an increased burden on the centralized CCM cluster. The remote IP phones' call setup traffic also uses precious IP WAN bandwidth. Therefore, for larger deployments, designers might opt for a distributed deployment design.

Distributed Call Processing Model

Companies with multiple remote locations, or even a few large remote locations, might select a distributed call processing model, as shown in Figure 4-7, as opposed to a centralized call processing model. Distributed deployments place CCM clusters at all remote locations.

Figure 4-7. Distributed Call Processing Model

Because each remote location contains its own CCM cluster, remote sites are minimally impacted by IP WAN outages. The potential exists, however, for the IP WAN's bandwidth to become saturated with too many voice calls. Therefore, a distributed deployment model often uses a gatekeeper to keep track of the number of calls being placed between sites. As the IP WAN bandwidth usage approaches capacity, a gatekeeper can deny additional call attempts. Think of a gatekeeper as a traffic cop with a GO/STOP sign in hand, letting calls know whether or not they are allowed to cross the IP WAN.

A distributed deployment model can scale to multiple sites (that is, over 100 sites). However, additional expense is incurred, as compared to the centralized deployment model, due to the extra hardware and maintenance required for the remote sites. However, for large enterprise-wide IP telephony deployments, the distributed deployment model is usually the design of choice.

Clustering over the WAN Call Processing Model

A final option for deploying CCM servers across multiple geographic locations is a clustering over the WAN model. Some designers consider this model to be the best of both worlds, in that it offers the simplified dial plan of the centralized deployment model and the high availability of the distributed deployment model, as shown in Figure 4-8.

Figure 4-8. Clustering over the WAN Model

The clustering over the WAN model is not without its challenges. Specifically, to successfully deploy this model, you'll need bandwidth and plenty of it. If 10,000 phone calls are placed on the company's telephony system during the busiest hour of the day (that is, 10,000 Busy Hour Call Attempts [BHCAs]), the IP WAN requires 900 kbps of bandwidth. If 20,000 phone calls are placed during the busiest hour of the day, 1.8 Mbps of IP WAN bandwidth is needed, and so on.

Besides plenty of bandwidth, the delay between the sites needs to be very low. At a maximum, a packet should travel from one site across the IP WAN and back again in 40 milliseconds (ms). Just for fun, you can try a PING from your computer while connected to the Internet to see what sort of round trip delay you're experiencing. On a Windows platform, click on the START button. Then click RUN. In the OPEN dialog box, type ping www.ciscopress.com, and press ENTER. Notice the round trip delay in the time = field. On my home computer, connected to the Internet via digital subscriber line (DSL), I get a round trip delay of about 82 ms, not even close to the clustering over the WAN requirement of 40 ms.

With the advent of metropolitan-area networks (MANs), which use high-speed fiber optics to interconnect locations scattered across large cities, clustering over the WAN is gaining popularity.

As a final design consideration for the clustering over the WAN model, only four sites can belong to a cluster. Therefore, for larger deployments (that is, more than four sites), designers should select the distributed deployment model, even over a WAN with plenty of bandwidth and low delay.