Meet-Me Conferencing

A Meet-Me conference is established by using the MeetMe softkey on the phone. The person who sets up the conference is referred to as the conference controller . Unlike in an Ad Hoc conference, the conference controller does not have complete control over who joins the conference. The Meet-Me conference controller selects one of the Meet-Me conference numbers from the range specified for the CallManager node that is controlling the call. The conference controller then establishes the conference using that Meet-Me conference number. After the conference is established, anyone who calls that particular Meet-Me conference number is immediately connected to the conference.

Meet-Me Feature Operation

Two separate operations are involved in a Meet-Me conference call:

• A user must establish a Meet-Me conference by pressing the MeetMe softkey on the phone and then dialing a Meet-Me number from a range of numbers available for that particular CallManager node.

• After the conference has been established, each conference participant places a call to that particular Meet-Me conference number and is immediately connected into the conference.

Tip

If more control is needed over who can participate in a Meet-Me conference, participants can be instructed to dial in to an operator or attendant who then transfers them to the conference number and announces their joining.

Conference Configuration

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

Table 5-6. CallManager Conferencing Service Parameters

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.

What Happens When Conference Resources Are Not Available

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 .

Out of Resources When Creating a Conference

When you attempt to create a conference and a conference bridge is not available, CallManager does not respond to the MeetMe or Confrn softkey. In other words, the softkey/button presses are ignored. The user is notified of the failure condition. Possible reasons for this condition include the following:

• The conference bridge server has not registered with CallManager yet.

• The conference bridge server failed for some reason.

• All available conference bridges in the Null MRG are in use.

• No conference bridge servers are in the Null MRG.

• All available conference servers in the MRGL assigned to the conference controller are full.

• No conference servers are in the MRGL assigned to the conference controller.

Out of Resources When Extending an Ad Hoc Conference

When a conference is already active, the conference controller attempts to add another participant to the conference, but no more resources are available for this conference, the user is left on hold, and the conference controller is joined back into the conference.

Out of Resources When Extending a Meet-Me Conference

When a Meet-Me conference is active and no more resources are available, a user dialing the Meet-Me conference number will hear reorder tone (sometimes referred to as fast busy ) and will not be connected to the conference.

Maximum Number of Participants in an Ad Hoc Conference Exceeded

When a conference already has the maximum number of participants allowed in an Ad Hoc conference and the conference controller attempts to add another participant to the conference, CallManager displays a message on the phone indicating that the conference has the maximum number of participants allowed, and the conference controller stays connected to the conference.

Maximum Number of Participants in a Meet-Me Conference Exceeded

When a Meet-Me conference is active and the maximum conference participant count has been reached, a user dialing the Meet-Me conference number will hear a reorder tone and will not be connected to the conference.

Maximum Number of Conference Bridges Supported

The maximum number of conference bridges supported by the device can differ from the number of conference resources created in CallManager. If the device does not provide the maximum number of participants that can attend a single conference, CallManager creates one resource for each resource registered. If the device supports 24 participants total and does not tell CallManager that it supports six participants per conference, for example, CallManager creates 24 conference bridge resources for that device, even though it can support only four conferences. Normally this should never happen. If it does, the device has a registration or configuration problem.

Unicast Conference Performance Statistics

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:

• Unicast conference counters per CallManager node

• Counters per software conference server from a CallManager's perspective

• Counters per hardware conference server from a CallManager's perspective

Unicast Counters per CallManager

Each of the Unicast counters is for an individual CallManager node. They represent the total for all Unicast conference servers that are registered with that CallManager node, including both software and hardware counters. Table 5-7 lists the available counters and their meaning.

Table 5-7. Unicast Conference Counters per CallManager Node

Counters per Software Conference Server from a CallManager's Perspective

Each software conference server registers with a CallManager independently, and CallManager maintains statistics about each software conference server that is registered. Table 5-8 lists the counters that are maintained for each registered software conference server.

Table 5-8. Unicast Software Conference Counters per Software Conference Server

Counters per Hardware Conference Server from a CallManager's Perspective

Each hardware conference server registers with a CallManager independently, and CallManager maintains statistics about each hardware conference server that is registered. Table 5-9 lists the counters that are maintained for each registered hardware conference server.

Table 5-9. Unicast Hardware Conference Counters per Hardware Conference Server

MTP and Transcoding Resource Basic Architecture

This section describes the architecture of transcoding resources in CallManager, including a description of the Protocol Layer, the Media Control Layer, and device registration. Although the architecture is the same in many respects as conference resource architecture, there are important differences because transcoding resources are not signaling entities and are not known by the signaling layers .

Why to Use an MTP

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 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 :

• Send the device a capability set with zero capabilities in it, and the device closes its media streaming connections

