Cisco CallManager System Guide, Release 3.3(4)
System-Level Configuration Settings

Table Of Contents

System-Level Configuration Settings

Cisco CallManager Groups

Date/Time Groups

Device Defaults

Regions

Device Pools

Updating Device Pools

Enterprise Parameters

Call Admission Control

Automated Alternate Routing

Survivable Remote Site Telephony References

Dependency Records

System Configuration Checklist

Where to Find More Information


System-Level Configuration Settings


Configure system-level settings before you add devices and configure other Cisco CallManager features. This section covers the following topics:

Cisco CallManager Groups

Date/Time Groups

Regions

Device Pools

Device Defaults

Enterprise Parameters

Call Admission Control

Automated Alternate Routing

Survivable Remote Site Telephony References

System Configuration Checklist

Dependency Records

Where to Find More Information

Cisco CallManager Groups

A Cisco CallManager group comprises a prioritized list of up to three Cisco CallManagers. The first Cisco CallManager in the list serves as the primary Cisco CallManager for that group, and the other members of the group serve as secondary (backup) Cisco CallManagers.

Cisco CallManager groups associate with devices through device pools. Each device belongs to a device pool, and each device pool specifies the Cisco CallManager group for all of its devices.


Note Some Media Gateway Control Protocol (MGCP) devices, such as gateways, can associate directly with Cisco CallManager groups.


Cisco CallManager groups provide two important features for your system:

Prioritized failover list for backup call processing—When a device registers, it attempts to connect to the primary (first) Cisco CallManager in the group that is assigned to its device pool. If the primary Cisco CallManager is not available, the device tries to connect to the next Cisco CallManager that is listed in the group, and so on. Each device pool has one Cisco CallManager group that is assigned to it.

Call processing load balancing—You can configure device pools and Cisco CallManager groups to distribute the control of devices across multiple Cisco CallManagers. See the "Balanced Call Processing" section for more information.

For most systems, you will assign a single Cisco CallManager to multiple groups to achieve better load distribution and redundancy.

Date/Time Groups

Use Date/Time Groups to define time zones for the various devices that are connected to Cisco CallManager.

A default Date/Time Group called CMLocal configures automatically when you install Cisco CallManager. CMLocal synchronizes to the active date and time of the operating system on the Cisco CallManager server. After installing Cisco CallManager, you can change the settings for CMLocal as desired. Normally, you adjust the server date/time to the local time zone date and time.


Note CMLocal resets to the operating system date and time whenever you restart Cisco CallManager or upgrade the Cisco CallManager software to a new release. Do not change the name of CMLocal.



Tip For a worldwide distribution of Cisco IP Phones, create one group named Date/Time Group for each of the 24 time zones.


You cannot delete a Date/Time Group that any device pool uses. If you try to delete a Date/Time Group that is in use, Cisco CallManager displays an error message. Before deleting a Date/Time Group that is currently in use, you must perform either or both of the following tasks:

Assign a different Date/Time Group to any device pools that are using the Date/Time Group that you want to delete.

Delete the device pools that are using the Date/Time Group that you want to delete.

Device Defaults

Use device defaults to set the default characteristics of each type of device that registers with a Cisco CallManager. The device defaults for a device type apply to all devices of that type within a Cisco CallManager cluster. Default settings for devices include

Device firmware loads

Device pools (used for auto-registration)

Phone button templates (used for auto-registration)

When a device auto-registers with a Cisco CallManager, it acquires the device default settings for its device type. After a device registers, you can update its configuration individually to change the device settings.

Installing Cisco CallManager automatically sets the device defaults. You cannot create new device defaults or delete existing ones, but you can change the default settings.

Before updating the device defaults, perform any of the following tasks that apply to your system:

Add new firmware files for the devices to the TFTP server. For each available firmware load, a .bin file resides in the TFTPPath folder on the Cisco CallManager server in a location that is specified in the service parameters. (The Program Files\Cisco\TFTPPath folder serves as the default location.)

For example, for the firmware load P002A0305556, a file named P002A0305556.bin resides in the TFTPPath folder.

Configure new device pools.

If the device is a phone, configure new phone templates.

Regions

When you create a region, you specify the voice codec that can be used for calls between devices within that region, and between that region and other regions.

The voice codec type specifies the technology that is used to compress and decompress voice signals. The choice of voice codec determines the compression type and amount of bandwidth that is used per call. See Table 4-1 for specific information about bandwidth usage for available voice codecs.

