C H A P T E R 6

Media Resources

A media resource is a software-based or hardware-based entity that performs media processing functions
on the data streams to which it is connected. Media processing functions include mixing multiple
streams to create one output stream (conferencing), passing the stream from one connection to another
(media termination point), converting the data stream from one compression type to another
(transcoding), echo cancellation, signaling, termination of a voice stream from a TDM circuit
(coding/decoding), packetization of a stream, streaming audio (annunciation), and so forth.
This chapter focuses on the following topics pertaining to media resources:
• Voice Termination Resources, page 6-1
• Conferencing, Transcoding, and MTP Resources, page 6-7
• Conferencing Guidelines and Application Scenarios, page 6-18
• Software MTP Resources, page 6-24
• Transcoding Guidelines and Application Scenarios, page 6-24
For details about Music on Hold (MoH) media resources, refer to the chapter on Music on Hold, page
7-1.

Voice Termination Resources

Voice termination applies to a call that has two call legs, one leg on a time-division multiplexing (TDM)
interface and the second leg on a Voice over IP (VoIP) connection. The TDM leg must be terminated by
hardware that performs coding/decoding and packetization of the stream. This termination function is
performed by digital signal processor (DSP) resources residing in the same hardware module, blade, or
platform. All DSP hardware on Cisco TDM gateways is capable of terminating voice streams, and
certain hardware is also capable of performing other media resource functions such as conferencing or
transcoding (see Conferencing, page 6-7 and Transcoding, page 6-8).
Table 6-2 through Table 6-6 show the number of calls that each hardware platform can support, which
is determined by the type of DSP chipset and the number of DSPs on the hardware. The hardware has
either fixed DSP resources that cannot be upgraded or changed, or it has modular DSP resources that can
be upgraded. For modular (upgradeable) hardware, Table 6-2 through Table 6-6 also list the maximum
number of DSPs per hardware module.
The number of supported calls depends on the computational complexity of the codec used for a call and
also on the complexity mode configured on the DSP. Cisco IOS enables you to configure a complexity
mode on the hardware module. Some hardware platforms have two complexity modes, medium
complexity and high complexity, while other hardware platforms have medium and high complexity as
well as flex mode.

Cisco IP Telephony SRND

OL-7447-03 6-1
 Chapter 6 Media Resources
Voice Termination Resources

Medium and High Complexity Mode

To determine how many calls a module can support, locate the module in Table 6-2 through Table 6-6,
and determine the number of DSPs it can provide as well as the desired codec type. For example, an
NM-HD-2VE module with three C2510 DSPs configured in flex mode can support eight G.729 calls on
each DSP, for a total of 24 calls using flex mode and G.729 codecs. Using G.711 codecs in flex mode,
the same hardware could support 48 calls.
As indicate in Table 6-1, if a codec is supported in medium complexity mode, it is also supported in high
complexity mode, albeit with fewer supported calls.
You can configure each DSP separately as either medium complexity, high complexity, or flex mode
(C5510 only). The DSP treats all calls according to its configured complexity, regardless of the actual
complexity of the codec of the call. A resource with configured complexity equal or higher than the
actual complexity of the incoming call must be available, or the call will fail. For example, if a call
requires a high-complexity codec but the DSP resource is configured for medium complexity mode, the
call will fail. However, if a medium-complexity call is attempted on a DSP configured for high
complexity mode, then the call will succeed and Cisco IOS will allocate a high-complexity mode
resource.
To determine the maximum number of calls supported, find the appropriate row in Table 6-2 through
Table 6-6 that contains the desired hardware. Check the medium and high complexity columns in
Table 6-1 to verify which complexity modes are capable of handling the desired codecs. Then read the
maximum number of supported calls for each DSP at the desired complexity mode.

Flex Mode
Flex mode, available only on hardware platforms that use the C5510 chipset, eliminates the requirement
to specify the codec complexity at configuration time. A DSP in flex mode accepts a call of any
supported codec type, as long as it has available processing power. The overhead of each call is tracked
dynamically via a calculation of processing power in millions of instructions per second (MIPS).
Cisco IOS performs a MIPS calculation for each call received and subtracts MIPS credits from its budget
whenever a new call is initiated. The number of MIPS consumed by a call depends on the codec of the
call, as shown in the Flex Mode column of Table 6-1. The DSP will allow a new call as long as it has
remaining MIPS credits greater than or equal to the MIPS required for the incoming call. The Flex Mode
column of Table 6-1 groups the supported codecs by the number of MIPS for a single call (either 15, 30,
or 40 MIPS per call) and shows the MIPS budget available for various hardware.
Flex mode has an advantage when calls of multiple codecs must be supported on the same hardware
because flex mode can support more calls than when the DSPs are configured as medium or high
complexity. However, flex mode does allow oversubscription of the resources, which introduces the risk
of call failure if all resources are used. With flex mode it is possible to have fewer DSP resources than
with physical TDM interfaces.
For example, each DSP has a budget of 240 MIPS, for a total budget of 720 MIPS per NM-HD-2VE
module. For an NM-HDV2 module, the budget per DSP is also 240 MIPS, but refer to Table 6-2 to
determine the total number of MIPS available based on your choice and the number of PVDMs.
Compared to medium or high complexity mode, flex mode has the advantage of supporting the most
G.711 calls per DSP. In medium complexity mode a DSP can support 8 G.711 calls, while flex mode
supports 16 G.711 calls.

Cisco IP Telephony SRND

6-2 OL-7447-03
 Chapter 6 Media Resources
Voice Termination Resources

Note The product documentation uses various nomenclatures for the DSP designations. For example, the
C5510 is also referred to as the C2510. In addition, the C prefix is sometimes replaced by TI, as in
TI5510 or TI549.

DSP Resources for Voice Termination

Table 6-2 through Table 6-6, organized by DSP chipset, provide information on DSP support by
platform, DSP density, and the number of voice terminations (or calls) supported per DSP. Table 6-1 lists
the codecs supported by the hardware modules in each complexity mode.

Table 6-1 Codecs Supported by Each Complexity Mode

Medium Complexity High Complexity Flex Mode

G.711 (A-law, mu-law) G.711 (A-law, mu-law) At 15 MIPS per call:
Fax/modem pass-through Fax/modem pass-through • G.711 (A-law, mu-law)
Clear channel Clear channel • Fax/modem pass-through
G.726 (32K, 24K, 16K) G.726 (32K, 24K, 16K) • Clear channel
GSM-FR GSM-FR At 30 MIPS per call:
Fax relay Fax relay • G.726 (32K, 24K, 16K)
G.729 (a, ab) G.729 • GSM-FR
G.729 (a, b, ab) • Fax relay
G.728 • G.729
G.723.1 (32K, 24K, 16K) • G.729 (a, b, ab)
G.723.1a (5.3K, 6.3K) At 40 MIPS per call:
GSM-EFR • G.728
Modem relay • G.723.1 (32K, 24K, 16K)
• G.723.1a (5.3K, 6.3K)
• GSM-EFR
• Modem relay

Hardware based on the C5510 chipset supports medium and high complexity modes as well as flex mode,
as indicated in Table 6-2.

Cisco IP Telephony SRND

OL-7447-03 6-3
 Chapter 6 Media Resources
Voice Termination Resources

Table 6-2 DSP Resources on Cisco IOS Hardware Platforms with C5510 Chipset