• Insert an MTP into the media stream on behalf of the endpoint so that the media streams to the device are never closed

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 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-22 illustrates the final state of the call after extension 1006 has answered it.

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.

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.

When an MTP Is Inserted

The MCL inserts an MTP on behalf of the following:

• SIP endpoints

• H.323 endpoints such as Microsoft NetMeeting clients

• H.323 gateways only if the MTP Required flag is enabled through CallManager Administration for that device

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.

Why to Use a Transcoder

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.

Determining Which Device Needs the Transcoder

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.

What Happens When Transcoders or MTPs Are Not Available When Needed

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:

• If an MTP is required for an H.323 endpoint in a given call and neither an MTP nor a transcoder (to act as an MTP) is available at that point in time, CallManager connects the call directly, and supplementary services are not available on that call.

• If an MTP is required for a SIP endpoint in a given call and an MTP is not available at that point in time, CallManager terminates the call. All SIP calls through the SIP trunk require an MTP.

• If a transcoder is required, that means that the two endpoints do not have matching codecs and cannot communicate with each other directly. In this case, CallManager attempts to connect the call, which causes the call to terminate without ever establishing a media connection.

Rules for Inserting Transcoders and MTPs When They Are Available

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.

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.

Table 5-10. Rules for Inserting MTPs and Transcoders Within a Single CallManager Cluster

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.

Device Control and Operation

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.

Device Registration and Initialization

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.

MTP and Transcoder Configuration

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

MTP and Transcoder Performance Statistics

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:

• MTP and transcoder counters per CallManager Node

• Counters per MTP device from a CallManager's perspective

• Counters per transcoder device from a CallManager's perspective

MTP and Transcoder Counters per CallManager Node

Each of the counters described in Table 5-11 is for an individual CallManager. They represent the total for all MTP and transcoder servers that are registered with that CallManager node.

Table 5-11. MTP and Transcoder Counters per CallManager Node

Counters per MTP Device from a CallManager's Perspective

Each MTP device registers with a CallManager independently, and CallManager maintains statistics about each MTP device that is registered. Table 5-12 contains the counters that are maintained for each registered MTP device.

Table 5-12. Counters per Registered MTP Device

Counters per Transcoder Device from a CallManager's Perspective

Each transcoder device registers with a CallManager independently, and CallManager maintains statistics about each transcoder device that is registered. Table 5-13 contains the counters that are maintained for each registered transcoder device.

Table 5-13. Counters per Registered Transcoder Device

Music on Hold (MOH)

For callers to hear MOH, an MOH server must be registered with the CallManager cluster. When the Cisco IP Voice Media Streaming App is activated, it creates an MOH device using default settings that support the basic MOH functionality. The MOH feature has two different aspects. The feature requires an MOH server to provide the MOH audio stream sources, and the feature also requires CallManager to be configured to use the MOH streams provided by the MOH server when a call is placed on hold. This section describes both aspects of the feature:

• Configuring MOH servers

• Configuring CallManager to use MOH

Configuring MOH Servers

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 m -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.

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.

Note

The section "Configuring Cisco CallManager to Use MOH" explains in detail how to determine the source assignment for a particular call.

MOH Server Audio Source and Audio Source ID

An audio source can be either a file or a fixed audio source. The source files must be in either G.711 A-law or m -law formats, recorded at a sampling rate of 8 kHz, G.729a, or wideband. These data sources are disk files containing audio data that has been transcoded or formatted for the particular codec type before being loaded onto the disk of the MOH server. There is a one-to-one correspondence between audio sources and audio source IDs.

The fixed data source is provided by the Windows audio input that is normally linked to the local sound card. This allows radios, CD players, or any other compatible sound source to be used. The stream from the fixed data source is transcoded in real time to support the codec that was configured through CallManager Administration. The fixed data source can be transcoded into G.711 A-law and m -law, G.729a, and wideband. This is the only data source that is transcoded in real time. G.729 will consume about 5 to 7 percent of your total CPU time in this transcoding operation.

Using the MOH Audio Translator

When you want to add a new audio source or to update an existing one, the new audio source must be transcoded and converted to the proper format, and then copied to the proper location where the TFTP server can pick it up and send it to all MOH servers when requested . The MOH Audio Translator is used to accomplish this task.

To add a new audio source to the MOH servers, copy the source file into the Audio Source Input Directory as specified by the Cisco MOH Audio Translator service parameter MOH Source Directory. The default directory path for this directory is c:\Program Files\Cisco\MOH\DropMOHAudioSourceFilesHere. Valid input files are most standard .wav and .mp3 files. It takes about 30 seconds to convert a 3-MB .mp3 file.

