Six Weeks Project based Summer Training in Delhi/NCR

Summer Training/Industrial Training/Summer Internship

Network Bulls is Best Institute for Cisco CCNA, CCNA Security, CCNA Voice, CCNP, CCNP Security/CCSP and CCIE R&S/Security course/certifications Training in India. Network Bulls is a Networking Training and Network Consultancy company. Network Bulls offer Summer Trainings and Summer Internship programs for Btech BE and BCA Candidates. There are different programs for Summer Training Candidates. Those who are willing to take Six weeks summer training, they can join CCNA course as their training. We provide Projects on Real Cisco Networks. This would be a Project Based Industrial/Summer Training, which will be held in Delhi NCR region in Gurgaon.

Network Bulls has Biggest Cisco networking Training labs in North India. Students must visit Network Bulls and compare the labs with other training companies.

Network Bulls has a team of CCIE Certified Trainers and Dual CCIE Trainers.

We offer 24x7 labs Facility, as students can stay in nights for practice on real routers and switches.

During Summer Training programs, students will get 24x7 Lab access and project on real devices. Students will get a chance to implement a real Network and to troubleshoot on a Network topology. After their Networking Training in Summer Training or Industrial Training, students will get Training Certificate, Project certificate, Experience Letter and Awards to best candidates.

6/Six Weeks Summer Training in networking options:

Courses	CCNA	MCSE	MCITP	CCNA Sec	Linux	CEH
Training Fee	Rs 7,000/-	Rs 10,000/-	Rs 12,000/-	Rs 9,000/-	Rs 12,000/-	Rs 8,000/-

Call Park India's Best Cisco CCIE security Coaching Institute in Delhi

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192


408 Chapter 16: User Features
The call park feature works within a CUCM cluster. Each CUCM in a cluster must have its
own call park extension numbers defined, because the call park configuration is done on a
CUCM, not per cluster. Either a single directory number (DN) or a range of DNs can be
defined for use as call park extension numbers, up to 100 call park numbers per CUCM
cluster. call park numbers cannot overlap between CUCM servers.
CUCM can park only one call at each call park extension number.
Figure 16-1 shows how to use the Call Park feature, as follows:
1. The user on Phone A calls Phone B.
2. The user on Phone A wants to take the call in a conference room for privacy. The Phone
A user presses the Park softkey.
3. The CUCM server to which Phone A is registered sends the first available call park
number, which displays on Phone A. The user on Phone A watches the display for the
call park DN (so that he can dial that DN on Phone C).
4. The user on Phone A leaves the office and walks to an available conference room where
the phone is designated as Phone C. The user goes off-hook on Phone C and dials 1234
to retrieve the parked call.
5. The system establishes the call between Phones C and B.
The call park feature can also be used across CUCM clusters.
Figure 16-1 Call Park
CUCM
“1234”
A B
C
IP
IP 1 IP
2 Call Park
Sends Call Park
Code to Display
on Phone
3
Dial “1234” to
Pick Up Call
4
5
Initial Stream Call Park Code Final Stream
Call Park 409
The call park feature is configured by navigating to Call Routing > Call Park in CUCM
Administration. A maximum of 100 call park extension numbers can be provisioned per
CUCM cluster. Each CUCM server must have its own portion of call park numbers carved
out of the cluster wide maximum of 100 call park numbers. When a call gets parked,
CUCM chooses the next call park extension number that is available and displays that
number on the phone. The call park configuration is illustrated in Figure 16-2.
Figure 16-2 Call Park Configuration
Directed call park numbers can be configured in the CUCM Directed Call Park Configuration
window. Directed call park numbers exist cluster-wide. Phones that support the
directed call park Busy Lamp Field (BLF) can be configured to monitor the busy/idle status
of specific directed call park numbers. Users can also use the BLF to speed dial a directed
call park number. The directed call park feature enables users to point the call to a number
they use, whereas call park automatically assigns a DN.
CUCM can park only one call at each directed call park number. To retrieve a parked call,
a user must dial a configured retrieval prefix followed by the directed call park number at
which the call is parked. Configure the retrieval prefix in the Directed Call Park
Configuration window.
Figure 16-3 shows the directed call park process explained in the list that follows:
1. Users A and B connect in a call.
2. To park the call, A presses the Transfer softkey and dials the directed call park
number 80.
3. User A presses the Transfer softkey again to complete the directed call park transfer.
This action parks A2 on directed call park number 80.
4. Phone C dials the directed call park prefix (21) followed by the directed call park
number 80 to retrieve the call. After dialing the pattern of 2180, C connects to B.
5. If the call is not retrieved before expiration of the call park reversion timer configured
in the service parameter, the call reverts to the configured reversion number.
410 Chapter 16: User Features
Figure 16-3 Directed Call Park
Any phone that can perform a transfer can use directed call park. The directed call park
feature does not require special installation. To configure directed call park, define a unique
directed call park number or a range of directed call park numbers. 40XX configures a
range of directed call parks (4000 to 4099).
Directed call park is configured by navigating to Call Routing > Directed Call Park in
CUCM Administration. The directed call park configuration is illustrated in Figure 16-4.

Media Resource Access Control CCSP Coaching Institute in Delhi India

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