Maximum Number of Voice Terminations (Calls) per DSP and per Module
Hardware Module or Medium Complexity High Complexity Flex Mode1
Chassis DSP Configuration (8 calls per DSP) (6 calls per DSP) (240 MIPS per DSP)
VG-224 Fixed at 4 DSPs N/A 24 calls per platform N/A
Supported codecs:
• G.711 (A-law,
mu-law)
• G.729a
2
NM-HD-1V Fixed at 1 DSP 4 calls per NM 4 calls per NM 240 MIPS per NM
NM-HD-2V Fixed at 1 DSP 8 calls per NM 6 calls per NM 240 MIPS per NM
NM-HD-2VE Fixed at 3 DSPs 24 calls per NM 18 calls per NM 720 MIPS per NM
NM-HDV2 1 to 4 of: Calls per PVDM: Calls per PVDM: MIPS per PVDM:
3
NM-HDV2-2T1/E1 PVDM2-8 ( DSP) 4 3 120
PVDM2-16 (1 DSP) 8 6 240
NM-HDV2-1T1/E1
PVDM2-32 (2 DSPs) 16 12 480
PVDM2-48 (3 DSPs) 24 18 720
PVDM2-64 (4 DSPs) 32 24 960
2801 1 to 2 of: Calls per PVDM: Calls per PVDM: MIPS per PVDM:
3
2811 PVDM2-8 ( DSP) 4 3 120
PVDM2-16 (1 DSP) 8 6 240
PVDM2-32 (2 DSPs) 16 12 480
PVDM2-48 (3 DSPs) 24 18 720
PVDM2-64 (4 DSPs) 32 24 960
2821 1 to 3 of: Calls per PVDM: Calls per PVDM: MIPS per PVDM:
3
2851 PVDM2-8 ( DSP) 4 3 120
PVDM2-16 (1 DSP) 8 6 240
PVDM2-32 (2 DSPs) 16 12 480
PVDM2-48 (3 DSPs) 24 18 720
PVDM2-64 (4 DSPs) 32 24 960
3825 1 to 4 of: Calls per PVDM: Calls per PVDM: MIPS per PVDM:
3845 PVDM2-83 ( DSP) 4 3 120
PVDM2-16 (1 DSP) 8 6 240
PVDM2-32 (2 DSPs) 16 12 480
PVDM2-48 (3 DSPs) 24 18 720
PVDM2-64 (4 DSPs) 32 24 960
1. In flex mode, the maximum number of supported calls depends on the number of MIPS used per call (see Table 6-1).
2. With the NM-HD-1V module, the number of voice terminations (calls) is limited by the number of physical ports on the module.
3. The PVDM2-8 has a single half-capacity C5510.

Cisco IP Telephony SRND

6-4 OL-7447-03
 Chapter 6 Media Resources
Voice Termination Resources

Hardware that is based on the C5421 chipset may have DSPs configured as either medium complexity
or high complexity. Table 6-3 lists the call density per DSP, and Table 6-1 lists the codecs supported in
each complexity mode.

Table 6-3 DSP Resources on Cisco IOS Hardware Platforms with C5421 Chipset

Maximum Number of Calls per DSP and per Module

Medium Complexity High Complexity
Hardware Module DSP Configuration (8 calls per DSP) (8 calls per DSP)
NM-HDA-4FXS Fixed at 2 DSPs 16 calls per NM 8 calls per NM
or
Fixed at 1 of DSP-HDA-16 16 calls per NM 16 calls per NM
(4 DSPs)
AIM-VOICE-30 Fixed at 4 DSPs 30 or 60 calls per AIM 16 or 30 calls per AIM
AIM-ATM-VOICE-30

Hardware that is based on the C549 chipset may have DSPs configured as either medium complexity or
high complexity. Table 6-4 lists the call density per DSP, and Table 6-1 lists the codecs supported in each
complexity mode.

Table 6-4 DSP Resources on Cisco IOS Hardware Platforms with C549 Chipset

Maximum Number of Calls per DSP and per Module

Medium Complexity High Complexity
Hardware Module DSP Configuration (4 calls per DSP) (2 calls per DSP)
NM-HDV 1 to 5 of PVDM-12 12, 24, 36, 48, or 60 calls per NM 6, 12, 18, 24, or 30 calls per NM
(3 DSPs per PVDM-12)
NM-HDV-FARM
17511 1 to 2 of: Calls per NM: Calls per NM:
1760 PVDM-256K-4 (1 DSP) 4 or 8 2 or 4
PVDM-256K-8 (2 DSPs) 8 or 16 4 or 8
PVDM-256K-12 (3 DSPs) 12 or 24 6 or 12
PVDM-256K-16HD (4 DSPs) 16 or 32 8 or 16
PVDM-256K-20HD (5 DSPs) 20 10
Fixed at: Calls per PA: Calls per PA:
PA-VXA-1TE1-24+ 7 DSPs 28 14
PA-VXA-1TE1-30+ 8 DSPs 32 16
PA-VXB-2TE1+ 12 DSPs 48 24
PA-VXC-2TE1+ 30 DSPs 120 60
2
PA-MCX-2TE1 Fixed (No on-board DSPs) Depends on PA-VX(x) Depends on PA-VX(x)2
PA-MCX-4TE1
PA-MCX-8TE1
1. The 1751 supports a maximum of 8 DSPs (32 channels), and you can order these modules in multiples of 2 PVDMs as long as the total is less than
32 channels. The part number indicates the number of channels.
2. The multichannel port adaptors utilize unused DSPs from PA-VXAs, PA-VXBs, or PA-VXCs across the mix backplane.

Cisco IP Telephony SRND

OL-7447-03 6-5
 Chapter 6 Media Resources
Voice Termination Resources

Hardware that is based on the C542 chipset supports the following codecs:
• G.711 (A-law, mu-law)
• Fax/modem pass-through
• Clear channel
• G.726 (32K, 24K, 16K)
• GSM-FR
• Fax relay
• G.729
• G.729 (a, b, ab)
• G.728
• G.723.1 (32K, 24K, 16K)
• G.723.1a (5.3K, 6.3K)
• GSM-EFR
• Modem relay
Table 6-5 lists the call density per DSP.

Table 6-5 DSP Resources on Cisco IOS Hardware Platforms with C542 Chipset

Maximum Number of Calls per DSP and per

Hardware Module1 DSP Configuration Module
NM-1V Fixed at 2 DSPs 1 call per DSP
2 calls per NM
NM-2V Fixed at 4 DSPs 1 call per DSP
4 calls per NM
1. These modules do not have any complexity mode but support all codecs equally.

Table 6-6 lists non-IOS hardware for DSP resources. All non-IOS hardware platforms have a fixed
configuration of DSPs, as indicated in Table 6-6.

Table 6-6 DSP Resources on Non-IOS Hardware Platforms

Hardware Module or Maximum Number of Calls

Platform DSP Configuration per DSP and per Module Codecs Supported
WS-6608-T1 Fixed at 64 of C549 2 calls per DSP G.711 A-law, mu-law
WS-6608-E1 1 G.729a
(8 DSPs per port) 256 calls per module
WS-6624-FXS Fixed at 12 of C549 2 calls per DSP G.711 A-law, mu-law
G.729a
24 calls per module
VG-248 Fixed at 12 of C5409 4 calls per DSP G.711 A-law, mu-law
48 calls per platform G.729a

WS-SVC-CMM-ACT Fixed at 4 of Broadcom 1500 32 calls per DSP G.711 (10-30 ms)
G.729 (10-60 ms)
128 calls per module
G.723 (30-60 ms)

Cisco IP Telephony SRND

6-6 OL-7447-03
 Chapter 6 Media Resources
Conferencing, Transcoding, and MTP Resources

Table 6-6 DSP Resources on Non-IOS Hardware Platforms (continued)

Hardware Module or Maximum Number of Calls

Platform DSP Configuration per DSP and per Module Codecs Supported
WS-SVC-CMM-6T1 Fixed at 12 of C5441 15 calls per DSP G.711 (10, 20, 30 ms)
144 calls per module G.729 (10, 20, 30, 40, 50, 60 ms)
WS-SVC-CMM-6E1 Fixed at 12 of C5441 15 calls per DSP G.711 (10, 20, 30 ms)
180 calls per module G.729 (10, 20, 30, 40, 50, 60 ms)
WS-SVC-CMM-24FXS Fixed at 3 of C5441 15 calls per DSP G.711 A-law, mu-law
G.729
24 calls per module
G.729a
ATA-1882 Fixed at 1 of Komodo 3880 2 calls per platform G.711 A-law, mu-law
G.729
1. A maximum of 192 calls are possible with T1 and 240 calls with E1, based on the number of physical ports. If none of the DSPs are configured for T1
or E1, then a maximum of 256 DSP resources are available.
2. The ATA module does not define complexity. It supports G.711, G.729, and G.723 only.

