Designing IP Telephony Solutions © 2004 Cisco Systems, Inc. All rights reserved. Designing the Network for Cisco IP Telephony ARCH v1.211-1. - презентация

1 Designing IP Telephony Solutions © 2004 Cisco Systems, Inc. All rights reserved. Designing the Network for Cisco IP Telephony ARCH v

2 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Cisco CallManager Clusters Database relationship defines the cluster. Cluster has one publisher server and n number of subscriber servers. One database on the publisher is replicated to subscribers.

3 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Intracluster Communication

4 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v CallManager Cluster Design Considerations

5 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Device Weights BHCAs = Busy Hour Call Attempts Weight BHCAs < 6 Weight BHCAs < 12 Weight BHCAs < 18 Weight BHCAs < 24 CTI Server Port 2468 CTI Client Port 2468 CTI Third Party CTI Agent CTI Route Point 2468 Transcoder MTP 3N/A H.323 Gateway 3333 H.323 Client SCCP Client 1234 MGCP 3333 Conference 3N/A

6 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Single-Site IP Telephony Model Single Cisco CallManager or Cisco CallManager cluster Maximum of 10,000 IP Phones per cluster PSTN for all external calls DSP resources for conferencing, transcoding, and MTP Voice and unified messaging components Single G.711 codec for all IP phone calls

7 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Single-Site Solution Benefits Ease of deployment A common infrastructure for a converged solution Simplified dial plan No transcoding resources, due to the use of only G.711 codecs

8 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Single-Site Best Practices Know the calling patterns for the enterprise. Use G.711 codecs for all endpoints. Use MGCP gateways for the PSTN (unless H.323 functionality is required). Implement the recommended network infrastructure for high-availability connectivity options for phones, QoS, and security.

9 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Example: Single-Site

10 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Centralized Call Processing Model Single call processing agent Maximum of 10,000 IP Phones per cluster IP WAN carries call control signaling between central site and remote sites DSP resources for conferencing, transcoding, and MTP Voice and unified messaging component

11 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Centralized Call Processing Solution Benefits Simplified management and administration No need for a specialized support staff at the remote sites Lower maintenance costs Seamless WAN connectivity of all remote sites (toll bypass savings) Unified dial plan SRST that provides basic call processing at remote sites in the event of an IP WAN failure

12 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Centralized Call Processing Best Practices Minimize delay between Cisco CallManager and remote locations to reduce cut-through voice delays. Use a hub-and-spoke topology for the sites. Limit the remote sites to the number of phones supported by the SRST feature on the branch router. Include up to four active Cisco CallManagers in the central cluster for call processing. Add Cisco CallManager clusters and connect them using intercluster trunks to support more than 500 locations.

13 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Centralized Call Processing Best Practices (Cont.) Install gateways at the central site only, at the remote sites only, or at both the central and remote sites. –Use MGCP or H.323 gateways at the central site –Use H.323 gateways at remote branches to support high availability Do not move devices between locations because Cisco CallManager tracks the bandwidth and not physical locations. If you have more than one circuit or virtual circuit in a spoke location, set the bandwidth according to the dedicated resources on the smallest link.

14 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Distributed Call Processing Model Multiple independent sites, each with its own Cisco CallManager and applications Scales to hundreds of sites No call control signaling between sites Each site can be: –Single site with its own call processing agent –Centralized call processing site and its associated remote sites –Legacy PBX with VoIP gateway

15 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Distributed Call Processing Benefits Cost savings when using the IP WAN for calls between sites Use of the IP WAN to bypass toll charges by routing calls through remote site gateways Maximum utilization of available bandwidth by allowing voice to share the IP WAN with other traffic types No loss of functionality during IP WAN failure due to call processing agent at each site Scalability to hundreds of sites

16 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Distributed Call Processing Best Practices Use a logical hub-and-spoke topology for the gatekeeper. Use HSRP gatekeeper pairs, gatekeeper clustering, and alternate gatekeeper support for high availability. Use a single WAN codec to simplify capacity planning and eliminate the need to overprovision the IP WAN. Implement call admission control with an H.323 gatekeeper (IOS gatekeeper).

17 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Call Admission Control Using a Gatekeeper

18 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Example: Distributed Call Processing

19 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Clustering over the IP WAN with Local Failover Place the Cisco CallManager subscriber and backup servers at the same site, with no WAN between them Ideal for two or three sites with 2,500 to 5,000 IP phones per site

20 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Clustering over the IP WAN with Remote Failover Deploy the backup servers over the WAN Include up to six sites with Cisco CallManager subscribers and one or two sites with Cisco CallManager backup server Supports up to 10,000 IP phones shared over the sites

