6.5 Transcoder Implementation

This topic describes how to implement transcoders to allow low-bandwidth codecs to be used when they are not supported by both endpoints.

  • Allows low-bandwidth codecs to be used in the IP WAN when one or both endpoints do not support low-bandwidth codecs:
    1. Affected endpoint uses high-bandwidth codec toward the transcoder
    2. Transcoder changes voice stream from high-bandwidth codec to low-bandwidth codec
    3. Low-bandwidth codec stream is sent to other device (or transcoder) over the IP WAN
  • Efficiency depends on several factors:
    1. Number of devices at remote site and likelihood of requiring a transcoder
    2. Ease of adding required hardware resources (DSPs)
    3. Available bandwidth toward central site

Transcoders are devices that transcode media streams. That is, they change the way that the audio or video payload is encoded (for instance, G.711 audio streams are changed to G.729 audio streams). Transcoders are deployed to allow the use of low-bandwidth codecs over the IP WAN, even if one of the endpoints supports only high-bandwidth codecs.

The transcoder must be physically located near the device that does not support low-bandwidth codecs. For example, a device will send a G.711 stream to the transcoder, which transcodes the audio to a low-bandwidth codec such as G.729. The G.729 voice stream is then sent from the transcoder to the other device—a phone that is located at a remote site—over the IP WAN.


It is important for the MRGL to know that the device that is limited to the higher-bandwidth codec is the one that will request the transcoder media resource. If, for example, only G.729 is permitted between two IP phones, but one IP phone supports only G.711, the phone that cannot comply with the permitted codec (G.729, in this case) is the one that requests a transcoder. Therefore, the MRGL of this phone must have access to a transcoder, which should be physically located near the requesting device. Regions must be set up so that the requesting phone is allowed to use G.711 to the transcoder because the call legs of both endpoints to the transcoder are also subject to region configuration.

Before deploying transcoders, you must consider several factors. These factors are similar to the factors that must be considered when you deploy local conference bridges:

  • Cost of adding DSPs: Is it necessary to add DSPs to an existing router only, or must the whole platform be replaced?
  • Number of phones at remote site and number of calls that are placed to G.711-only phones over the IP WAN: How many phones are located at the remote site? How often do the phones need to communicate to phones located at the headquarters that support G.711 only and hence require a transcoder when G.729 must be used over the IP WAN? How many of these calls occur at the same time?
  • Available bandwidth and cost of additional bandwidth: Is there enough bandwidth (or can additional bandwidth be provisioned) to allow G.711 for calls to devices that do not support G.729? How does the cost of adding bandwidth compare to the cost of deploying local DSPs?

Example: Implementing a Transcoder at the Main Site

The figure illustrates an example of implementing a transcoder at the main site.

G.729 audio streams are transcoded at the main site before being passed on to endpoints that support only G.711.

At the main site, there are two devices that support G.711 only. One device is a Cisco Unified Communications Manager software conference bridge; the other device is a third-party voice-mail application.

Regions are configured so that all voice traffic between the remote site and the main site must use the G.729 codec.

When a user at a remote site must be added to a conference via the software conference bridge, the user cannot be added because G.729 must be used over the IP WAN, but only G.711 is supported by the conference bridge.

By adding a transcoder resource at the main site gateway, you enable the remote site user to send a G.729 voice stream, which is transcoded to G.711 and passed on to the conference bridge by the transcoder that is located at the main site.

The same approach can be used for calls to the voicemail system from the remote site.

The figure illustrates how the solution that was described earlier in this topic is implemented in Cisco Unified Communications Manager.

All headquarters devices (phones, voicemail system, software conference bridge, and the transcoder) are in region HQ. Remote site phones are in region BR.

Cisco Unified Communications Manager region configuration allows G.711 to be used within region HQ and within region BR. Calls between regions HQ and BR are limited to G.729.

When a call is placed from a remote site phone to the voicemail system, Cisco Unified Communications Manager identifies the need for a transcoder that is based on the capabilities of the devices (G.711 only at the voicemail system) and the maximum permitted codec (G.729). A device may support only a codec with higher bandwidth requirements than permitted by the region configuration, for example. If such a device can access a transcoder, the call is set up and invokes the transcoder resource. The call would otherwise fail.

Configuration Procedure for Implementing Transcoders

This section presents the procedure for implementing transcoders.

  1. Add transcoder resource in Cisco Unified Communications Manager.
  2. Configure transcoder resource in Cisco IOS Software.
  3. Configure MRGs.
  4. Configure MRGLs.
  5. Assign MRGLs to devices.


Implementing Transcoders

To implement transcoders, perform these steps:

  1. Add a transcoder resource in Cisco Unified Communications Manager.

  1. Configure the transcoder resource in Cisco IOS Software.

  1. Configure MRGs.

  1. Configure MRGLs.

  1. Assign MRGLs to devices.