Conferencing, Transcoding, and MTP Resources

This section describes the following types of media resources:
• Conferencing, page 6-7
• Transcoding, page 6-8
• Media Termination Point (MTP), page 6-9
• Hardware Resources for MTP, Conferencing, and Transcoding, page 6-10
• Software Conferencing, page 6-16
• Annunciator, page 6-16
• Cisco IP Voice Media Streaming Application, page 6-18

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

Cisco IP Telephony SRND

OL-7447-03 6-7
 Chapter 6 Media Resources
Conferencing, Transcoding, and MTP Resources

There are two main types of conference bridge resources:

• Software conference bridge
A software unicast conference bridge is a standard conference mixer that is capable of mixing G.711
audio streams and Cisco Wideband audio streams. Any combination of Wideband or G.711 A-law
and mu-law streams may be connected to the same conference. The number of parties that can be
supported on a given conference depends on the server where the conference bridge software is
running and on the configuration for that device.
• Hardware conference bridge
A hardware conference bridge has all the capabilities of a software conference bridge. In addition,
some hardware conference bridges can support multiple low bit-rate (LBR) stream types such as
G.729, GSM, or G.723. This capability allows some hardware conference bridges to handle
mixed-mode conferences. In a mixed-mode conference, the hardware conference bridge transcodes
G.729, GSM, and G.723 streams into G.711 streams, mixes them, and then encodes the resulting
stream into the appropriate stream type for transmission back to the user. Some hardware conference
bridges support only G.711 conferences.
All conference bridges that are under the control of Cisco CallManager use Skinny Client Control
Protocol (SCCP) to communicate with Cisco CallManager.
Cisco CallManager allocates a conference bridge from a conferencing resource that is registered with
the Cisco CallManager cluster. Both hardware and software conferencing resources can register with
Cisco CallManager at the same time, and Cisco CallManager can allocate and use conference bridges
from either resource. Cisco CallManager does not distinguish between these types of conference bridges
when it processes a conference allocation request.
Table 6-6 lists the types of hardware and software conference resources available, as well as the
maximum number of conference participants and bridges per resource and codec type.

Transcoding
A transcoder is a device that takes the output stream of one codec and converts it in real time (transcodes
it) into an input stream for a different codec type. In other words, a transcoder converts a stream of one
compression type into a stream of another compression type.
A transcoder can convert a G.711 voice stream into a low bit-rate (LBR) compressed voice stream, such
as G.729a. This conversion is critical for enabling applications such as Cisco IP Interactive Voice
Response (IVR), voice messaging, and conference calls over low-speed IP WANs. In addition, a
transcoder provides the capabilities of a media termination point (MTP) and can be used to enable
supplementary services for H.323 endpoints when required.
Table 6-8 lists the maximum number of MTPs and transcoding sessions for each codec type supported
on the indicated platforms.
To scale IP telephony systems in large enterprise environments, hardware conferencing is required. DSP
resources in the voice modules for the hardware platforms listed in Table 6-6 provide the hardware
conferencing features needed for large systems, and they support the following characteristics:
• Through the use of media resource groups (MRGs) and media resources group lists (MRGLs), Cisco
CallManager permits sharing of the hardware conference ports among the Cisco CallManager
servers in a cluster.
• Cisco CallManager uses Skinny Client Control Protocol (SCCP) to communicate with the hardware
conference bridges, but the gateway services on those platforms may use Media Gateway Control
Protocol (MGCP).

Cisco IP Telephony SRND

6-8 OL-7447-03
 Chapter 6 Media Resources
Conferencing, Transcoding, and MTP Resources

The following guidelines apply to hardware MTP resources:

• Some resources (for example, Cisco conferencing resources) have the capability to use only G.711
voice streams.
• Use codecs other than G.711 when you want to compress the voice streams.
• When a compressed voice stream connects to a device that supports only G.711, use hardware-based
MTP and transcoding services to convert the compressed voice streams into G.711.

Media Termination Point (MTP)

A media termination point (MTP) is an entity that accepts two full-duplex G.711 streams. It bridges the
media streams together and allows them to be set up and torn down independently. The streaming data
received from the input stream on one connection is passed to the output stream on the other connection,
and vice versa. In addition, the MTP can be used to transcode A-law to mu-law and vice versa, or it can
be used to bridge two connections that utilize different packetization periods (different packet sizes).
MTPs are also used to provide further processing of a call, such as RFC 2833 support.
MTPs can be used to extend supplementary services to H.323 endpoints that do not support the H.323v2
OpenLogicalChannel and CloseLogicalChannel request features with the EmptyCapabilitiesSet feature.
When needed, an MTP is allocated and connected into a call on behalf of an H.323 endpoint. Once
inserted, the media streams are connected between the MTP and the H.323 device, and these connections
are present for the duration of the call. The media streams connected to the other side of the MTP can
be connected and disconnected as needed to implement features such as hold, transfer, and so forth.

Note Implementations prior to Cisco CallManager Release 3.2 required MTPs to provide supplementary
services for H.323 endpoints, but Cisco CallManager Release 3.2 and later no longer require MTP
resources to provide this functionality.

There are two main types of MTPs:

• Software MTP
A software MTP is a device that is implemented by installing the Cisco IP Voice Media Streaming
Application on a server. When the installed application is configured as an MTP application, it
registers with a Cisco CallManager node and informs Cisco CallManager of how many MTP
resources it supports. A software MTP device supports only G.711 streams.
A Cisco IOS Enhanced software device may be implemented on a Cisco IOS router by configuring
a software-only MTP under a DSP farm.This DSP farm may be used only as a pure MTP and does
not require any hardware DSPs on the router.
• Hardware MTP
A hardware MTP is a DSP-based resource that resides on hardware external to Cisco CallManager.
Transcoders have MTP capabilities, and a hardware MTP is really a transcoder used as an MTP. The
hardware device registers with a Cisco CallManager node as a transcoder and informs Cisco
CallManager of how many resources it supports. Hardware MTPs that have transcoder functionality
can accept streams other than G.711.

MTPs for SIP RFC 2833 Support

SIP endpoints have the ability, as defined by the SIP specifications, to send DTMF digits and call
progress tones in-band in the media stream. The DTMF tones are sent in the RTP stream as modified
RTP packets. Skinny Client Control Protocol (SCCP) endpoints do not have this capability as of Cisco

Cisco IP Telephony SRND

OL-7447-03 6-9
 Chapter 6 Media Resources
Conferencing, Transcoding, and MTP Resources

CallManager Release 4.1. Therefore, to integrate a Cisco CallManager system with a SIP system, you
must insert an MTP in the media stream to convert SIP in-band signaling into SCCP out-of-band
signaling, and vice versa.
As of Cisco CallManager Release 4.1, both software and hardware are capable of providing RFC 2833
support. The Ad-hoc Conferencing and Transcoding (ACT) Port Adapter, minimum code version
12.3(8)XY2, and the Cisco IP Voice Media Streaming Application both support RFC 2833.
You must provision MTPs for calls that are to traverse a SIP trunk. If two Cisco CallManager clusters
are connected via a SIP trunk, then each cluster requires its own MTP resources for this purpose. A
software MTP can support 512 streams when implemented on a dual-CPU server dedicated for this
purpose.

Hardware Resources for MTP, Conferencing, and Transcoding

