Architecture and Functionality of the Media Control Layer

This section contains more detail on the devices and functions handled by the MCL. You can skip this section if you are not interested in such detail, or dive in if you really like this sort of thing. These are the major topics of discussion in this section:

• Conferencing and transcoding DSP resources
• Conference resource basic architecture
• Transcoding resource basic architecture
• MOH basic architecture
• Annunciator basic architecture
• Call preservation during system failures

Conferencing and Transcoding DSP Resources

The Communication Media Module (WS-SVC-CMM) with one or more conference and transcoding port adaptors (WS-SVC-CMM-ACT) is an example of a module that provides hardware conferencing and transcoding resources for CallManager. Videoconferencing resources are now available, too.

Note

A transcoding session is defined as one full-duplex codec translation between two different codecs. When a transcoder is used as an MTP, it also counts as one transcoding session.

The following is a partial list of gateways and switches that support transcoding resources. The currently supported devices might have changed, so you should search Cisco.com for the currently available transcoding resources.

• NM-HDV2 series of modules on the 26xx, 28xx, 37xx, 38xx gateways
• Communication Media Module (WS-SVC-CMM) line card with one or more conference and transcoding port adaptors (WS-SVC-CMM-ACT)
• Catalyst 6000 WS-X6608-T1 and Catalyst 6000 WS-X6608-E1 gateways

The following is a list of video conferencing bridges available. Again, the currently supported devices might change, so you should search Cisco.com for the currently available video bridges.

• Cisco IP/VC 3511 (video bridge)
• Cisco IP/VC 3520 (V.35/BRI H.323/H.320 gateway)
• Cisco IP/VC 3525 (PRI H.323/H.320 gateway)
• Cisco IP/VC 3540 (chassis-based bridge/gateway unit)
• Cisco VT Advantage

Limitations on Conferencing and Transcoding Resources

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.

Conference Resource Basic Architecture

This section describes the architecture of all conferencing resources in CallManager and the components that form the basis of control and operation of the conferencing subsystem. This includes the Supplementary Services Layer, the Call Control Layer, the Protocol Layer, and the Media Control Layer.

Supplementary Services Layer

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.

Protocol Layer

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

Creating and Managing Conference Bridge Resources

All conference bridge servers use SCCP to communicate with CallManager. This is true of both hardware-based conference servers and software-based servers. When a conference bridge server registers with CallManager, it provides several pieces of information needed by CallManager to communicate with the device and control conference allocation and usage on that device. The important ones for this discussion are as follows:

• Device name (conference bridge server name)
• Total number of resources (conference participants) that it can support (it takes one resource to support each conference participant)
• The number of resources that are currently active (normally set to 0)
• Number of resources (participants) that can be part of a single conference (this is an optional parameter)
• IP address of the device
• Device type

CallManager uses the device name provided at registration time to look up the device configuration information in the database. If the device is not configured in the database, the device is not allowed to register with CallManager. If the device is found in the database, it is allowed to complete registration, and CallManager creates a control process that communicates with the device and keeps track of the resources available for that device.

The device control process creates the number of conference bridge resources that the device can support using the total number of resources from the device registration message, and creates one conference bridge resource for every resource that the server supports. For instance, if a conference bridge supports 32 resources, CallManager creates 32 conference bridge resources to support this device. That means that from the CallManager perspective, it could create 32 separate conferences, each having 1 participant in it.

If the device provides the maximum number of resources that can be part of a single conference at registration time, CallManager uses that value to compute how many conference bridge resources to create. For example, if the device supports 6 conference resources or participants per conference and the device can support 24 resources total, CallManager creates 4 conference bridge resources. The control process registers the device with the Device Manager, which makes its resources available for allocation by the MRM.

Note

The number of conference bridge resources determines the number of conference bridges available on that device and, thus, the number of conferences that can be active simultaneously. Each conference bridge supports one active conference.

Also, there is a one-to-one correspondence between the number of resources a device supports and the number of conference participants it supports.

 

Built-in Bridge Support for Barge Feature

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.

Conference Resource Allocation and Control

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

Allocating a Conference Bridge Resource

The conference supplementary service allocates one conference bridge resource for each conference that it starts. The conference bridge allocation is released when the conference is terminated. When the conference supplementary service needs a conference bridge for a new conference, it allocates a conference bridge using the MRM. The MRM does not attempt to distinguish between software-based audio conference bridges, hardware-based audio conference bridges, or video conference bridges when they are being allocated. It therefore allocates the next available conference bridge following the normal media resource allocation process. The allocated bridge can be either an audio hardware-or software-based conference bridge or a video conference bridge, depending on how conferencing resources are configured for that endpoint.

Mixed-Mode Audio Conference Support