When the file is dropped into this directory, the Audio Translator service detects the file and automatically processes it, creating the audio source files needed for all supported codecs. The files are then moved to the output directory, along with all transcoded files that were created. The path for this directory is specified by the Cisco MOH Audio Translator service parameter Default TFTP MOH File Path. Whatever directory path is specified, \MOH will be appended to it. All transcoded files are stored in this MOH directory.

When you configure a particular audio source for a particular codec, CallManager Administration copies the files from the output MOH directory where they are stored to the TFTP file path directory. The path names used for these two directories can be changed by changing the values of the two Cisco MOH Audio Translator service parameters.

Caution

If Audio Translator is installed on the same server as CallManager and files are translated, CallManager might experience errors or slowdowns. This process consumes all available CPU cycles until it is done with the conversion. Cisco recommends that you do not install this service on a server where the CallManager service is activated and running.

Table 5-14 contains the service parameters used by the MOH servers and Audio Translator service.

Table 5-14. Service Parameters for Audio Translator and MOH Server

MOH Source Stream Play Mode

You configure the source play mode to one of two settings:

• Continuous

• One shot

CallManager is not aware of the play mode.

Continuous Play Mode

Continuous play mode causes the MOH server to stream the data from the audio source file in a loop. This means that as soon as it has streamed the file from start to finish, it immediately begins streaming from the start again. This continues for as long as this audio source is being streamed.

The MOH server keeps track of how many MOH output streams are connected to each audio source, and when the count reaches zero, the audio source streaming is stopped. The fixed audio source is always played continuously and is not stopped . If Multicast support is selected for this audio source, the audio source is played continuously, because the MOH server does not know when held devices are listening at a Multicast point.

One Shot Play Mode

One shot play mode, as it is currently implemented, is designed to support one connection at a time. It works as long as only one user is connected to a given audio source. The connected user always hears the complete audio clip from the beginning exactly one time. When the clip ends, the user hears silence until being retrieved from hold.

If any other users are connected to that audio source while the first user is still connected, they hear the clip starting wherever it was at the time the user was connected. If the clip is finished, they hear silence, just like the first caller. For example, if the first user already listened to half of the one shot audio clip when the second user was connected to the same audio source, the second user would only hear the second half of the clip, starting wherever the clip was in its playback when the user was connected. When all users are disconnected from the one shot audio source, the cycle starts again for the next user that is connected to the one shot source.

Handling MOH Stream Connections Errors

Table 5-15 shows what happens when the audio streams are not configured correctly in the system, and what will happen to the MOH stream connection if that error occurs.

Table 5-15. Stream Connection Errors

MOH Server Initialization

When an MOH server is initialized , it checks the date and timestamp for its audio source files against the values stored in the CallManager database. If they differ, the new files are obtained from the default TFTP client as specified by the Cisco IP Voice Media Streaming App service parameter Default TFTP MOH IP Address. After the transfer is completed, the date and times on the MOH server are updated for each file that was transferred.

The same process is followed when the MOH 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.

Summary of MOH Server Capabilities

The following are the current capabilities of the MOH servers:

• Supports a total of 500 one-way Unicast or Multicast audio output streams at the same time. All the output connections can be connected to one source stream or any combination of source streams. Note that a Multicast connection does not take any extra stream resources from the MOH server.

• Fifty audio source IDs, each of which is assigned to an audio source, can be specified.

• One fixed audio source (from sound card) can be used (audio source ID 51).

• An audio source can be configured to play in a continuous loop or one shot. If a source stream has the Multicast option selected, the data source is automatically played in a continuous loop, because the MOH server does not know when devices are connected to the Multicast points. The MOH server makes the assumption that someone is always connected to the MOH Multicast point. If the Multicast option is not selected, but the source stream is configured to play in a continuous loop, the music source is only played when output streams are connected to the audio source stream.

• G.711 A-law, G.711 m -law, G729a, and wideband audio codecs are supported.

• Unicast and Multicast output is supported for each audio source.

Tip

The possibility exists for the MOH server to support up to 500 output streams simultaneously. As new server hardware becomes available with faster processors, this stream count will likely increase. These are the current limits.

MOH Multicast Configuration

CallManager Administration configures each MOH server with a Multicast base address and port, and it specifies whether the port or the IP address is to be incremented to create a range of Multicast IP addresses as required. Each MOH server must be configured with a different range of Multicast addresses. This prevents multiple servers from streaming audio to the same Multicast address.

It is not necessary for all MOH servers to support Multicast streams. One server can provide all 51 streams to 51 different Multicast addresses for each enabled codec. If all codecs are enabled, you must have 204 different Multicast addresses.

Tip