The resources for implementing these features may be hardware or software based. Software resources
can reside on a Cisco CallManager server or on a Cisco IOS platform, and hardware platforms can be
either a Cisco IOS or Cisco Catalyst platform. This section summarizes the codec type and number of
streams supported by all the available resources. These resources are configured on the gateway as a DSP
farm and used by Cisco CallManager via the SCCP protocol. The gateway is responsible for control and
allocation of the resources.
The support of these features depends on the hardware platform, Cisco CallManager version, and
Cisco IOS version. Table 6-7 lists the minimum software releases required for the modules and
platforms to support MTP, conferencing, and transcoding. Use Table 6-11 to determine the number and
type of media resource modules supported in various Cisco IOS platforms. The tables list only the
modules that support media resources.

Note The Cisco VG200, 2620, 2621, and 3620 do not support the NM-HDV-FARM, nor do they support MTP,
conferencing, or transcoding. The Cisco 2801 has no NM slot. DSP farm services are not supported for
Cisco Survivable Remote Site Telephony (SRST) or Cisco CallManager Express

Table 6-7 Minimum Software Releases for Conferencing, Transcoding, and MTP

Cisco Platform Module MTP Conferencing and Transcoding

2691 and 2600XM NM-HD-1V Cisco CallManager 4.0(1) Cisco CallManager 3.3(4) or 4.0(1)
2811, 2821, and 2851 NM-HD-2V Cisco IOS: Cisco IOS:
3640, 3640A, and 3660 NM-HD-2VE • 12.3(8)T4 • 12.3(11)T for 3800 Series
3725 and 3745 • 12.3(11)T for 3800 Series • 12.3(8)T4 for all others listed
3825 and 3845
2691 and 2600XM NM-HDV2 Cisco CallManager 4.0(1) Cisco CallManager 3.3(4) or 4.0(1)
2811, 2821, and 2851 NM-HDV2-1T1/E1 Cisco IOS: Cisco IOS:
3725 and 3745 NM-HDV2-2T1/E1 • 12.3(8)T4 • 12.3(11)T for 3800 Series
3825 and 3845 • 12.3(11)T for 3800 Series • 12.3(8)T4 for all others listed

Cisco IP Telephony SRND

6-10 OL-7447-03
 Chapter 6 Media Resources
Conferencing, Transcoding, and MTP Resources

Table 6-7 Minimum Software Releases for Conferencing, Transcoding, and MTP (continued)

Cisco Platform Module MTP Conferencing and Transcoding

VG200 NM-HDV N/A Cisco CallManager 3.2(2c)
2691 and 2600XM NM-HDV-FARM Cisco IOS:
2650 and 2651 • 12.1(5)YH for VG200 with
HDV-FARM
2811, 2821, and 2851
• 12.2(13)T for listed 2600
3640, 3640A, and 3660
Series, 3600 Series, and VG200
3725 and 3745 with HDV.
3825 and 3845
1751, 1751V, and 1760 PVDM-256K N/A Cisco CallManager 3.3(4)
Cisco IOS 12.3(2)XE
2801 PVDM2-8 Cisco CallManager 4.1 Cisco CallManager 4.1
PVDM2-16 Cisco IOS 12.3(11)T Cisco IOS 12.3(11)T
PVDM2-32
PVDM2-48 No conferencing on PVDM2-8.
PVDM2-64
2811, 2821, and 2851 PVDM2-8 Cisco CallManager 3.3(5) or 4.1 Cisco CallManager 3.3(5) or 4.1
PVDM2-16 Cisco IOS 12.3(8)T4 Cisco IOS 12.3(8)T4
PVDM2-32
PVDM2-48 No conferencing on PVDM2-8.
PVDM2-64

As described in the following sections, the allocation of resources is handled differently on C549
platforms than it is on C5510 platforms.

Allocating Resources to Voice Termination or a DSP Farm

You can configure the DSP resources on a module as either voice termination of a voice trunk group or
as a DSP farm. Within a DSP farm, you can allocate the DSPs to either conferencing or
transcoding/MTP. Table 6-8 shows the number of participants that each conference bridge can support
and the number of conferencing sessions supported per module. Similarly, Table 6-9 lists the number of
transcoding sessions supported per DSP and per module, and Table 6-10 lists the number of MTP
sessions supported per DSP and per module. Use Table 6-2 through Table 6-6 to determine the number
of DSPs available on a module, and use Table 6-11 to determine the maximum number of NM modules
that a chassis can support. From these various tables, you can determine the necessary hardware
configuration for your deployment.

Note The number of calls or sessions that a module can support depends on the particular DSP configuration
on that module. Table 6-8 through Table 6-10 list only a few of the many DSP configurations possible
for each module type. For information on other DSP configurations and to calculate the number of calls
or sessions that a DSP configuration can support, use the Cisco DSP Calculator, available at
http://www.cisco.com/cgi-bin/Support/DSP/cisco_dsp_calc.pl (Cisco.com login required).

Cisco IP Telephony SRND

OL-7447-03 6-11
 Chapter 6 Media Resources
Conferencing, Transcoding, and MTP Resources

Table 6-8 Number of Supported Conference Calls per DSP and per Module

Hardware Module or Chassis DSP Configuration
NM-HDV2 1 to 4 of:
1
(8 participants per conference) PVDM2-8 ( DSP)
PVDM2-16 (1 DSP)
PVDM2-32 (2 DSPs)
PVDM2-48 (3 DSPs)
PVDM2-64 (4 DSPs)
NM-HD-1V Fixed at 1 DSP
(8 participants per conference)
NM-HD-2V Fixed at 1 DSP
(8 participants per conference)
NM-HD-2VE Fixed at 3 DSPs
(8 participants per conference)
NM-HDV 1 to 5 of PVDM-12
(3 DSPs per PVDM-12)
NM-HDV-FARM
(6 participants per conference)
17512 1 to 2 of:
(6 participants per conference) PVDM-256K-4 (1 DSP)
PVDM-256K-8 (2 DSPs)
PVDM-256K-12 (3 DSPs)
PVDM-256K-16HD (4 DSPs)
PVDM-256K-20HD (5 DSPs)
1760 1 to 2 of:
(6 participants per conference) PVDM-256K-4 (1 DSP)
PVDM-256K-8 (2 DSPs)
PVDM-256K-12 (3 DSPs)
PVDM-256K-16HD (4 DSPs)
PVDM-256K-20HD (5 DSPs)
WS-6608-T1 and WS-6608-E1 Fixed at 64 of C549
(3 to 32 participants per (8 DSPs per port)
conference)
WS-SVC-CMM-ACT Fixed at 4 of Broadcom 1500
(64 participants per conference)
Cisco IP Voice Media Streaming N/A
Application
(3 to 64 participants per
conference)
Conferences
All Participants Use One or More Participants
G.711 (A-law, mu-law) Use G.729 or G.729a
Conferences per PVDM: Conferences per PVDM:
4 1
8 2
16 4
24 6
32 8
Maximum of 50
conferences per NM
8 conferences per NM 2 conferences per NM
8 conferences per NM 2 conferences per NM
24 conferences per NM 6 conferences per NM
3, 6, 9, 12, or 15 3, 6, 9, 12, or 15
conferences per NM conferences per NM
1 conference per DSP 1 conference per DSP
Maximum of 5 Maximum of 5
conferences per chassis conferences per chassis
1 conference per DSP 1 conference per DSP
Maximum of 20 Maximum of 20
conferences per chassis conferences per chassis
32 participants per port 32 participants per port
G.729a only
128 conferences per 128 conferences per
module module
48 participants per N/A
coresident server

Cisco IP Telephony SRND

6-12 OL-7447-03
 Chapter 6 Media Resources
