A logical channel is a streaming data connection between two endpoints. A logical channel, in effect, is a pipeline through the data network between two endpoints that carries streaming data.

As an analogy, a home contractor builds the water pipes in a home and constructs a pipeline between the home and the city water supply. After the pipeline connecting the city water supply and the new home has been completed, the contractor is finished. The city then supplies the water that flows through the pipeline to the new home.

In a similar fashion, CallManager directs the construction of the logical channel or “pipeline” through the data network, and the endpoints then control the data that flows through that logical channel. CallManager itself does not create the logical channels. Instead, it directs the construction of the logical channels by supplying the parameters and instructing the endpoints how to construct each logical channel and where to connect it.

When creating a logical channel, the creating entity specifies parameters that establish what kind of data is transported through that logical channel, in which direction it is transported, the size of the data stream, and so forth. All voice, video, fax, and other data streams are transported through these logical channels. Multiple logical channels can exist between any two endpoints.

The endpoints in a voice call, for example, are instructed to establish either one or two simplex (one-way) logical channels between them. One logical channel carries the voice data stream from the calling party to the called party, and the other carries the voice data stream from the called party back to the calling party. CallManager sometimes instructs an endpoint device, such as a Cisco IP Phone, to create other logical channels such as video channels between themselves and other endpoints.

In another case, endpoint devices might be instructed to create one or more logical channels between themselves and a media processing resource, such as a conference bridge or a transcoder. This mechanism is used to create conferences and to provide MOH and other similar applications.

A voice codec is either a hardware or a software entity that converts an analog audio source into a digitized data stream, and vice versa. The codec packages the digitized data into a stream of data packets, each of which contains digitized voice data and is generated or sent at regular intervals. When silence suppression is enabled, variable numbers of bytes of data per interval can be generated, and it is possible that no packets of data are generated during silence. The interval at which codecs create and send data packets depends on the configuration of the packet sizes for each codec. You can set these configuration parameters through the Service Parameters page in Cisco CallManager Administration (Service > Service Parameters > select a server > Cisco CallManager). Table 5-1 defines the service parameters for controlling codec packet generation and their possible values in milliseconds.

Codecs normally exist in endpoint devices such as IP phones, gateways, and media processing devices. The codec in a given IP phone converts the caller’s voice from analog audio into a stream of data packets referred to as a voice data stream or a media stream. This stream of data packets is then routed to the other endpoint through a logical channel that has previously been established.

Different voice codecs are available and each codec follows a specific algorithm to convert analog voice into digital data. CallManager supports several different voice codec types, including the following:

Each of these codecs produces a different set of digital data. G.723, G.729a, and GSM are classified as low-bandwidth codecs, and G.711 and wideband are considered high-bandwidth codecs. G.722 and G.728 are normally used in conjunction with video streams. Table 5-2 lists some common voice codecs used in the packet-switched world and describes the amount of bandwidth each consumes. G.722 and G.726 have multiple entries in Table 5-2 because these codec algorithms can be used at various bitrates. The bandwidths CallManager uses are listed in the table, and depending on the bandwidth in use, the codec will adapt.

The most popular voice coding standards for telephony and packet voice include the following:

A video codec is an entity that converts an analog video source into a digitized data stream, and vice versa. It is usually implemented on specialized hardware containing digital signal processors (DSP) and other support hardware. The codec packages the digitized data into a stream of data packets, each of which contains digitized video data and is generated or sent at regular intervals.

Video codecs normally exist in endpoint devices such as IP phones, H.323 video endpoints, conference servers, and other video-enabled devices. The codec in a given device converts the caller’s video from analog video into a compressed stream of data packets of a specific format supported by that codec, and referred to generically as a video data stream or a media stream. This stream of data packets is then routed to the other endpoint through a logical channel that has previously been established.

Different video codecs exist, with each codec following a specific algorithm to convert video into digital data. CallManager supports video codec types H.261, H.263, and H.264. Each of these codecs implements a video standard and produces a different set of digital data. They are used for different purposes.

Some of the more popular video standards that CallManager supports and their usages are as follows:

Silence suppression is the capability to suppress or reduce the RTP packet flow on the network when silence is detected during a phone call. Silence suppression may also be called voice activity detection (VAD). When enabled, endpoints, such as Cisco IP Phones or gateways, detect periods of silence or pauses in voice activity and either stop sending normal RTP packets or reduce the number of packets sent during these pauses in a phone conversation. This reduces the number of RTP packets on the network and, thus, bandwidth consumed during the call.

To mask the silence suppression, the endpoint can play comfort noise. Comfort noise is also called white noise or background noise and is meant to make the user feel more comfortable that the call is still active while audio is being suppressed. Without comfort noise, the user might hear total silence. Some endpoints are capable of generating pink noise, which is background noise that resembles the background sounds from the current call.

Three service parameters control silence suppression, as shown in Table 5-3.

If users complain about the silence during a phone call or the comfort noise generated to replace it, you can disable silence suppression by setting the CallManager service parameters to False, and the calls will sound more natural. However, the calls will consume more bandwidth.

An IP phone in CallManager refers to a telephone device that contains, among other things, a digital signal processor (DSP), and another processor chip such as an ARM Risc processor. An IP phone can be plugged directly into an Ethernet port and looks like a standard network device to the network. An IP phone has an IP address, a Media Access Control (MAC) address, and is capable of using Dynamic Host Configuration Protocol (DHCP) and other standard network facilities.

During a call that is connected between two IP phones, each IP phone uses its codec (DSP) to create its own outgoing voice data stream. The voice data stream is sent through a logical channel to the other IP phone or other device to which it is connected. The IP phones also use their codecs (DSPs) to process the incoming voice data stream from the other IP phone or other endpoint device.

CallManager instructs each of the two IP phones to create a Transmit Logical Channel and a Receive Port between itself and the other IP phone in the call. The Transmit Logical Channel of one IP phone is connected to the Receive Port of the other IP phone.

Some IP phones can use their DSPs as a small conference bridge capable of supporting up to three participants. This capability is used by the barge feature.

If both endpoints in a call support video, CallManager can also instruct each of the two endpoints to create video channels between them.

A media termination point (MTP) is a software-based or hardware-based media processing resource that accepts two full-duplex stream connections. It bridges the media streams between the two connections and allows the streaming connections to be set up and torn down independently. An MTP might also be used to perform other processing on a media stream, such as digit detection and insertion (as defined in RFC 2833).

To transcode is to convert a voice data stream from one codec type to another codec type. For example, transcoding G.729a to G.711 means to convert the G.729a data stream produced by one codec into a G.711 data stream consumed by another codec. Transcoding might also be used to change the sampling rate between two streams produced by the same type of codec.

A transcoder is a hardware-based device that takes the output stream of one codec and converts it in real time (transcodes it) into an input stream for a different codec type. In addition, a transcoder also provides the capabilities of an MTP and can be used to enable supplementary services for H.323 endpoints when required.

The term call leg is used when referring to a call signaling connection between two entities. In CallManager, the term refers to a call signaling connection between CallManager and an endpoint device. In a standard call (one that does not involve any media processing devices) between two IP phones, for example, there are two call legs: one between the originating IP phone and CallManager, and the other between CallManager and the destination IP phone.

This chapter does not discuss call legs because media connections are made point to point between two endpoints. They do not follow the call legs in that there are no media connections established between CallManager and the endpoints in a call. The MCL establishes all media connections, and it is not aware of the call signaling connections being processed in the Call Control Layer of CallManager.

A Unicast conference bridge is a device that accepts multiple connections for a given conference. It can accept any number of connections for a given conference, up to the maximum number of participants allowed for a single conference on that device. There is a one-to-one correspondence between full-duplex media streams connected to a conference and participants connected to the conference. The conference bridge mixes the input streams together and creates a unique output stream for each connected party. The output stream for a given party is usually the composite of the input streams from all connected parties minus their own input stream. Some conference bridges mix only the three loudest talkers on the conference and distribute that composite stream to each participant (minus their own input stream if they were one of the talkers).

A Unicast conference server supports more than one conference bridge and is either hardware-based or software-based. CallManager allocates a conference bridge from a conference server that is registered with the cluster. Both hardware-based and software-based conference servers can be registered with CallManager at the same time, and CallManager can allocate and use conference bridges from both of them. Hardware-based and software-based conference servers have different capabilities. Some hardware-based conference servers can conference streams from different codecs together, although other hardware-based conference servers cannot. A software conference server is only able to conference streams from G.711 and wideband codecs.