It might be useful to configure two or more servers for Multicast so that if one server fails, Multicast is still available.

The MOH servers can provide each audio source as a Unicast stream and a Multicast stream. If Multicast output is desired, the Multicast check box for that source must be checked in the audio source configuration, and the MOH server must be configured for Multicast, as well.

Configuring CallManager to Use MOH

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.

Hold Types in CallManager

There are two different types of hold, as follows:

• User hold

• Network hold

User hold is invoked when a user directly places a call on hold by pressing the Hold softkey on a Cisco IP Phone. Network hold is invoked when a caller is placed on hold by some other feature, such as a transfer. The user presses the Transf... softkey on a Cisco IP Phone, and as a result, CallManager places the user on network hold until the transfer is completed.

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 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.

MOH and Conferences

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.

Configuring MOH in CallManager

Configuring and using MOH in CallManager can be very simple or very complex, depending on the requirements for your installation.

Initial MOH Configuration

MOH is disabled when CallManager is installed and the Cisco IP Voice Media Streaming App is not activated. In this configuration, CallManager plays Tone on Hold when a caller is placed on hold for any reason, if the endpoint device associated with that user is capable of generating Tone on Hold. If not, the caller hears silence.

Simplest MOH Configuration

The MOH server is installed when the Cisco IP Voice Media Streaming App is installed during the CallManager installation process. When the IP Voice Media Streaming App service is activated, it automatically installs a default sound source file, and it creates and configures an MOH device in the database. After MOH has been activated, all devices have access to MOH as soon as the MOH server registers with a CallManager node. By default, all callers hear audio source 1 from the MOH server anytime a call is placed on hold.

In this case, all devices are getting their MOH server through the Null MRG where the MOH server is declared by default because it is not part of any MRG. The Hold Stream Source defaults at the system level are set to audio source 1. This continues until you change the configuration by putting the MOH server into an MRG.

More Complex MOH Configurations

If a more complex configuration is needed, creating MRGs and MRGLs and assigning MRGLs to various devices in the system can achieve it. When you configure an MRG with an MOH server in it, you must also configure the Multicast/Unicast flag for that MRG.

The MOH User Hold Stream Source and the MOH Network Stream Source can be set to any MOH stream source that is configured on the MOH servers. If either User Hold Stream Source or Network Hold Stream Source is set to an audio source that has not yet been configured on the MOH servers, the callers will hear silence when connected to MOH.

A Multicast flag is in the MRG. If the Multicast box is not checked, Unicast streams are used for all MOH connections. If the Multicast box is checked, MOH allocation attempts try to allocate and use a Multicast stream connection. If Multicast MOH streams are not available, the held calls hear Tone on Hold, if their endpoint device supports it. Otherwise, they hear silence.

Order of Precedence of MOH Music Stream Source Assignments

MOH stream source assignments follow a defined order of precedence. When CallManager processes a hold request, it decides which MOH audio source stream to use based on the MOH stream source assignments in order of precedence, with 1 being the highest precedence. Table 5-16 defines the MOH source assignment order of precedence for both user hold and network hold.

Table 5-16. MOH Stream Source Assignment Precedence

CallManager MOH Usage and Performance Monitoring

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:

• MOH counters per CallManager

• Counters per MOH server from a CallManager's perspective

Counters per CallManager Node

Each of the following counters is for an individual CallManager node. They represent the total for all MOH servers that are registered with that CallManager node (see Table 5-17).

Table 5-17. MOH Counters per CallManager Node

Counters per MOH Server from a CallManager's Perspective

Each MOH server registers with a CallManager node independently, and CallManager maintains statistics about each MOH server that is registered. Table 5-18 lists and describes the counters that are maintained for each registered MOH server.

Table 5-18. Counters per Registered MOH Server

Video Call Processing Architecture

CallManager supports video as a normal part of call processing. If video is supported on a particular endpoint, then making a video call can be as simple as making a voice call. In fact, you do not have to do anything different when placing a video call. Locations and regions are used to control the bandwidth for video calls. Bandwidth is controlled separately for video and audio so that you can set limits on each of them independently.

When a call is attempted from an endpoint that supports video to another endpoint that also supports video, CallManager always attempts to set up both audio and video channels for the call. If CallManager cannot get the bandwidth required for the video call, it automatically retries the call as audio only. Video calls are supported for SCCP endpoints and H.323 endpoints.

CallManager Video Usage and Performance Monitoring

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:

• Video counters per CallManager node

• Video conference server counters per CallManager node

• Counters per video conference server from a CallManager's perspective

Counters per CallManager Node

Table 5-19 documents a set of counters for an individual CallManager node. They represent the total for all video calls processed by that CallManager node.

Table 5-19. Video Call Counters per CallManager Node