1. The PVDM2-8 has a single half-capacity C5510.
2. The 1751 supports a maximum of 5 conferences.
Table 6-9 Number of Supported Transcoding Sessions per DSP and per Module
Hardware Module or
Chassis DSP Configuration
NM-HDV2 1 to 4 of:
1
PVDM2-8 ( DSP)
PVDM2-16 (1 DSP)
PVDM2-32 (2 DSPs)
PVDM2-48 (3 DSPs)
PVDM2-64 (4 DSPs)
NM-HD-1V Fixed at 1 DSP
NM-HD-2V Fixed at 1 DSP
NM-HD-2VE Fixed at 3 DSPs
NM-HDV 1 to 5 of PVDM-12
(3 DSPs per PVDM-12)
NM-HDV-FARM
17512 1 to 2 of:
PVDM-256K-4 (1 DSP)
PVDM-256K-8 (2 DSPs)
PVDM-256K-12 (3 DSPs)
PVDM-256K-16HD (4 DSPs)
PVDM-256K-20HD (5 DSPs)
1760 1 to 2 of:
PVDM-256K-4 (1 DSP)
PVDM-256K-8 (2 DSPs)
PVDM-256K-12 (3 DSPs)
PVDM-256K-16HD (4 DSPs)
PVDM-256K-20HD (5 DSPs)
WS-6608-T1 and Fixed at 64 of C549
WS-6608-E1 (8 DSPs per port)
WS-SVC-CMM-ACT Fixed at 4 of Broadcom 1500
1. The PVDM2-8 has a single half-capacity C5510.
2. The 1751 supports a maximum of 16 transcoding sessions.
OL-7447-03
Conferencing, Transcoding, and MTP Resources
Transcoding G.711 to or from:
G.729a G.729
G.711 (A-law, G.729ab G.729b
mu-law) GSM-FR GSM-EFR
Sessions per PVDM: Sessions per PVDM: Sessions per PVDM:
32 4 3
64 8 6
128 16 12
192 24 18
256 32 24
16 sessions per NM 8 sessions per NM 6 sessions per NM
16 sessions per NM 8 sessions per NM 6 sessions per NM
48 sessions per NM 24 sessions per NM 18 sessions per NM
12, 24, 36, 48, or 60 12, 24, 36, 48, or 60 12, 24, 36, 48, or 60
sessions per NM sessions per NM sessions per NM
2 sessions per DSP 2 sessions per DSP 2 sessions per DSP
Maximum of 16 Maximum of 16 Maximum of 16
sessions per chassis sessions per chassis sessions per chassis
2 sessions per DSP 2 sessions per DSP 2 sessions per DSP
Maximum of 20 Maximum of 20 Maximum of 20
sessions per chassis sessions per chassis sessions per chassis
24 sessions per port 24 sessions per port 24 sessions per port
128 sessions per 128 sessions per 128 sessions per
module module module
Cisco IP Telephony SRND
6-13
 Chapter 6 Media Resources
Conferencing, Transcoding, and MTP Resources

Table 6-10 Number of Supported MTP Sessions per DSP and per Module

Hardware Module or MTP

Chassis DSP Configuration G.711 (A-law, mu-law)
NM-HDV2 1 to 4 of: Sessions per PVDM:
1
PVDM2-8 ( DSP) 8
PVDM2-16 (1 DSP) 16
PVDM2-32 (2 DSPs) 32
PVDM2-48 (3 DSPs) 48
PVDM2-64 (4 DSPs) 64
NM-HD-1V Fixed at 1 DSP 4 sessions per NM
NM-HD-2V Fixed at 1 DSP 16 sessions per NM
NM-HD-2VE Fixed at 3 DSPs 48 sessions per NM
WS-6608-T1 and Fixed at 64 of C549 24 sessions per port
WS-6608-E1 (8 DSPs per port)
WS-SVC-CMM-ACT Fixed at 4 of Broadcom 1500 256 sessions per module
1. The PVDM2-8 has a single half-capacity C5510.

Resource Allocation on the NM-HDV (C549-Based Hardware)

You configure each DSP individually, and each DSP functions independently of the others. The
conferencing, transcoding, and MTP resources must be allocated to different DSPs, and a single DSP
can support only one of these functions at a time. The configuration specifies which function each DSP
will perform.
An NM-HDV module may be associated with only a single Cisco CallManager.

Resource Allocation on the NM-HDV2, NM-HD-xx, and PVDM2 (C5510-Based Hardware)

Hardware resources based on the C5510 chipset are allocated using DSP profiles that define the resource
type within the profile. The profile is associated with a DSP farm so that DSPs are not defined as specific
resource types.
DSPs from a DSP farm may be used by multiple Cisco CallManagers.

Calculating DSP Requirements for NM-HDV

For sample rates of 20, 30, 40, or 60 ms with voice activity detection (VAD) enabled or disabled (or
10 ms with VAD enabled), it is possible to configure an NM-HDV or NM-HDV-FARM with a full
complement of 5 PVDMs, giving 60 usable DSP resources.
To calculate the number of DSPs required for a given application, add the number of desired
conferences, the number of DSPs for voice terminations, and the number of DSPs for transcoding
sessions. The number of DSPs needed for transcoding is equal to the number of desired transcoding
sessions divided by 4, then rounded up to the next whole number.
Because PVDMs have a fixed configuration of 3 DSPs, the number of required PVDMs is equal to the
number of DSPs divided by 3, then rounded up to the next whole number.
Finally, the number of required NM-HDV or NM-HDV-FARM modules is equal to the number of
PVDMs divided by 5, then rounded up to the next whole number.

Cisco IP Telephony SRND

6-14 OL-7447-03
 Chapter 6 Media Resources
Conferencing, Transcoding, and MTP Resources

For a sampling rate of 10 ms with VAD disabled, it is not possible to utilize all DSPs on a fully populated
NM-HDV. The following additional calculation is required to ensure that the packet rate does not exceed
6600 packets per second (pps), which is the capacity of the NM-HDV.
100 pps ∗ (number of voice terminations) + 600 pps ∗ (number of conferences) + 200 pps ∗ (number
of transcoding sessions) < 6600 pps

Platform Support of DSP Resources

Cisco 2800 and 3800 Series
Although the Cisco 2800 and 3800 Series routers all have two AIM slots, they do not support the
AIM-VOICE-30 or AIM-ATM-VOICE-30 cards because the functionality of these cards is provided
instead by PVDM2s that are installed on the motherboard.

Network Modules
You can install the NM-HDV2, NM-HD-xx, and NM-HDV modules in the Cisco IOS platforms listed in
Table 6-11, up to the maximum numbers indicated.
All three families of modules in Table 6-11 may be installed in a single chassis. However, the
conferencing and transcoding features cannot be used simultaneously on both the NM-HDV family and
either of the other two families (NM-HD-xx or NM-HDV2)
The NM-HDV (TI-549), NM-HD-xx, and NM-HDV2 (TI-5510) cannot be used simultaneously for
conferencing and transcoding within a single chassis.
You can mix NM-HDV and NM-HDV-FARM modules in the same chassis, but not all chassis can be
completely populated by these modules. Table 6-11 shows the maximum number of modules that each
type of hardware platform can support.

Table 6-11 Maximum Number of Modules per Cisco IOS Platform

Modules Supported by Platform

NM-HD-1V
NM-HD-2V NM-HDV
Cisco IOS Platform Number of Slots NM-HDV2 NM-HD-2VE NM-HDV-FARM
VG2001 1 N N Y
26002 1
36203 2
2600XM, 2691 1 Y Y Y
3640 3 N N Y
3660 6 N Y Y
3725 2 Y Y Y
3745 4 Y Y Y
2811 1 Y Y Y
2821 1 Y Y Y
2851 1 Y Y Y
3825 2 Y Y Y
3845 4 Y Y Y

Cisco IP Telephony SRND

OL-7447-03 6-15
 Chapter 6 Media Resources
Conferencing, Transcoding, and MTP Resources

1. The VG200 is no longer available for purchase and has been replaced by the Cisco 2610 Router. Existing models of the
VG200 can still be used in an IP Telephony deployment.
2. For IP Telephony applications, use Cisco 2600XM routers. For memory considerations for the Cisco 2600 routers, see the
Product Bulletin at http://www.cisco.com/warp/customer/cc/pd/rt/2600/prodlit/1675_pp.htm
3. Although it has two NM slots, the Cisco 3620 Router supports only a single NM-HDV module.