21 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Clustering over the IP WAN Best Practices: Local Failover Model Configure each site to contain at least one primary Cisco CallManager subscriber and one backup subscriber. Replicate key services, all media resources, and gateways at each site. Allow 900 kbps of bandwidth for every 10,000 BHCA. Allow a maximum RTT of 40 ms between any two servers in the Cisco CallManager cluster.

22 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Clustering over the IP WAN Best Practices: Remote Failover Configure each site to contain at least one primary Cisco CallManager subscriber and an optional backup subscriber. Replicate key services, all media resources, and gateways at each site. Allow 900 kbps of bandwidth for every 10,000 BHCA. Allow additional bandwidth for signaling or control plane traffic. Allow a maximum RTT of 40 ms between any two servers in the Cisco CallManager cluster.

23 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Validating the Network Infrastructure for IP Telephony Questions to ask: What features are required for each device in the campus network? Will the physical plant in the campus support IP telephony or is an upgrade required? What features are required for each device at the enterprise edge? Are the WAN links sufficient to support IP telephony or is an upgrade required? Does the network provide the bandwidth required to support both voice and call control traffic?

24 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Layer 2 Voice Alternatives Voice over IP –VoIPovSerial (leased lines) using HDLC encapsulation –VoIPovSerial (leased lines) using MLPPP encapsulation Voice over Frame Relay Voice over ATM

25 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Bandwidth Provisioning Consider voice, video, and data Do not exceed 75 percent of the total available bandwidth for the link Provision for voice bearer traffic –Voice bearer traffic (bps) = (Packet payload + all headers in bits) * (Packet rate per second) Provision for call control traffic –Bandwidth (bps) with no TAPI traffic = 150 * (Number of IP phones and gateways in the branch) –Bandwidth (bps) with TAPI applications = 225 * (Number of IP phones and gateways in the branch)

26 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Traffic Engineering Collect the existing voice traffic data. Categorize the traffic by groups. Determine the number of physical trunks required to meet the traffic. Determine the proper mix of trunks. Convert the number of erlangs of traffic to packets or cells per second.

27 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Dial Plan Design Considerations Determine outbound and inbound call processing. For outbound calls, determine which calls are internal and external. Define transformations. Identify calling restrictions (class of service). Consider emergency responder processing. Work with an expert in developing dial plans.

28 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Network Management for IP Telephony OAM&P Traditional PBX Management –Operation –Administration –Maintenance –Provisioning FCAPS Traditional Data Management –Fault –Configuration –Accounting –Performance –Security

29 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Network Management Tools for IP Telephony

30 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v High Availability for Voice

31 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Remote Site Survivability

32 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Security for Voice Secure the Cisco CallManager. Create a voice VLAN (auxiliary VLAN). Provide the same security features as on any enterprise network. Restrict and encrypt Telnet access. Use TACACS+/RADIUS for all devices.

33 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Quality of Service Design Considerations for IP Telephony Campus environment: Where is the trust boundary? How should traffic be classified? What queuing technique will be used? Enterprise edge environment: How much bandwidth is needed? Is traffic prioritization maintained? Are any link efficiency techniques needed? Will traffic shaping be used?

34 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Recommended Device Features Campus Access Switch Campus Distribution/ Core Switch WAN Aggregation Router Branch Router Branch Switch Inline Power XX Multiple Queues XXXXX 802.1p/802.1Q XXXXX Traffic Classification XXX Traffic Reclassification XXX Traffic Shaping X Link Efficiency XX Fast Link Convergence X

35 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Summary A Cisco CallManager cluster may contain up to eight servers, of which a maximum of six provide call processing to support up to 10,000 phones. The single-site IP telephony model offers ability to use the PSTN for all off-net calls. In the LAN environment, there is sufficient bandwidth for voice traffic and the bandwidth allocations are less of a concern. In a centralized call processing system, Cisco CallManagers are centrally located at the hub or aggregation site, with no local call processing at the branch or remote office location. In the distributed call processing model, each Cisco CallManager cluster has it own set of resources and connects to the other clusters within the network via intercluster trunk links.

36 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Summary (Cont.) You may deploy a single Cisco CallManager cluster across multiple sites that are connected by an IP WAN with QoS features enabled. IP telephony places strict requirements on the network infrastructure. The network must provide sufficient bandwidth and quick convergence after network failures or changes. The network management, high availability, security, and QoS intelligent network services extend to incorporate voice-specific attributes.

37