Some station devices also have a DSP capable of supporting a small three-party G.711 conference. This conference bridge is allocated and used by the barge feature. CallManager knows about the station-based conference bridges, but it allocates the station-based bridge only when processing a barge request that is targeted for that station device. To use the station-based conference bridge in a barge operation, the Barge softkey must be used.

For features used to set up conferences such as Ad Hoc or Meet-Me conferences or Join, CallManager always allocates system-based conference resources. CallManager does not distinguish between the types of system-based conference bridges when a conference-allocation request is processed. CallManager cannot specifically allocate a hardware conference bridge or a software conference bridge or a videoconference bridge directly. It simply allocates a conference bridge from the pool of conference resources available to the device for which the conference bridge is being allocated.

You have control over the types of conference resources that are in the pool of resources available to a particular device. The section “Controlling the Allocation and Usage of Media Resources” covers this in detail. If you know that a particular endpoint, such as a gateway, normally needs a hardware conference bridge to take advantage of its mixed-stream conferencing capabilities, you could configure CallManager so that the gateway only has access to hardware conference resources. The same applies to video-capable endpoints or any particular group of devices that would normally need a particular resource type. You could also configure the device, or set of devices, so that it has access to software conference resources only after all hardware conference resources have been allocated, or any other arrangement that seems appropriate.

CallManager allocates a Unicast conference bridge when a user presses the Confrn, MeetMe, Join, or cBarge softkey on the phone. If no conference resources are available to that phone when the user presses the softkey, the request is ignored and no conference or barge is started. Unicast conference bridges can be used for both Ad Hoc and Meet-Me conferences.

An MTP is an entity that accepts two full-duplex stream connections. The streaming data received from the input stream on one connection is passed to the output stream on the other connection, and vice versa. In addition, software-based MTPs transcode A-law to μ-law, and vice versa, and adjust packet sizes as required by the two connections. Hardware-based MTPs (transcoders) can also transcode data streams between two different codec types when needed. Some MTPs have the additional capability of supporting Dual-Tone Multi-Frequency (DTMF) detection and generation for SIP calls as specified in RFC 2833.

Figure 5-2 illustrates the connections to and usage of an MTP. MTPs are used to extend supplementary services to SIP endpoints and H.323 endpoints that do not support empty capability sets. When needed, an MTP is allocated and connected into a call on behalf of these endpoints. When the MTP is inserted, the media streams are connected between the MTP and the SIP or H.323 device and are not torn down for the duration of the call. The media streams connected to the other side of the MTP can be connected and torn down as needed to implement features such as hold, transfer, and so forth. There are both hardware-and software-based MTPs. Hardware MTPs are really transcoders being used as MTPs.

Figure 5-2. MTP

MOH resources are provided by software-based MOH servers that register with CallManager as MOH servers. MOH servers are configured through CallManager Administration, as are the other media processing devices.

Up to 51 different audio sources can be configured on the MOH servers. All MOH servers in the cluster have the same MOH source configuration. This allows CallManager to connect a held device to any MOH server in the cluster, and it receives the same audio source stream regardless of which server provides it.

A given IP phone can be connected to any available MOH output stream port, and the MOH server will connect the requested audio source to the output stream port where the IP phone is connected. The MOH server can have up to 50 different source files on its disk for each codec type that it supports, and when a particular source is requested, it streams the audio data from the source file through the designated output stream port. It is possible to connect all MOH output stream ports to the same audio source.

One fixed source is always identified as source 51. Source 51 is connected to a fixed source, usually a sound card, in the server. Any sound source that can be attached to the sound card can then provide the audio stream for source 51.

Each MOH server can supply up to 500 Unicast output audio streams or up to 204 Multicast audio streams. It can supply both stream types simultaneously, but the total stream count including both types cannot exceed the maximum. The number of streams that can be supported by a given server depends on such things as the speed of the server and which other services are running on that server. These maximum stream counts can only be achieved using high-end dedicated servers. In most cases, Cisco recommends configuring the servers with a smaller stream count. If the server has a security agent installed (even if it is deactivated) the maximum stream counts are normally about half the maximum values that would normally be supported by that server. You need to consider these factors along with server capabilities and the network infrastructure when configuring MOH servers.

When generating Multicast streams, each Multicast output stream requires a different audio source stream. Each audio source can supply an audio stream for each of the four different codecs that are supported. Thus, you can have up to 204 Multicast streams. If a single codec is used then a maximum of 51 Multicast sources can be used. The number 204 comes from 51 audio sources times 4 codecs each.

Annunciator resources are provided by software-based servers that register with CallManager as annunciator servers. Annunciator servers are configured through CallManager Administration, as are the other media processing devices. Each annunciator can supply up to 400 simultaneous streams of either tones or announcements. Tones and announcements are considered the same as far as the annunciator is concerned.

All annunciators in the cluster have the same audio files. This allows CallManager to allocate an annunciator from any server that is available to play either a tone or an announcement. Annunciators can be connected to IP phones, gateways, MTPs, conference bridges, and other devices to inject either audio announcements or tones as required.

Announcements can be localized, allowing them to be used in different countries and locales. When a locale is installed on CallManager, the announcements and tones are associated with that locale. Two types of locales are installed on CallManager:

Tones are installed as part of a network locale such as China or Taiwan, and announcements are installed as part of a user locale such as “Chinese (China)” or “Chinese (Taiwan).” Figure 5-3 illustrates a cluster of two CallManagers with media resources.

All resources are accessible by both CM1 and CM2

Figure 5-3. A Cluster of Two CallManagers with Media Resources

In Figure 5-3, a complement of media processing resources is registered with each of the CallManager nodes. Figure 5-3 illustrates that there can be both hardware-based media resources and software-based media resources in the same cluster and on the same CallManager node. All resources are available to both CallManager nodes, regardless of which one they are registered with.

Cisco IP Phones have an internal DSP that acts as a small conference bridge. This capability is referred to as a built-in bridge. The capability is used only to support the barge feature as described in Chapter 3. It can only support a maximum of three parties, including the phone itself as one of them. During barge operation (which is really a small three-party conference), this bridge supports only the G.711 codec. The built-in bridges are handled automatically by CallManager, and are not visible in the resource pools.

Software-based resources generally provide fewer processing-intensive features than do their hardware counterparts. Table 5-4 shows you recommendations based on various goals.

All media processing resources currently register and communicate with CallManager using the Skinny Client Control Protocol (SCCP). All Cisco IP Phones also use this protocol. Media processing resources do not use most of the protocol elements of SCCP. Media devices in general use some of the registration elements and the media control elements from this protocol.

The Media Control Layer (MCL) is a layer of software within CallManager that controls all media streaming connections between endpoints or devices in the CallManager system. The MCL directs the construction of the logical channels through the network for each call that is processed by CallManager.

This chapter does not discuss the elements that compose the underlying data network. It discusses only the logical connections made between the devices and endpoints that compose the CallManager system. All signaling and data streams are carried through an IP data network, and it is assumed for purposes of this discussion that the MCL can make all TCP/IP or UDP connections requested, and that the underlying network can carry all the voice, video, and other traffic as needed.

Users of the system are directly or indirectly aware of the endpoints in the call. For this discussion, consider the physical devices to be the endpoints in a call, and not the actual persons involved. Thus, if you pick up your phone and call another person, consider your phone as the originating endpoint of the call, and the called person’s phone as the terminating endpoint of the call. Think of the voice and/or video streams as being created by your phone, traveling through the network, and being terminated by the called phone. You, a user, are aware of these two endpoints, because you directly used them by picking up one and dialing the other. The streaming data connections between endpoints might be for audio channels, video channels, or some combination. This section discusses audio and video connections and processing.

Audio Channel Processing in CallManager

Figure 5-4 depicts the signaling and streaming connections made between two audio endpoints (in this case, Cisco IP Phones and CallManager). MCL directs the phones to open two logical channels, one in each direction between the two phones.

Figure 5-4. Calls Between Two Audio Endpoints

In some cases, it is not as simple as it seems at first glance. If the called party does not have an IP phone that is on the CallManager system directly, such as when you call home from your IP phone at the office, even though you can think of your voice traveling from your IP phone directly to the phone at home, in fact there are other endpoints or devices in the call as far as CallManager is concerned. In this case, the endpoints in the call are really your IP phone as the originating endpoint and a VoIP gateway as the terminating endpoint. The gateway connects directly to the Public Switched Telephone Network (PSTN), and the PSTN then carries the voice the remainder of the way. In this case, you are only indirectly aware of the endpoints. Figure 5-5 depicts that scenario.

