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

High-Level IPT Design

This section covers these high-level design aspects of the proposed IPT system for XYZ:

Fax and analog terminals

Voice gateways

Media resources

IPT applications

Fax and Analog Terminals

The VG248 and FXS ports on Cisco IOS routers will handle the fax needs. Three VG248s will be deployed in San Jose to provide a total of 3 x 48 = 144 analog ports to connect fax machines and provide modem access to the users. VG248 communicates with CallManager via the Skinny Client Control Protocol (SCCP).

Voice Gateways

Voice gateways connect the IPT network to the public switched telephone network (PSTN) and the PBX system. This section discusses the voice gateway modules and signaling protocols used to interface the IPT network with the PSTN and PBX system.

Access to the PSTN

Each site in the XYZ network has direct access to the PSTN. At each site, the primary path to call the PSTN is the local voice gateway. Calls between sites take the IP WAN as a first preference and are rerouted to the PSTN if the IP WAN is down or not enough bandwidth is available to route the call. Detailed call-routing requirements are discussed in the "Dial Plan Architecture" section later in this chapter.

As mentioned in Chapter 4, "Planning Phase," in the "PBX Infrastructure and Migration" section, the San Jose site has six T1 connections. At the beginning of IPT deployment in the San Jose site, only four of the T1s that are currently terminating on the PBX will be moved to voice gateways in the IPT system. The remaining two T1s will stay connected to the PBX. This is required to route the calls between the IP Phones and the phones that are on the PBX (not yet migrated to the IPT network). Table 6-1 shows the different hardware used for PSTN access and the type of PRI signaling used for the trunking.

^[1] FXS = Foreign Exchange Station

^[2] FXO = Foreign Exchange Office

Access to the PBX

The PBX system will continue to operate in the San Jose office. Table 6-2 shows the location where a PBX will remain connected to the IPT network.

Note

In both San Jose and Sydney, for redundancy and high-availability purposes, the Communication Media Module (CMM) and WS-X6608-E1 modules are deployed in two separate Catalyst 6500 chassis. Half of the trunks from the PSTN are connected to one chassis and the other half to the other chassis.

Media Resources

Media resources are the entities that provide resources for media mixing (conferencing), codec conversion (transcoding), Media Termination Point (MTP), and Music on Hold (MoH). These resources, except the transcoding, are available as both software and hardware. Transcoding requires the use of digital signal processors (DSPs), so it is available only as hardware. Every CallManager in the cluster provides conferencing, MTP, and MoH resources by default. The CallManager services that are responsible for providing these resources are Cisco IP Voice Media Streaming Application and Cisco MoH Audio Translator (used only by MoH).

Enabling these software-based resources on the CallManager consumes some part of the system resources. Hence, you need to take into account these services when you calculate device weights, discussed later in this section.

Tip

Cisco IOS gateways and Catalyst gateways provide the conferencing, transcoding, and media termination resources in hardware. If you have enough hardware equipment to provide these resources, disable these two services on the CallManager to reduce its load.

In a multisite IPT deployment, you can deploy all the media resources at a central location or use the distributed approach.

If you choose centralized deployment, for every conferencing or transcoding request, the streams from the remote sites have to traverse to the central site, which is a waste of bandwidth on the WAN link. If the requirement is to use a centralized deployment, make sure that you choose a lower-bandwidth codec to optimize the bandwidth usage on the WAN links by multiple streams.

Distributed media resource deployment conserves the bandwidth, but you might have to spend more money on the hardware. You should compare the cost of the additional hardware required to the cost of additional bandwidth on the WAN links before you make a decision on placing the media resources in the network.

Conferencing and Transcoding

The following two types of conferencing services are available in CallManager:

Ad Hoc conferencing The conference call initiator (conference controller) adds the participants to the conference call. IP Phone users press the Confrn softkey on the IP Phone to join the other participants in the existing conversation.

Meet-Me conferencing All participants are provided with a preconfigured bridge or directory number that they dial to join the conference call. Before users can invoke Meet-Me, the CallManager system administrator must configure the Meet-Me directory numbers in the CallManager as a part of the dial plan configuration and publish these numbers to all the users in the organization.