Software Conferencing
The software conference service is the Cisco IP Voice Media Streaming Application, and it runs on any
approved platform for Cisco CallManager. (See the chapter on Call Processing, page 8-1, for a list of
approved platforms.) This application can be configured to operate and register with Cisco CallManager
as any of the following device types: software conference bridge, media termination point (MTP),
annunciator, or music on hold (MoH) server.
The Cisco IP Voice Media Streaming Application uses the IP Voice Media Streaming Driver to do
real-time voice media streaming. This application also obtains the configuration information both for
itself and for the IP Voice Media Streaming Driver. Because the software conference bridge supports
only G.711 codecs, it is best suited for single-site deployments, where transcoding is not needed for
conference calls. It is a relatively scalable solution for a software conferencing service that does not
require scheduling features.
Software conference bridges have the following characteristics:
• Support for G.711 (A-law and mu-law) and Cisco Wideband
• Maximum of 64 participants in Ad Hoc conferences, or 128 in a Meet Me conference
• All low bit-rate (LBR) calls must be transcoded prior to joining the conference call

Note If calls using codecs other than G.711 want to join a software conference bridge, a separate transcoder
resource must be available.

Annunciator
An annunciator is a software function of the Cisco IP Voice Media Streaming Application that provides
the ability to stream spoken messages or various call progress tones from the system to a user. It is
capable of sending multiple one-way RTP streams to devices such as Cisco IP phones or gateways, and
it uses SCCP messages to establish the RTP stream. The device must be capable of SCCP to utilize this
feature. Tones and announcements are predefined by the system. The announcements support
localization and also may be customized by replacing the appropriate .wav file. The annunciator is
capable of supporting G.711 A-law and mu-law, G.729, and Wideband codecs without any transcoding
resources.
The following features require an annunciator resource:
• Cisco Multilevel Precedence Preemption (MLPP)
This feature has streaming messages that it plays in response to the following call failure conditions.
– Unable to preempt due to an existing higher-precedence call.
– A precedence access limitation was reached.
– The attempted precedence level was unauthorized.
– The called number is not equipped for preemption or call waiting.

Cisco IP Telephony SRND

6-16 OL-7447-03
Chapter 6 Media Resources
Conferencing, Transcoding, and MTP Resources

• Integration via SIP trunk

SIP endpoints have the ability to generate and send tones in-band in the RTP stream. Because SCCP
devices do not have this ability, an annunciator is used in conjunction with an MTP to generate or
accept DTMF tones when integrating with a SIP endpoint. The following types of tones are
supported:
– Call progress tones (busy, alerting, and ringback)
– DTMF tones
• Cisco IOS gateways and intercluster trunks
These devices require support for call progress tone (ringback tone).
• System messages
During the following call failure conditions, the system plays a streaming message to the end user:
– A dialed number that the system cannot recognize
– A call that is not routed due to a service disruption
– A number that is busy and not configured for preemption or call waiting
• Conferencing
During a conference call, the system plays a barge-in tone to announce that a participant has joined
or left the bridge.
An annunciator is automatically created in the system when the Cisco IP Voice Media Streaming
Application is activated on a server. If the Media Streaming Application is deactivated, then the
annunciator is also deleted. A single annunciator instance can service the entire Cisco CallManager
cluster if it meets the performance requirements (see Annunciator Performance, page 6-17); otherwise,
you must configure additional annunciators for the cluster. Additional annunciators can be added by
activating the Cisco IP Voice Media Streaming Application on other servers within the cluster.
The annunciator registers with a single Cisco CallManager at a time, as defined by its device pool. It will
automatically fail over to a secondary Cisco CallManager if a secondary is configured for the device
pool. Any announcement that is playing at the time of an outage will not be maintained.
An annunciator is considered a media device, and it can be included in media resource groups (MRGs)
to control which annunciator is selected for use by phones and gateways.

Annunciator Performance
By default, the annunciator is configured to support 48 simultaneous streams, which is the maximum
recommended for an annunciator running on the same server (coresident) with the Cisco CallManager
service. If the server has only 10 Mbps connectivity, lower the setting to 24 simultaneous streams.
A standalone server without the Cisco CallManager service can support up to 255 simultaneous
announcement streams, and a high-performance server with dual CPUs and a high-performance disk
system can support up to 400 streams. You can add multiple standalone servers to support the required
number of streams.

Cisco IP Telephony SRND

OL-7447-03 6-17
 Chapter 6 Media Resources
Conferencing Guidelines and Application Scenarios

Cisco IP Voice Media Streaming Application

The Cisco IP Voice Media Streaming Application provides the following resources in software:
• Music on Hold (MoH)
• Annunciator
• Software conference bridge
• Media termination point (MTP)
When the Media Streaming Application is activated, one of each of the above resources is automatically
configured. If the annunciator, software conference bridge, or MTP are not needed, Cisco recommends
that you disable them by disabling the Run Flag service parameter for the Cisco IP Voice Media
Streaming Application.
Give careful consideration to situations that require multiple resources and to the load they place on the
Media Streaming Application. Each resource has a service parameter that controls the maximum number
of connections it can handle, with an associated default setting. You may run all four resources on the
same server if you have not changed the default settings. However, if your deployment requires more
than the default number of any one resource, configure that resource to run on its own dedicated server
(without any other resources or the Cisco CallManager service running on that server).

Conferencing Guidelines and Application Scenarios

This section provides conferencing resource guidelines for the following Cisco IP Telephony
deployment models:
• Conferencing Guidelines for All Deployment Models, page 6-18
• Conferencing Guidelines for Single-Site Deployments, page 6-19
• Conferencing Guidelines for Multi-Site WAN Deployments with Centralized Call Processing, page
6-19
• Conferencing Guidelines for Multi-Site WAN Deployments with Distributed Call Processing, page
6-22

Conferencing Guidelines for All Deployment Models

• Cisco recommends that you provide the following minimum conferencing resources for your users:
– Ad Hoc conferencing resources for at least 5% of the user base
– Meet-Me conferencing resources for at least 5% of the user base
• In general, use media resource groups (MRGs) and media resource group lists (MRGLs) to provide
sharing and load balancing of resources across multiple Cisco CallManagers. If you do not use
MRGs and MRGLs, the resources are available to a single Cisco CallManager only.
• You can also use MRGs and MRGLs to separate resources based on geographical location, thereby
conserving WAN bandwidth whenever possible.
• Each type of conferencing resource has different limits on the maximum number of participants in
a single bridge (see Table 6-8). If multiple resources are defined in an MRGL, the first available
resource is used. Two Cisco Callmanager service parameters control the maximum number of

Cisco IP Telephony SRND

6-18 OL-7447-03
 Chapter 6 Media Resources
Conferencing Guidelines and Application Scenarios

participants: Maximum Ad Hoc Conferences, which can be 3 to 64, and Maximum Meet Me
Conference Unicast, which can be 1 to 128. The default setting for both is 4. The maximum number
of participants for the conference resource overrides the service parameter settings.
To maximize the conference bridge size, set the service parameters to match the smallest bridge size
of the resources in the MRGL. Otherwise, maximize bridge size by using only resources of
homogenous characteristics, and set the service parameters to match.
• CTI applications and the Drop Any Party feature do not support more than 16 participants. Although
some Ad Hoc conference resources can support more than 16 participants, these applications display
only the 16 most recent participants.

Conferencing Guidelines for Single-Site Deployments

In a single-site deployment, no voice traffic travels over the IP WAN, and only one type of codec (usually
G.711) is used. Therefore, this type of deployment does not require transcoding resources for conference
calls, so you can use software conferencing. If more conferencing capacity is needed, you can add
hardware conferencing resources.
The following guidelines apply to single-site deployments:
• In this model, voice traffic does not travel over an IP WAN; therefore, use a single type of codec
(usually G.711), and transcoding resources are not required.
• Either software or hardware conferencing may be used. Use software conferencing for small
deployments only.