CallManager supports mixed-mode conferences, which means that a single audio conference can consist of users with different codecs, such as G.729a, G.723, and G.711 codecs, in the same conference. This is supported directly by some hardware-based conference bridges. Some hardware-based audio conference bridges automatically provide any transcoding that is required, based on the codec type of the connected participant within the transcoding capabilities of that conference bridge device.

Tip

Hardware conference bridges do not all support the same set of codecs, so when you purchase hardware and configure the system, make sure that the conference bridge devices and transcoders in your system support the codecs that are required.

Not all hardware conference bridges support mixed-mode conferences. If a conference bridge does not support mixed-mode conferences itself, CallManager allocates and inserts transcoders as required by the conference participants of a given conference. This is true for both software-based conference bridges and hardware-based conference bridges.

 

Mixed-Mode Conference Support for Catalyst 6000 Conference Bridges

Mixed-mode conferences on Catalyst 6000 WS-X6608-T1 and WS-X6608-E1 voice modules use DSPs to perform the transcoding operations for conferences. The conference mixers on the Catalyst 6000-based hardware conference bridges only mix G.711 streams and do not use a DSP for mixing. If a conference participant is using some other codec, such as a G.729a codec, the incoming stream is transcoded from G.729a to G.711 automatically before being sent to the mixer, and the output stream from the mixer is transcoded from G.711 to G.729a before being output to the conference participant. All such transcoding is handled transparently on the Catalyst 6000 voice modules.

When setting up a conference on this type of device, you are guaranteed the availability of a minimum of three conference resources. You cannot extend the conference unless additional resources are available on the device when you attempt to extend the conference.

Mixed-Mode Conference Support for Software Conference Bridges

Software conference bridges support G.711 A-law, G.711 m-law, and wideband codecs. If a software conference bridge requires mixed-mode support for any other codecs, CallManager allocates and inserts transcoders as needed to handle the transcoding operations. Software conference bridges cannot transcode for any other codec type.

When setting up a conference on this type of device, you are guaranteed the availability of a minimum of three resources. You cannot extend the conference unless additional resources are available on the device when you attempt to extend the conference.

Mixed-Mode Conference Support for Gateway Supported Conference Bridges

The 26xx, 28xx, 36xx, and 38xx with voice processing modules do not directly support mixed-mode conferences. Their conference mixers only support G.711 A-law and m-law. If mixed-mode conference support is needed when using these devices, CallManager allocates and inserts transcoders as needed.

Each conference on this device is mixed in a DSP. This limits the size of the conference to six or eight participants depending on which hardware is present, but has the advantage of guaranteeing that you can always have up to configured number of participants in each conference.

If CallManager knows that your conference is going to require more than three resources for features such as Join, where it is creating a conference from several current calls, it will request a conference bridge of sufficient size to accommodate the new conference.

If you know that a particular device is always used to set up large conferences and you want to use particular devices, such as Catalyst 6500 WS-SVC-CMM-ACT (up to 128 participants) or a software conference bridge (up to 48 conference participants), you could configure an MRGL for this device, and structure the MRGs with the appropriate devices in them in the order that you want them used. Such a setup would force the device to allocate from a resource pool that supports large conferences. (Conversely, you could construct another MRG and MRGL set with small conference resources in it and force another set of devices to use only those resources.)

Tip

Software conference bridges can support much larger conferences if they are installed on a dedicated server. Cisco does not recommend or officially support larger configurations, but CallManager and the Cisco IP Voice Media Streaming App are both capable of supporting much larger configurations. Larger configurations might stress the limits of the underlying network; so if you want to experiment with them, you should consider the network implications also. Large conferences can also affect voice quality, so you should carefully test your intended configurations.

 

Video Conference Support

Video conference bridges are set up much like audio conference bridges. Calls are initiated using the Confrn softkey or the MeetMe softkey. The IP phone reports its capabilities to CallManager when it registers, so the call is handled appropriately based on the capabilities of the devices involved in the call. A video bridge is normally capable of supporting either video or audio conferences and mixed conferences containing both audio calls and video calls.

Whether a given endpoint gets an audio conference bridge or a video conference bridge when a conference is invoked is determined solely by the MRGL to which the device is assigned.

CallManager also supports the use of H.323 video bridges, but their resources cannot be invoked using the Confrn softkey on the IP phones themselves.

Extending Existing Conferences

CallManager does not guarantee that resources will be available to extend the conference on hardware-based or software-based conference resources. It is possible to allocate a conference bridge on a device that has plenty of additional resources available to extend the conference at the time it was allocated and still have those resources all used in other conferences by the time you attempt to extend your conference. It is also possible to allocate a conference on a device that only has sufficient resources available to establish the conference. In this case, the conference cannot be extended, even though it would normally be allowed to grow. Some devices, by their implementation, guarantee that at least six participants can join any conference.

Controlling the Usage of Conference Bridge Servers