The transcoding resources convert voice streams from one compression type to another. In a multisite IPT deployment, such as XYZ's, the remote sites typically use the G.729 codec over the WAN to conserve the bandwidth, because G.729 consumes less bandwidth than G.711. Voice applications such as IVR and voice mail can stream either G.711 or G.729. In case of XYZ, these two applications are deployed at the central site to use the G.711 codec only. It is highly recommended not to enable the transcoding features on these applications even if they are available, because it consumes a lot of system resources and generates poor voice quality. Deploying the hardware-based transcoder is the best approach when a user in a remote site needs to access one of these two applications and when a transcoder will be required in the voice path to convert the audio G.729 to G.711 or vice versa.

When an IP Phone (G.729 voice stream) at a remote site connects to IVR or the Cisco Unity server, CallManager invokes the transcoder to transcode the G.729 voice stream to G.711. Chapter 7, "Voice-Mail System Design," covers the Cisco Unity design and deployment.

Two endpoints using different codecs cannot establish a two-way communication if no transcoding devices are available. You can press the i button twice on the Cisco IP Phone (7960/7940 models) during the call to see the codec used for the call. The following list summarizes the deployment of transcoding and conferencing resources for XYZ:

In San Jose, Cisco CMM provides conferencing and transcoding resources using the Ad Hoc Conferencing and Transcoding (ACT) port adapter (WS-SVC-CMM-ACT), which has four DSPs. Each ACT port adapter provides 128 channels (32 channels per DSP) for conferencing and transcoding. A single CMM can have a maximum of four ACT port adapters, providing a maximum of 512 channels. One ACT port adapter in the San Jose CMM provides the resources for transcoding and conferencing by using the partitioning technique. We will partition the ACT port adapter to use three DSPs to provide a conferencing resource pool of 96 channels and to use one DSP to provide a transcoding resource pool of 32 channels.

In Seattle and Melbourne, the Cisco 3745 router that is equipped with the NM-HDV provides support for conferencing only, by partitioning the DSP resources. The ACT port adapter in the CMM at San Jose handles all the transcoding requests for Seattle.

In Sydney, the additional E1 ports on the Catalyst 6000 Family Voice E1 (WS-6608-E1) card provide transcoding and conferencing resources. Two E1 ports provide conference resources, and two E1 ports provide transcoding.

No local conferencing and transcoding resources are deployed in Dallas or Brisbane. Users in Dallas and Brisbane use the conferencing and transcoding resources at the San Jose and Sydney central sites, respectively.

Table 6-3 shows the hardware deployed in each location for providing conferencing and transcoding resources.

Note

Cisco CMM and WS-X6608-E1 modules are deployed in two separate Catalyst 6500 chassisin San Jose and Sydneyfor redundancy and high-availability purposes. In each chassis, one port is configured as a conference bridge and one port as a hardware transcoder.

Music on Hold

Music on Hold, as the name implies, streams the predefined music from an MoH server to the caller when the caller is placed on hold. The MoH feature allows two types of hold:

End-user hold An IP Phone user presses the Hold key while on the call.

Network hold An IP Phone user attempts to transfer a call, joins a conference call, or parks the call at a call park number.

MoH supports both unicast and multicast transport mechanisms to transport the audio streams to the endpoints. Unicast MoH consists of streams sent directly from the MoH server to the endpoint requesting an MoH audio stream. With multicast, the MoH server continuously plays the audio stream. Endpoints that request a multicast MoH stream have to join the multicast IP address of the stream. This is similar to a multicast client joining a multicast group.

As discussed in the preceding section, CallManager offers MoH as a software feature. While designing the MoH feature, you need to consider the following:

Can CallManager servers provide the MoH feature in the network? Alternatively, is a dedicated MoH server needed?

How many simultaneous MoH requests are required for the planned IPT network?

Is the MoH feature required for all the sites?

Should unicast MoH or multicast MoH be used?

Before you choose an MoH model for XYZ, you need to consider some of the MoH design scenarios, described next.

Enabling the MoH feature on the CallManager consumes system resources. If you plan to enable the MoH feature on the CallManager servers in the cluster, ensure that you account for the device weights for the MoH feature when you calculate the device weights. As long as the device weights do not exceed the maximum capacity of the server, you can enable the feature on the CallManager servers. However, in larger IPT deployments, consider separating the MoH feature onto a dedicated server. For instance, you can combine DHCP, TFTP, and MoH functionality into a single server. An MoH server that is co-resident with CallManager supports 20 streams, whereas a dedicated standalone MoH server supports up to 250 streams depending on the server platform. You can install the dedicated MoH server on any approved Media Convergence Server (MCS) platforms.