Table 5-20 documents the set of video conference counters for each CallManager node. The counters represent the total for all video conferences on all video conference servers that are registered with that particular CallManager node.

Table 5-20. Video Conference Server Counters per CallManager Node

Counters per Video Conference Server from a CallManager's Perspective

Each Video Conference server registers with a CallManager independently, and CallManager maintains statistics about each Video Conference server that is registered. Table 5-21 lists and describes the counters that are maintained for each registered Video Conference server.

Table 5-21. Counters per Registered Video Conference Server

Annunciator/Tone Plant Processing Architecture

The annunciator architecture is very similar to the MOH architecture. These devices are known by both the call signaling layers and the MCL. Annunciators are used in CallManager to play various pre-recorded announcements and tones to a single party, a conference, or an MTP.

When CallManager is required to play a tone such as ringback, busy, or reorder, and is unable to have this performed by the end device, the annunciator can be used to perform this function. Announcements or tones are played by connecting a one-way stream from the annunciator to the device and then directing the annunciator to play the specific tone or announcement. This scenario is encountered , for example, on some H.323 devices where the endpoint is being transferred or forwarded.

In CallManager, annunciators are used to play both tones and announcements because they are all audio files as far as the annunciator is concerned. Each announcement or tone file has a particular identifier, and the system identifies the item it wants to play by that identifier. When CallManager connects a device to the annunciator, it specifies a network locale, a user locale, and the announcement or tone identifier. This enables the annunciator to play the appropriate localized tone or announcement.

Annunciators provide specific functions for features, including the following:

• To play a ringback tone to a SIP client when the SIP client is being transferred from an IP phone.

• To play Vacant Code Announcement (VCA). "Your call cannot be completed as dialed . Please consult your directory and call again or ask your operator for assistance. This is a recording."

• To play Isolated Code Announcement (ICA). "A service disruption has prevented the completion of your call. In case of emergency call your operator. This is a recording."

• To play ringback and other tones for transfers on H.323 intercluster trunks.

• To play a busy tone based on an error generated by CTI for H.323- related calls.

• To play beginning and ending tones for monitoring sessions.

• To play audible tones at the beginning and end of recording sessions.

• To play Blocked Precedence Announcements for the MLPP feature.

• To play announcements for MLPP calls being released abnormally.

• To play ringback tone to an Ad Hoc conference when a participant is added to the conference until the participant answers the call.

To an annunciator, a tone and any other announcement is the same thing. They are all recorded audio files stored on the disk of the annunciator server. Annunciators can play an announcement only once, or play it repeatedly until CallManager tells it to stop. An annunciator can notify CallManager when an announcement has finished playing if requested to do so.

After the annunciator device has registered, CallManager allocates resources from the annunciator device as needed, and connects them, as one-way streams, to devices such as IP phones, gateways, MTPs, and conferences. When the connection is established, CallManager starts an announcement by sending a StartTone SCCP message to the annunciator. The annunciator then starts playing the specified announcement file. If requested by CallManager, the annunciator device signals CallManager when the announcement has finished. The annunciator sends this signal only when CallManager indicates that an end-of-play notification is required. If the announcement is configured as repeating and CallManager requested an end-of-play notification, the annunciator notifies CallManager each time the announcement file has been played once, and continues until the playback is stopped.

CallManager stops playback of an announcement by sending a StopTone SCCP message to the annunciator. The annunciator automatically stops playback when the streaming connection between the annunciator and the listening device terminates.

The following tones are supported for the U.S. locale:

• Line busy tone -400-450 Hz tone for 0.5 second duration with 0.5 second silent period between tones

• Alerting tone -400-450 Hz tone for 0.67 to 1.5 second duration with 3- to 5-second silent period between tones

Annunciator devices support localization, so all tones and announcements can be localized as needed. The tones are network tones and are associated with the country that CallManager serves, as defined in the network locale. Having several different locales within the same country is possible. This structure allows for multiple languages within a given country.

You can specify both the network locale and the user locale for a device. The user locale specified for a device sets the language that will be played, and the network locale sets the tones that will be played. CallManager allows you to edit the announcements as needed.

Device Control and Operation

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.

Configuring Annunciator Servers

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:

• G.711 A-law

• G.711 m -law

• G.729a

• Wideband

Annunciator Server Initialization

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.

Note

CallManager supplies U.S. English tone and announcement audio source files with the system when it is installed. You can install additional locales on the system; when you do, additional announcement files are installed on CallManager as needed to support the new locale.

Annunciator Performance Statistics

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:

• Annunciator counters per CallManager node

• Counters per annunciator server from a CallManager's perspective

Counters per CallManager Node