Figure 5-5. Call Between a Cisco IP Phone and a Non-IP Phone

Figure 5-5 depicts the signaling and streaming connections made between two endpoints (in this case, a Cisco IP Phone and an IP gateway). The MCL directs the IP phone and the IP gateway to open two logical channels, one each direction between the IP phone and the IP gateway.

All endpoints are not apparent to the users of the system. Sometimes the MCL inserts media processing entities into the voice data stream path without the user’s knowledge. MTPs and transcoders are examples of these devices.

Figure 5-6 depicts the signaling and streaming connections made between three endpoints (in this case, two Cisco IP Phones and a transcoder). MCL instructs IP Phone A and Transcoder A to create two logical channels between themselves. It also instructs Transcoder A and IP Phone B to create two logical channels between themselves, making a total of four logical channels. The IP phones are not aware of the transcoder, and each phone believes that it has established a connection with another phone in the network. The two phones are logically connected, but the actual connections run through a transcoder.

Figure 5-6. Calls Between Two Cisco IP Phones Using a Transcoder

Some devices, such as conference bridges, are inserted at the user’s request, and the user has indirect knowledge and control of their insertion. The control is indirect because the user cannot select the specific conference bridge to insert, but can indirectly select a conference bridge by pressing the Confrn softkey on the phone. No audio data travels between endpoints in the CallManager system without the MCL first instructing the endpoints involved in the call to establish media connections between them.

Video Channel Processing in CallManager

In contrast to audio channels, video channels are usually more directly controlled by the end users. A call can complete without video channels being established, but a call will never complete without audio channels. If you are using video, you are usually either directly or indirectly aware of video processing resources.

Video differs in many respects from audio. One of the differences is that the video streams created by and associated with a given call might not terminate on the same device as the voice streams. If the called party does not have a video phone that is on the CallManager system directly, but has a video-enabled endpoint such as Cisco VT Advantage, the voice streams are connected to the IP phone, and the video streams are connected to the associated PC.

On the other hand, if both endpoints are video endpoints, both the video and audio streams are connected directly to the endpoints. When you make a call from a video-enabled endpoint to an endpoint that does not support video, such as when you call home from your video-enabled IP phone at the office, your voice travels from your IP phone to a gateway that connects directly to the PSTN, and the PSTN then carries the voice the remainder of the way. In this case, the PSTN cannot carry video data, so the gateway is not video-enabled, and the call is connected without creating video channels.

Figure 5-7 depicts the signaling and streaming connections made between two video endpoints (in this case, two video-enabled IP Phones using Cisco VT Advantage). The MCL directs the IP Phone and the associated PCs to open two voice logical channels, one in each direction between the two IP Phones, and two video logical channels, one in each direction between the associated PCs. The respective cameras are connected to the video logical channels and pass video data directly between the PCs. The voice channels are connected normally, and voice data passes directly between the IP Phones.

Figure 5-7. Call Between Video-Enabled Cisco IP Phones Using VT Advantage

You do not do anything different when you make a video call than when you make a normal voice-only call. CallManager automatically understands when a video connection can be established, and automatically sets up the video and tears it down as appropriate. If you transfer a video call to a voice-only endpoint, the video is automatically terminated. Conversely if you call from your video-enabled IP Phone to a video endpoint and the video has been disabled, no video channels are established. If the called party then enables video, CallManager immediately attempts to establish a video connection between the endpoints.

Videoconferencing connections are similar to voice-conferencing connections in that the voice and video streams are directed through logical channels to a video conference bridge where the streams are mixed appropriately and mixed streams are generated for each endpoint in the conference and sent to their respective endpoints. As a user, you might be directly or indirectly aware of a conference bridge depending on the type of conference involved. Video conference bridges also support audio conferences and mixed audio and video conferences. In some cases, you might dial into a video bridge directly for a Meet-Me conference so you are directly aware of this bridge.

In some cases, such as Ad Hoc conferences, the conference bridge is inserted at the user’s request, and users have indirect knowledge and control of their insertion in that you do not select the bridge directly. You indirectly select a conference bridge by pressing the Confrn softkey on the phone. If your phone is video-enabled, it can select a video bridge and connect a video conference if one is available.

No audio or video data travels between CallManager controlled endpoints in the CallManager system without the MCL first instructing the endpoints involved in the call to establish appropriate media connections between them. This enables the MCL to tear them down again at the end of the call or whenever it is appropriate.

When allocating a media processing resource, it is important to be able to select which resource or set of resources can be used by a particular endpoint. If you have a geographically dispersed network, such as one that covers both Dallas and San Jose, and you have gateways in both Dallas and San Jose to handle local calls, it becomes very important where the media processing devices inserted into a call are physically located on the network. If CallManager inserts a media resource that is physically located in Dallas into a San Jose local call, the voice data for that call streams from the IP phone in San Jose to a media resource in Dallas and back to the gateway in San Jose, before going out over the PSTN for the local call. This is a very inefficient use of bandwidth and resources.

Because all media resources that are registered with CallManager are available to all CallManager nodes within the cluster, any CallManager node in the cluster can select and insert any available resource into a call, no matter where the device physically resides or the CallManager node to which it is registered. You have complete flexibility to configure the system any way you choose. You can associate media processing resources with endpoints so that if an endpoint requires a media resource such as a conference bridge, CallManager knows which set of conference bridge resources are available to that endpoint.

If CallManager is configured correctly, and you are making a local call from an IP phone in San Jose that requires a media resource, CallManager controlling the call selects a media resource from a pool of local resources in San Jose.

In the absence of any configuration defined in CallManager Administration, all media resource devices are available to any endpoint in the system. The resources are used in the order that they were read from the database, and no attempt is made to associate a media processing resource with any particular endpoint. This arrangement is usually fine for small installations in a single location. If the system is large or geographically dispersed, you will probably need to control media resource allocation.

Built-in bridges are mini conference bridges within the IP Phones themselves, and appear as separate allocatable devices that are attached to or part of a specific IP Phone. You can enable the built-in bridge associated with a given IP Phone through CallManager Administration. Built-in bridges are currently used only by the barge feature. When a barge feature requests a conference bridge, it specifically requests the built-in bridge for a specified target device in the allocation request. If the built-in bridge for that device is enabled, the MRM allocates it and returns it as the conference bridge selected. If the built-in bridge requested is not available, the barge function will not work.

Allocation of the built-in bridge is not discussed in the remainder of this chapter because it applies only to the barge feature. A built-in bridge is allocated upon specific request for that particular device. It cannot be used as a general conference resource.

This section discusses media resource groups (MRG), media resource group lists (MRGL), and how they are used to control the allocation and usage of media processing resources. It also explains the algorithms used during the resource allocation process. The main topics are as follows:

Media Resource Group Definition

All media processing resources belong to at least one MRG. An MRG is essentially a list of media processing resources that are made available as a group. If a media processing resource is not explicitly assigned to an MRG, it belongs to the Null MRG.

The Null MRG is the default MRG that exists even when no MRGs have been explicitly created through CallManager Administration. When CallManager is first installed, the default configuration includes only the Null MRG and does not have any MRGLs defined. All media processing devices that register with a CallManager node are therefore assigned to the Null MRG by default. After MRGs have been created through CallManager Administration, media processing devices can be assigned to them. The Null MRG does not appear in CallManager Administration.

An MRG can contain one or more media processing resources of the same type. The same media processing resource can be a member of as many MRGs as are necessary to achieve the desired configuration. The types of media processing resources are as follows:

• Conference bridge

• MTP

• Transcoder

• MOH server

• Annunciator server

An MRG can contain one or more types of media processing resources. You can specify media processing resources of different types in any order, because their order is not a primary concern in the MRG.

Figure 5-8 illustrates the resources in the Null MRG. The grouping illustrated is a logical grouping and is not visible in CallManager Administration. When multiple resources of the same type are in an MRG, they are grouped together. This figure shows devices of each type and how they are grouped within the Null MRG. Notice that the MTP group includes both MTPs and transcoders. The conference resources contain hardware-based and software-based audio conference resources as well as video conference resources. These resources are allocated in the order that they appear in the list.

Figure 5-8. Resources in the Null MRG

Resource allocation from the Null MRG on either CM1 or CM2 is as follows:

• Conference allocation—. When a conference is needed by the phones on CM1, they get a software conference resource, or a hardware conference resource, or a video conference resource. This continues until there are no more conference resources.

• MTP allocation—. Either a transcoder or an MTP is allocated when an MTP is requested.