The industry recommendation to calculate the number of users who will be using the Hold feature in any telephony system is approximately 1 to 2 percent of the total user base. This could be network or end-user hold. Based on the numbers that you derive by using this formula, you can choose either a co-resident or a dedicated MoH server solution.

Another approach to the MoH design is to enable MoH on the CallManager servers and monitor the MoH server performance counters (refer to "Memory Upgrades" in Chapter 9, "Operations and Optimization," for a discussion on Performance Monitor counters and monitoring procedures) to check the MoHOutOfResources performance counter for the Cisco MoH device performance object. If you see this counter going up, you can plan to add the dedicated MoH server to the network.

With multisite IPT deployment models, enabling the MoH feature for the remote branches consumes bandwidth on the WAN links. If you enable MoH, ensure that you provision the Low Latency Queueing (LLQ) for WAN links to include the additional bandwidth required for the MoH streams.

Finally, you have to consider whether you want to enable unicast, multicast, or both for MoH streams. Multicast MoH is attractive especially when streaming the audio files from the central site MoH server. Consider the scenario in which two IP Phones at the remote site place their respective callers on hold. With multicast MoH, only one stream traverses from the MoH server to the remote-site router, whereas with unicast MoH, two separate streams would go from the MoH server to each IP Phone, which consumes twice the bandwidth. In XYZ, the approach taken to deploy MoH across the network is as follows:

One CallManager in the cluster runs the MoH server, and all the central site users receive the audio streams from this MoH server via unicast.

In addition to the capability of CallManager to provide centralized MoH, the remote-site routers at Seattle and Melbourne can function as multicast MoH resources. This allows a distributed MoH design. This feature is available on the routers starting with Cisco IOS releases 12.2(15)ZJ2 and 12.3(4)T.

XYZ has no plans to deploy the MoH feature for the Dallas and Brisbane sites. A Beep/Tone on Hold is played when a user in either of these two locations is placed on hold. The Beep/Tone on Hold replaces MoH when MoH is turned off. Instead of hearing music, the user on hold will hear a beep/tone every 10 seconds (could be more or less depending on the configuration of a service parameter in CallManager)

IPT Applications

Cisco offers a wide variety of IPT applications that integrate with CallManager. Deploying these applications in the network adds functionality and, in some cases, helps to increase the overall productivity of the organization. Based on the requirements received by XYZ, it requires the following applications:

AutoAttendant (AA)

Interactive Voice Response (IVR)

Call Center

AutoAttendant

XYZ requires an application that can provide full-time AutoAttendant functionality to take every call on the first ring, present to the caller a menu of options, and provide the following three choices:

Dial by extension

Dial by name

Transfer to the operator

XYZ has a dedicated number for the AutoAttendant. Every external caller who calls this number reaches the AutoAttendant application's main menu and is provided with the preceding three choices.

Interactive Voice Response

XYZ also has a separate number to reach an IVR system. When external callers call this number, the IVR system provides the caller with the following two options:

Transfer to the AutoAttendant

Transfer to the sales and support group

Multiple Directory Handlers" section of Chapter 7 for details on implementing the AutoAttendant feature in Cisco Unity.

Call Center

XYZ needs a call center capability in the IPT network. The XYZ call center group consists of 20 personnel from the sales group and support groups, all of whom are employees of XYZ, USA. These groups are responsible for answering customer calls regarding the new sales and support of existing products.

At any given time, 20 personnel will be servicing the customers. The call center operates from 8 a.m. to 5 p.m., Monday through Friday. The proposed architecture includes a CRS/IP Contact Center (IPCC) Express solution, which is best suited for companies such as XYZ that have a small- to medium-scale call center network.

Voice Messaging

According to the proposed voice-messaging architecture for XYZ, the present Octel voice-mail system at San Jose integrates with CallManager via the Simplified Message Desk Interface (SMDI). Cisco Unity replaces the voice-mail system at Sydney. The remote locations in Australia will use the Sydney Unity voice-mail system.

Whereas Chapter 7 provides the details of the voice-messaging system design, this chapter covers the configuration and design requirements to configure the CallManager system to support the proposed voice-mail architecture.