The default voice codec for all calls through Cisco CallManager specifies G.711. If you do not plan to use any other voice codec, you do not need to use regions.

Regions prove useful for Cisco CallManager multisite deployments where you may need to limit the bandwidth for individual calls that are sent across a WAN link, but where you want to use a higher bandwidth for internal calls.

To specify voice codec usage for devices using regions, you must

Create regions and specify the voice codecs to use for calls within those regions and between other regions.

Create or modify device pools to use the regions that you created.

Assign devices to device pools that specify the appropriate region.

See the "Device Pools" section for more information about device pool settings.

Supported Voice Codecs and Bandwidth Usage

Cisco CallManager supports the following voice codecs for use with the regions feature:

G.711—Default codec for all calls through Cisco CallManager.

G.729—Low-bit-rate codec with 8-kbps compression supported by Cisco IP Phone 7900 Family models. Typically, you would use low-bit-rate codecs for calls across a WAN link because they use less bandwidth. For example, a multisite WAN with centralized call processing can set up a G.711 and a G.729 region per site to permit placing intrasite calls as G.711 and placing intersite calls as G.729.

G.723—Low-bit-rate codec with 6-kbps compression for older Cisco IP Phone model 12 SP+ and Cisco IP Phone model 30 VIP devices.

GSM—The global system for mobile communications (GSM) codec enables the MNET system for GSM wireless handsets to operate with Cisco CallManager. Assign GSM devices to a device pool that specifies GSM as the voice codec for calls within the GSM region and between other regions. Depending on device capabilities, this includes GSM EFR (enhanced full rate) and GSM FR (full rate).

Wideband—Currently only supported for calls from IP phone to IP phone, the wideband audio codec, uncompressed with a 16-bit, 16-kHz sampling rate, works with phones with handsets, acoustics, speakers, and microphones that can support high-quality audio bandwidth, such as Cisco IP Phone 7900 model phones.

Regions that specify wideband as the codec type must have a large amount of network bandwidth available because wideband uses four times as much bandwidth as G.7ll.

The total bandwidth that is used per call stream depends on the voice codec type as well as factors such as data packet size and overhead (packet header size), as indicated in Table 4-1.


Note Each call has two streams, one in each direction.


Table 4-1 Bandwidth Used per Call by Each Codec Type 

Voice Codec

Bandwidth Used for Data Packets Only (Fixed Regardless of Packet Size)
Bandwidth Used Per Call (Including IP Headers) With 30-ms Data Packets
Bandwidth Used Per Call (Including IP Headers) With 20-ms Data Packets

G.711

64 kbps

80 kbps

88 kbps

G.723

6 kbps

24 kbps

Not applicable

G.729

8 kbps

24 kbps

32 kbps

Wideband1

256 kbps

272 kbps

280 kbps

GSM2

13 kbps

29 kbps

37 kbps

1 Uncompressed. Cisco CallManager supports wideband audio from IP phone to IP phone for Cisco IP Phone 7900 Family model phones only.

2 Global system for mobile communications.


Example

Figure 4-1 shows a very simple region configuration example for deployment with a central site and two remote branches. In the example, an administrator configures a region for each site. The G.711 codec equals the maximum bandwidth codec that is used for calls within each site, and the G.729 codec equals the maximum bandwidth codec that is used for calls between sites across the WAN link.

After region configuration, the administrator assigns devices to the following sites:

The Central Campus site to device pools that specify CentralCampus as the region setting

Remote Site A to device pools that specify RemoteSiteA as the region setting

Remote Site B to device pools that specify RemoteSiteB for the region setting

Figure 4-1 Simple Region Example

Locations and Regions

In Cisco CallManager, locations-based call admission control works in conjunction with regions to define the characteristics of a network link. Regions define the type of codec that is used on the link (and therefore, the amount of bandwidth that is used per call), and locations define the amount of available bandwidth for the link. You must assign each device on the network to both a region (by means of a device pool) and a location. See the "Call Admission Control" section.

Modifying or Deleting Regions

When you update region settings, the changes do not take effect until you restart the devices that use that region.

You cannot delete a region that any device pool uses. If you try to delete a region that is in use, Cisco CallManager displays an error message. Before deleting a region that is currently in use, you must perform either or both of the following tasks:

Assign a different region to any device pools that are using the region that you want to delete.

Delete the device pools that are using the region that you want to delete.

Device Pools