• Transcoder allocation—. Only transcoders are allocated when a transcoder is requested.

• MOH allocation—. Both MOH servers are used, and the load is spread across both of them.

• Annunciator—. Both annunciators are used and the load is spread across both of them.

Media Resource Group List Definition

After an MRG is created, you can add it to an MRGL. An MRGL is an ordered list of MRGs. An MRGL can have one or more MRGs in its list. When you create an MRGL, if it contains more than one MRG, specify the list in priority order. The list is searched from first to last when looking for an available media processing resource. When looking for a resource of a specific type, all resources of that type that are available in the first MRG from the list are allocated before any resources of that type are used from the second and subsequent MRGs in the list.

Figure 5-9 illustrates some characteristics of both MRGs and MRGLs. The same devices exist in more than one MRG, and the Music MRG exists in more than one MRGL. With this arrangement, the IP Phones on CM1 get media resources in a different order than the IP Phones on CM2. Video-enabled IP Phones get both a different set of resources and a different order than the IP Phones on either CallManager.

Figure 5-9. Media Resource Group and List Structures

Resource allocation for IP Phones on CM1 (assigned to MRGL 2) is as follows:

• Conference allocation—. The phones on CM1 get a software conference resource or a hardware conference resource or a video conference resource. All conference resources in the cluster are allocated as a single pool of resources, and no distinction is made between them.

• MTP allocation—. All MTPs and transcoders in the cluster are allocated as a single pool of resources. There is no distinction made between them.

• Transcoder allocation—. Only transcoders are allocated when a transcoder is requested.

• MOH allocation—. Both MOH servers are used, and the load is spread across both of them.

• Annunciator allocation—. Both annunciator servers are used, and the load is spread across both of them.

Resource allocation for IP Phones on CM2 (assigned to MRGL 1) is as follows:

• Conference allocation—. The phones on CM2 always get a software conference bridge until there are no more software conference resources in the cluster. Then they get hardware conference resources or video conferences resources until software resources are available again. Software resources always have priority over hardware conference resources and video conference resources. There is no priority given to hardware conference resources over video conference resources. Both hardware and video resources are allocated as a pool of resources.

• MTP Allocation—. Software MTPs are allocated until there are no more software MTPs. Transcoders are allocated only when there are no software MTPs available. Software MTPs always have priority over transcoders.

• Transcoder allocation—. Only transcoders are allocated when a transcoder is requested.

• MOH allocation—. Both MOH servers are used, and the load is balanced across both of them.

• Annunciator allocation—. All annunciators are allocated from annunciator server 1. Annunciator server 2 is not available to phones on CM2.

Resource allocation for video-enabled IP Phones on CM1 or CM2 is the same, and is as follows:

• Conference allocation—. The video-enabled IP Phones on both CM1 and CM2 always allocate a video conference bridge if one is available. Then they get hardware conference resources until video conference resources are available again. Video resources always have priority over hardware conference resources.

• MTP allocation—. When an MTP is requested, transcoders are allocated until there are no more transcoders available. Software MTPs are then allocated until a transcoder becomes available. Transcoders always have priority over software MTPs.

• Transcoder allocation—. Only transcoders are allocated when a transcoder is requested.

• MOH allocation—. Both MOH servers are used, and the load is balanced across both of them.

• Annunciator allocation—. All annunciators are allocated from annunciator server 2. Annunciator server 1 is not available to video-enabled IP Phones.

Selecting a Resource Within an MRG

Resources within an MRG are organized so that all resources of each given type are in a list together in the order presented in the MRG. In other words, it contains a set of lists, one for each type of resource that is present in that MRG.

This algorithm performs the following steps:

1. Find the resource list for the type of resource requested.

2. When the list is found, allocate the next available resource using a next-available algorithm on the list. The next-available allocation begins at the point in the list where the previous allocation request ended and looks for the next resource in the list that is available.

3. If an available resource is found, allocate it and return it to the requestor. If one is not found, notify the MRM that one is not available in this MRG.

Figure 5-10 illustrates the allocation order within an MRG. All resources are contained in the MRG. For calls that require a transcoder, the allocation order is illustrated. Note that they are allocated in next-available fashion.

Figure 5-10. Allocation Order Within an MRG for a Transcoder Request

Allocating a resource is accomplished by finding a device in the list that appears to have resources available. The device control process maintains the resource status for each device, so the MRM sends an allocation request to the device control process and attempts to allocate a resource. If one is available and the device status is good, a resource is allocated and returned to the MRM. If one is not available or the device status is bad (not available), the MRM is notified that no resource is available on that device. Figures 5-11, 5-12, and 5-13 illustrate this.

Figure 5-11. Normal Resource Allocation Sequence

Figure 5-12. Device Is Not Registered or Out of Service

Figure 5-13. Device Controller Has No Resources Available

Figure 5-11 shows the order of processing for resource allocation. The MRM gets a device name from the MRG and then sends a device look up request to the device manager. The device manager responds with the location of the device controller, whereupon the MRM sends an Allocation Request to the device controller. If the device controller has available resources, it responds with a Resource Allocation Response message, which is then returned to the requestor.

Figure 5-12 shows the allocation sequence when the first device is not registered. The MRM selects another device from the MRG and makes another request to the device manager. The sequence then proceeds normally.

Figure 5-13 shows the sequence when the device controller has no resources available for the device. In this case, the MRM must select another device from the MRG, request the location of the device controller, and then ask that device controller whether it has a resource. The device controller responds with a Resource Allocation Response, and the Resource Allocation Response is returned to the requestor.

When the MRM has exhausted the list of devices in the MRG and subsequently in the MRGL, it notifies the requestor that no resources of the requested type are available.

Tip

If you want the processing load for a given resource type spread across several media resource servers, put all media resource servers of a given type in the same MRG. Within a single MRG, a resource of a given type is allocated in a next-available fashion. This does not guarantee that it will spread the load evenly, but it will spread the load. If you want to force CallManager to allocate resources from the same server until no more resources are available on that server, you must put each resource server of the same type in a separate MRG, and organize the MRGs in the MRGL in the order that you want the resource servers used.

Organizing Resource Allocation Using MRGs and MRGLs

The resource allocation tools provided allow a great deal of flexibility in determining how CallManager allocates media processing resources. Several different arrangements are shown in this section. This is not an exhaustive set, but perhaps it is enough to spark some ideas and to help you understand how MRGs and MRGLs can be used effectively.

Figure 5-14 illustrates a possible arrangement of media resources within a CallManager cluster. In this example, different departments are homed on separate CallManager nodes. This arrangement forces phones in Sales to use resources from the Sales group, phones in Marketing to use resources in the Marketing group, and phones in Engineering to use resources in the Engineering group. In this case, the resources are registered with the same CallManager node as the phones and gateways. See Figure 5-15 for another possible arrangement.

Figure 5-14. Media Resource Group Cluster Overview

Figure 5-15. Media Resource Group System Overview

Figure 5-15 illustrates the fact that media resources are available throughout the cluster and do not have to be registered with the same CallManager from which they are used. All IP phones and the gateway in this figure have full access to media processing resources, even though in some instances the IP phones are registered to CallManager nodes that do not have any media processing resources registered to them. This arrangement still forces the IP phones on CallManagers A or B to use only resources from MRG1. The devices on CallManager C or D can use all resources, but they use the resources from MRG2 first. When those are exhausted, they can use the resources from MRG1.

Figure 5-16 illustrates a possible arrangement for restricting access to media processing resources.

Figure 5-16. Using an MRGL to Restrict Access to Media Resources

As shown, you can assign all resources to three groups (no resources are left in the default group). Create MRGL 1 and assign the three MRGs to it. Do not assign an MRGL at the device pool level. In the phone configuration, for the phones homed on CM1, do not assign an MRGL to them. These phones cannot use any media resources when they are configured this way because there are no resources available in the Null MRG and none available at the device pool level. Assign MRGL 1 to all the other IP phones. The other IP phones have access to all the resources.

You can use the same concept to restrict any particular device or type of devices from groups of users. For example, if you want to restrict phones on CM1 from using any conference resources, create another MRGL, and add the two MRGs without the conference resources to it. Assign the MRGL without conference resources to the phones on CM1. Now they cannot access conference bridges.

