Cisco.IP.Telephony.Planning.Design.Implementation.Operation.and.Optimization [Electronic resources] نسخه متنی

IP Telephony Deployment Architectures

By using CallManager, organizations can eliminate PBX and replace it with IPT over a converged network. CallManager provides call-control functionality and, when used in conjunction with IP phone sets or a soft phone application, it can provide PBX functionality in a distributed and scalable fashion. Cisco IPT solution deployment models fall into one of the following categories:

Single-site deployment

Centralized call processing with remote branches

Distributed call-processing deployment

Clustering over the IP WAN

Selection of the deployment model depends on the organization's requirements, such as the size of the network, features, and availability of the WAN bandwidth. This section provides information on various deployment models at a high level. To get detailed information on the benefits and limitations, refer to the IP Telephony Solution Reference Network Design for Cisco CallManager 4.0 on Cisco.com, available for download at http://www.cisco.com/go/srnd.

Single-Site Deployment

In this deployment model, shown in Figure 1-15, CallManager applications such as voice mail, IP-IVR, AutoAttendant (AA), Transcoding, and conferencing resources are located at the same physical location. All the IP phones are located within this single site. The PSTN is used to route the off-net calls.

Centralized Call Processing with Remote Branches

Figure 1-16 shows the centralized call-processing deployment with remote braches. All the call processing is done at the central site. This is suitable for organizations in which the majority of the workforce is concentrated at a single site and small numbers of employees work at the remote branches.

At each remote branch, SRST routers ensure that call processing is preserved in case of WAN link failure. The voice traffic travels via the IP WAN and falls back to the PSTN if not enough bandwidth is available across the WAN link, by using the Automated Alternate Routing (AAR) feature available in the CallManager.

You can avoid the oversubscription of the WAN bandwidth by using the locations-based CAC feature in the CallManager. This feature works for hub-and-spoke topologies. For example, as shown in Figure 1-16, the hub site is the headquarters and the braches are spokes. Each branch is defined as a location in CallManager, and maximum bandwidth is assigned to each location along with the codec to be used when placing calls between two locations. CallManager maintains the current state of the utilized bandwidth and checks the bandwidth availability before placing a new call to the locations.

With this deployment model, you can use the G.711 codec within the LAN. However, when placing the voice calls between the headquarters site and the branch sites or between the branch sites, you can use lower-bandwidth codecs such as G.729. The amount of bandwidth required per voice call depends on the type of codec chosen between the central and remote sites. Remote branch routers running Cisco IOS software along with the CallManager software can provide transcoding and conferencing functions locally. QoS configurations are required on the WAN links between the central site and each of the remote sites to prioritize the traffic. The traffic that requires priority includes the call-control traffic between the IP phones and the CallManager, the gateway signaling protocol (H.323, MGCP) traffic between the remote gateways and the CallManager, and the actual voice traffic.

This deployment model is cost effective and provides many benefits, such as a unified dial plan, less administrative overhead, and potential savings on communications costs as intersite calls use the IP WAN as first choice. The only limitation is that the remote sites will have limited features available if a WAN failure occurs while you are operating in the SRST mode.

Distributed Call Processing Deployment

In a distributed call-processing deployment, CallManager and applications are located at each site. Device weights and dial plan weight calculations determine the number of IP phones supported at each site.

Figure 1-17 depicts a distributed call-processing model in which headquarters and branch A IP phones are served by separate CallManager clusters and branch B is served by the Cisco CallManager Express (CME) feature that is enabled on the router. CME solution is suitable for a small branch.

Intercluster Trunks link CallManager clusters. The Cisco IOS gatekeeper ensures that only a permitted number of calls are sent across the IP WAN between the CallManager clusters. PSTN connections on the gateways route the local off-net calls from each location and serve as a backup connection to IP WAN when insufficient bandwidth is available to support additional calls.

Clustering over the IP WAN

The vital activities in any business are continuity planning and disaster recovery. Large and small disasters happen all the time. Events ranging from purely local disasters, such as flooding, fire, evacuations caused by a hazardous material spill, or a region-wide blizzard, all have potential impact on the organization's business.

The Cisco IPT solution allows organizations to build disaster recovery sites by separating the single CallManager cluster across the WAN. CallManager servers in a cluster update the configuration information via the Microsoft SQL replication process. To ensure successful SQL replication and propagation of other critical information in real time, the round-trip time (RTT) between any CallManager servers in the cluster should not exceed 40 ms. You need to satisfy many other requirements before selecting this deployment model. Refer to the Cisco document, IP Telephony Solution Reference Network Design for Cisco CallManager 4.0, at http://www.cisco.com/go/srnd.

When using the clustering over the IP WAN deployment model, deploy voice gateways, media resources, and voice mail locally at each site. Essential services such as DHCP, DNS, and TFTP that are critical for the functioning of IP phones and other IPT endpoints must also be deployed locally. This configuration avoids dependency on a single site for crucial resources.

Tip

When using centralized DHCP services, you should configure the IP address lease intervals for IPT endpoints for long periods. Otherwise, the DHCP servers are not reachable to respond to the address renewal requests made by the IPT endpoints at the branch sites during a WAN failure.

Clustering over the WAN can support two types of deployments:

Local failover deployment model

Remote failover deployment model

Local Failover Deployment Model

In this model, each site contains a primary CallManager subscriber and at least one backup subscriber. All the servers are part of the same CallManager cluster. As depicted in Figure 1-18, the headquarters has a publisher server, a DHCP and TFTP server, subscriber 1, subscriber 2, and the backup subscriber 12. Branch A houses subscriber 3, subscriber 4, and backup subscriber 34.

Remote Failover Deployment Model

In this model, shown in Figure 1-19, each site contains at least one primary CallManager subscriber and might or might not have a backup subscriber. Branch A and branch B have only primary subscribers, and the backup subscriber is not located in each site.