Conferencing Guidelines for Multi-Site WAN Deployments with Centralized

Call Processing
In this model, call processing is localized at the central site. The MTP, transcoding, and conferencing
services may be centralized or distributed, or a combination of both.
• If the media resources are centralized:
– The WAN will be used in every call involving one of these resources.
– Centrally located resources can cause local calls to traverse the WAN, so you must consider the
effects on bandwidth consumption. (See the chapter on Call Admission Control, page 9-1.)
• If the media resources are distributed:
– Group resources into MRGLs based on their location to prevent one remote site from using
resources located at another remote site. This practice helps you to manage call admission
control between the sites.
– Use hardware conferencing resources if the cluster contains more than one type of codec and
any devices that do not support G.729. All Cisco devices are currently capable of supporting
both codec types. Cisco Customer Response Solution (CRS), Release 3.0 and later, is capable
of supporting G.729 or G.711 but not both on the same installation.
All centralized call processing deployments use the locations mechanism in Cisco CallManager to
provide call admission control. Cisco CallManager uses locations in conjunction with regions to define
the characteristics of a network link. Regions define the type of compression used on the link, and
locations define the amount of available bandwidth for the link. Figure 6-1 depicts a typical centralized
call processing model with locations that are constrained by the amount of bandwidth allocated for voice

Cisco IP Telephony SRND

OL-7447-03 6-19
 Chapter 6 Media Resources
Conferencing Guidelines and Application Scenarios

calls. Because of the bandwidth limitations, the regions in this configuration use a low-bit-rate (LBR)
codec such as G.729. Each LBR call uses approximately 24 kbps instead of the 80 kbps required for a
G.711 call.

Figure 6-1 Locations-Based Call Admission Control for Centralized Call Processing Deployments

Central Site

IP IP
Conf

M Location 1

V
M M

PSTN WAN

Remote sites

IP IP IP IP
77311

Location 2 Location 3

Cisco IP Telephony SRND

6-20 OL-7447-03
 Chapter 6 Media Resources
Conferencing Guidelines and Application Scenarios

Media Resource Groups and Lists

Through the use of media resource groups and lists in Cisco CallManager, you can provide conferencing
resources at the remote sites, thus minimizing bandwidth usage on the WAN. (See Figure 6-2.) Call
admission control based on locations is still required to ensure that WAN bandwidth is not
oversubscribed.

Figure 6-2 Localized Conferencing Resources in a Centralized Call Processing Deployment

Central site
CallManager cluster

M
X
M M
PSTN
Branch
M M
IP
IP
A
IP WAN IP
IP V
B MRG2 MRG3
IP

Conf
Conf Conf
MRG1
Conf Conf

77312
In Figure 6-2, the phones at the remote branch site are assigned a media resource group list (MRGL) that
contains the media resource group MRG1, which in turn contains the conference bridge resource at that
site. This configuration allows for conferencing within that site without using any WAN bandwidth. For
example, assume Phone X calls Phone A, and Phone A conferences Phone B. At this point, conferencing
resources are requested by Cisco CallManager to host the conference call. Because of the MRG and
MRGL configuration, Cisco CallManager selects the conference bridge at the branch site for this
conference call.

Media Resource Allocation in Cisco CallManager

It is imperative to understand how Cisco CallManager allocates resources in a media resource group
(MRG). As noted previously, an MRG is part of a media resource group list (MRGL), and the MRGL is
associated with a device pool. When allocating resources, Cisco CallManager first selects the
appropriate MRG according to the order specified in the MRGL. Within an MRG, resources are listed
alphabetically by name regardless of the order in which you added the resources to the MRG, and
Cisco CallManager allocates resources from the MRG in the order listed (that is, alphabetically).
Therefore, if you require prioritized allocation of a resource (such as hardware conference bridges before
software conference bridges), you have to name those resources properly in the MRGs and/or configure
the appropriate MRGLs to define the desired order.

Cisco IP Telephony SRND

OL-7447-03 6-21
 Chapter 6 Media Resources
Conferencing Guidelines and Application Scenarios

Conferencing Guidelines for Multi-Site WAN Deployments with Distributed

Call Processing
In distributed call processing deployments, several sites are connected through an IP WAN. Each site
contains its own call processing entity, such as a Cisco CallManager cluster, and can in turn follow the
single-site model or the centralized call processing model. A gatekeeper may be used for call admission
control between sites. Also in this case, WAN bandwidth is typically limited, so inter-site calls are
usually configured to use a low bit-rate codec (such as G.729) when traversing the WAN.
The following guidelines apply to distributed call processing deployments:
• In this model, the Cisco CallManager cluster at each site may have its own conferencing resources.
• Each cluster may use multiple types of codecs, typically G.729 on the WAN between the clusters
and G.711 within the cluster.
• With conferencing across multiple Cisco CallManager clusters, the identity of the conference
initiator determines which conferencing resources are allocated for the conference call. (See
Figure 6-3.)
• The number of streams traversing the WAN depends on who initiates the conference and on the
location of the other participants. Each participant in a cluster remote from the initiator adds an
additional stream across the WAN that terminates on a resource in the initiator’s cluster. Take these
factors into account when configuring call admission control. (See the chapter on Call Admission
Control, page 9-1.)
• Within a single cluster, the maximum number of conference participants is determined by the type
of resource and the service parameter settings. However, with participants from multiple clusters,
that maximum number can be exceeded in a conference call. Within a cluster, only the conference
initiator may add a participant. However, conference participants who are members of a different
cluster than the conference initiator can also add participants if they have available conference
resources in their own cluster. This expansion of a conference call is possible because a cluster is
not aware that an incoming call is part of an existing conference in another cluster, and each cluster
can add its maximum number of participants.
Figure 6-3 provides an example of how conferencing resource allocation works across multiple
Cisco CallManager clusters.

Cisco IP Telephony SRND

6-22 OL-7447-03
 Chapter 6 Media Resources
Conferencing Guidelines and Application Scenarios

Figure 6-3 Localized Resources for a Distributed Call Processing Deployment

Site 1 Site 2
CallManager cluster CallManager cluster

M M

M M M M
PSTN
M M M M

IP
IP
A
C
IP WAN
IP V V
B IP
D

77314
Conf Conf

In Figure 6-3, two Cisco CallManager clusters at Site 1 and Site 2 are connected through an IP WAN and
intercluster trunks. Each site has its own conferencing resources that are assigned to individual IP phones
through MRGs and MRGLs.
Assume that phone A at Site 1 calls phone C at Site 2 and then conferences phone D at Site 2. Because
the conference initiator is controlled by the Cisco CallManager cluster at Site 1, the conference bridge
allocated to this call is one located at Site 1. This means that there are now two streams traversing the
WAN, one between phone A and phone C and another between phone A and phone D. If, on the other
hand, the conference had been initiate by phone C, which is controlled by the Cisco CallManager cluster
at Site 2, the call would have been assigned the conference bridge located at Site 2, and only one stream
(between phone C and phone A) would have traversed the WAN.
Note that, when a conference call crosses multiple Cisco CallManager clusters, it is possible to exceed
the maximum number of participants defined in each cluster. Consider the following example, based on
Figure 6-3:
Phone A at Site 1 uses a conference bridge located at Site 1 to set up a six-party conference call that
includes phone C at Site 2. The service parameters for both clusters are set so that conference sizes
are limited to six participants. Phone C can now set up another conference call for another five
parties and “join” the two conferences together using a conference bridge located at Site 2
(assuming that there is sufficient bandwidth to accommodate all voice streams).

Note If all resources in the MRGL are exhausted, Cisco CallManager looks for media resources in the default,
or <None>, MRG.

Cisco IP Telephony SRND

OL-7447-03 6-23
 Chapter 6 Media Resources
Software MTP Resources

Software MTP Resources