You might have several conferences running on the CallManager system using combinations of different codecs in them. For example, you might have one or more G.711 conferences running at the same time as one or more G.729a conferences. You might also have one or more conferences running where different endpoints in the conference use different codecs. Calls that use different codecs require different amounts of processing power from the DSPs on the conferencing resource. CallManager has no visibility into the allocation or usage of the DSP resources on media resource devices. The G.723 codec, for example, requires more DSP CPU cycles than does G.729a or G.711. The Catalyst 6500 CMM line card with conference and transcoding port adaptor modules register 128 resources per adaptor with CallManager, which would support 128 simultaneous calls using any available codec.

The Supplementary Services Layer in CallManager implements the feature operation as seen from a user perspective. It controls the operation of the feature and processes all softkey and button presses from the user after a feature has been activated. The Supplementary Services Layer in CallManager implements all features that exist in CallManager itself. For the conferencing features, it maintains all the conference information, such as which conferences are active and who the participants are for each one. This layer of processing is the one that processes all feature requests from the phones. When the conference supplementary services receives a conference request, it either processes the request or notifies the IP phone that there are no conference resources available. The Supplementary Services Layer interfaces directly with the Call Control Layer. It can communicate with the Protocol Layer only through call control.

The Protocol Layer receives and handles the device registration. It also handles all communication with the device. This layer also handles conference bridge device failures. Device failures and the subsequent handling of active conferences are both described in the section “Call Preservation During System Failures.”

Cisco IP Phone endpoints have a DSP inside the phone that can act as a small conference bridge. This capability is used only to support the barge feature, as described in Chapter 3. As far as the MCL is concerned, the barge feature activates a small conference, so resources are allocated as conference resources.

CallManager release 4.1 can take advantage of this small conference bridge during barge operations. This capability is either enabled or disabled, and depends on how the system is configured.

The advantage of using the built-in bridge in the phone is that no system conferencing resources are in use during barge feature operation. This makes conference bridge support essentially free for the barge feature because no additional hardware is needed.

The disadvantage is that the barge feature can use only the G.711 codec. Also, when the DSP in the phone is being used as a conference bridge, it is not available to process voice streams from low-bit-rate codecs such as G.729a or G.723.

The section describes in more detail how CallManager controls and allocates conferencing resources.

Each conference device has a list of CallManager nodes with which it is allowed to register. The list is in priority order. In general, each conference device attempts to register with its primary CallManager node, which is the first node in its list. If it cannot register with that CallManager node for some reason, it attempts to register with each of the other CallManager nodes in its list, from highest priority to lowest priority, until it successfully registers with one of them. Because conference devices use the SCCP, their failover and fallback characteristics are similar to other station type devices and are not covered in detail here.

CallManager in general has a “resource-centric” view of conferencing resources that are registered with it. This view is consistent with the implementation of both the software conference bridges and the Catalyst WS-6608-T1 and WS-6608-E1 hardware modules. When dealing with standard G.711 conferences, the view is accurate and complete. In these cases, CallManager creates one conference bridge resource for each resource that is registered by these devices. It requires at least three participants to set up an Ad Hoc conference. These devices support conference sizes ranging from three up to the maximum number of resources supported by the device. This means that CallManager has complete control over the resources registered and can establish any number of conferences of varying sizes, as long as the total number of resources used in the conferences does not exceed the number of resources registered by the device. The conference sizes are, of course, limited by the maximum sizes configured through CallManager Administration.

For example: The device registers 32 resources. It does not limit the maximum number of conference participants per conference at the device level, and the maximum participants for a conference at the system level is set at 32. In this case, CallManager creates 32 conference resources to support this device, which allows CallManager to set up a maximum of 32 simultaneous conferences on this device. The device can support from 1 to 32 simultaneous conferences using the 32 resources. Some of the possible configurations that CallManager could set up are as follows:

Some DSP farms used for conference bridges, such as those available on the 26xx, 28xx, 37xx, and 38xx series gateways, are not implemented in the same manner. These devices are more “DSP-centric” in that they implement each conference on a separate DSP. This means that a single conference is limited in size to the maximum number of resources that can be processed by one DSP. In this case, even though the device might register 24 resources, for example, the largest conference it can support is six participants, because each DSP can handle a maximum of six resources. When these devices register, they also supply the optional parameter Max Resources Per Conference, which informs CallManager about this configuration. When this parameter is provided, CallManager divides the registered resource count by this parameter to compute the number of conference resources to create for that device. If the device registers 24 resources and 6 resources maximum per conference, CallManager creates four conference resources for this device.

For example, one of these devices registers 24 resources and a maximum per-conference resource limit of six. The maximum participants for a conference set through CallManager Administration is six. CallManager creates four conference bridge resources for this device, which in turn allows CallManager to create four simultaneous conferences. CallManager could then use the 24 resources to set up conferences in the following configurations:

The Cisco IP Voice Media Streaming App supports Unicast conferences and is a Cisco software application that installs on an MCS server during the CallManager installation process. In the installation, the component is called the Cisco IP Voice Media Streaming App and is common to the MTP, MOH, software Unicast conference bridge, and annunciator applications. The Cisco IP Voice Media Streaming App runs as a service under Microsoft Windows 2000.

You enable Ad Hoc or Meet-Me conferencing in CallManager by completing the following steps:

The conferencing service parameters in Table 5-6 are clusterwide parameters. The service parameters that set the size of conferences are normally set to 4. You can configure a higher number if you choose. Some conference bridge devices are limited to six participants, some to eight participants. Some of the newer bridges can support up to 64 participants in an Ad Hoc conference and 128 in a Meet-Me conference.

If you attempt to create or extend an Ad Hoc conference or to create a Meet-Me conference when the necessary conference resources are not available, the conference will not be created or extended. The behavior that the conference controller or the potential participants sees will vary depending on what conference resource is not available, and when that was determined. The following behaviors might be observed.

Performance counters are available that monitor the usage of Unicast conference resources. All performance statistics are monitored through Microsoft Windows 2000 counters. You can monitor these counters in the Real-Time Monitoring Tool (RTMT) in Cisco CallManager Serviceability. CallManager provides three sets of counters that are maintained by each CallManager node:

An MTP is inserted on behalf of H.323 endpoints, such as third-party H.323 gateways that are involved in a call, to enable supplementary services to those endpoints. An MTP is only needed when an H.323 gateway does not support empty capability sets (ECS). Supplementary services include such features as hold, transfer, conference, park, and so forth. To implement these features, the logical channels to the endpoint must be closed and reopened again. Sometimes the logical channels are opened to another endpoint that differs from the first to implement a feature such as transfer.

An MTP is inserted on behalf of SIP endpoints to enable DTMF digit detection/generation as specified in RFC 2833. MTPs also supply ringback tone to SIP clients that are being transferred by an SCCP IP phone.

Figures 5-17, 5-18, and 5-19 illustrate the streaming connections created and torn down during a consultation transfer involving an H.323 endpoint.

Figure 5-17. Call Transfer Initiation

Figure 5-18. IP Phone A Transfers Phone B to Phone C

Figure 5-19. Transfer Completion

Figure 5-17 shows the initial call from Phone B to IP Phone A. It goes through a third-party H.323 gateway that requires an MTP, so the MCL inserted an MTP into the media stream. It illustrates both the signaling and the media streaming connections.

Figure 5-18 illustrates the connections that exist after the user on IP Phone A pressed the Transf... softkey and called Phone C. Note that the media streams between the MTP and the H.323 gateway are still connected; so as far as the gateway knows, it is still connected to Phone A. The logical channels between the MTP and IP Phone A have been closed, and a new set of logical channels has been created between IP Phone A and IP Phone C. These two parties are talking to each other. After a short conversation, the user on IP Phone A presses the Transf... softkey again and completes the transfer.

Figure 5-19 shows the final signaling and streaming connections that exist when the transfer has been completed. Logical channels have been connected between IP Phone C and the MTP. As far as call control signaling layers and the users involved know, IP Phone C is connected to Phone B. The use of the MTP is transparent to the users. If the MTP had not been inserted into the call when it was required, supplementary services would not have been available on that call.

CallManager uses one of two basic methods to prevent the endpoint from tearing down the call when the media streams are closed, as follows:

If the endpoint supports empty capability sets, when CallManager wants to close the media streams it sends the device a set of capabilities that has no capabilities in it. The device, on receiving that set of capabilities, closes all logical channels, but it does not tear down the call. CallManager can now establish a connection with another device. It sends the H.323 device another capability set with appropriate capabilities in it and then opens new logical channels to the new destination. H.323 v1 endpoints do not allow empty capability sets. If an endpoint does not support empty capability sets, it is not possible to extend any features to that endpoint directly. This is because the logical channels must be closed to implement any of the supplementary services such as those mentioned. As soon as the logical channels are closed, the H.323 endpoint tears down the call, even though it has not been instructed to do so through the signaling channels. In H.323 v2, the concept of empty capability sets was implemented. If the device is using H.323 v2 or a later protocol version, it allows CallManager, for example, to send a capability set to the H.323 device, which has no capabilities specified in it (an empty capability set). When the H.323 device receives these capabilities, it closes the logical channels and waits for a new capability set. All Cisco H.323 gateways support zero capability sets and thus do not require MTPs.

Figures 5-20 through 5-22 illustrate the connections and operation of an MTP in a SIP call where a SIP phone calls an IP phone extension 1005. 1005 answers the call and then blind transfers it to extension 1006.

Figure 5-20. Initial Call from SIP Phone to Extension 1005

Figure 5-20 shows the media connections that exist when the initial call is made from the SIP client to extension 1005 and the call was answered. Figure 5-21 illustrates the state of the call after a blind transfer has been initiated. The annunciator inserts a ringback tone toward the SIP client on command using an MTP. The tone plays until extension 1006 is answered or the call terminates.

Figure 5-21. Blind Transfer Initiated

Figure 5-22 illustrates the final state of the call after extension 1006 has answered it.

Figure 5-22. Blind Transfer Completed

MTPs are also used to detect and generate DTMF tones from and to SIP clients respectively. Figure 5-23 illustrates DTMF detection between the SIP client and a MGCP gateway.

Figure 5-23. DTMF Detection from SIP Phone

MTPs detect tones by looking for tone packets in the RTP stream. If found, the MTP captures the tone packet and forwards it to CallManager, where a digit notification is then sent to the gateway. Digits are inserted by an MTP when an out-of-band digit request is received by the MTP. It is inserted as a tone packet as specified by RFC 2833.

The MCL inserts an MTP on behalf of the following:

MTPs are used in support of SIP and H.323 endpoints and are not used for any other type of endpoint. The MCL follows the steps in Figure 5-24 to determine whether an MTP is required. Figure 5-24 illustrates the processing steps in the MCL to determine whether to insert an MTP. When the MCL determines that an MTP should be inserted, it allocates an MTP resource from the resource pool specified by the MRGL associated with that device. The MCL inserts the MTP resource into the call on behalf of a SIP or H.323 endpoint. The MTP resource use is not visible to either the users of the system or the endpoint on whose behalf it was inserted.

Figure 5-24. MTP Allocation Flowchart

Transcoders are used to connect calls whose endpoints do not have a common codec. A transcoder can be used as an MTP if an endpoint in the call requires an MTP and none are available. Transcoders are allocated and inserted into a call automatically by the MCL. The use of a transcoder resource is not visible to either the users of the system or the endpoint on whose behalf the transcoder was inserted.

It is possible that the endpoint devices in the call have common codecs available, but they cannot use them because CallManager restricts their usage. Regions are commonly used to restrict the bandwidth between endpoints, which in turn limits the codecs that can be used by the two endpoints. If the region specifications require a low-bandwidth codec be used between the two endpoints, and the two endpoints do not have a common low-bandwidth codec, a transcoder will be inserted, if it is available. For example, if one endpoint supports only G.723 and the other supports only G.729a for low-bandwidth usage, a transcoder is required. Another example occurs when a call is transferred to voice mail and that voice mail system requires a G.711 input stream. If a low-bandwidth caller cannot use a G.711 codec (possibly because of region restrictions), a transcoder is inserted on behalf of the voice mail port to transcode the media stream from a low-bandwidth stream to a higher-bandwidth G.711 stream. Figure 5-25 illustrates an example of how the system is configured when transcoders are needed. Transcoders are invoked only if matching codecs do not exist at the endpoints of a call.

Figure 5-25. The Insertion of a Transcoder into a Call

CallManager looks at the codecs for each endpoint in a call and, if a transcoder is required, allocates a transcoder using the MRGL assigned to the device that is using the highest-bit-rate codec in that call. If device A calls device B and device A is using a G.711 codec while device B requires a G.729a codec, the MCL in CallManager allocates a transcoder using the MRGL assigned to device A because G.711 codec produces a higher-bit-rate data stream.

On the other hand, assume that the same call were made between the same two devices but this time device A required the G.729a codec and device B was using its G.711 codec. The MCL in CallManager would allocate a transcoder using the MRGL assigned to device B because it is using the higher-bit-rate codec.

This general rule is always followed unless region specifications force allocations to occur in a different way. CallManager attempts to minimize the size of the data stream that is sent through the network. It makes the assumption that the transcoder is close to the device for which it is allocated. Therefore, if there is a low-bandwidth link between the two endpoints in a call, such as between a branch office and a main campus, the lower-bit-rate data stream crosses the low-bandwidth link between the two sites.

CallManager always attempts to connect calls whenever it can, and then provides supplementary services, if possible. Thus, if the choice is to connect the call without supplementary services or not to connect the call at all, CallManager by default chooses to connect the call, even with diminished capabilities. You can change this behavior by setting the CallManager service parameter Fail Call If MTP Allocation Fails to True, which will cause CallManager to fail the calls. With the default setting of False, CallManager follows these rules:

As far as the MCL is concerned, a call is a connection between two parties. If the call is a conference call, for example, the MCL is not aware of the conference. To the MCL, a conference call is a series of individual calls. The fact that the second party in all of those individual calls is a conference bridge is of no particular interest to the MCL. The MCL simply makes connections between two parties as directed by call control. In the case of a conference call, the conference supplementary service is the only entity within CallManager that knows that there is a conference call being set up. In a conference call, each person connected to the conference bridge appears to the MCL as a separate call between the caller and the conference bridge. Because each party is individually connected to the conference bridge, the MCL inserts an MTP or transcoder only if one is required for that call. Thus, many MTPs or transcoders might be involved in a single conference, or none at all, depending on the requirements of each connection that is part of the conference.

The rules for inserting transcoders and MTPs apply to each individual call and can be quite complex in some instances. Provided first is a simple set of rules that will suffice for understanding how, in general, the selection is made. A more in-depth explanation follows for those interested in greater detail.

In any single call, MCL inserts a maximum of two MTPs. If a transcoder is required, normally only one transcoder is inserted in a call by a given CallManager cluster.

The MCL first obtains the capabilities of both endpoints involved in the call. The MCL does not attempt to make a connection until it has received the capabilities from both endpoints in the call.

Figure 5-26 shows the configuration where phones at a remote site call each other using G.711 both at the central office and at the remote office. The communication link between the remote site and the central campus is a low-bandwidth connection, so the calls over that link are restricted to G.723.

Figure 5-26. Intercluster Calls with Restricted Bandwidth

In this example, two transcoders are required because the region matrix forces a G.723 codec between the endpoints and the trunk devices. (The bandwidth between Region A and Region B is set to G.723, and the bandwidth between Regions C and D is set to G.723.) Within Regions A and D, the bandwidth is set to G.711. The CallManager node at the central campus inserts a transcoder between voice mail and the H.225 trunk, because the bandwidth between Region C and Region D is G.723 and voice mail does not support that codec. The CallManager node at the remote site inserts a transcoder between the phone and the H.225 trunk, because the Cisco IP Phone 7960 does not support the G.723 codec.

CallManager automatically inserts a transcoder when one is needed because of lack of a common codec between endpoints in a call. CallManager allocates a transcoder based on the capabilities of the endpoints involved in the call and the region matrix that is applicable to the respective endpoints. Table 5-10 describes MCL actions when determining whether to insert MTPs or transcoders.

H.323 devices usually do not require an MTP or transcoder, so the MCL does not allocate one unless the H.323 device has the MTP Required flag set. The Cisco H.323 gateways support all of the low-bandwidth codecs supported by Cisco IP Phones, so it usually comes down to configuring the right codec on the gateway to work with the phones. If this is not adequate because of various regions and third-party devices, you can explicitly invoke an MTP by enabling MTP Required for the gateway.

The device control process maintains device status, resource availability, and other such information about the device. It is also responsible for device registration and all communication to and from the device. When the MRM is allocating resources, it always queries the device control process for available resources once a potential device is selected.

Normally, when a device registers with a CallManager node, it has all its resources available. If the device was previously registered with a CallManager node that failed, and the MTP device had active calls at the time of the failure, the device still attempts to register with its backup CallManager node. Calls that are active on the server at the time it lost communication with its primary CallManager node are maintained in an active state. In other words, CallManager attempts to maintain all calls that are in an active state when a CallManager node fails. See the section “Call Preservation During System Failures” for more details on how calls are preserved.