Each of the counters listed and described in Table 5-22 is for an individual CallManager node. The counters represent the total for all annunciator servers that are registered with that CallManager node.

Table 5-22. Annunciator Counters per CallManager Node

Counters per Annunciator Server from a CallManager's Perspective

Each annunciator server registers with a CallManager node independently, and CallManager maintains statistics about each annunciator server that is registered. Table 5-23 lists and describes the counters that are maintained for each registered annunciator server.

Table 5-23. Counters per Registered Annunciator Server

Call Preservation During System Failures

Call preservation refers to the capability of the CallManager node to maintain call connections during failure conditions on either the underlying network or the components within CallManager. This section describes the processing involved in call preservation and covers failure conditions for all major components . Call preservation is included in the media processing section because when a failure occurs, it is the media streaming that must be maintained to keep the call connected.

General Overview of Call Preservation

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.

Note

Normally without call preservation, each call that is controlled by a CallManager node that fails, or any call that involves a device that is controlled by a node that fails, would terminate immediately on the failure of any node or device involved in the call. This happens either because the other node or nodes involved in the call recognize the node or device failure and disconnect their end of the call (which ends media streaming), or because the devices themselves recognize that the CallManager node to which they are registered has failed. In that case, the device normally closes its media streaming connections and reregisters with another 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:

• Failure and recovery objectives

• Handling system and device failures

• Device recovery and call preservation algorithms

• Call preservation during device failure and recovery

Failure and Recovery Objectives

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:

• Maintain all active streaming connections that existed at the time of the failure so that no active call is interrupted

• Clear all calls that are in the call setup phase at the time of the failure and were affected by the failure

• Maintain communication with all devices that are still accessible after the failure

• Recover all devices that were registered to a failed CallManager node

• Minimize downtime for CallManager nodes and devices involved in or affected by a failure

• Maintain normal system operation as much as possible during the failure

Handling System and Device Failures

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:

• CallManager node failure

• Media processing device failure

• Endpoint device failure

• CallManager-to-device communication failure

• Node-to-node communication failure within a cluster

• Device-to-device communication failure

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

CallManager Node Failure

CallManager node failures can be caused by a CallManager software error, by a server failure, or by a network failure. If the failure is caused by a software error or a server failure, the failure causes call processing functions on that node to stop, and all communication with that node is lost.

When this failure occurs, all devices registered to that CallManager node recognize that their current CallManager node has failed. Similarly, the other CallManager nodes in the cluster detect the failure of that node. When a node failure occurs, all remaining CallManager nodes immediately execute a call preservation teardown of all calls that they are processing that involve the failed node. A call preservation teardown is the same as a normal teardown , except that all devices involved in the call are not notified that the call has been torn down, and the device control processes in CallManager for each of the devices involved in the call maintain low-level state information about the call so that they know the device is involved in a call without call signaling support. No new calls are extended to devices that are in a call preservation mode. The affected devices involved in a call maintain all active calls until the end user hangs up or the devices can determine that the media connection has been closed. No call processing features can be invoked on the preserved calls.

If the failure is caused by a network failure, call processing functions are still intact, but communications between that CallManager node and some or all of the devices registered with that node, as well as communication with other nodes in the cluster, might be lost. When communication with a node or device is lost, that device or node is treated as though it has failed.

A CallManager node recognizes that another node has failed when the TCP/IP link to the other CallManager node returns an error that indicates a link failure. If the communication link fails, the other node is considered to have failed.

A CallManager node recognizes that a device has failed in one of two ways: Either the TCP/IP link to the device returns an error that indicates the link has failed, or no KeepAlive request has been received from the device within its prescribed KeepAlive interval. Whether the device actually failed or just the link failed is not significant, because either case is treated the same.

Similarly, a device recognizes that its CallManager node has failed when CallManager fails to respond to its KeepAlive requests within the prescribed time. If the communication link has failed, the device recognizes the error when it receives an error from its TCP/IP stack that indicates the link has failed. Whether the CallManager node actually failed or only the communication link failed is not significant, because either case is treated the same.

Media Processing Device Failure

Typical media processing devices are audio conference bridges, video conference bridges, MTPs, transcoders, annunciators, and MOH servers. CallManager recognizes device failures when a KeepAlive timeout for that device occurs. The failure can be caused by a device software error, a server failure, or a network failure; to CallManager, however, it makes no difference. When a device fails for any reason, the result is a loss of communication with the device. Because all communication is lost, the device must execute its own failure and recovery algorithms. CallManager's responsibility in this case is to release its own call processing resources as appropriate without terminating the call or calls being handled by the device.

