Cisco Unified Communications Manager (CallManager)

Understanding Transcoding and Conference Bridging Using a Catalyst 6000 WS-X6608-T1/E1 Blade

Document ID: 15267

Updated: Feb 03, 2006



This document describes the capabilities (capacities) of the Transcoder (hardware MTP) and Conference Bridge applications that run on a CAT6000 WS-X6608-T1/E1 card. It specifically addresses changes in the capacities advertised for Cisco CallManager release 3.0(8). It also spells out certain packet size constraints required to achieve the stated capacity. Smaller packet sizes can reduce the capacity.



There are no specific requirements for this document.

Components Used

The information in this document is based on the software and hardware versions below.

  • Cisco CallManager 3.0(8)

  • CAT6000 WS-X6608-T1/E1 card

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.


For more information on document conventions, see the Cisco Technical Tips Conventions.

Cisco CallManager Voice Service

Among all voice services featured in a Cisco CallManager, Media Termination Point (MTP), transcoder, and conference bridge are implemented in a CAT6000 WS-X6608-T1/E1 card. Two services (MTP and transcoder) are combined in a single CAT6000 WS-X6000-T1/E1 port, and the port is defined in the Cisco CallManager Web Administration program as a "Transcoder". A different port in the same CAT6000 card can be defined as a Conference Bridge to provide the conference bridge service, and the Conference Bridge can use its built-in transcoders to add a low-bit-rate participant to a conference. Note that two existing PC software programs implement the functions of MTP and conference bridge, but they do not have built-in transcoders.


In this document, a Transcoder and an MTP port are used interchangeably to represent a CAT6000 WS-X6000-T1/E1 port to provide MTP and transcoders. A Conference Bridge is a term for a CAT6000 WS-X6000-T1/E1 port that provides conference bridge functions.

Service Platform

A CAT6000 WS-X6608-T1/E1 card has eight (8) ports in one module. Each port can be configured as a Digital Gateway, a Transcoder or a Conference Bridge. A Transcoder and Conference Bridge communicate with a Cisco CallManager using Skinny Client Control Protocol (SCCP).


A Transcoder performs two functions:

  • codec conversion

  • H323 Media Termination Point (MTP)

When two IP endpoints without common codecs want to speak to each other, a codec converter must be inserted between them to translate. The purpose of the H323 MTP is to connect two streams with incompatible signaling capability. Its origin has nothing to do with transcoding. Early H323 devices did not allow stopping (or switching) the RTP streams. Specifically, they did not support tearing down the H245 session without also tearing down the H225 link. Therefore, calls could not be placed on hold or transferred. To allow these features, H323 devices were connected to an MTP port, the other side of which was connected to an SCCP device. This allowed the CallManager to maintain the H323 connection while stopping and restarting the SCCP streams. Using the DSPs on the WS-X6008-T1/E1, the ability to transcode has now been added to the MTP application. It should be noted that H.323v2 (version 2) added capabilities to handle such stream manipulations. Devices using this newer protocol do not need to use MTP resources, and the system should be configured accordingly.

A Conference Bridge provides a conference call among a group of participants. It has built-in transcoding hardware (like the MTP port) to allow any conference party to use a low-bit-rate codec. When using the WS-X6608-T1/E1 blade, conference bridging is accomplished by summing the RTP streams in the host processor (MPC860) - not the DSPs. To do this, all streams must be G711. Each non-G711 stream must first be transcoded from its original low-bit-rate format. In the software conference bridge application (which runs on a PC), the limitation of all streams needing to be G711 still exists. If required, any transcoding must be done externally (by a different device).


Within the scope of this document, the following terms are synonymous:

  • Transcoder = a WS-X6608-T1/E1 DSP = MTP port = Hardware MTP

  • Conference Bridge = WS-X6608-T1 DSP Conference Bridge = Hardware Conference Bridge

  • Cisco CallManager 3.0 (1) = Accolade

  • Cisco CallManager 3.0 (5A) = Encore

  • Cisco CallManager 3.0 (8) = Encore Maintenance

Configuration with Cisco CallManager

Capacities Advertised when Registering a Cisco CallManager

When a Transcoder registers with a Cisco CallManager, it advertises a capacity of 24 (2-party) sessions, where a session connects an H323 party to an SCCP party (MTP) or a G711 party to a low-bit-rate party (transcode). At registration, a Conference Bridge advertises a capacity of 32 bridge participants. The Cisco CallManager Performance Monitors translate them and display, on screen, 24 transcoders and 10 conferences. (The minimum participant size for a conference is 3.)

A transcoding session is one full-duplex codec translation between a G711 voice stream and a low-bit-rate stream. An MTP call between an H323 device that uses a G711 voice stream and a SCCP device that uses G711 also counts as one transcoding session.

For contrast, the following tables summarize the history of the capacities advertised by the two applications in various Cisco CallManager releases:

Release Transcoding Sessions Advertised Total Number of G.723-G.711 Transcoding Sessions Total Number of G.729-G.711 Transcoding Sessions
3.0(1) 16 16 12
3.0(5A) 31 31 24
3.0(8) 24 24 24

Conference Bridge
Release Total Number of Participants Total Number of G.711 codecs Total number of G.723 codecs Total number of G.729 codecs
3.0(1) 16 16 16 12
3.0(5A) 32 32 32 24
3.0(8) 32 32 32 24

Transcoding Session Number Changes