You can enable MTPs and transcoders by completing the following steps:

A number of performance counters are available to monitor the usage of MTPs and transcoders. All performance statistics are monitored through Microsoft Windows 2000 counters. You can monitor these counters using the Real-Time Monitoring Tool in CallManager Serviceability. CallManager provides three sets of counters that are maintained by each CallManager node:

An MOH server is a software application that runs on a Microsoft Windows 2000 server. It is installed as a service during CallManager installation and by default is deactivated. If an MOH server is needed, the Cisco IP Voice Media Streaming App service must be activated. If the MOH server is installed on a dedicated server, it can support up to a total of 500 MOH Unicast or Multicast streaming connections between all of its audio sources. All MOH servers in a cluster have the same audio source file configuration. This means that audio source 1 provides the same audio source on all MOH servers, audio source 2 provides the same audio source on all MOH servers, and so forth. One audio source on an MOH server can support from 1 to 500 MOH output streaming connections. In other words, the users connected to all 500 MOH output streams could be listening to the same music or audio source at the same time.

MOH servers support a total of 51 audio sources, 50 of which come from audio files on the disk. One audio source, source 51, is a fixed audio source connected to a sound card. An audio source file on disk can be encoded in one of several different formats for the supported codecs. Each of those 51 sources can support both Unicast and Multicast connections at the same time, and the source can be streamed for all supported codecs simultaneously. The MOH servers support G.711 (A-law and μ-law), G.729a, and wideband audio codecs.

The IP Voice Media Streaming App implements the MOH server. The IP Voice Media Streaming App is the same application software that implements software Unicast conference bridges and MTPs. Each source stream is essentially a nailed-up conference with a fixed identifier called an audio source ID. It has a single input stream that is streaming audio data from a data source, and one or more output streams that transport the streaming data to the devices that are connected to MOH. The source stream audio source IDs range from 1 to 51, with 51 being reserved for the single fixed data source that is usually from the sound card.

Figure 5-27 illustrates phones with particular source assignments and how the MOH server handles the connections. Figure 5-27 illustrates the basic architecture of the MOH subsystem. In this drawing, it is assumed that the MOH source assignment for each phone was already determined, and it is shown below the phone. A held device can be connected to any of the 500 possible MOH output streams and receive its specified audio source. When the logical channel is connected to the MOH server, the MOH server looks at the codec type being specified and the audio source ID supplied. It then connects the correct source to the port where that logical channel was connected.

Figure 5-27. MOH Stream Connections

Note that there is a source file on the disk for each of the codec types. This means that for source 1, which is Pop music, there are four files with the same music in them, but each of them is formatted for one of the different codecs. The MOH server selects the right source file to use based on the audio source ID supplied and the codec type specified in the logical channel connection. When the held device closes the logical channel to the MOH server, the MOH server stops the stream for that port as well.

Many logical channels can receive music from the same source file at the same time. As long as one logical channel is receiving music from a given source file, the MOH server continues streaming that source file. When there are no more connections to that source file, the MOH server stops streaming that source.

MOH is configured through CallManager Administration. After an MOH server has been configured in the database, it can be added to one or more MRGs. An MOH server is a standard media processing resource. Its usage can be controlled and configured the same as any other media processing resource by using MRGs and MRGLs.

How a Stream Source Is Selected When a User Is Placed on Hold

The stream source that a given held call hears depends on how both the device that originated the hold and the device being held are configured. The device that originated the hold determines which audio source is played to the user being held, and the device that is being held determines which MOH server will be used to supply the source audio stream. Figure 5-28 illustrates these connections.

Figure 5-28. How MOH Streams Are Selected

Figure 5-28 illustrates a possible configuration of a cluster with two CallManager nodes in one location and a PSTN connection. The following examples use this configuration.

Example 1: Caller on 5000 Is Placed on Hold

Scenario: PSTN phone 5000 calls 3001 at PWI Brokerage Inc., and 3001 answers the call. 3001 places 5000 on hold.

In this example, 5000 is connected to MOH server MOH 1 because the gateway is assigned to MRGL1. MRGL1 has Hold Group 1 in its list. The caller is listening to the stream source 2 because the user hold stream for 3001 is set to stream source 2, which just happens to be a sales infomercial about new account types and services. The user on phone 5000 listens to a great sales pitch.

Example 2: Caller on 5001 Is Placed on Network Hold and then on User Hold

Scenario: PSTN phone 5001 calls 3000 at PWI Brokerage Inc. A stockbroker at 3000 answers and finds out that the caller wants to set up a new account. The stockbroker then transfers the caller to 3001 in new accounts.

When the stockbroker presses the Transf... softkey on the phone, the caller is placed on network hold. The caller then hears stream source 4, which is playing country music because the Network Hold Stream Source for 3000 is set to stream source 4, Country. The music is delivered from server MOH 1 because the gateway is assigned to MRGL1.

After a minute or two, the new account representative answers on 3001, but is extremely busy and puts the caller on 3001 on hold. Now the caller hears a nice sales pitch on all of the new accounts and services being offered. This occurs because the User Hold Stream Source for 3001 is set to stream source 2, Sales Info. The Sales Info stream is provided from MOH 1 because the gateway is assigned to MRGL1. Finally, the new account representative retrieves the call from hold and sets up the new account.

Conference is a special case for MOH. With default settings, MOH is never played directly into a conference. If a conference participant places the conference on hold, CallManager recognizes this as a special case and does not connect that held call to MOH. The conference hears silence from that participant until he or she resumes the conference call. You can change this behavior by setting the CallManager service parameter Suppress MOH to Conference Bridge to False. This causes MOH to be played into a conference when the conference is placed on hold.

All performance monitoring provided by CallManager occurs through the use of Cisco-provided objects and counters. Each Cisco object contains one or more counters. You can monitor these counters in the RTMT in CallManager Serviceability. CallManager provides two sets of counters that are maintained by each CallManager node:

All performance monitoring provided by CallManager occurs through the use of Cisco-provided objects and counters. Each Cisco object contains one or more counters. You can monitor these counters in the RTMT in CallManager Serviceability. CallManager provides three sets of counters that are maintained by each CallManager node:

The Cisco IP Voice Media Streaming App implements the annunciator server. The IP Voice Media Streaming App is the same application software that implements software Unicast conference bridges, MTPs, and the MOH servers. It registers with CallManager in the same way as an MOH server.

When the annunciator device registers with CallManager, CallManager creates a control process that maintains device status, resource availability, and other such information about the device. It is also responsible for device registration and all communication to and from the device. When the MRM is allocating resources, it always queries the device control process for available resources once a potential device is selected.

You can enable annunciators in the system by activating the Cisco IP Voice Media Streaming App. When the IP Voice Media Streaming App is activated, an annunciator device is automatically created in the CallManager database with default settings.

Upon registration, the device informs CallManager how many resources it can support. Unlike conferencing and MTP resources, annunciator devices do not preserve any stream connections in progress when any a failure occurs. All tones or announcements in progress are interrupted at the time of the failure.

If you install the annunciator device on a dedicated server, it supports up to a total of 400 simultaneous streams. Each stream plays one announcement; thus, the annunciator device can play up to 400 simultaneous announcements. All annunciator servers in a cluster have the same audio source file configuration. This means that the tone or announcement file can be obtained from any available annunciator server. The same tone or announcement can be played on all active output streams simultaneously, or any mix of announcements or tones can be played as needed.

There is a separate audio source file for each tone or announcement for each of the four supported codecs. Thus each announcement has four audio files associated with it on the annunciator server.

The annunciator servers support the same audio codecs as MTPs and MOH servers, as follows:

When an annunciator server initializes, it checks the date and timestamp for its audio source files against the values stored in the CallManager database. If the date and timestamps differ from the CallManager database values, the new audio source files will be loaded on the annunciator server. After the transfer is completed, the date and times on the annunciator server are updated for each file that was transferred.

CallManager follows the same process when the annunciator server receives a change notification for the selected audio source. If the audio source is currently being streamed and a change is noted, the new audio source is retrieved and used when the current audio source is no longer active.

A number of performance counters are available to monitor the usage of annunciators. All performance statistics are monitored through Microsoft Windows 2000 counters. You can monitor these counters in the RTMT in Cisco CallManager Serviceability. CallManager provides two sets of counters that are maintained by each CallManager node:

CallManager consists of a cluster of CallManager nodes, Cisco IP Phones, gateways that provide connections to the PSTN, and various media processing resources such as conference bridges, transcoders, MTPs, and annunciators. It can also support numerous other voice applications, such as call centers and interactive voice response (IVR) systems. Any of these entities can be involved in a call being processed by CallManager.

CallManager nodes provide call processing services and call connection control for all calls processed by a device. After a device has created media streaming connections to other devices under the direction of CallManager, the devices themselves control all aspects of the media streams and connections until directed to terminate the media streaming connections.

Each CallManager node maintains primary call state information for all calls that it controls. If a CallManager node is not involved in a given call, it has no knowledge of that call. If a CallManager node does not control a call but controls devices that are involved in the call, that CallManager node maintains only call state information relating to the devices registered to itself that are part of that call, and not the call itself. Because the various endpoint devices and media processing resources can be registered with different CallManager nodes in the cluster, the entities involved in a given call can be, and usually are, controlled by more than one CallManager node.

With the enhanced call preservation, users are generally able to continue their conversations without call processing support. This means that while the call is still active, no supplementary services are available, and the call configuration cannot be changed for the duration of the call. Hanging up will clear the call.

Call preservation involves complex processing in both CallManager and the devices that register with CallManager. Many communication links of various types are involved in calls being processed. This creates complex recovery scenarios, because any one signaling path or any combination of paths might be broken.

The failure of any given device or CallManager node creates some interesting and complex failure and recovery scenarios. This section explores some of the failure possibilities and identifies recovery algorithms used by CallManager and the devices. The following topics are covered:

In several failure cases, the signaling path for call processing is interrupted, but the media streaming connections are not necessarily affected. When a CallManager node fails, for example, the media streams between devices are not affected. It is also possible that when communication between a CallManager node and a device fails, the streaming connections between devices are not affected. In this case, a CallManager node involved in the call might have communication with other devices that are in the call. It becomes the responsibility of all CallManager nodes involved in the call to clear down the signaling paths that are related to the failure, without instructing the devices with which they still have communication to clear the call as they would in normal circumstances when the signaling path is cleared.

CallManager does not know whether the streaming connections between the devices have been interrupted. In failure conditions, it becomes the responsibility of the devices involved in a call to maintain the streaming connections that are already established. This is true even when the signaling path between the device and its CallManager node has failed.

If communication between a device and its CallManager node did not fail, it is the device’s responsibility to inform its CallManager node when the streaming connections have been closed in the same manner as they do in normal call processing.

When handling failure scenarios, CallManager attempts to accomplish the following objectives:

Endpoint and media processing devices have responsibility for and control over media connections and media streams, after the streams have been established under the direction of CallManager. Maintaining them in a failure condition is primarily the devices’ responsibility, but it also requires close cooperation with CallManager. Failures present unique and sometimes difficult situations that must be handled correctly to maintain active calls through the system.

The recognized failure cases are as follows:

The main causes for each of these failure cases are defined and some of the failure scenarios are discussed in this section.

Call Preservation Examples

The following two examples illustrate some of the complexities that exist even in these relatively simple configurations.

Example 1: Call Between Two Phones, Each Registered to a Different Node

Figure 5-29 shows a single node failure when two CallManager nodes are involved in a call.

Figure 5-29. Single Node Failure When Two CallManager Nodes Are Involved in a Call

Note that Phone A is registered to CallManager node 1 and Phone B is registered to CallManager node 2. Phone A calls Phone B, and the call is connected successfully. If CallManager node 2 fails, CallManager node 1 recognizes that signaling path B has failed, and it does a call preservation call teardown for Phone A. Signaling path C also fails, and that failure is recognized by Phone B. This leaves only signaling path A and the media streaming connections still active. No call processing support is available for the remainder of this call, but the devices can continue streaming data to each other indefinitely. The phones tear down the media streaming connections when they are placed on-hook, thus terminating the call. Phone A reports the on-hook to CallManager node 1. Phone B will then register with its backup CallManager node. If CallManager node 1 fails, the same process occurs, with the actions on the two phones being reversed.

If the signaling path B fails, each CallManager node does a call preservation teardown for its respective phone. No call processing support is available for the remainder of the call. When either phone goes on-hook, the call is terminated. Both phones report the termination to their respective CallManager nodes, and each CallManager node will release all remaining low-level resources associated with the call.

Example 2: A Conference Call

Figure 5-30 illustrates the connections that are present for a conference call that was set up by Phone A. This example explains what happens to the call in call preservation situations caused by failures of various devices and communication links. Not all of the possibilities are discussed, but enough are discussed to illustrate how call preservation works.

Figure 5-30. Call Preservation for Conference Call

Phone A sets up a conference, which includes A, B, and C. Several different scenarios could occur because of failures on this conference call. If CallManager 1 fails, signaling paths A, C, and F fail, and call processing for Phone A, who is the conference controller, is lost. The conference continues, but it cannot be extended to any other parties. When Phone A is placed on-hook, it terminates its media streaming connections to the conference bridge and registers with another CallManager node. The other participants in the conference terminate the conference normally. They are unaffected by the failure.

If CallManager 2 fails, signal paths A, B, D, and E fail, and call processing for the conference bridge and Phone B is lost. The conference can continue only if the conference bridge allows the media connections to remain active even though it cannot communicate with CallManager. No call processing functions are available on this conference call. Even though the conference controller is still active, the conference cannot be extended, because there is no communication between CallManager and the conference bridge. When Phone B is placed on-hook, it terminates its media streaming connections to the conference bridge and registers with another CallManager node. As soon as either Phone A or C hangs up, the conference terminates and the conference bridge registers with another CallManager node.

If CallManager 3 fails, signaling paths B, C, and G fail. The conference can continue, but Phone C has no call processing functions available. The conference can also be extended because the conference controller and the conference bridge are unaffected by the failure. When Phone C is placed on-hook, it terminates its media streaming connections to the conference bridge and registers with another CallManager node.

If Phone A’s network connection fails, signaling path F and the media streaming connections to Phone A are lost. This causes a normal call teardown for Phone A. The conference bridge recognizes the failure of the media streams and closes the media connections, leaving Phone B and Phone C in the conference. The conference cannot be extended because the conference controller is lost. Phone A registers with CallManager again when its network connection is restored.

If Phone B’s or Phone C’s network connection fails, signaling path E or G, respectively, and the media streaming connections to Phone B or Phone C are lost. This causes a normal call teardown for the affected phone. The conference bridge recognizes the failure of the media streams and closes the media connections to the lost phone, leaving Phone A and either Phone B or Phone C in the conference. Phone A can extend the conference, if desired, because the rest of the conference is not affected. The lost phone registers with CallManager again when its network connection is restored.

If signaling path A fails, it causes a call preservation teardown for all phones, because CallManager 1 was controlling the conference and each of the calls. Because CallManager 1 cannot talk to the conference bridge because of the signaling path failure, the entire conference goes into call preservation mode. The conference can continue without call processing support.

If signaling path B fails, it has no effect on the conference call.

If signaling path C fails, it causes a call preservation teardown for Phone C, because CallManager 1 was controlling the call from Phone C to the conference bridge, and the communication link to Phone C is lost. The conference continues, but Phone C does not have call processing support. The conference can be extended, if desired.

Combinations of failures can occur, resulting in even more complex recovery scenarios.

CallManager is a multinode system, which provides redundancy for CallManager nodes that handle all call processing. All devices are not redundant, meaning, for example, if a Cisco IP Phone fails, there is no backup phone to take over. In the case of gateways, there might be redundancy, depending on the implementation of CallManager. Call processing redundancy is implemented in CallManager by creating a cluster of CallManager nodes, some of which serve as backups for other CallManager nodes in the event of a node failure.

All devices are intelligent endpoints and are responsible for finding a CallManager node with which to register. Redundant call processing support for devices is implemented by assigning each device an ordered list of CallManager nodes with which it is to register. The list is in priority order from first to last and is referred to as the CallManager list. The device registers with the first CallManager node that is in its list and currently available. The first CallManager in its list is often referred to as its primary CallManager. During failure conditions, a device registers with the CallManager node that is highest on its list and available when its primary CallManager fails. The process of unregistering with one CallManager node and registering with a CallManager node that is lower on the list is referred to as failover. Devices reregister with a CallManager node that is higher on their list during recovery from the failure. A failure recovery occurs when the primary CallManager node or another node higher on the list returns to service, or node-to-device communications are restored. The process of unregistering with one CallManager node and registering with a CallManager node that is higher on the list is known as fallback.