Device pools provide a convenient way to define a set of common characteristics that can be assigned to devices. You can specify the following device characteristics for a device pool:

Device Pool Name—Specifies the name for the new device pool.

Cisco CallManager group—Specifies a prioritized list of up to three Cisco CallManagers to facilitate redundancy. The first Cisco CallManager in the list serves as the primary Cisco CallManager for that group, and the other members of the group serve as secondary (backup) Cisco CallManagers. See the "Cisco CallManager Groups" section for more details.

Date/Time group—Specifies the date and time zone for a device. See the "Date/Time Groups" section for more details.

Region—Specifies the voice codecs that are used within and between regions. Use regions only if you have different types of voice codecs within the network. See the "Regions" section for more details.

Survivable Remote Site Telephony (SRST) reference—Specifies the gateway that provides SRST functionality for the devices in a device pool. See the "Survivable Remote Site Telephony References" section for more details.

Media resource group list (optional)—Specifies a prioritized list of media resource groups. An application selects the required media resource (for example, a Music On Hold server, transcoder, or conference bridge) from the available media resource groups according to the priority order that is defined in the media resource group list. See the "Media Resource Group Lists" section on page 16-5 for more details.

User hold music on hold (MOH) audio source (optional)—Specifies the audio source for user hold. See the "Music On Hold Audio Sources" section in the Cisco CallManager Features and Services Guide for more details.

Network hold music on hold (MOH) audio sources (optional)—Specifies the audio source for network hold. See the "Music On Hold Audio Sources" section in the Cisco CallManager Features and Services Guide for more details.

User locale—Identifies a set of detailed information to support users, including language and font. This characteristic associates with the phones and gateways in a device pool.

Network locale—Contains a definition of the tones and cadences that the phones and gateways use in a device pool in a specific geographic area.


Note You must choose only a network locale that is already installed and that is supported by the associated devices. The list contains all available network locales for this setting, but not all are necessarily installed. If the device is associated with a network locale that it does not support in the firmware, the device will fail to come up.


Calling search space for auto-registration (optional)—Specifies the partitions that an auto-registered device can reach when a call is placed. See the "Partitions and Calling Search Spaces" section for more details.

Softkey template—Used to manage softkeys that are associated with applications on Cisco IP Phones. See the "Softkey Template Configuration" section in the Cisco CallManager Administration Guide for more details.

You must configure the preceding items before you configure a device pool if you want to choose the items for the device pool.

After adding a new device pool to the database, you can use it to configure devices such as Cisco IP Phones, gateways, conference bridges, transcoders, media termination points, voice-mail ports, CTI route points, and so on.

To assign all devices of a given type to a device pool, use the Device Defaults window in Cisco CallManager Administration. See the "Device Defaults" section for more information.

Updating Device Pools

If you make changes to a device pool, you must reset the devices in that device pool before the changes will take effect.

You cannot delete a device pool that has been assigned to any devices or one that is used for Device Defaults configuration. If you try to delete a device pool that is in use, an error message displays. Before deleting a device pool that is currently in use, you must perform either or both of the following tasks:

Update the devices to assign them to a different device pool.

Delete the devices that are assigned to the device pool that you want to delete.

Enterprise Parameters

Enterprise parameters provide default settings that apply to all devices and services in the same cluster. (A cluster comprises a set of Cisco CallManagers that share the same database.) When you install a new Cisco CallManager, it uses the enterprise parameters to set the initial values of its device defaults.

You cannot add or delete enterprise parameters, but you can update existing enterprise parameters.

You can display additional descriptions for enterprise parameters through use of the i button on the Enterprise Parameters Configuration page.

Call Admission Control

Use call admission control to maintain a desired level of voice quality over a WAN link. For example, you can use call admission control to regulate the voice quality on a 56-kbps frame relay line that connects your main campus and a remote site.

Voice quality can begin to degrade when too many active calls exist on a link and the amount of bandwidth is oversubscribed. Call admission control regulates voice quality by limiting the number of calls that can be active on a particular link at the same time. Call admission control does not guarantee a particular level of audio quality on the link, but it does allow you to regulate the amount of bandwidth that is consumed by active calls on the link.

Cisco CallManager supports two types of call admission control:

Locations—Use locations to implement call admission control in a centralized call-processing system. Call admission control lets you regulate voice quality by limiting the amount of bandwidth that is available for calls over links between the locations.