All media resources are located in a null media resource group by default. Usage of media
resources is load balanced between all existing devices. Hardware resources are preferred
in the selection algorithm based on their enhanced capabilities (multiple audio codec
support) and the reduction of load on the CUCM.
Media resource management controls and manages the media resources within a cluster.
The Media Resource Manager (MRM) service enhances CUCM features by making it
easier for CUCM to control access to transcoder, annunciator, conferencing, MTP, and
MoH resources.
Media resource groups (MRG) define logical groupings of media resources. MRGs create
a logical collection of resources and are normally arranged to service a geographical
location.
Media resource group lists (MRGL) specify a list of prioritized MRGs. An application
can select required media resources from among the available resources according to the
priority order that is defined in the MRGL. MRGLs are assigned to devices or device pools.
Figure 15-19 illustrates the hierarchical processing order of media resources. MRGLs are
similar to route lists, whereas MRGs are similar to route groups.
Figure 15-19 Media Resource Management
IP
Media Resource
1
Media Resource
2
Media
Resource
Group
Media
Resource
Group
Media
Resource
Group List
Media
Resource
Manager
Media Request
First
Choice
Second
Choice
Assigned to Device
or Device Pool
Similar to Route Lists and
Route Groups
Media Resource
3
Media Resource
4
Media Resource Access Control 399
Figure 15-20 shows a media resource management scenario based on arbitrary values for
learning purposes.
Figure 15-20 Media Resource Management Example
The five conference bridges in Figure 15-20 have the following capabilities:
■ HW_CFB_1: 2 conference capacity
■ HW_CFB_2: 1 conference capacity
■ SW_CFB_1: 1 conference capacity
■ SW_CFB_2: 1 conference capacity
■ SW_CFB_3: 1 conference capacity
The following media resource groups have been configured:
■ MRG_HW-CFB: HW_CFB_1 and HW_CFB_2
■ MRG_SW-CFB: SW_CFB_1 and SW_CFB_2
■ SW_CFB_3: Not assigned to an MRG
The MRGL of MRGL_CFB has MRG_HW-CFB configured as first priority and
MRG_SW-CFB listed as second priority.
Conf. 1
HW_CFB_1
(Default - no MRG)
SW_CFB_3 (1 conf.)
MRGL CFB
1. MRG HW_CFB
2. MRG SW_CFB
IP
Conf. 2
HW_CFB_2
IP
Conf. 3
HW_CFB_1
IP
Conf. 4
SW_CFB_1
IP
Conf. 5
SW_CFB_2
IP
Conf. 6
SW_CFB_3
IP
MRG HW-CFB
HW_CFB_1 (2 conf.)
HW_CFB_2 (1 conf.)
SW_CFB_1 (1 conf.)
SW_CFB_2 (1 conf.)
MRG SW-CFB
400 Chapter 15: Media Resources
Assume that six conferences are established from devices that all use the MRGL_CFB
MRGL. The conference bridges will be allocated in the following way:
■ The first conference uses conference bridge HW_CFB_1. The second conference uses
conference bridge HW_CFB_2, because the resources within an MRG are load shared
and not used in the configured order. The third conference uses HW_CFB_1 again
because there are available resources available in that conference bridge resource.
■ The fourth conference uses a resource in the second media resource group because the
first is out of resources. The fourth conference uses SW_CFB_1, and the fifth
conference uses SW_CFB_2.
■ The sixth conference does not find a free resource in either MRG, but it finds
SW_CFB_3 in the default list. Resources not assigned to a media resource group can
be used by any device.
Three configuration steps are required to configure media resource access control:
Step 1 Configure the MRGs.
Step 2 Configure the MRGLs.
Step 3 Assign the MRGLs to phones.
To add an MRG, navigate to Media Resources > Media Resource Group in CUCM
Administration. At the Media Resource Group Configuration window, enter a name and
description for the MRG and add the desired media resources to the MRG. An MRG
configuration is illustrated in Figure 15-21.
To add an MRGL, navigate to Media Resources > Media Resource Group List in CUCM
Administration. At the Media Resource Group List Configuration window, enter a name for
the MRGL and add the desired MRG to the MRGL.
Because the order of MRGs within a MRGL specifies the priorities of the MRG, it is
important to list the MRGs in the desired order. In Figure 15-22, hardware conference
bridges should be used before software conference bridges.
Media Resource Access Control 401
Figure 15-21 Media Resource Group Configuration
Figure 15-22 Media Resource Group List Configuration
402 Chapter 15: Media Resources
MRGLs can be assigned to devices (phones, trunks, or gateways) or to device pools. In
Figure 15-23, an MRGL is assigned directly to an IP phone. If the device pool associated
with the phone has a different MRGL, the phone configuration overrides the device pool
inheritance.

Annunciator CCNP Coaching Institute in Delhi India

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

An annunciator is automatically created in the system when the Cisco IPVMS is activated
on a server. If Cisco IPVMS is deactivated, the annunciator is also deleted. A single
annunciator instance can service the entire CUCM cluster if it meets the performance
requirements. Additional annunciators can be configured for the cluster if necessary.
The annunciator registers with a single CUCM at a time, as defined by its device pool. It
automatically fails over to a secondary CUCM if a secondary is configured for the device
pool. Any announcement that is playing at the time of an outage is not maintained.
The annunciator service is responsible for the following features:
■ 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 (prioritization) access limitation was reached.
—The attempted precedence level was unauthorized.
—The called number is not equipped for preemption or call waiting.
■ Integration via SIP trunk: SIP endpoints can generate and send tones in-band in the
RTP stream, but SCCP cannot. An annunciator is used in conjunction with an MTP to
generate or accept Dual-Tone Multifrequency (DTMF) tones when integrating with a
SIP endpoint.
■ Cisco IOS gateways and intercluster trunks: These devices require support for callprogress
tone (ringback tone).
NOTE When you are using multicast MoH for devices that are not in the same IP
subnet, multicast routing has to be enabled in the IP network.
Annunciator 397
■ 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 because of 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.
The annunciator is configured to support 48 simultaneous streams by default. The
maximum recommended is 48 for an annunciator running on the same server with the
CUCM service (call processing).
If the server has only 10-Mbps connectivity, lower the setting to 24 simultaneous streams. A
standalone server without the CUCM 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. Multiple standalone servers can be added to support
the required number of streams. The maximum streams are configured in the Cisco IPVMS
service parameters.
The annunciator can be configured by navigating to Media Resources > Annunciator
from CUCM Administration. Figure 15-18 shows the annunciator configuration.

Music on Hold Best CCNA Coaching Institute in Delhi India

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