If the device truly failed, call streaming through the device also stops, and other devices involved in the call must detect the streaming failure and clear the call. The device's active CallManager node recognizes the device failure and clears call processing entities within CallManager that are associated with calls in the failed device.

If the device loses communication with CallManager while media streaming connections are active, the device assumes all responsibility for and control over all active connections and media streams. It must also find another CallManager node with which it can register. The device itself decides when and if it will register with CallManager while it has streaming connections active.

Endpoint Device Failure

Typical endpoint devices are Cisco IP Phones, other IP phones, gateways, video IP phones, and other similar devices. Device failures and loss of communication with a device are considered the same failure.

CallManager-to-Device Communication Failure

A communication failure to a device, regardless of the cause of the failure, is treated as a device failure. CallManager recognizes a device failure when a KeepAlive timeout occurs. CallManager also recognizes a device failure when the TCP/IP socket connection to the device is broken. When a device fails, all call processing resources associated with that device are released, and call signaling is cleared.

Node-to-Node Communication Failure Within a Cluster

A CallManager cluster is fully meshed between all CallManager nodes in the cluster, which means that there is a TCP/IP connection from each CallManager node to every other CallManager node in the cluster. If, for any reason, the TCP/IP link from any given CallManager node to any other CallManager node fails, the other node to which it is connected is considered to have failed. An appropriate call preservation teardown will occur for all calls associated with the failed node.

Device-to-Device Communication Failure

Device-to-device communications are usually in the form of logical channels or, in other words, media streaming connections that are carrying audio or video streaming data. When the communication path breaks, the error is detected as a media streaming error, and the CallManager node to which the device is registered is notified. Device-to-device call preservation is implemented completely in the devices, and the CallManager nodes involved in the call have little or no ability to help or influence the processing, other than making sure that CallManager does not clear the call. This allows the devices to handle processing in the best way they can and to report to CallManager when the call clears, if they are still registered.

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.

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.

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.

Recovering Devices After a Failure

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 .

Devices and Applications That Support Call Preservation

The following list of devices and applications are known to support call preservation:

• Cisco IP Phones

• Software conference bridge (service)

• MTP (service)

• Cisco hardware conference bridges

• Cisco Transcoders

• Cisco non-IOS gateways using MGCP PRI backhaul

• IOS MGCP gateways

• SRST-enabled H.323 gateways

• CallManager Attendant Console

• CTI applications (depending on the endpoint devices involved)

• VG248 gateways

Devices and Applications That Do Not Support Call Preservation

The following devices and applications do not support call preservation:

• Non-SRST-enabled H.323 devices

• Annunciators

• MOH

Call Preservation Algorithms

The next sections describe the failover and fallback algorithms used by devices that are involved in active calls at the time of a failure. These algorithms do not specify how the device should decide to failover or fallback, but rather the actions that must take place once the device has made the decision to failover or fallback.

Failover Algorithms

Two algorithms are used by devices to determine when to fail over to a CallManager node that is lower on their list. Each device that is capable of maintaining calls in failure situations is required to implement either one or both of the algorithms. If the device implements both of the algorithms, you configure the device to use the one you prefer.

Graceful Failover

This algorithm allows the device to delay failover to another CallManager node until the device stops all active streaming connections. The device determines when to terminate the streaming connections based on the disconnect supervision options supported by that device. A Cisco IP Phone, for example, terminates its streams when the user hangs up the phone, or when it detects an error in transmission to the other endpoint in the call.

If no CallManager is lower in its list and is available when the device initiates a failover attempt, the device can reregister with the primary CallManager node if it is available, or another CallManager node that is higher in its list.

If no CallManager node is available when the device initiates a failover, the device terminates the active streaming connections after attempting to locate an available CallManager node for a reasonable amount of time. It continues looking for an available CallManager node to which it can register.

Immediate Failover

This algorithm allows the device to failover immediately to a CallManager that is lower in its list. When this device registers with the new CallManager node, it tells CallManager during registration how many connections it supports and how many of them are active at the time of registration. Thereafter, the device informs CallManager each time one of the active streams is closed.

When a device initiates a failover attempt, it is possible that no backup or lower-order CallManager node is available. In this case, the device can choose to reregister with the original primary or other CallManager higher in its list. This is exactly the same as a failover with a subsequent fallback.

If no CallManager node is available when the device initiates a failover, the device terminates the active streaming connections after attempting to locate an available CallManager node for a reasonable amount of time. It continues looking for an available CallManager node to which it can register.

Fallback Algorithms

Each device implements one or more of the following fallback algorithms. If the device supports more than one fallback algorithm, you configure which algorithm it uses. Only one configuration is active at any given time. A fallback does not occur because of an error condition directly. It is a recovery operation when some or all of the failure conditions have cleared. The device, therefore, has the opportunity to choose when it will fallback to its primary CallManager. Table 5-24 documents all allowed fallback algorithms.