H.323 Gatekeeper—Use an H.323 gatekeeper, also known as a Cisco Multimedia Conference Manager (MCM), to provide call admission control in a distributed system with a separate Cisco CallManager or Cisco CallManager cluster at each site.


Note If you do not use call admission control to limit the voice bandwidth on an IP WAN link, an unlimited number of calls can be active on that link at the same time. This can cause the voice quality of each call to degrade as the link becomes oversubscribed.


See the "Call Admission Control" section for more information.

Automated Alternate Routing

Automated alternate routing (AAR) provides a mechanism to reroute calls through the PSTN or other network by using an alternate number. As a subset of the AAR feature, Cisco CallManager automatically reroutes calls through the PSTN or other networks when Cisco CallManager blocks a call due to insufficient location bandwidth. With automated alternate routing, the caller does not need to hang up and redial the called party.

When a call is made from the device of one location to the device of another location, location bandwidth gets deducted from the maximum available bandwidth that is available for the call at either location. If not enough location bandwidth for the call exists at either location, instead of blocking the call, Cisco CallManager uses the table of AAR groups and the external number of the terminating directory number to supply the alternate number that is used to reroute the call through the PSTN or other network. The Cisco IP Phone displays the message "Network congestion, rerouting." Cisco CallManager automatically attempts to reroute the call by using the alternate number. If the reroute is successful, the caller connects to the called party.

AAR supports the following call scenarios for insufficient bandwidth:

Call originates from a line or directory number (DN) of an IP phone within one location and terminates to a line or DN of another IP phone within another location. This scenario includes calls that terminate at the shared line with terminating IP phone devices that are resident in multiple locations and calls that terminate at the Cisco voice-mail port.

Incoming call through a gateway device within one location terminates to a line or DN of an IP phone within another location. This scenario includes calls that terminate at the shared line with terminating IP phone devices that are resident in multiple locations and calls that terminate at the Cisco voice-mail port.

Cisco CallManager automatically attempts to reroute calls, due to insufficient bandwidth, through the PSTN or other network only when the AAREnable enterprise parameter is set to true. Cisco CallManager uses the device-based AAR calling search space, which is assigned to Cisco IP Phone station devices and gateway devices, when it attempts to route the call to the gateway device that connects to the PSTN or other network. Cisco CallManager uses the external phone number mask and the directory number of the line or DN and the Cisco voice-mail port to derive the alternate number that is used to reroute the call.

The AAR group appears as an entry in the line/DN table, in the Cisco voice-mail port table, and in the gateway device table. AAR group comprises a character string with a default value of the null string. The AAR group represents the dialing area where the line/DN, the Cisco voice-mail port, and the gateway are located. Cisco CallManager uses the AAR group value to index into the AAR dial prefix matrix table, which contains the prefix digits for transforming the alternate number.

Automated Alternate Routing Example

In the following scenario, line/DN 5000 in the Richardson AAR group calls line 5001 in the San Jose AAR group. If not enough location bandwidth exists, the call attempts to reroute through the PSTN or other network. To route the call from AAR group Richardson to AAR group San Jose, Cisco CallManager needs to know the access digit(s) to dial out to the PSTN or other network, the long-distance dialing requirement, if any, and the alternate number. Cisco CallManager retrieves the information from the AAR dial prefix matrix table, which is indexed by the originating line AAR group value and the terminating line AAR group value. Table 4-2 shows how the AAR group field is data filled in the line/DN table:

Table 4-2 Line/DN and AAR Group Association 

Line/DN
AAR Group

5000

Richardson

5001

San Jose

5002

Dallas


Cisco CallManager retrieves the prefix digits from the AAR dial prefix matrix table based on the AAR group value of the originating line/DN and gateway device and the AAR group value of the terminating line, and Cisco voice-mail port, to transform the derived alternate number. Table 4-3 shows an example of how the AAR dial prefix matrix table is data filled:

Table 4-3 AAR Dial Prefix Matrix Table Example 

From AAR Group
To AAR Group
Prefix Digits

Richardson

San Jose

91

Richardson

Dallas

9

Richardson

Richardson

9

San Jose

Richardson

91

San Jose

Dallas

91

San Jose

San Jose

9

Dallas

Richardson

9

Dallas

San Jose

91

Dallas

Dallas

9


Cisco CallManager prepends the prefix digits that are retrieved from the AAR dial prefix matrix table to the derived alternate number. Digit analysis uses the transformed digits, plus the AAR calling search space, to route the call to the PSTN or other network.