In earlier releases, the Transcoding Session Advertised was 31. The number was changed to 24 for several reasons:

  • The primary use of the Transcoder is to connect streams that are incompatible because of differing codecs. Typically, a Low Bit Rate (LBR) codec must be transcoded to G711.

  • The classic Cisco-Selsius IP phones (as well as NetMeeting) used G723 as the LBR codec.

  • The WS-X6608-T1/E1 Blade supports 31 channels of G723 transcoding, so it made sense to register with this 31-stream capability.

  • Today’s IP phone, as well as the Catalyst 6000 voice blades, use G729 as the LBR codec.

  • Since the WS-X6608-T1/E1 Blade only supports 24 of these streams, it makes sense to register accordingly.

The advantage of this change is that the Transcoder does not register advertising more sessions than it can actually support in the case of G729-G711 transcoding, so the CallManager will not offer calls that a Transcoder must deny. The disadvantage is that only 24 of the classic phones (or low-bit-rate NetMeeting devices) are supported, since the CallManager will not offer additional calls once the advertised capacity limit has been reached.

Maximum Number of Participants Per Conference

For consistency and simplicity, marketing documents define the maximum number of participants per conference to be 6—the same number that the DSP resource board for the CAT4000 chassis supports. When necessary, a customer may expand the conference size by changing the Cisco CallManager Web Admin parameter—Service parameter | MaxAdHocConference to be up to 32.

Device Allocation by Cisco CallManager: Transcoder and Conference Bridge

If more than one Transcoder is available, the Cisco CallManager will allocate a transcoder session (when required) from the Transcoder with the most unused sessions. The result of this is that transcoder calls are spread fairly evenly across all Transcoders that are registered. The same methodology applies to Conference Bridges. In the Encore software stream, Transcoders and Conference Bridges register with a particular Cisco CallManager, and only that one Cisco CallManager controls the allocation of the associated resources. Therefore, the statements above pertain to multiple resources assigned to a single Cisco CallManager. A single pool of resources cannot be shared between multiple Cisco CallManagers.

A Cisco CallManager does not combine resource from two conference bridges to make a conference call.

Cisco CallManager allows a G729-G723 transcode in a Transcoder. This operation actually requires two transcode sessions—one G729-G711 and one G711-G723. In Cisco CallManager version 3.0(8), the Performance Monitor shows only a single transcoder being consumed. Originally, it was not anticipated that this functionality would work, so LBR-to-LBR (Low Bit Rate) transcoding was not documented as being supported. Consequently, this shortcoming was not classified as a "bug". When LBR-LBR support is advertised, Performance Monitor will have been fixed.

If, for any reason, sufficient resources are unavailable to provide transcoding, the Transcoder will reject a call and the Cisco CallManager will play a reorder tone to the end user.

Full Capacity with Minimum Packet Size

Due to processing power limitations of both the host CPU and the DSP, the capacities reported by the Transcoder and Conference Bridge applications during Cisco CallManager registration (in the above tables) can only be realized with a specific minimum packet size for each codec type. In other words, as the packet size decreases, more packets per second are required to transport the voice data, and the packet-processing overhead on the host processor is greatly increased. The packet size can be specified in the Cisco CallManager Web Administrator as Service Parameters:

  • PreferedG711MillesecondPacketSize = 20msec

  • PreferedG729MillesecondPacketSize = 20msec

  • PreferedG723MillesecondPacketSize = 30msec

  • SilenceSupressionSystemWide = True or False

Based on these settings (which are the configuration default values), the capacity of a WS-X6608-T1/E1 DSP port (in 3.0(8)) is:

  • Maximum conference participants in a Conference Bridge: 32

  • Total number of participants that uses G711 codecs is: 32 or less

  • Total number of participants that uses G723 codecs is: 32 or less

  • Total number of participants that uses G729 codecs is: 24 or less

  • Maximum transcoding sessions in a Transcoder: 24

  • G711-G711 MTP session: 24 (no DSP is involved)

  • G729-G729 MTP session: 24 (no DSP is involved when streaming begins, see Notes)

  • G711-G723 transcoding session: 24

  • G711-G729 transcoding session: 24

Note: G729-G723 transcoding is supported, but it should be used with care. It requires double DSP resources (for two transcoding sessions—G729-G711 and G711-G723). However, the Cisco CallManager software, at present, counts it as one ordinary transcoding session when allocating the resources. Therefore, the customer should provision extra hardware and check the resulting audio, since the processing delay caused by performing two separate translations could result in latency the user finds unacceptable.

Note: When a Transcoder is inserted between two end points that use G729 codec, a DSP resource may first be allocated and then removed when the second party is identified as the same type of G729. So a resource is required to accept the first party, but release for the second.

Note: As long as the packet size configured is greater than, or equal to, the numbers above, the capacities are valid. For example, setting PreferedG711MillesecondPacketSize to 30msec (instead of 20msec) will still yield up to 32 conference participants and up to 24 Transcoding (or MTP) sessions.

Valid Packet Sizes

The following packet sizes are valid:

  • PreferedG711MillesecondPacketSize = 10msec, 20, 30

  • PreferedG729MillesecondPacketSize = 10msec, 20, 30, 40, 50, 60

  • PreferedG723MillesecondPacketSize = 30msec, 60

Note: If a 10-millisecond packet size is used, less transcoding or bridging capacity will result. A new call may be denied or possibly only partially processed, with the possible symptom of one-way or broken audio, when most of CPU time is consumed. This will typically occur before the advertised number of transcoding sessions is reached.

Even with larger packet sizes, audio can be poor as a result of transcoding latencies, network jitter, or lost packets.


There is currently no verification procedure available for this configuration.


There is currently no specific troubleshooting information available for this configuration.

Related Information

Updated: Feb 03, 2006
Document ID: 15267