Table 5-24. Fallback Algorithms

Tip

The Immediate option leaves the active maintained calls connected but without call processing support for remainder of their calls. The users cannot change the configuration of their calls and do not have access to features such as hold, transfer, conference, and so forth. This option also drops any calls that are in the process of being established. Only the calls that are already connected at the time of fallback are maintained. Because there is no CallManager node failure or communication failure condition in this case, the Immediate option is the least desirable of all the algorithms, because it affects active calls and is visible to the user.

Call Attempts During Failover and Fallback

It is possible that a new call setup is initiated from the device during the failover or the fallback time frame. The call attempt is handled in the following manner.

During the process of failover or fallback, when the device is not registered with a CallManager node, any new call setup request initiated from the device is ignored until the device has completed its registration with the CallManager node.

If the configured fallback algorithm is other than Immediate, registration with a CallManager node that is higher in its list can be delayed. During this time, the current CallManager node is still the active node and is capable of processing calls.

During any fallback delay introduced by a fallback option, the device processes new call setup attempts normally until the delay condition is satisfied and fallback can be initiated.

Cisco IP Phone Unregistration Sequence Requirements

Unregister requests from Cisco IP Phones are used when the phone is registered to a CallManager node lower in its list and a CallManager node that is higher in its list returns to service. When CallManager receives an unregister request, it checks for pending calls or connections to that phone, such as held calls, transfers in progress, call park in progress, and so forth. These calls can exist in CallManager without the Cisco IP Phone having an active media connection for that call. If CallManager determines that there are pending calls for the device, CallManager returns an unregister acknowledgement with a NAK, indicating that the device is not permitted to unregister at that time.

If CallManager determines that there are no pending calls for the device, it returns an unregister acknowledgement with an ACK, indicating that the Cisco IP Phone is free to register with the higher CallManager node.

Active Connection Management in Device Modules on Device Registration

Some devices can register with a CallManager node while involved in active connections. The following sections detail requirements that CallManager must satisfy to restore active connections and manage their release during call tear down.

Hardware Conference Bridge and Transcoders

When a hardware conference bridge or transcoder registers with CallManager, it reports the number of resources that it supports and the number of resources that are currently active on that device. CallManager notes the number of active resources, and it does not make these resources available for allocation until the device notifies CallManager that the resource is no longer active. The resource is then added to the available pool.

MGCP Gateway Device Modules

On MGCP gateway registration, the CallManager node sends the Audit Endpoint message to each endpoint of each PSTN interface of the registering gateway. When the endpoint returns a connection identifier in the Audit Endpoint Response, the device control process in CallManager marks the device endpoint active. This allows the gateway to control when the resource is released and ready for use.

For each connection identifier returned in the Audit Endpoint Response, the device module that is managing the gateway interfaces in the CallManager node marks the endpoints active to allow the endpoint to control release sequence.

For interfaces that use MGCP call control signaling and support either end-user or media streaming failure disconnect supervision, CallManager sends a Request Notify command to the gateway to have the gateway report call termination events to the CallManager node. As the calls are terminated, the endpoints are made available for use again.

There are specific requirements for MGCP gateways using MGCP call control signaling. MGCP call control signaling is supported for the following interfaces and platforms:

• FXO/FXS on IOS gateways

• T1-CAS on IOS gateways

There are specific requirements for MGCP gateways using PRI-backhaul call control signaling. PRI-backhaul signaling is supported for the following interfaces and platforms:

• T1-PRI on non-IOS (Catalyst 6000 WS-X6608-T1 and DT24+ gateways) and on IOS gateways

• E1-PRI on non-IOS (Catalyst 6000 WS-X6608-E1 and DE30+ gateways) and on IOS gateways

• FXS/FXO on non-IOS gateways

• T1-CAS on Catalyst 6000 WS-C6608-T1 and Catalyst 6000 WS-C6608-E1 gateways

For each of the active connections, the device control process that is managing the gateway ports in the CallManager node sets the ports in an active call state. When working with the PRI protocol, the device control process needs the Q.931 call reference value.

During normal call setup, the CallManager node includes the Q.931 call reference value in the Call ID parameter of the Create Connection command for each connection associated with the PRI interface. The MGCP protocol provides the audit connection sequence to relay active connection information from the gateway to the CallManager node.

Media Streaming Failure Disconnect Supervision Handling

Devices that support media streaming failure disconnect supervision report media failure signals to the CallManager node on detection of the failure. If the associated call is in a preserved state, it should be cleared (from a call control perspective) toward the device. Otherwise, it is assumed that the call will be cleared through normal means.