CallManager provides flexible and powerful mechanisms to control the allocation of conference bridges and other media resources. Which conference server to use when allocating a conference bridge depends first on the system configuration relating to media resource allocation, and second on which device is controlling the conference. Conference servers can be included in an MRG. MRGs are assigned to one or more MRGLs. Each device in CallManager might have an MRGL assigned to it, either by default or explicitly when the device is configured through CallManager Administration.

Note

Conference bridge servers are handled through MRGs and MRGLs the same as any other media processing resource. To understand how to configure and use MRGs and MRGLs to control conference bridge allocation, see the section "How to Control Media Resources Allocation."

Note

CallManager allocates all conference resources based on the device and directory number the conference controller is using to set up the conference. The conference controller is the one who sets up the conference.

When CallManager determines that a conference bridge is needed, it allocates a conference bridge, using the MRGL assigned to the directory number that the conference controller is using on this call. If an MRGL is not assigned to the directory number explicitly, CallManager uses the MRGL assigned to the conference controller's device. Failing that, CallManager uses the MRGL assigned to the device pool. If there is no MRGL assigned to the device pool, CallManager uses the conference servers that are available in the Null MRG. This group contains all servers that are not explicitly assigned to at least one MRG. If no conference servers are in the Null MRG, conferencing is not available for this call.

Default Configuration for Conference Servers

The initial system configuration does not have any MRGs defined. This initial configuration causes all media resource servers registered with CallManager to be in the Null MRG. It also forces all devices to use the Null MRG for all media resources allocation requests. This is the simplest configuration and makes every conference server that registers with CallManager available to all devices that are registered to CallManager. This configuration is sufficient for small- or medium-sized installations, where there is no requirement to assign media processing resources to particular groups of devices.

Device Registration and Initialization

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.

Note

The conference devices attempt to keep calls active in the event of failures. This along with their failover and fallback algorithms is covered in the section "Call Preservation During System Failures."

 

A Look at Device Registration from the Side of CallManager

You control device registration in the CallManager cluster. Every device that is allowed to register with the cluster must first be defined in the CallManager database through CallManager Administration. The only exception is when phones are configured to auto-register, which requires that you enable auto-registration. When you define media processing resources, those resources are given a name and device type. Depending on the device being defined, other parameters and information are required, such as the maximum resource count for that device. Specific configuration parameters for each device are covered in the device-specific section.

The media processing device registration sequence is as follows:

1. CallManager receives a registration request from a device, followed by a Station IP Port message that identifies the port that CallManager is to use when communicating with this device. The registration request contains the device name and the device type, among other things. CallManager then attempts to look up the device in the database using the device name. If the lookup attempt succeeds, all configuration information associated with this device is retrieved from the database, and the device is allowed to continue registering.

   See the section "Creating and Managing Conference Bridge Resources" for more details on what information is passed to CallManager on device registration.

2. CallManager sends a Register Ack message, followed by a Capabilities Request message.
3. The device sends a Capabilities Response message, followed by a KeepAlive message. The Capabilities Response message informs CallManager what codecs the device supports for incoming and outgoing media streams.
4. CallManager responds with a KeepAlive Ack, and the device registration is complete.
5. The device can send a StationMediaResourceNotificationMessage at any time following registration to inform CallManager of any changes in its resource processing capabilities, or to inform CallManager about its specific conference configuration. This message contains the following:
   • Maximum resources per conference
   • Number of resources in service
   • Number of resources out of service
6. CallManager uses the maximum number of resources per conference as the maximum size of conference participants this device supports in any one conference. The StationMediaResourceNotificationMessage is also used to decrease or increase the number of resources that the device can support at the current time (which can also change the number of resources that the device can support). This message is used whenever the device experiences an event that changes its processing capabilities, such as a nonrecoverable DSP failure, some of its resources have been allocated outside of CallManager control, the device has been reconfigured, and so forth.

After the device has been registered, all the CallManager nodes in the cluster have access to it and can allocate and use the media processing resources of that device.

Conferencing Limitations and Configuration Notes

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:

• A single conference with 32 participants
• Two conferences with 16 participants each
• Three conferences, one with 20 participants, one with 9 participants and the other with 3 participants
• Eight conferences with three participants each and two conferences with four participants each
• Ten conferences with three participants each
• Any other combination, so long as the total number of conference participants does not exceed 32

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:

• Four conferences with six participants each
• Four conferences, each having between three and six participants each
• Four conferences with three participants each
• Any other combination, as long as the total number of conferences does not exceed four and the maximum participants per conference does not exceed six

Tip

When using hardware that mixes conferences on the DSPs and the same device registration parameters as in the previous example, it is possible to use all the conference bridge resources and still have half of the resources unused, by setting up four conferences. This occurs when each conference has only three participants, which is the downside. The upside is that each conference has three more resources that are guaranteed to be available, and thus each conference can add three more participants, if desired.

 

Unicast Conference Bridge Application (Software)

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.