CUCM may be configured to provide MoH. The MoH feature has two main requirements:
■ An MoH server must provide the MoH audio stream sources.
■ CUCM must be configured to use the MoH streams provided by the MoH server when
a call is placed on hold.
The integrated MoH feature enables users to place on-net and off-net callers on hold with
music instead of the default “one on hold.” The MoH source makes music available to
any on-net or off-net device placed on hold. On-net devices include Cisco IP Phones and
applications placed on hold. Off-net users include those connected through MGCP, SIP, and
H.323 gateways. The MoH feature is also available for plain old telephony service (POTS)
phones connected to the Cisco IP network through Foreign Exchange Station (FXS) ports.
It is also possible to configure multicast MoH streaming to leverage external media servers
providing media streams. CUCM Express and Cisco Unified Survivable Remote Site
NOTE Meet-me bridges do not offer any security, scheduling, or name-confirmation
features. Security and scheduling features are offered by the Cisco MeetingPlace and
Cisco MeetingPlace Express products. The conference controller could be given access
to the ConfList softkey, which will allow the controller to view the conference participants
by caller ID information. The conference controller can individually remove users,
but the conference controller does not have access to the users’ line state information.
Cisco MeetingPlace and MeetingPlace Express allow the conference controller to see
which conference participant has a phone on hold. This is especially useful if MoH
is being injected into the conference bridge. If the bridge has not been set up by the
controller, callers to the meet-me number pattern receive a reorder tone.
Music on Hold 389
Telephony (SRST) gateways can be configured as media streaming servers for MoH, too.
The CUCME and SRST router-based resources provide MoH by streaming one audio file
stored in the router’s flash memory or a fixed audio source connected through an optional
E&M (ear and mouth) hardware interface. You can find detailed information about this
feature in the CUCM Solution Reference Network Design (SRND) Guide.
The CUCM integrated MoH Server supports multicast and unicast for MoH streaming. The
advantage of using multicast for MoH streaming over unicast is to save bandwidth and to
reduce load on the MoH server. Saving bandwidth is normally not a major issue for campus
LAN environments, but reducing load on the MoH server is always a big consideration.
Reducing the number of media streams is especially advantageous when the MoH server is
co-located on the same server as call processing. It is advisable to scope MoH traffic to the
local site so that MoH does not consume WAN bandwidth. There are various ways of
implementing multicast scoping and unicast filtering on the data network.
MoH audio codecs (G.711ulaw, G.711alaw, Cisco wideband, and G.729) are generated by
CUCM when files with a .wav extension are uploaded to the MoH server. The recommended
format for audio source files includes the following specifications:
■ 16-bit PCM WAV file
■ Stereo or mono
■ Sample rates of 48 kHz, 32 kHz, 16 kHz, or 8 kHz
If live audio (Muzak, radio broadcast) is a requirement, MoH can be generated from a fixed
source. A sound card is required for a fixed audio source. The fixed audio source is connected
to the audio input (line in) of the local sound card. The Cisco MoH USB audio sound
card (MUSIC ON HOLD-USB-AUDIO=) must be used for connecting a fixed audio source
to the MoH server. This USB sound card is compatible with all MCS platforms supporting
CUCM Release 6.x.
This mechanism enables the use of radios, CD players, or any other compatible sound
source. The stream from the fixed audio source is transcoded in real time to support the
codec that was configured through CUCM Administration. The fixed audio source can be
transcoded into G.711 (a-law or mu-law), G.729 Annex A, and wideband, and it is the only
audio source that is transcoded in real time.
Before using a fixed audio source to transmit MoH, consider the legalities and the ramifications
of rebroadcasting copyrighted audio materials. Consult your legal department for
potential issues.
390 Chapter 15: Media Resources
A unicast MoH stream is a point-to-point, one-way audio RTP stream between the server
and one endpoint device. Unicast MoH uses a separate source stream for each connection.
As more endpoint devices receive MoH, the number of MoH streams increases. If one
hundred devices are on hold, there will be 100 independent streams of RTP traffic generated
over the network between the server and the endpoints receiving the MoH. The number of
streams can potentially have a negative effect on network throughput. Unicast MoH can
be useful in networks where multicast is not enabled or where devices are not capable of
multicast, thereby still allowing an administrator to take advantage of the MoH feature.
Multicast MoH streams are point-to-multipoint, one-way audio RTP stream between the
MoH server and the multicast group IP address. Multicast MoH conserves system resources
and bandwidth because it enables multiple users to use the same audio source stream to
provide MoH. If 100 devices were simultaneously on hold, a single multicast RTP stream
could be replicated over the network to all 100 resources. Bandwidth and server processor
utilization would be greatly reduced. It is recommended to use a multicast IP address of
239.1.1.1 through 239.255.255.254 because these multicast addresses are implicitly scoped
by the router because the IP packets are generated with a time to live (TTL) value of 2. Each
data router decrements the TTL value by 1. When a TTL of 0 is reached, the packet is not
forwarded by a router. A TTL of 0 has a drop operation.
The basic operation of MoH in a Cisco Unified Communications environment consists of
a holding party and a held party. The holding party is the endpoint placing a call on hold,
and the held party is the endpoint placed on hold, receiving MoH.
The MoH stream that an endpoint receives is determined by a combination of the user hold
audio source identifier of the device placing the endpoint on hold (holding party) and the
configured prioritized list of MoH resources of the endpoint placed on hold (held party).
The user hold audio source configured for the holding party determines the audio file that
will be streamed when the holding party puts a call on hold, and the held party’s list of MoH
resources determines the server from which the held party will receive the MoH stream.
Figure 15-12 illustrates an on-net phone being placed on hold by a phone with a different
MoH audio source identifier and server configuration. Phone B places Phone A on hold.
Phone B will instruct CUCM to place Phone A on hold with Audio Source 2 and the MoH
server relevant to Phone B’s configuration.
NOTE When multiple MoH servers are active in your network, make sure that all the
configured MoH files are available on all MoH servers.
Music on Hold 391
Figure 15-12 Music on Hold: Resource Selection
MoH Configuration
Configuration of MoH consists of four main steps. Additional configuration is required if
multicast MoH is used.
Step 1 Plan MoH server capacity.
Step 2 Configure MoH audio sources:
a. Convert MoH audio files.
b. Configure MoH audio sources.
Step 3 Configure the MoH server.
Step 4 Configure MoH service parameters.
Step 5 (Optional) Configure multicast for MoH:
a. Configure audio sources for multicast MoH.
b. Configure the server for multicast MoH.
Capacity planning is crucial to ensure that the hardware can support the anticipated MoH
volume of the network. The 7815 and 7825 servers allow up to 250 users to be placed on
hold, and the 7835 and 7845 servers allow up to 500 users to be placed on hold (co-resident
or standalone). If MoH sessions exceed the platform limitations, various issues can arise:
■ Poor MoH quality
■ Erratic MoH operation
■ Loss of MoH functionality
IP Phone B
User Hold Audio 2
MOH Server B
Phone B
Puts
Phone A
on Hold
Listen to Audio 2
Use MOH Server A
Server
MOH B
Audio 1
Audio 2
Audio 3
Audio 4
IP Phone A
User Hold Audio 4
MOH Server A
Server
MOH A
Audio 1
Audio 2
Audio 3
Audio 4
392 Chapter 15: Media Resources
The following MoH server configuration parameters affect MoH server capacity:
■ Maximum Half Duplex Streams: This parameter determines the number of devices
that can be placed on unicast MoH. This value is set to 250 by default. The Maximum
Half Duplex Streams parameter should be set to the value derived from the following
formula: (Server capacity) – [(Number of multicast MoH sources) × (Number of MoH
codecs enabled)]. The value of this parameter should never be set higher than the
hardware capacity of the server.
■ Maximum Multicast Connections: This parameter determines the number of devices
that can be placed on multicast MoH. The default value is set to 30, which represents
a maximum of 30,000. Multicast connections are configured in thousands of held
parties because multicast is scalable. The Maximum Multicast Connections parameter
should be set to a number that ensures that all devices can be placed on multicast MoH
if necessary. Although the MoH server can generate only a finite number of multicast
streams (204), a large number of held devices can join each multicast stream through
the network multicast protocols. This parameter should be set to a number that is
greater than or equal to the number of devices that might be placed on multicast
MoH at any given time.
Typically, multicast traffic is accounted for based on the number of streams being generated;
however, CUCM maintains a count of the actual number of devices placed on multicast
MoH or joined to each multicast MoH stream. This method is different from the way
multicast traffic is normally tracked. You can find additional information in the CUCM
SRND (http://www.cisco.com/go/srnd).
CUCM ships with a default MoH audio file. To add additional MoH audio files, navigate to
Media Resources > MoH Audio File Management from CUCM Administration (shown
in Figure 15-13). Click the Upload File button, and browse the local directory structure for
the WAV audio file.
Figure 15-13 Music on Hold: Audio File Conversion
Music on Hold 393
The uploaded file is automatically converted into four different audio formats. A file status
of Translation Complete indicates that the audio file has been successfully converted. If any
other status is displayed, or if the status remains open for a long period of time (conversion
can take up to several minutes), the audio file translation failed. The uploaded audio file
might be in the wrong file format or have improper audio qualities.
Navigate to Media Resources > Music On Hold Audio Source from CUCM Administration
to configure the MoH audio sources, as illustrated in Figure 15-14. The MoH audio
sources are identified by an MoH audio stream number from 1 to 51. Up to 50 prerecorded
sources and 1 live audio source are available per CUCM cluster.
In the Music On Hold Audio Source Configuration window, select the MoH audio stream
number of the audio source that you want to configure. Choose the MoH audio source file.
The MoH audio source name defaults to the MoH audio source filename, but it can be
modified. Enable continuous playing (repeat) of the audio file if desired.
Figure 15-14 Music on Hold: Audio Source Configuration
If a fixed audio source will be used, navigate to Media Resources > Fixed MoH Audio
Source from CUCM Administration to configure a fixed MoH audio source. The source ID
is 51 and cannot be modified. The name of the fixed MoH audio source has to be entered,
and the fixed MoH audio source must be enabled. Figure 15-15 shows this configuration.
394 Chapter 15: Media Resources
Figure 15-15 Music on Hold: Fixed Audio Source Configuration
Navigate to Media Resources > Music On Hold Server from CUCM Administration to
configure the MoH server parameters. Figure 15-16 illustrates the default configuration of
the MoH media resource. Various parameters can be modified. It is best practice to use a
media resource device pool. If MoH functionality is not desired on this server, but other
services of the Cisco IPVMS are, the run flag should be set to No. If a fixed audio source
that is physically connected to the server is used, the name of the audio source device has
to be specified.
Figure 15-16 Music on Hold: Server Configuration
Music on Hold 395
The following list of CUCM service parameters and the associated defaults are related to
MoH:
■ Suppress MoH to Conference Bridge (True)
■ Default Network Hold MoH Audio Source ID (1)
■ Default User Hold MoH Audio Source ID (1)
■ Duplex Streaming Enabled (False)
To enable multicast MoH on an MoH server, the Multicast Audio Source Information
section of the MoH server configuration window must be configured. Check the Enable
Multicast Audio Sources on This MoH Server check box. The Base Multicast IP Address,
Base Multicast Port Number, and Increment Multicast On parameters are automatically
populated when you enable multicast MoH on the server. You can modify these values
if desired. Figure 15-17 shows this section of the MoH Server Configuration page.
Figure 15-17 Music on Hold: Server Configuration (Multicast Settings)
All MoH audio sources that have been configured to allow multicasting are listed in the
Selected Multicast Audio Sources section of the MoH Server Configuration window. Each
audio source can have a different Max Hops value (default is 2). This parameter sets the
TTL value in the IP header of the multicast MoH RTP packets to the specified value. The
NOTE It is recommended to increment multicast on IP address rather than port number
to avoid network saturation in firewall situations. This results in each multicast audio
source having a unique IP address and helps to avoid network saturation.
396 Chapter 15: Media Resources
TTL field in an IP packet indicates the maximum number of routers that an audio source is
allowed to cross. If the Max Hops value is set to 1, the multicast MoH RTP packets remain
in the subnet of the multicast MoH server.
Check the Allow Multicasting check box for each MoH audio source. This applies to MoH
audio sources and to fixed MoH audio sources.

Conferencing Cisco's Best CCIE Security Training Center in Delhi

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

The CUCM supports hardware and software conference bridges.
The software-based conference bridge, implemented as a CUCM service, supports only
conferences, using a single audio codec (G.711 or Cisco wideband).
V
IP
IP
PSTN
Annunciator
GW
Audio Signaling
V
IP
IP
PSTN
Integrated
MOH Server
GW
MOH Stream
MOH
Audio Signaling
Conferencing 375
Some hardware conference bridges can support multiple low bit-rate (LBR) stream types
such as G.729, Global System for Mobile Communications (GSM), G.723, and iLBC. A
mixed-mode conference is a conference in which multiple audio codecs are used for different
audio streams. A mixed-mode conference bridge has the added burden of transcoding
the RTP bearer streams. Mixed-mode conferences limit the number of conference participants
and active conferences based on the capabilities of the hardware. There are multiple
hardware conference bridge families that should be investigated.
Software conferencing scalability is limited by the server platform CUCM is running on.
Conferencing capabilities of the server are throttled by default because it is assumed that
CUCM will be running call processing co-resident while providing conferencing capabilities.
The number of streams can be tuned up to 64 ad hoc conference participants and 128
meet-me conference participants on a standalone server (dependent on the server hardware
platform). A standalone server is dedicated to providing services to the CUCM, but it never
performs call processing (call setup and teardown).
A hardware conference bridge can support multiple LBR audio stream types, including
G.729, GSM, G.723, and iLBC.
All conference bridges that are under the control of CUCM currently use SCCP to
communicate with CUCM.
CUCM allocates a conference bridge from a conferencing resource that is registered with
the CUCM cluster. Both hardware and software conferencing resources can register with
CUCM at the same time, and CUCM can allocate conference bridges from either resource.
CUCM does not distinguish between these types of conference bridges when it processes
conference allocation requests.
The number of individual conferences and maximum number of participants per
conference varies by resource.
NOTE Hardware conference capabilities are well documented in the CUCM Solution
Reference Network Design Guide available at http://www.cisco.com/go/srnd. The DSP
Calculator should also be used when designing a solution involving hardware media
resources. As mentioned previously, the DSP Calculator is available at http://
www.cisco.com/go/dspcalculator.
376 Chapter 15: Media Resources
Cisco Conference Bridge Hardware
The following types of hardware conference bridge resources may be used on a CUCM
system:
■ Cisco Conference Bridge Hardware (Cisco Catalyst WS-X6608-T1 and WS-X6608-E1)
■ Cisco IOS Conference Bridge (Cisco NM-HDV)
■ Cisco Conference Bridge (Cisco WS-SVC-CMM and WS-SVC-CMM-ACT)
■ Cisco IOS Enhanced Conference Bridge (Cisco NM-HDV2, NM-HD-1V/2V/2VE,
PVDM2)
■ Cisco Video Conference Bridge (CUVC-3510 or 3540)
Cisco Conference Bridge Hardware (Cisco Catalyst WS-X6608-T1 and WS-X6608-E1)
This hardware has eight DSPs that are physically associated to each port, and there are eight
ports per card. The 6608 module is supported only in the Catalyst operating system of the
6500 series switch.
Configuration of the DSPs is at the port level, so all DSPs associated to a port perform the
same function.
Conference bridges may have up to 32 participants, and each port supports 32 conference
bridges.
For conferences with G.711 or G.723, there may be 32 conferences per port. If G.729 calls
are used, there may be 24 conferences per port. The 6608-T1/E1 gateway module is end of
sale (EoS).
Cisco IOS Conference Bridge (Cisco NM-HDV and 1700 Series Routers)
This hardware uses the PVDM-256K-type modules that are based on the C549 DSP
chipset. Conferences using this hardware provide bridges that allow up to six participants
in a single bridge.
The resources are configured per DSP for conference bridges.
The NM-HDV may have up to four PVDM-256K modules, whereas the Cisco 1700 series
routers may have one or two PVDM-256K modules.
Each DSP provides a single conference bridge that can accept G.711 or G.729 calls.
The Cisco 1751 is limited to 5 conference calls per chassis, and the Cisco 1760 can support
20 conference calls per chassis.
Conferencing 377
Any PVDM2-based hardware, such as the NM-HDV2, may be used simultaneously in a
single chassis for voice termination but may not be used simultaneously for other media
resource functionality. The DSPs based on PVDM-256K and PVDM2 have different DSP
farm configurations, and only one may be configured in a router at a time.
Cisco Conference Bridge (Cisco WS-SVC-CMM-ACT)
This Cisco Catalyst-based hardware provides DSP resources that may provide conference
bridges of up to 32 participants per bridge.
Each module contains 4 DSPs that are individually configurable, and each DSP can support
32 conference bridges.
The G.711 and G.729 codecs are supported on these conference bridges without extra
transcoder resources. However, transcoder resources are necessary if other codecs are used.
Cisco IOS Enhanced Conference Bridge (Cisco NM-HDV2, NM-HD-1V/2V/2VE, 2800
Series, and 3800 Series Routers)
Based on the Texas Instruments (TI) C5510 DSP chipset, the NM-HDV2 and the router
chassis use the PVDM2 (Packet Voice DSP Modules - 2nd generation) modules for
providing DSPs.
DSPs on PVDM2 hardware are configured individually as voice termination, conferencing,
media termination, or transcoding resources. The DSPs on a single PVDM may be used
as different resource types. Allocate DSPs to voice termination first, and then to other
functionality as needed.
The NM-HDV2 (high-density voice) has four slots that will accept PVDM2 modules in any
combination. The other network modules have fixed numbers of DSPs.
A conference based on these DSPs allows a maximum of eight participants. When a
conference begins, all eight positions are reserved at that time. This means that unused
DSP resources on the same DSP chip are not available for other conferences.
The PVDM2-8 is listed as having a DSP because it has a DSP that has half the processing
capacity of the PVDM2-16. If the DSP on a PVDM2-8 is configured for G.711, it can
provide (0.5 x 8) bridges/DSP = 4 conference bridges. PVDM2 modules are available in 8,
16, 32, 48, or 64 quantities. The number of resources uses a divisor of 16. A PVDM2-64
has 64/8, or 8 DSP resources, which will allow up to 64 conferences with 8 conference
participants in each conference. The PVDM2 I/O limits the number of conference streams
in this scenario because 512 (64 × 8) audio streams are possible with 64 conferences of 8
conference participants.
378 Chapter 15: Media Resources
A DSP farm is a configuration parameter in Cisco IOS that specifies which codecs are
supported for the DSPs that are working together (farming). A DSP farm that is configured
for conferencing for G.711 provides 8 conferences. When configured to accept both G.711
and G.729 calls, a single DSP provides two conferences because it is also reserving its
resources for performing transcoding of streams.
The I/O of an NM-HDV2 is limited to 400 streams, so ensure that the number of conference
resources allocated does not cause this limit to be exceeded. If G.711 conferences are
configured, no more than 6 DSPs (total of 48 conferences with 8 participants each) should
be allocated per NM because 48 × 8 participants = 384 streams. If all conferencing is
configured for both G.711 and G.729 codecs, each DSP provides only two conferences
of eight participants each. In this case, it is possible to populate the network module (NM)
fully and configure it with 16 DSPs (PVDM2-64) because there can only be 2 conferences
with 8 participants (16) in each of the 16 DSPs (16 × 16 = 256 streams).
Conferences cannot natively accept calls using the GSM codec. A transcoder must be
provided separately for these calls to participate in a conference.
Meet-me conferences allow users to dial in to a conference. Ad hoc conferences allow the
conference controller to add specific participants to the conference.
Meet-me conferences require that a range of directory numbers (DN) be allocated for
exclusive use of the conference. When a meet-me conference is set up, the conference
controller chooses a DN and advertises it to members of the group. The users call the
DN to join the conference after the conference controller has set up the bridge using the
MeetMe softkey.
Ad hoc conferences comprise two types: basic and advanced. In basic ad hoc conferencing,
the originator of the conference acts as the controller of the conference and is the only
participant who can add or remove other participants.
In advanced ad hoc conferencing, any participant can add or remove other participants; that
capability is not limited to the originator of the conference. Advanced ad hoc conferencing
also allows linking multiple ad hoc conferences. Set the Advanced Ad Hoc Conference
Enabled cluster-wide service parameter to True to gain access to advanced ad hoc
conferencing. Advanced ad hoc conferencing is also referred to as conference chaining.
Conferencing 379
Conferencing Media Resource Configuration
The following steps are required to configure media resources:
1. Configure software conference media resources (if desired).
a. Enable the IP Voice Media Streaming application service.
b. Configure IP Voice Media Streaming application service parameters.
c. Configure desired software conferencing media resources.
2. Implement hardware conference media resources (if desired).
a. Configure hardware media resources in CUCM.
b. Configure hardware media resources in Cisco IOS.
c. Verify that hardware media resources are registered with CUCM.
The Cisco IP Voice Media Streaming application service is activated in Cisco Unified
Serviceability at Tools > Service Activation. At the top of the Service Activation window,
the server on which services should be activated or deactivated has to be selected. After
selecting the server, check the IP Voice Media Streaming App check box (Figure 15-7)
and click Save to activate the service.
The Cisco IPVMS parameters are accessible via the CUCM Administration, System >
Service Parameters. The following two conference bridge service parameters are
illustrated in Figure 15-8:
■ Call Count: This parameter specifies the maximum number of conference participants
that the conference bridge will support. Increasing this value above the recommended
default might cause performance degradation on a CUCM server that is also performing
call processing (co-resident). If this value needs to be tuned above the default,
consider installing the Cisco IPVMS on a standalone server. Alternatively, hardware
conferencing or a version of Cisco MeetingPlace can be used to offload conferencing
processing from the call-processing server. The configurable range is 0 to 256, and the
default is 48.
■ Run Flag: This parameter determines whether the conference bridge functionality of
the Cisco IPVMS is enabled. Valid values specify True (enabled) or False. The default
is True. All media resources are turned on by default when the Cisco IPVMS is
activated. Each media service can be turned on or off individually via the service
parameters or MoH server configuration.
380 Chapter 15: Media Resources
Figure 15-7 IP Voice Media Streaming Application Service Activation
Figure 15-8 IP Voice Media Streaming Application Service Parameters
Conferencing 381
Figure 15-9 shows the default configuration of a software conference resource. The only
configurable items are Name, Description, Device Pool, Common Device Configuration,
and Location.
Figure 15-9 IP Voice Media Streaming Application Service Parameters
When adding a hardware conference bridge in CUCM, the type of conference bridge must
match the hardware family used. The IOS Enhanced Conference Bridge used in Figure 15-9
represents an NM-HDV2 or NM-HD-1V/2V/2VE, as discussed earlier in this chapter. This
particular type of conference bridge is configured by name, which must match between
CUCM and the Cisco IOS router.
To add a hardware conference bridge, navigate to Media Resources > Conference Bridge
and click the Add New button. The Conference Bridge Configuration window displays.
Enter the appropriate settings for that particular conference bridge and click Save. Figure
15-9 is based on a Cisco IOS Enhanced Conference Bridge configuration. Configurable
parameters vary by platform.
■ Conference Bridge Type: Choose Cisco IOS Enhanced Conference Bridge.
■ Conference Bridge Name: Enter a name for the conference bridge. The name must
match the name of the conference media resource as configured at the Cisco IOS router.
NOTE The CUCM software conferencing media resource supports only the G.711 and
Cisco wideband audio codecs. A hardware conference bridge or transcoder is necessary
to allow devices that use other audio codecs to participate in a conference.
382 Chapter 15: Media Resources
■ Device Pool: Choose a device pool. Best practice is to configure a separate device pool
dedicated to media resources. A good naming convention recommendation is
Media_Resources_DP.
■ Common Device Configuration: Choose the common device configuration to assign
to the conference bridge. The common device configuration includes attributes such as
MoH audio source.
■ Location: Choose the appropriate location for this conference bridge to enforce call
admission control (CAC). The location specifies the total bandwidth that is available
for calls to and from this location. A location setting of Hub_None means that the
Locations feature does not keep track of the bandwidth that this conference bridge
consumes. CAC is covered in more detail in Cisco IP Telephony Part 2.
■ Device Security Mode: This field displays for Cisco IOS Enhanced Conference Bridge
because only this audio conference bridge supports secure encrypted conferencing starting
in CUCM Version 6.0. If choosing Non Secure Conference Bridge, the nonsecure
conference establishes a TCP port connection to CUCM on port 2000. Ensure this setting
matches the security setting on the conference bridge; otherwise, the call will fail.
The Encrypted Conference Bridge setting supports the secure conference feature. Refer
to the CUCM Security Guide for secure conference bridge configuration procedures.
Figure 15-10 Cisco IOS Enhanced Conference Bridge Configuration
NOTE The name of the Cisco IOS Enhanced Conference Bridge configured in CUCM
must match the name of the conference bridge configured in the Cisco IOS router. The
name is case sensitive. Good naming conventions should be used to easily identify the
component. Prefix CFB (conference bridge), and then use a burned-in MAC address of
the router. CFB012345012345 is an example of a hardware conference bridge in a router
where the MAC address of 012345012345 is burned into the Gigabit Ethernet controller.
Conferencing 383
Example 15-1 is a configuration of a Cisco IOS Enhanced Conference Bridge. Each
command is explained following the configuration example.
■ dspfarm (DSP farm): To enable DSP farm service, use the dspfarm command in
global configuration mode. The DSP farm service is disabled by default.
■ dsp services dspfarm: To enable DSP farm services for a particular voice network
module, use the dsp services dspfarm command.
■ sccp local: To select the local interface that SCCP applications (transcoding and
conferencing) use to register with CUCM, use the sccp local command in global
configuration mode.
■ sccp ccm: To add a CUCM server to the list of available servers and set various
parameters, including IP address or DNS name, port number, and version number, use
the sccp ccm command in global configuration mode.
■ sccp: To enable the SCCP protocol and its related applications (transcoding and
conferencing), use the sccp command in global configuration mode.
■ sccp ccm group: To create a CUCM group and enter SCCP CUCM configuration
mode, use the sccp ccm group command in global configuration mode.
■ associate ccm: To associate a CUCM with a CUCM group and establish its priority
within the group, use the associate ccm command in SCCP CUCM configuration mode.
Example 15-1 Cisco IOS Configuration
voice-card 0
dspfarm
dsp services dspfarm
sccp local FastEthernet0/0.72
sccp ccm 10.1.1.1 identifier 1 version 6.0
sccp
sccp ccm group 1
associate ccm 1 priority 1
associate profile 1 register CFB001B0CC250F8
dspfarm profile 1 conference
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 2
associate application SCCP
no shutdown
384 Chapter 15: Media Resources
■ associate profile: To associate a DSP farm profile with a CUCM group, use the
associate profile command in SCCP CUCM configuration mode.
■ dspfarm profile: To enter DSP farm profile configuration mode and define a profile for
DSP farm services, use the dspfarm profile command in global configuration mode.
■ codec (DSP): To specify call density and codec complexity based on a particular codec
standard, use the codec command in DSP interface DSP farm configuration mode.
■ associate application sccp: To associate SCCP to the DSP farm profile, use the
associate application sccp command in DSP farm profile configuration mode.
■ maximum sessions (DSP farm profile): To specify the maximum number of sessions
that are supported by the profile, use the maximum sessions command in DSP farm
profile configuration mode.
■ no shutdown: If you fail to use the no shutdown command, the DSP farm profile will
display in the gateway but fail to operate.
To verify the Cisco IOS media resource configuration, use the show commands
demonstrated in Example 15-2.
Example 15-2 Verifying Cisco IOS Media Resource Configuration
show sccp
SCCP Admin State: UP
Gateway IP Address: 10.1.1.101, Port Number: 2000
IP Precedence: 5
User Masked Codec list: None
Call Manager: 10.1.1.1, Port Number: 2000
Priority: N/A, Version: 6.0, Identifier: 1
Conferencing Oper State: ACTIVE
- Cause Code: NONE
Active Call Manager: 10.1.1.1, Port Number: 2000
TCP Link Status: CONNECTED, Profile Identifier: 1
Reported Max Streams: 16, Reported Max OOS Streams: 0
Supported Codec: g711ulaw, Maximum Packetization Period: 30
Supported Codec: g711alaw, Maximum Packetization Period: 30
Supported Codec: g729ar8, Maximum Packetization Period: 60
Supported Codec: g729abr8, Maximum Packetization Period: 60
Supported Codec: g729r8, Maximum Packetization Period: 60
Supported Codec: g729br8, Maximum Packetization Period: 60
Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30
Supported Codec: rfc2833 pass-thru, Maximum Packetization Period: 30
Supported Codec: inband-dtmf to rfc2833 conversion, Maximum Packetization Period: 30
10.1.1.101
10.1.1.1
6.0
10.1.1.1
CONNECTED
Conferencing 385
Various CUCM service parameters are related to conferencing. The following conferencing
options should be considered when leveraging the conferencing features of CUCM:
■ Suppress Music on Hold to Conference Bridge: This parameter determines whether
MoH plays to a conference when a conference participant places the conference on
hold. Valid values specify True (the system does not play MoH to the conference when
a conference participant presses the Hold button) or False. The default is True.
■ Drop Ad Hoc Conference: This parameter determines how an ad hoc conference terminates.
This is an important toll-fraud prevention setting, because inside facilitators
can set up a conference call to expensive international numbers and then drop out of
show sccp ccm group 1
CCM Group Identifier: 1
Description: None
Binded Interface: NONE, IP Address: NONE
Associated CCM Id: 1, Priority in this CCM Group: 1
Associated Profile: 1, Registration Name: CFB001B0CC250F8
Registration Retries: 3, Registration Timeout: 10 sec
Keepalive Retries: 3, Keepalive Timeout: 30 sec
CCM Connect Retries: 3, CCM Connect Interval: 10 sec
Switchover Method: GRACEFUL,Switchback Method: GRACEFUL_GUARD
Switchback Interval: 10 sec, Switchback Timeout: 7200 sec
Signaling DSCP value: cs3, Audio DSCP value: ef
show dspfarm profile 1
Dspfarm Profile Configuration
Profile ID = 1, Service = CONFERENCING, Resource ID = 1
Profile Description :
Profile Admin State : UP
Profile Operation State : ACTIVE
Application : SCCP Status : ASSOCIATED
Resource Provider : FLEX_DSPRM Status : UP
Number of Resource Configured : 2
Number of Resource Available : 2
Codec Configuration
Codec : g711ulaw, Maximum Packetization Period : 30 , Transcoder: Not Required
Codec : g711alaw, Maximum Packetization Period : 30 , Transcoder: Not Required
Codec : g729ar8, Maximum Packetization Period : 60 , Transcoder: Not Required
Codec : g729abr8, Maximum Packetization Period : 60 , Transcoder: Not Required
Codec : g729r8, Maximum Packetization Period : 60 , Transcoder: Not Required
Codec : g729br8, Maximum Packetization Period : 60 , Transcoder: Not Required
Example 15-2 Verifying Cisco IOS Media Resource Configuration (Continued)
1 1 CONFERENCING
386 Chapter 15: Media Resources
the call. Without the conference controller, international tariffs are billed back to the
company in which the conference call was set up. Valid values are as follows:
—Never (default): The conference remains active after the conference
controller and all on-net parties hang up. This default setting could result
in potential toll fraud.
—When Conference Controller Leaves: Terminate the conference when the
conference controller hangs up.
—When No On-Net Parties Remain in the Conference: Terminate the
conference when there are no on-net parties remaining in the conference.
This distinction is important because the conference controller might
have to drop out of the call, but other business partners on the call should
continue the conference. The When Conference Controller Leaves option
would hang up the call when the conference controller left the
conference.
■ Advanced Ad Hoc Conference Enabled: This parameter determines whether
advanced ad hoc conference features are enabled. Advanced ad hoc conference
features include the ability for conference participants other than the conference
controller to add new participants to an existing ad hoc conference (conference
chaining); the ability for any noncontroller conference participant to drop other
participants from the conference via the ConfList and RmLstC softkeys; and whether
ad hoc conferences can be linked using features such as conference, join, direct
transfer, and transfer. Valid values specify True (allow advanced ad hoc conference
features) or False. The default is False.
■ Nonlinear Ad Hoc Conference Linking Enabled: This parameter determines
whether more than two ad hoc conferences can be linked directly to an ad hoc
conference in a nonlinear fashion. Nonlinear conference linking occurs when three
or more ad hoc conferences are linked directly to one other ad hoc conference. Linear
conference linking occurs when one or two ad hoc conferences are linked directly
to one other ad hoc conference. For this parameter to work, the Advanced Ad Hoc
Conference Enabled service parameter must be set to True. Valid values specify True
(allow nonlinear conference linking so that three or more ad hoc conferences can be
linked to a single other conference) or False. The default is False. The Advanced Ad
Hoc Conference Enabled service parameter must be set to True for the Nonlinear Ad
Hoc Conference Linking Enabled service parameter to work.
■ Maximum Ad Hoc Conference: This parameter specifies the maximum number of
participants who are allowed in a single ad hoc conference. The value of this field
depends on the capabilities of the software/hardware conference bridge. The maximum
number of conference bridge participants for typical conference bridges follow:
Conferencing 387
Software, 64; Cisco Catalyst WS-X6608, 16; Cisco Catalyst 4000, 16; and NM-HDV,
6. Setting this value above the maximum capacity of the conference resource will result
in failed entrance to a conference bridge if more ports than the specific conference
bridge configuration allows are added. The range is 3 to 64. The default is 4.
■ Maximum Meet-Me Conference Unicast: This parameter specifies the maximum
number of participants that are allowed in a single meet-me conference. The value of
this field depends on the capabilities of the software/hardware conference bridge. A
software conference bridge is capable of conferencing up to 128 participants. When a
conference is created, the system automatically reserves a minimum of three streams,
so specifying a value less than 3 allows a maximum of three participants. The range is
1 to 128. The default is 4.
Meet-Me Conference Configuration
To add a range of numbers to be used for meet-me conferences in CUCM Administration,
navigate to Call Routing > Meet-Me Number/Pattern and click Add New. Configure the
new pattern with the following data:
■ Directory Number or Pattern: Enter a meet-me number or number range.
■ Description: Enter up to 30 alphanumeric characters for a description of the meet-me
number.
■ Partition: To use a partition to restrict access to the meet-me/number pattern, choose
the desired partition from the drop-down list.
■ Minimum Security Level: Choose the minimum meet-me conference security level
for this meet-me number or pattern from the drop-down list:
—ChooseAuthenticated to block participants with nonsecure phones from
joining the conference.
—Choose Encrypted to block participants with authenticated or nonsecure
phones from joining the conference.
—Choose Non Secure to allow all participants to join the conference.
Figure 15-11 shows a meet-me range of 100 numbers beginning with 4500 and ending with
4599. The numbers are not in a partition, which will allow any phone to set up a meet-me
bridge by clicking the Meet-Me softkey and dialing one of the numbers in the meet-me
number range. Subsequent meeting members will need to dial only the number of the
bridge.

Media Resource Support Cisco's Best CCSP Training Center in Delhi

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

CUCM offers software-based media resources. Start the IP Voice Media Streaming
application to activate the following:
■ Audio conferencing
■ MTP
■ Annunciator
■ MoH
370 Chapter 15: Media Resources
The following media resources are available only in hardware:
■ Transcoding
■ Voice termination
Audio conferencing and MTP media resources can also be offered by hardware media
resources. MoH is a special case. Because of the potential WAN bandwidth utilization
of MoH, the multicast streams of the server are normally scoped at the headquarters.
Survivable Remote Site Telephony (SRST) can stream one media resource at branch
locations.
The signaling between hardware media resources and CUCM most often uses SCCP to set
up and tear down calls. All audio streams from any endpoint are always terminated by the
media resources involved in the call. There is no direct IP phone-to-IP phone audio stream
with media resources involved in the call flow.
The voice-termination function is needed when an incoming or outgoing TDM call is
terminated on a gateway. The TDM leg is terminated by the Cisco IOS router’s DSP and
has to perform decoding, coding, and packetization functions.
There are two different audio streams in Figure 15-1, one inside the public switched
telephone network (PSTN), the other one a VoIP audio stream using RTP transport.
Signaling messages are exchanged between the gateway and CUCM and between the
telephony device and CUCM. The PSTN signaling is not considered in Figure 15-1.
Figure 15-1 PSTN Voice Termination
DSPs for Voice
Termination
V
IP
IP
PSTN
PSTN Call
Audio Signaling
VoIP
TDM
Media Resource Support 371
RTP bearer traffic streams are sent from the IP phones to the conference bridge resource
mixing the audio. The conference resource mixes the audio streams and sends back a
unique audio stream to the IP phones. The audio stream must subtract the audio stream of
the person receiving the audio stream so that no echo is heard. Some conference devices,
because of processing limitations, mix only the three loudest talkers.
Signaling messages (control traffic) are exchanged among the IP phones, CUCM, and
the conferencing resource (if using a hardware resource or a version of Cisco Unified
MeetingPlace). Cisco Unified MeetingPlace is not covered in this book.
Most conference bridges that are under the control of CUCM use SCCP to communicate
with CUCM. Session Initiation Protocol (SIP) support is increasingly being added to all the
Unified Communications components.
CUCM does not distinguish between software- and hardware-based conference bridges
when it processes a conference allocation request. Allocation of conferencing resources is
covered in further detail later in this chapter. The number of individual conferences and
maximum number of participants per conference varies based on the resource in use.
Figure 15-2 illustrates that software conferencing is integrated into CUCM.
Figure 15-2 Software Conferencing
NOTE The Cisco Press book Voice and Video Conferencing Fundamentals is an
excellent resource for a more thorough understanding of audio conferencing and
videoconferencing.
V
IP
IP
PSTN
Conference Call
Integrated
Conference
Bridge
GW
Audio Signaling
372 Chapter 15: Media Resources
A transcoder converts an input audio stream using one audio codec into an output stream
that uses a different audio codec. The transcoder in Figure 15-3 is implemented using DSP
resources in the Cisco router. Transcoders are necessary when audio streams are using
compressed audio codes (G.729 or iLBC), but the resource they are attempting to use
accepts only G.711 calls. iLBC is the Internet Low Bandwidth Codec, which operates at
15.2 kbps. Most Cisco Unify voice-mail deployments use the G.711 audio codec for voicemail
storage to guarantee high quality.
Audio streams (RTP bearer channels) are set up between the telephony devices and the
transcoder. Signaling messages are exchanged between the telephony devices and CUCM
and between the transcoder resource and CUCM. DSP resources are required to perform
transcoding. Those DSP resources are located in Cisco routers and switches.
Figure 15-3 Transcoding Media Resources
An MTP bridges two media streams and allows them to be set up and torn down
independently.
An MTP can be used as an instance of translation between incompatible audio streams, to
synchronize clocking, or to enable supplementary services for devices that do not support
the empty capability set (ECS) option of the H.323 Version 2 protocol.
Audio streams exist between telephony devices and the MTP resource. Signaling messages
are exchanged between the telephony devices and CUCM. Figure 15-4 illustrates a
hardware-based MTP.
V
IP
IP
PSTN
Transcoded Call
G.711
Application
Server
Hardware
Transcoding
G.729
Audio Signaling
G.711
G.729
Media Resource Support 373
Figure 15-4 Hardware MTP
An annunciator is a function of the Cisco IP Voice Media Streaming application service that
provides the ability to stream spoken messages or various call-progress tones from the
CUCM system to a user.
The annunciator can send multiple one-way RTP streams to devices such as Cisco IP Phones
or gateways, using SCCP messages to set up the RTP stream. Tones and announcements
are predefined by the system. The announcements support localization and may also be
customized by replacing the appropriate WAV file. The annunciator can support G.711
a-law, G.711 mu-law, G.729, and Cisco wideband audio codecs without transcoding
resources.
Signaling messages are exchanged between telephony devices and CUCM. The audio
stream is one way, from the annunciator to the telephony device. The annunciator is a
software component of CUCM, as shown in Figure 15-5.
The MoH feature is part of the Cisco IP Voice Media Streaming (IPVMS) service running
on CUCM. This feature provides music to callers when their call is placed on hold or a
supplementary service is initiated. Supplementary services are not limited to, but include
the following: transfer, park, and conference. When a supplementary service is initiated,
the call is temporarily put on hold before the function is completed. Implementing MoH is
relatively simple but requires a basic understanding of IP unicast and multicast traffic, MoH
call flows, configuration options, server behavior, and requirements.
V
IP
IP IP
SIP
Hardware MTP
Call Using MTP
Audio Signaling
G.711
G.711
374 Chapter 15: Media Resources
Figure 15-5 Annunciator Services
Audio streams are created between telephony devices and the MoH server. Signaling
messages are exchanged between telephony devices and CUCM. Figure 15-6 illustrates
the MoH component of CUCM.