The following guidelines apply to software MTP resources:
• They are suited for single-site deployments, where transcoding is typically not required.
• In such deployments, the software MTP resources are needed only to support devices that are not
compliant with H.323v2 (for example, Microsoft NetMeeting prior to version 3.1).
• Cisco strongly recommends running the IP Voice Media Streaming Application on a server other
than the publisher or any Cisco CallManager providing call processing. The increase in CPU load
from the MTP sessions might adversely impact call processing performance, and security issues can
arise because User Datagram Protocol (UDP) traffic must be received on the Cisco CallManager
server.

Transcoding Guidelines and Application Scenarios

This section examines where and when the MTP and transcoding resources are used within the following
three enterprise IP Telephony deployment models plus a fourth application scenario:
• Single-Site Deployments, page 6-24, consist of one or more call processing agents within a single
site, with no voice traffic carried over the IP WAN.
• Multi-Site WAN Deployments with Centralized Call Processing, page 6-24, consist of a single call
processing agent that provides service for many sites connected through an IP WAN.
• Multi-Site WAN Deployments with Distributed Call Processing, page 6-26, consist of call
processing agents residing at each of several remote sites connected through an IP WAN.
• IP PSTN Access, page 6-27, is another scenario that requires MTP resources, and it applies to all of
the preceding deployment models.

Single-Site Deployments
In a single-site deployment, there is no need for transcoding because there are no low-speed links to
justify the use of a low bit-rate (LBR) codec. Some MTP resources might be required in the presence of
a significant number of devices that are not compliant with H.323v2, such as older versions of Microsoft
NetMeeting or certain video devices. Another case in which MTP resources might be needed is that of
a single site accessing the PSTN via an IP PSTN provider (see IP PSTN Access, page 6-27).

Multi-Site WAN Deployments with Centralized Call Processing

In a centralized call processing deployment, the Cisco CallManager cluster and the applications (such
as voice mail and IVR) are located at the central site, while several remote sites are connected through
an IP WAN. The remote sites rely on the centralized Cisco CallManagers to handle their call processing.
Because WAN bandwidth is typically limited, calls are configured to use a low bit-rate codec, such as
G.729, when traversing the WAN. See Figure 6-4.
Voice compression between IP phones is easily configured through the use of regions and locations in
Cisco CallManager. A region defines the type of compression (for example, G.711 or G.729) used by the
devices in that region, and a location specifies the total amount of bandwidth available for calls to and
from devices at that location.

Cisco IP Telephony SRND

6-24 OL-7447-03
 Chapter 6 Media Resources
Transcoding Guidelines and Application Scenarios

With current versions of Cisco applications, it is possible and recommended to avoid use of transcoding
resources. The Cisco CRS (Release 3.0 or later) applications can support either G.711 or G.729, but not
both simultaneously. If both codecs are required, then you can use two separate servers. If you are using
a single server with G.711, then transcoding resources become necessary.
Prior to Cisco CRS Release 3.0, the applications supported only G.711, which requires use of
transcoding when two codec types are used in a centralized call processing deployment.

Figure 6-4 Transcoding for the WAN with Centralized Call Processing

VM/UM Server CallManager

G.711 only Cluster

M
Router/GW Router/GW

IP WAN IP
IP

IP
Xcode

Compressed Call Leg

G.711 Call Leg
DSP Farm

77304
Xcode

Cisco CallManager uses media resource groups (MRGs) to enable sharing of MTP and transcoding
resources among the Cisco CallManager servers within a cluster. In addition, when using an LBR codec
(for example, G.729) for calls that traverse different regions, the transcoding resources are used only if
one (or both) of the endpoints is unable to use the LBR codec. This means that, even with G.711-only
applications at the central site and H.323 gateways at the remote sites, the gateways are not always
required to go through a transcoder.

Note For Cisco CallManager releases prior to Release 3.3(2), the MTP and transcoding resources must be
located at the central site with the Cisco CallManager cluster because they cannot be configured in a
location for call admission control.

In summary, Cisco CallManager provides the following features:

• Optimum utilization of the transcoding resources through resource sharing across the
Cisco CallManager cluster
• Efficient utilization of the resources through dynamic allocation of transcoding resources only when
required by one or both of the endpoints

Cisco IP Telephony SRND

OL-7447-03 6-25
 Chapter 6 Media Resources
Transcoding Guidelines and Application Scenarios

Multi-Site WAN Deployments with Distributed Call Processing

In distributed call processing deployments, several sites are connected through an IP WAN. Each site
contains a Cisco CallManager cluster that can, in turn, follow the single-site model or the centralized
call processing model. A gatekeeper may be used for call admission control between sites.
Because WAN bandwidth is typically limited, calls between sites are configured to use an LBR codec
(such as G.729) when traversing the WAN. H.323v2 intercluster trunks are used to connect
Cisco CallManager clusters. Cisco CallManager also supports compressed voice call connections
through the MTP service if a hardware MTP is used. (See Figure 6-5.)
A distributed call processing deployment might need transcoding and MTP services in the following
situations:
• With current versions of Cisco applications, it is possible and recommended to avoid use of
transcoding resources. The Cisco CRS (Release 3.0 or later) applications can support either G.711
or G.729, but not both simultaneously. If both codecs are required, then you can use two separate
servers. If you are using a single server with G.711, then transcoding resources become necessary.
Prior to Cisco CRS Release 3.0, the applications supported only G.711, which requires use of
transcoding when two codec types are used in a distributed call processing deployment.
• Some endpoints (for example, video endpoints) do not support the H.323v2 features.

Figure 6-5 Intercluster Call Flow with Transcoding

Region A Region B

G.711 only
IVR CallManager A CallManager B

M M
Router/GW Router/GW
IP IP
IP WAN

IP IP

Xcode Xcode
Transcoding

Region BW M atrix Co m pressed Call Leg Regi on BW M atrix

G.711 Call Leg
A to A = G.711 B to B = G .711
77306

A to B = G.729 = DSP Fa rm B to A = G.729

Xcode

Cisco CallManager uses media resource groups (MRGs) to enable sharing of MTP and transcoding
resources among the Cisco CallManager servers within a cluster. In addition, for calls across intercluster
trunks, MTP and transcoding resources are used only when needed, thus eliminating the need to
configure the MTP service for applications that do not support LBR codecs.

Cisco IP Telephony SRND

6-26 OL-7447-03
 Chapter 6 Media Resources
Transcoding Guidelines and Application Scenarios

The following characteristics apply to distributed call processing deployments:

• Only the intercluster calls that require transcoding will use the MTP service. For example, if both
endpoints of a call are capable of using a G.729 codec, no transcoding resources will be used.
• Sharing MTP resources among servers within a cluster provides more efficient resource utilization.

IP PSTN Access
The fourth application scenario for MTP and transcoding resources involves a service provider that
provides its customers with access to an IP PSTN instead of the traditional PSTN. In such a scenario,
the gatekeepers reside in the service provider network. In order to simplify the dial plan, each customer
is required to use an MTP to anchor its calls, so that the individual IP addresses assigned to the endpoints
can be hidden. The service provider’s central office can then relay through the traditional PSTN and/or
provide IP connectivity to other customers. Figure 6-6 illustrates this deployment model.

Figure 6-6 IP PSTN Access Example

IP

IP
DSP Gatekeeper(s)

Other Customer
V V
IP PSTN V
M
V

IP PSTN
s. V

IP Central Office
DSP
77307

Customer Site

Note that the customer site in Figure 6-6 can use any of the previous three deployment models: single
site, multi-site WAN with centralized call processing, or multi-site WAN with distributed call
processing.
The H.323 trunk from the customer site to the IP PSTN must be configured with MTP so that the
endpoint IP addresses remain masked. Thus, all external calls use the MTP resources. However, MTP
resources can be shared within the Cisco CallManager cluster to achieve more efficient use of the
resources.

Cisco IP Telephony SRND

OL-7447-03 6-27
 Chapter 6 Media Resources
Transcoding Guidelines and Application Scenarios

Cisco IP Telephony SRND

6-28 OL-7447-03