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.
Wednesday, December 15, 2010
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.
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.
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.
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.
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.
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.
Media Resources Best Cisco CCNP 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
A media resource is a software- 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 (MTP), converting the data stream from one compression type to another (transcoding),
echo cancellation, signaling, termination of a voice stream from a time-division multiplexing
(TDM) circuit (coding/decoding), packetization of a stream, and streaming audio (annunciation).
368 Chapter 15: Media Resources
Not all the different media resources described in Table 15-1 are needed in every deployment.
Software resources are provided by CUCM services, whereas hardware features are
provided by digital signal processors (DSP). The DSP resources are hardware modules in
the gateway router or switch. The software resources are controlled by the Cisco IP Voice
Media Streaming application running on CUCM.
Table 15-1 introduces the different types of media resources.
A conference bridge is a resource that joins multiple participants into a single call. It can
accept a number of connections for a given conference, up to the maximum number of
streams allowed for a single conference on that device. 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. Software conferencing is limited to the G.711 audio
codec.
Table 15-1 Media Resource Functions
Resource Function
Voice termination TDM legs must be terminated by hardware that performs coding/decoding and
packetization of the stream. This is performed in DSPs on the gateway router.
Audio conferencing A conference bridge joins multiple participants into a single call. It mixes the
streams together and creates a unique output stream for each connected party.
Transcoding A transcoder converts an input stream from one codec into an output stream
that uses a different codec.
MTP An MTP bridges the media streams and allows them to be set up and torn
down independently.
Annunciator An annunciator streams spoken messages and various call progress tones.
Music on hold Music on hold provides music to callers when their call is placed on hold,
transferred, parked, or added to a conference.
NOTE All hardware resource limitations are well documented in the media resource
chapter of the SRND available online at http://www.cisco.com/go/srnd. It is best practice
to use the Cisco DSP Calculator, which you can find at http://www.cisco.com/go/
dspcalculator. The Cisco DSP Calculator requires Cisco.com membership access.
Media Resource Support 369
A transcoder takes the stream of one codec and converts it from one compression type to
another compression type. For example, it could take a stream from a G.711 codec and
transcode it in real time to a G.729 stream. In addition, a transcoder provides MTP
capabilities and may be used to enable supplementary services for H.323 endpoints
when required.
Two streams that use the same codec using different sampling intervals may also be
connected.
A single-site deployment usually has no need for transcoding devices.
An MTP is an entity that accepts two full-duplex G.711 streams. It bridges the media
streams 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.
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 Real-Time Transport Protocol
(RTP) streams to devices such as Cisco IP Phones or gateways, and it uses Skinny Client
Control Protocol (SCCP) messages to establish the RTP stream. The announcements may
be customized by replacing the appropriate WAV file.
Music on hold (MoH) is an integral feature of the Cisco Unified Communications system.
This feature provides music to callers when their call is placed on hold, transferred, parked,
or added to an ad hoc conference.
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
A media resource is a software- 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 (MTP), converting the data stream from one compression type to another (transcoding),
echo cancellation, signaling, termination of a voice stream from a time-division multiplexing
(TDM) circuit (coding/decoding), packetization of a stream, and streaming audio (annunciation).
368 Chapter 15: Media Resources
Not all the different media resources described in Table 15-1 are needed in every deployment.
Software resources are provided by CUCM services, whereas hardware features are
provided by digital signal processors (DSP). The DSP resources are hardware modules in
the gateway router or switch. The software resources are controlled by the Cisco IP Voice
Media Streaming application running on CUCM.
Table 15-1 introduces the different types of media resources.
A conference bridge is a resource that joins multiple participants into a single call. It can
accept a number of connections for a given conference, up to the maximum number of
streams allowed for a single conference on that device. 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. Software conferencing is limited to the G.711 audio
codec.
Table 15-1 Media Resource Functions
Resource Function
Voice termination TDM legs must be terminated by hardware that performs coding/decoding and
packetization of the stream. This is performed in DSPs on the gateway router.
Audio conferencing A conference bridge joins multiple participants into a single call. It mixes the
streams together and creates a unique output stream for each connected party.
Transcoding A transcoder converts an input stream from one codec into an output stream
that uses a different codec.
MTP An MTP bridges the media streams and allows them to be set up and torn
down independently.
Annunciator An annunciator streams spoken messages and various call progress tones.
Music on hold Music on hold provides music to callers when their call is placed on hold,
transferred, parked, or added to a conference.
NOTE All hardware resource limitations are well documented in the media resource
chapter of the SRND available online at http://www.cisco.com/go/srnd. It is best practice
to use the Cisco DSP Calculator, which you can find at http://www.cisco.com/go/
dspcalculator. The Cisco DSP Calculator requires Cisco.com membership access.
Media Resource Support 369
A transcoder takes the stream of one codec and converts it from one compression type to
another compression type. For example, it could take a stream from a G.711 codec and
transcode it in real time to a G.729 stream. In addition, a transcoder provides MTP
capabilities and may be used to enable supplementary services for H.323 endpoints
when required.
Two streams that use the same codec using different sampling intervals may also be
connected.
A single-site deployment usually has no need for transcoding devices.
An MTP is an entity that accepts two full-duplex G.711 streams. It bridges the media
streams 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.
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 Real-Time Transport Protocol
(RTP) streams to devices such as Cisco IP Phones or gateways, and it uses Skinny Client
Control Protocol (SCCP) messages to establish the RTP stream. The announcements may
be customized by replacing the appropriate WAV file.
Music on hold (MoH) is an integral feature of the Cisco Unified Communications system.
This feature provides music to callers when their call is placed on hold, transferred, parked,
or added to an ad hoc conference.
Call Hunting Best CIsco CCNA 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 call-hunting implementation is composed of the following components:
■ Phone DNs or voice-mail ports are assigned to line groups.
■ Line groups are assigned to hunt lists. A hunt list can have one or more line groups.
Line group hunt options and distribution algorithms can be specified to define how call
hunting should be performed for the members of the line group.
■ Hunt lists are assigned to hunt pilots. A hunt list is an ordered list of one or more line
groups.
■ Hunt pilots are the numbers that will match on dialed digits to invoke the hunting
process. A hunt pilot can be called directly or a call may be forwarded to the hunt pilot
from an IP phone that received a call and is configured to forward calls to the hunt pilot
to provide call coverage.
While hunting, the forwarding configuration of line group members is not used. If the
hunting algorithm is ringing a phone and the call is not answered, the CFNA setting of that
phone is ignored, and the hunting algorithm goes on to the next line group member.
Figure 14-3 illustrates the call-hunting process and components. The hunt pilot in this
example has been configured as 1 800 555-0111. Calls are distributed among the four DNs
at the bottom of the figure.
Call Hunting 343
Figure 14-3 Call Hunting
In the following example, two line groups are configured:
■ Agents line group: Contains the DNs 2001 and 2002.
■ Operators line group: Contains the DNs 2101 and 2102.
The line groups are assigned to the hunt list HelpDesk:
■ The first line group is Agents.
■ The second line group is Operators.
A hunt pilot of HelpDesk with the pattern 2222 is configured to use hunt list HelpDesk for
call coverage.
IP IP IP IP
Line Group 1
1000 1001
Line Group 2
1003 1004
Hunt List
1 800 555-0111
Hunt Pilot
1st Choice 2nd Choice
344 Chapter 14: Call Coverage
Figure 14-4 and the list that follows illustrate the call-coverage components involved in
distributing a call from the hunt pilot.
Figure 14-4 Call-Hunting Process
1. A call is received for extension 2222. The CUCM digit analysis result matches the hunt
pilot number of 2222. The hunt pilot distributes the call to the hunt list HelpDesk.
2. The hunt list uses top-down processing of the line groups. The first line group of
Agents is processed.
3. The line group distributes the call to agent DNs. Assuming the top-down calldistribution
algorithm was selected, 2001 would ring, then 2002. The various calldistribution
algorithms are covered later in this chapter.
4. If no agent answers, the hunt list sends the call to the second line group, Operators.
5. The line group Operators distributes the call to the operator DNs.
Hunt pilots are dialable patterns in the call-routing database (similar to route patterns,
translation patterns, and DNs). The hunt pilot points to a hunt list. The hunt list points to
one or more line groups, which include DNs.
QuickTime™ and a
Graphics decompressor
are needed to see this picture. IP
Hunt List HelpDesk
Line Group Agents
2001
2002
Line Group Operators
2102
2101
User Dials 2222
1
HL distributes call
to LG.
2
If no agents answers,
HL sends call to
second LG.
4
IP
IP
IP
IP
LG distributes
call to agents.
3
LG distributes call
to operators.
5
Hunt Pilot
HelpDesk
2222
Call Hunting 345
Beginning with CUCM Release 4.1, calls can be redirected to a final destination when the
hunting fails. Hunting may fail for one of the following reasons:
■ All hunting options have been exhausted, and the call has not been answered.
■ The maximum hunt timer has expired (configured at the hunt list level).
This call redirection is configured in the Hunt Forward Settings section of the Hunt Pilot
Configuration page, and the destination for this redirect can be either of the following
options:
■ A specific destination configured globally at the hunt pilot.
■ A personal preference, configured at the DN of the originally called number when
hunting on behalf of that number fails. The personal preference is configured using the
CFNC settings at the phone line.
You can implement the personal preferences option by configuring a user’s phone so that
the Forward No Answer field redirects the call to a hunt pilot, to search for someone else
who can answer the call. If the call hunting fails, either because all the hunting options were
exhausted or because a timeout period expired, the call can be sent to a destination personalized
for the person who was originally called. For example, if the Forward No Coverage
field is set to voice mail, the call will be sent to that person’s voice-mail box when hunting
fails.
The following considerations apply to calls handled by hunt pilots:
■ Call Pickup and Group Call Pickup are not supported on calls distributed by a hunt
pilot. A member of the line group cannot pick up the hunt pilot call offered to another
member in the line group, even if they belong to the same call-pickup group.
■ The hunt pilot can distribute calls to any of its line group members, regardless of the
partition of the line group member. Class of service is not implemented in the callcoverage
paradigm.
A hunt list is a prioritized list of line groups used for call coverage. Hunt lists have the
following characteristics:
■ Multiple hunt pilots can point to the same hunt list.
■ Multiple hunt lists can contain the same line group.
■ A hunt list is a prioritized list of line groups; line groups are hunted in the order of their
configuration in the hunt list.
346 Chapter 14: Call Coverage
Line groups control the order in which a call is distributed, and they have the following
characteristics:
■ Line groups point to specific extensions, which are typically IP phone extensions or
voice-mail ports.
■ The same extension may be present in multiple line groups.
■ Line groups are configured with a global distribution algorithm that is used to select
the next line group member for hunting.
■ Line groups are configured with a hunt option that describes how hunting should be
continued after trying the first member of the line group. The hunt option is configured
per hunt failure event: No Answer, Busy, and Not Available.
■ The Ring No Answer Reversion (RNAR) timeout specifies how long the hunting
algorithm rings a member of the line group before it continues hunting according to the
line group No Answer hunt option setting.
Line group members are the endpoints accessed by line groups, and they can be of any of
the following types:
■ Any SCCP endpoints, such as Cisco Unified IP Phone models VG248 or ATA 188
■ SIP endpoints
■ Voice-mail ports
■ H.323 clients
■ Foreign Exchange Station (FXS) extensions attached to an Media Gateway Control
Protocol (MGCP) gateway
Computer telephony integration (CTI) ports and CTI route points cannot be added to a line
group. Therefore, calls cannot be distributed to endpoints controlled through CTI applications
such as Cisco Customer Response Solution (CRS), Cisco Unified IP Interactive Voice
Response (IVR), and so forth.
Call-Hunting Options and Distribution Algorithms
Various hunt options are available at the line group configuration level. The default works
for most implementations, but life is rife with options to accommodate the requirements of
various organizations and collaborative groups. The following hunt options are available:
■ Try Next Member, Then, Try Next Group in Hunt List (Default): Sends the call to
the next idle or available member of this line group. If no more members are available
in this line group, go to the next line group configured in the hunt list. If no more line
groups are available, hunting stops.
Call Hunting 347
■ Try Next Member, but Do Not Go to Next Group: Sends the call to the next idle or
available member of this line group. If no more members are available in this line
group, hunting stops.
■ Skip Remaining Members, and Go Directly to Next Group: Sends the call to the
next line group. If no more line groups are available, hunting stops.
■ Stop Hunting: Do not proceed to the next Line Group or next member.
The line group distribution algorithm specifies the order line in which group members
should be used during the hunting process. The available algorithms are as follows:
■ Top down: If you choose a top-down distribution algorithm, CUCM distributes the call
to idle or available members starting from the first idle or available member at the top
of the line group to the last idle or available member (bottom of the list). In Figure 14-5,
a top-down distribution algorithm would extend the next call to 1000, then to 1001,
then to 1002, then 1003, and back to 1000 depending on the line state of the destination
DN. An important distinction in this model is that every new call attempts to use
extension 1000, no matter how long the lines in the line group are idle. If extension
1000 is available every time there is a new call distributed, extension 1000 will receive
the call. The user at extension 1000 would be very busy in this model.
■ Circular: If you choose a circular distribution algorithm, CUCM distributes the call
to idle or available members starting from the first member of the line group (1000).
CUCM retains the most recently extended call target in memory and attempts to place
the second call to the second member of the line group (1001). The third call is distributed
to the third member of the line group (1002), and the fourth call is extended to the
fourth member of the line group (1003). The circular distribution algorithm might
appear to be the same as the top-down distribution algorithm, but it is much fairer
in its distribution of calls.
■ Longest idle time: If you choose a longest idle time distribution algorithm, CUCM
distributes the call to the member that has been idle for the longest amount of time.
Only members in the idle call state are considered by this distribution algorithm.
Available and busy call states do not receive calls. A phone in the available state is
servicing a call but can manage a second call. Figure 14-5 assumes that 1000 has
been idle for 10 minutes and 1003 has been idle for 5 minutes. A longest idle time
distribution mechanism extends the call to extension 1000.
■ Broadcast: If you choose a broadcast distribution algorithm, CUCM distributes the
call to all idle or available members of a line group simultaneously.
Distribution algorithms are configured once per line group in CUCM Administration.
348 Chapter 14: Call Coverage
Figure 14-5 Line Group Distribution Algorithms
Call-Hunting Flow
The call-hunting flow in CUCM is as follows:
1. A direct call is placed to the hunt pilot number, or a call is forwarded to the hunt pilot
number from a phone.
2. The hunt pilot starts the maximum hunt timer to monitor the overall hunting time. If
the timer expires, hunting stops, and final forwarding is performed. The hunt pilot is
logically associated with a hunt list.
3. The hunt list associated with the hunt pilot sends the call to the first line group
configured in the hunt list.
—The call is sent to the next line group member based on the distribution
algorithm configured at the line group. Each line group is attempted until
all resources are exhausted (or the maximum hunt timer expires).
4. If the call to the hunt pilot goes unanswered, hunt failure has occurred. Possible hunt
failure reasons include no one answered the phone or everyone is busy servicing other
customers.
Figure 14-6 illustrates the call-coverage distribution of a call destined to a hunt pilot of 7000.
Figure 14-7 illustrates the final forwarding options of the hunt pilot configuration.
If hunting stops (ring no answer or busy) and the hunt pilot is not configured for final
forwarding, the call fails and a reorder tone is played.
If a final forwarding number is specified at the hunt pilot, the call is routed to the number.
If Use Personal Preference is selected, the call is routed as configured for Call Forward No
Coverage at the phone line that invoked the call to the pilot number.
IP IP IP IP
1000 1001 1002 1003
Idle
10 min.
Available Idle
5 min.
Available, CUCM
Last Extended Call
Line Group 1
Call Hunting 349
Figure 14-6 Call-Hunting Flow
Figure 14-7 Call-Hunting Flow
Hunt Pilot
7000
Hunt List
First Line
Group
Second
Line Group
Direct Call to Hunt Pilot or
Call Forwarded from Phone
Call Sent to First Line Group of Hunt List
Call Sent to Next Member as per
Line Group Distribution Algorithm
If Hunt List maximum hunt
timer Expires, Stop
Hunting
No Answer (Based on
Line Group RNAR Timer)
Busy Not
Available
Stop Hunting
Go to Next Line Group
Try Next Member of This Line
Group; If None Left, Stop
Hunting
Try Next Member of This Line
Group; If None Left, Go to Next
Line Group; If No Line Group
Left, Stop Hunting
Check Line Group Hunt Option How to Continue
IP IP IP
IP
IP
Check Hunt Pilot
Final Forward
Configuration
Hunting Stopped
No Final
Forwarding
Call Failed
(Reorder)
Hunt Option: Stop Hunting
Hunt Exhaustion (No More
Line Groups or Line Group
Members)
Hunt List Maximum Hunt
Timer Expired Final
Forwarding
Number
Specified in
Hunt Pilot
Use
Personal
Preference
Route Call to
Number Specified
in Hunt Pilot
Route Call to
Number
Specified at
Phone Line
(Call Forward No
Coverage)
350 Chapter 14: Call Coverage
Call-Hunting Configuration
To access the line group, hunt list, and hunt pilot configuration windows in CUCM
Administration, choose Call Routing > Route/Hunt.
When configuring hunting, follow these steps:
Step 1 Create the line groups, add members, and configure the distribution
algorithm and hunt options.
Step 2 Create the hunt list and add the line groups.
Step 3 Create the hunt pilot, associate the hunt list with the hunt pilot, and
configure hunt forward settings.
Step 4 Configure personal preferences on phone lines in the event that hunting
ends with no coverage.
These steps are covered in more detail on the following pages.
The DNs that will become the members of the line group must already exist in the database
before you can complete this procedure. The following steps describe the creation of a line
group. The configuration of the line group is illustrated in Figure 14-8.
Step 1 Choose Call Routing > Route/Hunt > Line Group from CUCM
Administration.
Step 2 Click the Add New button.
Step 3 Enter a name in the Line Group Name field. The name can contain up to
50 alphanumeric characters and can contain any combination of spaces,
periods (.), hyphens (-), and underscore characters (_). Ensure that each
line group name is unique to the route plan. Use a naming nomenclature
that is brief and descriptive of the line group usage in the environment. It
is good practice to append _LG to the line group name so that it can be
easily identified.
Step 4 Configure the distribution algorithm, hunt options, and ring no answer
reversion (RNAR) timeout as desired. The RNAR parameter limits the
amount of time (in seconds) that each DN in the line group rings before
CUCM reports a No Answer condition.
Step 5 Add members to the line group. To locate a DN, choose a route partition
from the Partition drop-down list, enter a search string in the Directory
Number Contains field, and click Find. To find all DNs that belong to a
Call Hunting 351
partition, leave the Directory Number Contains field blank and click
Find. A list of matching DNs is displayed in the Available DN/Route
Partition pane.
Step 6 In the Available DN/Route Partition pane, select a DN to add and click
Add to Line Group to move it to the Selected DN/Route Partition pane.
Repeat this step for each member that you want to add to this line group.
Step 7 In the Selected DN/Route Partition pane, choose the order in which the
new DNs will be accessed in this line group. To change the order, click a
DN and use the up and down arrows to the right of the pane.
Step 8 Click Save to add the new DNs and to update the DN order for this line
group.
Figure 14-8 Line Group Configuration
To add a hunt list, follow these steps:
Step 1 Choose Call Routing > Route/Hunt > Hunt List.
Step 2 Click the Add New button.
352 Chapter 14: Call Coverage
Step 3 In the Name field, enter a descriptive name for the hunt list functionality
and append _HL to indicate that the item is a hunt list. The name can
include up to 50 alphanumeric characters and can contain any
combination of spaces, periods (.), hyphens (-), and underscore
characters (_). Each hunt list name must be unique.
Step 4 Choose a CUCM group from the drop-down list.
Step 5 Click the Save button. The Hunt List Configuration window will display
the newly added hunt list.
Step 6 Add at least one line group to the new hunt list. To add a line group, click
Add Line Group. The Hunt List Detail Configuration window will open.
Step 7 From the Line Group drop-down list, choose a line group to add to the
hunt list.
To add the line group, click Save. The popup window is shown stating that for the
changes to take effect, you must reset the hunt list. Click OK to confirm the
message.
The line group name is displayed in the Selected Group list on the right side of the
window.
Step 8 To add more line groups to this list, click Add Line Group and repeat the
preceding two steps.
Step 9 When you finish adding line groups to the hunt list, click Save.
Step 10 A popup window will launch. Click OK to reset the hunt list.
CUCM accesses line groups in the order in which they are shown in the hunt list. The access
order of line groups is changed by selecting a line group from the Selected Groups pane and
clicking the up or down arrow on the right side of the pane to move the line group up or
down in the list. Figure 14-9 illustrates the configuration order of the hunt list configuration.
Follow these steps to create a hunt pilot:
Step 1 Choose Call Routing > Route/Hunt > Hunt Pilot from the menu.
Step 2 Click the Add New button.
Step 3 Enter the hunt pilot number in the Hunt Pilot field.
Step 4 Assign the hunt pilot to a hunt list using the Hunt List drop-down list.
Step 5 Scroll down to the bottom of the page to configure final forwarding
settings and the maximum hunt timer.
Step 6 Click the Save button.
Call Hunting 353
Figure 14-9 Hunt List Configuration
The hunt pilot configuration is illustrated in Figure 14-10. The Hunt Forward Settings pane
of the Hunt Pilot Configuration window specifies the final forwarding settings and
maximum timer values, as described in Table 14-1.
Figure 14-10 Hunt Pilot Configuration
354 Chapter 14: Call Coverage
Table 14-1 Hunt Forward Settings
Setting Description
Forward Hunt No
Answer
When the call distributed through the hunt list is not answered within a
specific period of time, this field specifies the destination to which to forward
the call. Choose from these options:
Use Personal Preferences: Enables the CFNC settings for the original called
number that forwarded the call to this hunt pilot.
The CFNC setting specifies a call-forwarding reason that you administer in
the Directory Number Configuration window.
Calls are diverted based on the value in the Coverage/Destination field of
the DN when a call to the DN first diverts to coverage, and coverage either
exhausts or times out, and the associated hunt pilot for coverage specifies
Use Personal Preferences for its final forwarding.
When the Use Personal Preferences check box is checked, CUCM ignores the
settings in the Destination and Calling Search Space fields.
Destination: This setting indicates the DN to which calls are forwarded.
Calling Search Space: This setting applies to all devices that are using this
DN.
Forward Hunt Busy When the call distributed through the hunt list encounters only busy lines for a
specific period of time, this field specifies the destination to which to forward
the call. Choose from these options:
Use Personal Preferences: Use this check box to enable the CFNC settings
for the original called number that forwarded the call to this hunt pilot.
When this check box is checked, CUCM ignores the settings in the
Destination and Calling Search Space fields.
Destination: This setting indicates the DN to which calls are forwarded.
Calling Search Space: This setting applies to all devices that are using this
DN.
Maximum Hunt
Timer
Specifies the maximum time for hunting (in seconds).
Call Hunting 355
The Directory Number Configuration window provides configuration options for internal
and external forwarding based on whether a call is CFA or CFNA, as specified in
Table 14-2.
Table 14-2 Hunt Forward Settings
Field Description
Forward All Specifies the forwarding treatment for calls to this DN if the DN is set to
forward all calls.
Voice Mail: Check this check box to use settings in the Voice Mail Profile
Configuration window.
When this check box is checked, CUCM ignores the settings in the
Destination and Calling Search Space fields.
Destination: This setting indicates the DN to which all calls are forwarded.
Use any dialable phone number, including an outside destination.
Calling Search Space: This setting applies to all devices that are using this
DN.
Forward Busy
Internal
Forward Busy
External
When the call distributed through the hunt list encounters only busy lines for a
specific period of time, this field specifies the destination to which to forward
the call. Choose from these options:
Use Personal Preferences: Use this check box to enable the CFNC settings
for the original called number that forwarded the call to this hunt pilot.
When this check box is checked, CUCM ignores the settings in the
Destination and Calling Search Space fields.
Destination: This setting indicates the DN to which calls are forwarded.
Calling Search Space: This setting applies to all devices that are using this
DN.
continues
356 Chapter 14: Call Coverage
The following five examples explore the related call-forwarding options used at the Cisco
IP Phone and the hunt pilot configuration. In Example 14-1, User A at DN 3000 has the DN
configuration illustrated in Figure 14-11.
Example 14-1 Call Forwarding Without Forward No Coverage Settings
Figure 14-11 shows the following configuration:
■ CFB: Call Forward Busy has two settings: Forward Busy Internal and Forward Busy
External. Both forwarding options are set to 3001. This setting forwards both internal
and external (PSTN) calls to 3001 when 3000 is busy. 3001 is probably the second line
of the phone, but this cannot be determined from Figure 14-11 alone.
■ CFNA: Call Forward No Answer has two settings as well: Forward No Answer
Internal and Forward No Answer External. The CFNA setting in Figure 14-11 forwards
internal calls to 3001, and external calls to 303 555-0111 when 3000 does not answer.
■ CFNC: Call Forward No Coverage does not have a configuration. Any calls that are
sent back to this phone from the hunt pilot for personal treatment will result in a reorder
tone.
Forward No Answer
Internal
Forward No Answer
External
Specifies the forwarding treatment for internal or external calls to this DN if
the DN does not answer.
Voice Mail: Check this check box to use settings in the Voice Mail Profile
Configuration window.
When this check box is checked, CUCM ignores the settings in the
Destination and Calling Search Space fields.
Destination: This setting indicates the DN to which an internal call is
forwarded when the call is not answered. Use any dialable phone number,
including an outside destination.
Calling Search Space: This setting applies to all devices that are using this DN.
Forward No
Coverage Internal
Forward No
Coverage External
This setting applies only if you configure one of the other forwarding fields
(CFA, CFB, or CFNA) with a hunt pilot number in the Destination DN field.
For the hunt pilot settings, you must also configure the Forward Hunt No
Answer or Forward Hunt Busy fields and check the Use Personal Preferences
check box under the Hunt Forward Settings section in the Hunt Pilot
Configuration window; otherwise, the Forward No Coverage configuration in
the Directory Number Configuration window has no effect.
Table 14-2 Hunt Forward Settings (Continued)
Field Description
Call Hunting 357
Figure 14-11 Call Hunting: Example 14-1
The following examples will discuss scenarios where the Hunt Pilot final forwarding rules
are used. Example 14-2 is a scenario where no final forwarding rules were configured.
Example 14-2 Forward No Coverage Examples
User A at DN 3000 has the configuration shown in Figure 14-12 in the Directory Number
Configuration window:
■ CFB: When busy, incoming internal calls are forwarded to 3001, and external calls are
forwarded to hunt pilot 7000.
■ CFNA: When there is no answer, incoming internal calls are forwarded to 3001,
whereas external calls are forwarded to hunt pilot 7000.
Hunt pilot 7000 is associated with hunt list abc and has four hunt parties equally distributed
over Line Group 1 and Line Group 2. Hunt pilot 7000 has no final forwarding fields
provisioned (default).
Question: What behavior results when an internal caller calls 3000 and user 3000 is busy?
Answer: The call forwards to line 3001.
Question: What behavior results when an external caller calls 3000 and user 3000 does not
answer?
Answer: The call forwards to hunt pilot 7000, which will cause hunting to lines 3001, 3002,
4001, and 4002. If one of the hunt parties answers, the caller is connected to that party. If
no hunt party answers, then, regardless of the reason, the caller receives a reorder tone (or
an equivalent annunciator announcement).
358 Chapter 14: Call Coverage
Figure 14-12 Call Hunting: Example 14-2
Example 14-3 Call Coverage: Forward Hunt No Answer
In call-hunting Example 14-3 in Figure 14-13, hunt pilot 7000 has the Forward Hunt No
Answer field set to 3002, but all Forward Hunt Busy fields are empty.
Figure 14-13 Call Hunting: Example 14-3
Line Group 1
3001
3002
Hunt List abc
Hunt Pilot 7000
Hunt List abc
Line Group 2
4001
4002
Forward Hunt Busy
Forward Hunt No Answer
UPP Dest.
UPP = Use Personal Preferences
Line Group 1
3001
3002
Hunt List abc
Hunt Pilot 7000
Hunt List abc
Line Group 2
4001
4002
Forward Hunt Busy
Forward Hunt No Answer
Dest.
3002
UPP
UPP = Use Personal Preferences
Call Hunting 359
If an external caller calls 3000 and user 3000 does not answer, the call forwards to hunt pilot
7000, which causes hunting to lines 3001, 3002, 4001, and 4002. If one of the hunt parties
answers, the caller is connected to that party.
If all hunt parties are busy, the caller receives a reorder tone. The reorder tone was sent
because of the missing Forward Hunt Busy configuration in the hunt pilot.
If at least one hunt party is alerted (phone rings) but does not pick up, the call forwards to
3002 because 3002 is the value configured for the Forward Hunt No Answer field.
Example 14-4 illustrates a scenario where user personal preferences are used for the final
forwarding for forward hunt busy. The forward hunt no answer calls to 3002.
Example 14-4 Call Coverage: Forward Hunt Busy
Figure 14-14 is different from Figure 14-13 because Forward Hunt Busy is configured at
the hunt pilot level. The DN configuration also differs from previous examples because the
DN has two Call Forward No Coverage numbers configured.
Figure 14-14 Call Hunting: Example 14-4
When an external caller calls 3000 and user 3000 does not answer, the call forwards to hunt
pilot 7000, which hunts to lines 3001, 3002, 4001, and 4002.
If one of the hunt parties answers, the caller is connected to that party. If at least one party
is alerted, but hunting exhausts the hunt list, the call is forwarded to 3002.
Line Group 1
3001
3002
Hunt List abc
Hunt Pilot 7000
Hunt List abc
Line Group 2
4001
4002
Forward Hunt Busy
Forward Hunt No Answer
Dest.
3002
UPP
UPP = Use Personal Preferences
360 Chapter 14: Call Coverage
If all hunt parties are busy, the call is forwarded as configured by the DN that forwarded the
call to the hunt pilot. The DN’s Forward No Coverage External setting determines what
happens to the call if the hunt pilot has Use Personal Preferences configured. In this case,
the call will forward to 303 555-0111.
Example 14-5 illustrates a situation in which the Forward No Coverage External has not
been configured. This missing configuration will cause any external calls forwarded to Hunt
Pilots to result in reorder tone.
Example 14-5 Call Coverage: Forward No Coverage External Missing
Figure 14-15 has a similar configuration to Figure 14-14, but the DN does not have a
Forward No Coverage External provisioned.
Figure 14-15 Call Hunting: Example 14-5
NOTE If the hunt pilot is configured to use personal preferences, the corresponding
Forward No Coverage field should be set at the phone forwarding the call to the hunt
pilot. A call forwarded from a phone to the hunt pilot leveraging personal preferences
with no Forward No Coverage setting will result in a reorder tone. This is similar to the
behavior when final forwarding settings are missing at the hunt pilot.
Line Group 1
3001
3002
Hunt List abc
Hunt Pilot 7000
Hunt-List abc
Line Group 2
4001
4002
Forward Hunt Busy
Forward Hunt No Answer
Dest.
3002
UPP
UPP = Use Personal Preferences
Chapter Summary 361
The RNAR timer for a line group determines how long hunting will ring a hunt party before
moving to the next party in its list (assuming that the customer did not select the broadcast
algorithm). This timer has a default value of 10 seconds.
In Figure 14-15, there are four hunt parties. How long will it take before hunting exhausts?
It will take 40 seconds before hunting exhausts (10 seconds RNAR default × 4 hunt
members).
Assume that the maximum hunt timer for hunt pilot 7000 is set to 25 seconds. The call must
be answered within this hunt timer. In this example, the maximum hunt timer is 2.5 times
the RNAR timer, which is 10 seconds.
If a user calls hunt pilot 7000, the call attempts to hunt for the four parties. If all the phones
ring but no one picks up within 25 seconds, hunting terminates and the cause is treated as
no answer. Hunting terminates after the third member has been alerted for 5 seconds (10
seconds RNAR on each of the first two members leaves 5 seconds before expiration of the
25 seconds maximum hunt time configured at the hunt pilot). The call forwards to 3002
because hunting failed with a No Answer condition.
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 call-hunting implementation is composed of the following components:
■ Phone DNs or voice-mail ports are assigned to line groups.
■ Line groups are assigned to hunt lists. A hunt list can have one or more line groups.
Line group hunt options and distribution algorithms can be specified to define how call
hunting should be performed for the members of the line group.
■ Hunt lists are assigned to hunt pilots. A hunt list is an ordered list of one or more line
groups.
■ Hunt pilots are the numbers that will match on dialed digits to invoke the hunting
process. A hunt pilot can be called directly or a call may be forwarded to the hunt pilot
from an IP phone that received a call and is configured to forward calls to the hunt pilot
to provide call coverage.
While hunting, the forwarding configuration of line group members is not used. If the
hunting algorithm is ringing a phone and the call is not answered, the CFNA setting of that
phone is ignored, and the hunting algorithm goes on to the next line group member.
Figure 14-3 illustrates the call-hunting process and components. The hunt pilot in this
example has been configured as 1 800 555-0111. Calls are distributed among the four DNs
at the bottom of the figure.
Call Hunting 343
Figure 14-3 Call Hunting
In the following example, two line groups are configured:
■ Agents line group: Contains the DNs 2001 and 2002.
■ Operators line group: Contains the DNs 2101 and 2102.
The line groups are assigned to the hunt list HelpDesk:
■ The first line group is Agents.
■ The second line group is Operators.
A hunt pilot of HelpDesk with the pattern 2222 is configured to use hunt list HelpDesk for
call coverage.
IP IP IP IP
Line Group 1
1000 1001
Line Group 2
1003 1004
Hunt List
1 800 555-0111
Hunt Pilot
1st Choice 2nd Choice
344 Chapter 14: Call Coverage
Figure 14-4 and the list that follows illustrate the call-coverage components involved in
distributing a call from the hunt pilot.
Figure 14-4 Call-Hunting Process
1. A call is received for extension 2222. The CUCM digit analysis result matches the hunt
pilot number of 2222. The hunt pilot distributes the call to the hunt list HelpDesk.
2. The hunt list uses top-down processing of the line groups. The first line group of
Agents is processed.
3. The line group distributes the call to agent DNs. Assuming the top-down calldistribution
algorithm was selected, 2001 would ring, then 2002. The various calldistribution
algorithms are covered later in this chapter.
4. If no agent answers, the hunt list sends the call to the second line group, Operators.
5. The line group Operators distributes the call to the operator DNs.
Hunt pilots are dialable patterns in the call-routing database (similar to route patterns,
translation patterns, and DNs). The hunt pilot points to a hunt list. The hunt list points to
one or more line groups, which include DNs.
QuickTime™ and a
Graphics decompressor
are needed to see this picture. IP
Hunt List HelpDesk
Line Group Agents
2001
2002
Line Group Operators
2102
2101
User Dials 2222
1
HL distributes call
to LG.
2
If no agents answers,
HL sends call to
second LG.
4
IP
IP
IP
IP
LG distributes
call to agents.
3
LG distributes call
to operators.
5
Hunt Pilot
HelpDesk
2222
Call Hunting 345
Beginning with CUCM Release 4.1, calls can be redirected to a final destination when the
hunting fails. Hunting may fail for one of the following reasons:
■ All hunting options have been exhausted, and the call has not been answered.
■ The maximum hunt timer has expired (configured at the hunt list level).
This call redirection is configured in the Hunt Forward Settings section of the Hunt Pilot
Configuration page, and the destination for this redirect can be either of the following
options:
■ A specific destination configured globally at the hunt pilot.
■ A personal preference, configured at the DN of the originally called number when
hunting on behalf of that number fails. The personal preference is configured using the
CFNC settings at the phone line.
You can implement the personal preferences option by configuring a user’s phone so that
the Forward No Answer field redirects the call to a hunt pilot, to search for someone else
who can answer the call. If the call hunting fails, either because all the hunting options were
exhausted or because a timeout period expired, the call can be sent to a destination personalized
for the person who was originally called. For example, if the Forward No Coverage
field is set to voice mail, the call will be sent to that person’s voice-mail box when hunting
fails.
The following considerations apply to calls handled by hunt pilots:
■ Call Pickup and Group Call Pickup are not supported on calls distributed by a hunt
pilot. A member of the line group cannot pick up the hunt pilot call offered to another
member in the line group, even if they belong to the same call-pickup group.
■ The hunt pilot can distribute calls to any of its line group members, regardless of the
partition of the line group member. Class of service is not implemented in the callcoverage
paradigm.
A hunt list is a prioritized list of line groups used for call coverage. Hunt lists have the
following characteristics:
■ Multiple hunt pilots can point to the same hunt list.
■ Multiple hunt lists can contain the same line group.
■ A hunt list is a prioritized list of line groups; line groups are hunted in the order of their
configuration in the hunt list.
346 Chapter 14: Call Coverage
Line groups control the order in which a call is distributed, and they have the following
characteristics:
■ Line groups point to specific extensions, which are typically IP phone extensions or
voice-mail ports.
■ The same extension may be present in multiple line groups.
■ Line groups are configured with a global distribution algorithm that is used to select
the next line group member for hunting.
■ Line groups are configured with a hunt option that describes how hunting should be
continued after trying the first member of the line group. The hunt option is configured
per hunt failure event: No Answer, Busy, and Not Available.
■ The Ring No Answer Reversion (RNAR) timeout specifies how long the hunting
algorithm rings a member of the line group before it continues hunting according to the
line group No Answer hunt option setting.
Line group members are the endpoints accessed by line groups, and they can be of any of
the following types:
■ Any SCCP endpoints, such as Cisco Unified IP Phone models VG248 or ATA 188
■ SIP endpoints
■ Voice-mail ports
■ H.323 clients
■ Foreign Exchange Station (FXS) extensions attached to an Media Gateway Control
Protocol (MGCP) gateway
Computer telephony integration (CTI) ports and CTI route points cannot be added to a line
group. Therefore, calls cannot be distributed to endpoints controlled through CTI applications
such as Cisco Customer Response Solution (CRS), Cisco Unified IP Interactive Voice
Response (IVR), and so forth.
Call-Hunting Options and Distribution Algorithms
Various hunt options are available at the line group configuration level. The default works
for most implementations, but life is rife with options to accommodate the requirements of
various organizations and collaborative groups. The following hunt options are available:
■ Try Next Member, Then, Try Next Group in Hunt List (Default): Sends the call to
the next idle or available member of this line group. If no more members are available
in this line group, go to the next line group configured in the hunt list. If no more line
groups are available, hunting stops.
Call Hunting 347
■ Try Next Member, but Do Not Go to Next Group: Sends the call to the next idle or
available member of this line group. If no more members are available in this line
group, hunting stops.
■ Skip Remaining Members, and Go Directly to Next Group: Sends the call to the
next line group. If no more line groups are available, hunting stops.
■ Stop Hunting: Do not proceed to the next Line Group or next member.
The line group distribution algorithm specifies the order line in which group members
should be used during the hunting process. The available algorithms are as follows:
■ Top down: If you choose a top-down distribution algorithm, CUCM distributes the call
to idle or available members starting from the first idle or available member at the top
of the line group to the last idle or available member (bottom of the list). In Figure 14-5,
a top-down distribution algorithm would extend the next call to 1000, then to 1001,
then to 1002, then 1003, and back to 1000 depending on the line state of the destination
DN. An important distinction in this model is that every new call attempts to use
extension 1000, no matter how long the lines in the line group are idle. If extension
1000 is available every time there is a new call distributed, extension 1000 will receive
the call. The user at extension 1000 would be very busy in this model.
■ Circular: If you choose a circular distribution algorithm, CUCM distributes the call
to idle or available members starting from the first member of the line group (1000).
CUCM retains the most recently extended call target in memory and attempts to place
the second call to the second member of the line group (1001). The third call is distributed
to the third member of the line group (1002), and the fourth call is extended to the
fourth member of the line group (1003). The circular distribution algorithm might
appear to be the same as the top-down distribution algorithm, but it is much fairer
in its distribution of calls.
■ Longest idle time: If you choose a longest idle time distribution algorithm, CUCM
distributes the call to the member that has been idle for the longest amount of time.
Only members in the idle call state are considered by this distribution algorithm.
Available and busy call states do not receive calls. A phone in the available state is
servicing a call but can manage a second call. Figure 14-5 assumes that 1000 has
been idle for 10 minutes and 1003 has been idle for 5 minutes. A longest idle time
distribution mechanism extends the call to extension 1000.
■ Broadcast: If you choose a broadcast distribution algorithm, CUCM distributes the
call to all idle or available members of a line group simultaneously.
Distribution algorithms are configured once per line group in CUCM Administration.
348 Chapter 14: Call Coverage
Figure 14-5 Line Group Distribution Algorithms
Call-Hunting Flow
The call-hunting flow in CUCM is as follows:
1. A direct call is placed to the hunt pilot number, or a call is forwarded to the hunt pilot
number from a phone.
2. The hunt pilot starts the maximum hunt timer to monitor the overall hunting time. If
the timer expires, hunting stops, and final forwarding is performed. The hunt pilot is
logically associated with a hunt list.
3. The hunt list associated with the hunt pilot sends the call to the first line group
configured in the hunt list.
—The call is sent to the next line group member based on the distribution
algorithm configured at the line group. Each line group is attempted until
all resources are exhausted (or the maximum hunt timer expires).
4. If the call to the hunt pilot goes unanswered, hunt failure has occurred. Possible hunt
failure reasons include no one answered the phone or everyone is busy servicing other
customers.
Figure 14-6 illustrates the call-coverage distribution of a call destined to a hunt pilot of 7000.
Figure 14-7 illustrates the final forwarding options of the hunt pilot configuration.
If hunting stops (ring no answer or busy) and the hunt pilot is not configured for final
forwarding, the call fails and a reorder tone is played.
If a final forwarding number is specified at the hunt pilot, the call is routed to the number.
If Use Personal Preference is selected, the call is routed as configured for Call Forward No
Coverage at the phone line that invoked the call to the pilot number.
IP IP IP IP
1000 1001 1002 1003
Idle
10 min.
Available Idle
5 min.
Available, CUCM
Last Extended Call
Line Group 1
Call Hunting 349
Figure 14-6 Call-Hunting Flow
Figure 14-7 Call-Hunting Flow
Hunt Pilot
7000
Hunt List
First Line
Group
Second
Line Group
Direct Call to Hunt Pilot or
Call Forwarded from Phone
Call Sent to First Line Group of Hunt List
Call Sent to Next Member as per
Line Group Distribution Algorithm
If Hunt List maximum hunt
timer Expires, Stop
Hunting
No Answer (Based on
Line Group RNAR Timer)
Busy Not
Available
Stop Hunting
Go to Next Line Group
Try Next Member of This Line
Group; If None Left, Stop
Hunting
Try Next Member of This Line
Group; If None Left, Go to Next
Line Group; If No Line Group
Left, Stop Hunting
Check Line Group Hunt Option How to Continue
IP IP IP
IP
IP
Check Hunt Pilot
Final Forward
Configuration
Hunting Stopped
No Final
Forwarding
Call Failed
(Reorder)
Hunt Option: Stop Hunting
Hunt Exhaustion (No More
Line Groups or Line Group
Members)
Hunt List Maximum Hunt
Timer Expired Final
Forwarding
Number
Specified in
Hunt Pilot
Use
Personal
Preference
Route Call to
Number Specified
in Hunt Pilot
Route Call to
Number
Specified at
Phone Line
(Call Forward No
Coverage)
350 Chapter 14: Call Coverage
Call-Hunting Configuration
To access the line group, hunt list, and hunt pilot configuration windows in CUCM
Administration, choose Call Routing > Route/Hunt.
When configuring hunting, follow these steps:
Step 1 Create the line groups, add members, and configure the distribution
algorithm and hunt options.
Step 2 Create the hunt list and add the line groups.
Step 3 Create the hunt pilot, associate the hunt list with the hunt pilot, and
configure hunt forward settings.
Step 4 Configure personal preferences on phone lines in the event that hunting
ends with no coverage.
These steps are covered in more detail on the following pages.
The DNs that will become the members of the line group must already exist in the database
before you can complete this procedure. The following steps describe the creation of a line
group. The configuration of the line group is illustrated in Figure 14-8.
Step 1 Choose Call Routing > Route/Hunt > Line Group from CUCM
Administration.
Step 2 Click the Add New button.
Step 3 Enter a name in the Line Group Name field. The name can contain up to
50 alphanumeric characters and can contain any combination of spaces,
periods (.), hyphens (-), and underscore characters (_). Ensure that each
line group name is unique to the route plan. Use a naming nomenclature
that is brief and descriptive of the line group usage in the environment. It
is good practice to append _LG to the line group name so that it can be
easily identified.
Step 4 Configure the distribution algorithm, hunt options, and ring no answer
reversion (RNAR) timeout as desired. The RNAR parameter limits the
amount of time (in seconds) that each DN in the line group rings before
CUCM reports a No Answer condition.
Step 5 Add members to the line group. To locate a DN, choose a route partition
from the Partition drop-down list, enter a search string in the Directory
Number Contains field, and click Find. To find all DNs that belong to a
Call Hunting 351
partition, leave the Directory Number Contains field blank and click
Find. A list of matching DNs is displayed in the Available DN/Route
Partition pane.
Step 6 In the Available DN/Route Partition pane, select a DN to add and click
Add to Line Group to move it to the Selected DN/Route Partition pane.
Repeat this step for each member that you want to add to this line group.
Step 7 In the Selected DN/Route Partition pane, choose the order in which the
new DNs will be accessed in this line group. To change the order, click a
DN and use the up and down arrows to the right of the pane.
Step 8 Click Save to add the new DNs and to update the DN order for this line
group.
Figure 14-8 Line Group Configuration
To add a hunt list, follow these steps:
Step 1 Choose Call Routing > Route/Hunt > Hunt List.
Step 2 Click the Add New button.
352 Chapter 14: Call Coverage
Step 3 In the Name field, enter a descriptive name for the hunt list functionality
and append _HL to indicate that the item is a hunt list. The name can
include up to 50 alphanumeric characters and can contain any
combination of spaces, periods (.), hyphens (-), and underscore
characters (_). Each hunt list name must be unique.
Step 4 Choose a CUCM group from the drop-down list.
Step 5 Click the Save button. The Hunt List Configuration window will display
the newly added hunt list.
Step 6 Add at least one line group to the new hunt list. To add a line group, click
Add Line Group. The Hunt List Detail Configuration window will open.
Step 7 From the Line Group drop-down list, choose a line group to add to the
hunt list.
To add the line group, click Save. The popup window is shown stating that for the
changes to take effect, you must reset the hunt list. Click OK to confirm the
message.
The line group name is displayed in the Selected Group list on the right side of the
window.
Step 8 To add more line groups to this list, click Add Line Group and repeat the
preceding two steps.
Step 9 When you finish adding line groups to the hunt list, click Save.
Step 10 A popup window will launch. Click OK to reset the hunt list.
CUCM accesses line groups in the order in which they are shown in the hunt list. The access
order of line groups is changed by selecting a line group from the Selected Groups pane and
clicking the up or down arrow on the right side of the pane to move the line group up or
down in the list. Figure 14-9 illustrates the configuration order of the hunt list configuration.
Follow these steps to create a hunt pilot:
Step 1 Choose Call Routing > Route/Hunt > Hunt Pilot from the menu.
Step 2 Click the Add New button.
Step 3 Enter the hunt pilot number in the Hunt Pilot field.
Step 4 Assign the hunt pilot to a hunt list using the Hunt List drop-down list.
Step 5 Scroll down to the bottom of the page to configure final forwarding
settings and the maximum hunt timer.
Step 6 Click the Save button.
Call Hunting 353
Figure 14-9 Hunt List Configuration
The hunt pilot configuration is illustrated in Figure 14-10. The Hunt Forward Settings pane
of the Hunt Pilot Configuration window specifies the final forwarding settings and
maximum timer values, as described in Table 14-1.
Figure 14-10 Hunt Pilot Configuration
354 Chapter 14: Call Coverage
Table 14-1 Hunt Forward Settings
Setting Description
Forward Hunt No
Answer
When the call distributed through the hunt list is not answered within a
specific period of time, this field specifies the destination to which to forward
the call. Choose from these options:
Use Personal Preferences: Enables the CFNC settings for the original called
number that forwarded the call to this hunt pilot.
The CFNC setting specifies a call-forwarding reason that you administer in
the Directory Number Configuration window.
Calls are diverted based on the value in the Coverage/Destination field of
the DN when a call to the DN first diverts to coverage, and coverage either
exhausts or times out, and the associated hunt pilot for coverage specifies
Use Personal Preferences for its final forwarding.
When the Use Personal Preferences check box is checked, CUCM ignores the
settings in the Destination and Calling Search Space fields.
Destination: This setting indicates the DN to which calls are forwarded.
Calling Search Space: This setting applies to all devices that are using this
DN.
Forward Hunt Busy When the call distributed through the hunt list encounters only busy lines for a
specific period of time, this field specifies the destination to which to forward
the call. Choose from these options:
Use Personal Preferences: Use this check box to enable the CFNC settings
for the original called number that forwarded the call to this hunt pilot.
When this check box is checked, CUCM ignores the settings in the
Destination and Calling Search Space fields.
Destination: This setting indicates the DN to which calls are forwarded.
Calling Search Space: This setting applies to all devices that are using this
DN.
Maximum Hunt
Timer
Specifies the maximum time for hunting (in seconds).
Call Hunting 355
The Directory Number Configuration window provides configuration options for internal
and external forwarding based on whether a call is CFA or CFNA, as specified in
Table 14-2.
Table 14-2 Hunt Forward Settings
Field Description
Forward All Specifies the forwarding treatment for calls to this DN if the DN is set to
forward all calls.
Voice Mail: Check this check box to use settings in the Voice Mail Profile
Configuration window.
When this check box is checked, CUCM ignores the settings in the
Destination and Calling Search Space fields.
Destination: This setting indicates the DN to which all calls are forwarded.
Use any dialable phone number, including an outside destination.
Calling Search Space: This setting applies to all devices that are using this
DN.
Forward Busy
Internal
Forward Busy
External
When the call distributed through the hunt list encounters only busy lines for a
specific period of time, this field specifies the destination to which to forward
the call. Choose from these options:
Use Personal Preferences: Use this check box to enable the CFNC settings
for the original called number that forwarded the call to this hunt pilot.
When this check box is checked, CUCM ignores the settings in the
Destination and Calling Search Space fields.
Destination: This setting indicates the DN to which calls are forwarded.
Calling Search Space: This setting applies to all devices that are using this
DN.
continues
356 Chapter 14: Call Coverage
The following five examples explore the related call-forwarding options used at the Cisco
IP Phone and the hunt pilot configuration. In Example 14-1, User A at DN 3000 has the DN
configuration illustrated in Figure 14-11.
Example 14-1 Call Forwarding Without Forward No Coverage Settings
Figure 14-11 shows the following configuration:
■ CFB: Call Forward Busy has two settings: Forward Busy Internal and Forward Busy
External. Both forwarding options are set to 3001. This setting forwards both internal
and external (PSTN) calls to 3001 when 3000 is busy. 3001 is probably the second line
of the phone, but this cannot be determined from Figure 14-11 alone.
■ CFNA: Call Forward No Answer has two settings as well: Forward No Answer
Internal and Forward No Answer External. The CFNA setting in Figure 14-11 forwards
internal calls to 3001, and external calls to 303 555-0111 when 3000 does not answer.
■ CFNC: Call Forward No Coverage does not have a configuration. Any calls that are
sent back to this phone from the hunt pilot for personal treatment will result in a reorder
tone.
Forward No Answer
Internal
Forward No Answer
External
Specifies the forwarding treatment for internal or external calls to this DN if
the DN does not answer.
Voice Mail: Check this check box to use settings in the Voice Mail Profile
Configuration window.
When this check box is checked, CUCM ignores the settings in the
Destination and Calling Search Space fields.
Destination: This setting indicates the DN to which an internal call is
forwarded when the call is not answered. Use any dialable phone number,
including an outside destination.
Calling Search Space: This setting applies to all devices that are using this DN.
Forward No
Coverage Internal
Forward No
Coverage External
This setting applies only if you configure one of the other forwarding fields
(CFA, CFB, or CFNA) with a hunt pilot number in the Destination DN field.
For the hunt pilot settings, you must also configure the Forward Hunt No
Answer or Forward Hunt Busy fields and check the Use Personal Preferences
check box under the Hunt Forward Settings section in the Hunt Pilot
Configuration window; otherwise, the Forward No Coverage configuration in
the Directory Number Configuration window has no effect.
Table 14-2 Hunt Forward Settings (Continued)
Field Description
Call Hunting 357
Figure 14-11 Call Hunting: Example 14-1
The following examples will discuss scenarios where the Hunt Pilot final forwarding rules
are used. Example 14-2 is a scenario where no final forwarding rules were configured.
Example 14-2 Forward No Coverage Examples
User A at DN 3000 has the configuration shown in Figure 14-12 in the Directory Number
Configuration window:
■ CFB: When busy, incoming internal calls are forwarded to 3001, and external calls are
forwarded to hunt pilot 7000.
■ CFNA: When there is no answer, incoming internal calls are forwarded to 3001,
whereas external calls are forwarded to hunt pilot 7000.
Hunt pilot 7000 is associated with hunt list abc and has four hunt parties equally distributed
over Line Group 1 and Line Group 2. Hunt pilot 7000 has no final forwarding fields
provisioned (default).
Question: What behavior results when an internal caller calls 3000 and user 3000 is busy?
Answer: The call forwards to line 3001.
Question: What behavior results when an external caller calls 3000 and user 3000 does not
answer?
Answer: The call forwards to hunt pilot 7000, which will cause hunting to lines 3001, 3002,
4001, and 4002. If one of the hunt parties answers, the caller is connected to that party. If
no hunt party answers, then, regardless of the reason, the caller receives a reorder tone (or
an equivalent annunciator announcement).
358 Chapter 14: Call Coverage
Figure 14-12 Call Hunting: Example 14-2
Example 14-3 Call Coverage: Forward Hunt No Answer
In call-hunting Example 14-3 in Figure 14-13, hunt pilot 7000 has the Forward Hunt No
Answer field set to 3002, but all Forward Hunt Busy fields are empty.
Figure 14-13 Call Hunting: Example 14-3
Line Group 1
3001
3002
Hunt List abc
Hunt Pilot 7000
Hunt List abc
Line Group 2
4001
4002
Forward Hunt Busy
Forward Hunt No Answer
UPP Dest.
UPP = Use Personal Preferences
Line Group 1
3001
3002
Hunt List abc
Hunt Pilot 7000
Hunt List abc
Line Group 2
4001
4002
Forward Hunt Busy
Forward Hunt No Answer
Dest.
3002
UPP
UPP = Use Personal Preferences
Call Hunting 359
If an external caller calls 3000 and user 3000 does not answer, the call forwards to hunt pilot
7000, which causes hunting to lines 3001, 3002, 4001, and 4002. If one of the hunt parties
answers, the caller is connected to that party.
If all hunt parties are busy, the caller receives a reorder tone. The reorder tone was sent
because of the missing Forward Hunt Busy configuration in the hunt pilot.
If at least one hunt party is alerted (phone rings) but does not pick up, the call forwards to
3002 because 3002 is the value configured for the Forward Hunt No Answer field.
Example 14-4 illustrates a scenario where user personal preferences are used for the final
forwarding for forward hunt busy. The forward hunt no answer calls to 3002.
Example 14-4 Call Coverage: Forward Hunt Busy
Figure 14-14 is different from Figure 14-13 because Forward Hunt Busy is configured at
the hunt pilot level. The DN configuration also differs from previous examples because the
DN has two Call Forward No Coverage numbers configured.
Figure 14-14 Call Hunting: Example 14-4
When an external caller calls 3000 and user 3000 does not answer, the call forwards to hunt
pilot 7000, which hunts to lines 3001, 3002, 4001, and 4002.
If one of the hunt parties answers, the caller is connected to that party. If at least one party
is alerted, but hunting exhausts the hunt list, the call is forwarded to 3002.
Line Group 1
3001
3002
Hunt List abc
Hunt Pilot 7000
Hunt List abc
Line Group 2
4001
4002
Forward Hunt Busy
Forward Hunt No Answer
Dest.
3002
UPP
UPP = Use Personal Preferences
360 Chapter 14: Call Coverage
If all hunt parties are busy, the call is forwarded as configured by the DN that forwarded the
call to the hunt pilot. The DN’s Forward No Coverage External setting determines what
happens to the call if the hunt pilot has Use Personal Preferences configured. In this case,
the call will forward to 303 555-0111.
Example 14-5 illustrates a situation in which the Forward No Coverage External has not
been configured. This missing configuration will cause any external calls forwarded to Hunt
Pilots to result in reorder tone.
Example 14-5 Call Coverage: Forward No Coverage External Missing
Figure 14-15 has a similar configuration to Figure 14-14, but the DN does not have a
Forward No Coverage External provisioned.
Figure 14-15 Call Hunting: Example 14-5
NOTE If the hunt pilot is configured to use personal preferences, the corresponding
Forward No Coverage field should be set at the phone forwarding the call to the hunt
pilot. A call forwarded from a phone to the hunt pilot leveraging personal preferences
with no Forward No Coverage setting will result in a reorder tone. This is similar to the
behavior when final forwarding settings are missing at the hunt pilot.
Line Group 1
3001
3002
Hunt List abc
Hunt Pilot 7000
Hunt-List abc
Line Group 2
4001
4002
Forward Hunt Busy
Forward Hunt No Answer
Dest.
3002
UPP
UPP = Use Personal Preferences
Chapter Summary 361
The RNAR timer for a line group determines how long hunting will ring a hunt party before
moving to the next party in its list (assuming that the customer did not select the broadcast
algorithm). This timer has a default value of 10 seconds.
In Figure 14-15, there are four hunt parties. How long will it take before hunting exhausts?
It will take 40 seconds before hunting exhausts (10 seconds RNAR default × 4 hunt
members).
Assume that the maximum hunt timer for hunt pilot 7000 is set to 25 seconds. The call must
be answered within this hunt timer. In this example, the maximum hunt timer is 2.5 times
the RNAR timer, which is 10 seconds.
If a user calls hunt pilot 7000, the call attempts to hunt for the four parties. If all the phones
ring but no one picks up within 25 seconds, hunting terminates and the cause is treated as
no answer. Hunting terminates after the third member has been alerted for 5 seconds (10
seconds RNAR on each of the first two members leaves 5 seconds before expiration of the
25 seconds maximum hunt time configured at the hunt pilot). The call forwards to 3002
because hunting failed with a No Answer condition.
Subscribe to:
Posts (Atom)