A much greater rate of success for automated alternate routing occurs when a gateway is located in the same location as the originating or terminating device. Therefore, a call that is outgoing to the PSTN or other network from a gateway that is located in the same location as the originating device and that is also incoming from a gateway located in the same location as the terminating device describes the best scenario. In other scenarios, the call remains subject to location bandwidth validation between the originating device and outgoing gateway, and between the terminating device and incoming gateway.

Survivable Remote Site Telephony References

If an IP phone is in a remote part of the IP network (for instance, across a wide-area network from a Cisco CallManager) and the phone loses IP connectivity to the Cisco CallManager, persevering rudimentary call capability is desirable. Survivable remote site telephony (SRST) references provide limited call capability in this situation. Using SRST references, IP gateways can take over limited Cisco CallManager functionality. When phones lose connectivity to all associated Cisco CallManagers, the phones in a device pool attempt to make a Cisco CallManager connection to the SRST reference IP gateway.

The system administrator can configure the SRST configuration for a device pool of phones. The following list gives configuration options that are available:

Disable-If a phone cannot reach any Cisco CallManagers, it does not try to connect to an SRST gateway.

Use Default Gateway-If a phone cannot reach any Cisco CallManagers, it tries to connect to its IP gateway as an SRST gateway.

User-defined-If a phone cannot reach any Cisco CallManagers, it tries to connect to an administrator-specified SRST gateway. The SRST Reference field of the Device Pool Configuration lists user-defined SRST references.

The administrator defines SRST configurations in the SRST Reference Configuration page. Any of the preceding SRST configuration options can apply to a device pool. The Cisco TFTP reads the SRST configuration and provides it to the IP phone in a .cnf.xml file. The IP phone reacts appropriately to the SRST configuration.

Dependency Records

To find out specific information about system-level settings such as servers, device pools, and date/time groups, click the Dependency Records link that is provided on the Cisco CallManager Administration configuration windows for each system-level setting.


Note The Device Defaults and Enterprise Parameters Configuration windows do not have a Dependency Records link.


The Cisco CallManager Configuration Dependency Records window provides information about Cisco CallManager groups that it accesses. The Date/Time Group Configuration Dependency Records window provides information about Device Pools that it accesses.

For more information about Dependency Records, refer to Accessing Dependency Records, Cisco CallManager Administration Guide.

System Configuration Checklist

Table 4-4 lists the general steps for configuring system-level settings.

Table 4-4 System Configuration Checklist 

Configuration Steps
Procedures and Related Topics

Step 1 

Configure Cisco CallManager groups for redundancy.

Cisco CallManager Groups

Redundancy

Cisco CallManager Group Configuration, Cisco CallManager Administration Guide.

Step 2 

Configure regions, if needed.

You do not need to configure regions if you are using only the default G.711 voice codec.

Regions

Region Configuration, Cisco CallManager Administration Guide.

Step 3 

Configure Date/Time groups.

Date/Time Groups

Date/Time Group Configuration, Cisco CallManager Administration Guide.

Step 4 

Configure media resource groups and media resource group lists.

Media Resource Management, page 16-1

Media Resource Group Configuration, Cisco CallManager Administration Guide.

Step 5 

Configure device pools.

Device Pools

Device Pool Configuration, Cisco CallManager Administration Guide.

Step 6 

Update device defaults, if needed.

Device Defaults

Updating Device Defaults, Cisco CallManager Administration Guide.

Step 7 

Configure locations or gatekeepers for call admission control.

Locations and Regions

Call Admission Control

Step 8 

Configure automated alternate routing for alternate routing of calls due to insufficient bandwidth.

Automated Alternate Routing

Automated Alternate Routing Group Configuration, Cisco CallManager Administration Guide

Step 9 

Configure survivable remote site telephony (SRST) references.

Survivable Remote Site Telephony References

Survivable Remote Site Telephony Configuration, Cisco CallManager Administration Guide

Step 10 

Update enterprise parameters, if necessary.

Enterprise Parameters

Enterprise Parameters Configuration, Cisco CallManager Administration Guide.


Where to Find More Information

Related Topics

Cisco CallManager Groups

Date/Time Groups

Regions

Device Pools

Device Defaults

Enterprise Parameters

Call Admission Control

Automated Alternate Routing

Survivable Remote Site Telephony References

Redundancy

Additional Cisco Documentation

Cisco CallManager Administration Guide