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

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

•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 and route/hunt lists, 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.

---

Note Deactivating or removing a Cisco CallManager removes it from the Cisco CallManager group. For example, when a backup Cisco CallManager gets deactivated, it gets removed from the associated device pool. If the primary Cisco CallManager fails, devices will not failover to the secondary Cisco CallManager because it is deactivated. When the secondary Cisco CallManager gets reactivated, it must be manually added back to the device pool to which it was once associated. If it does not, then the failover does not work.

---

•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.

Cisco CallManager provides a default Date/Time Group called CMLocal that configures automatically when you install Cisco CallManager; however, Cisco recommends that you configure a group for each local time zone. 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 a 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. To find out which device pools use the Date/Time Group, click the Dependency Records link on the Date/Time Group Configuration window. 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 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.

Cisco IP Phone models 7910, 7940, 7960, and 7970 have image authenticated phone loads, which are included with Cisco CallManager. Authenticated phone loads, called signed loads, comprise firmware images in the phones and as such are listed as the device default for each of these phones in the Device Defaults Configuration window.

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 codec that can be used for calls between devices within that region, and between that region and other regions. The system uses regions also for applications that only support a specific codec; for example, an application that only uses G.711.

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

The default audio codec for all calls through Cisco CallManager specifies G.711. If you do not plan to use any other audio 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 audio codec usage for devices using regions, you must

•Create regions and specify the audio 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. For information about codes and video calls, see Understanding Video Telephony.

Supported Audio Codecs and Bandwidth Usage

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

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

•G.722—Audio codec often used in video conferences.

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

•G.728—Low-bit-rate codec that video endpoints support.

•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.

•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 audio 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 audio codec type as well as factors such as data packet size and overhead (packet header size), as indicated in Table 5-1. (The bandwidth information provided in Table 5-1 applies for ethernet.)

---

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

---

Table 5-1 Bandwidth Used Per Call by Each Codec Type 

Audio 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 5-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 5-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. To find out which device pools are using the region, click the Dependency Records link on the Region Configuration window. 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 audio and video codecs that are used within and between regions. Use regions only if you have different types of 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 19-6 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 on page 13-1 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.

•MLPP Precedence and Preemption Information—Used to manage MLPP settings:

–MLPP Indication—Specifies whether devices in the device pool that are capable of playing precedence tones will use the capability when the devices plan an MLPP precedence call.

–MLPP Preemption—Specifies whether devices in the device pool that are capable of preempting calls in progress will use the capability when the devices plan an MLPP precedence call.

–MLPP Domain—A hexadecimal value for the MLPP domain that is associated with the device pool.

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.

If using auto-registration, you can assign all devices of a given type to a device pool, by using 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. To find out what devices are using the device pool, click the Dependency Records link in the Device Pool Configuration window. 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. Enterprise parameters are general or specific; for example, General parameters, CDR parameters, and Feature parameters.

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

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.

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, preserving 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 window. 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.

Connection Monitor Duration

An IP phone connected to the SRST over a Wide Area Network (WAN) reconnects itself to Cisco CallManager as soon as it can establish a connection with Cisco CallManager over the WAN link. However, if the WAN link is unstable, the IP phone switches back and forth between the SRST and Cisco CallManager causing temporary loss of phone service (no dial tone). These reconnect attempts, known as WAN link flapping issues, continue until the IP phone successfully reconnects itself back to Cisco CallManager. These WAN link disruptions can be classified into two kinds: infrequent random outages that occur on an otherwise stable WAN and the sporadic, frequent disruptions that last a few minutes.

To resolve the WAN link flapping issues between Cisco CallManager and SRST, Cisco CallManager provides an enterprise parameter and a setting in the Device Pool Configuration window called Connection Monitor Duration. Depending upon system requirements, the administrator decides which parameter to use. The value of the parameter gets delivered to the IP phone in the XML configuration file.

The default for the enterprise parameter specifies 120 seconds. Use the enterprise parameter to change the connection duration monitor value for all IP Phones in the Cisco CallManager cluster.

Use the Device Pool Configuration window to change the connection duration monitor value for all IP Phones in a specific device pool.

For more information refer to Device Pool Configuration Settings in the Cisco CallManager Administration Guide.

For information on configuring security for the SRST reference and the SRST-enabled gateway, refer to Cisco CallManager Security Guide 4.1.

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. If the dependency records are not enabled for the system, the dependency records summary window displays a message.

---

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 5-2 lists the general steps for configuring system-level settings.

Table 5-2 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 audio 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 19-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 survivable remote site telephony (SRST) references.	Survivable Remote Site Telephony References Survivable Remote Site Telephony Configuration, Cisco CallManager Administration Guide
Step 9	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

•Survivable Remote Site Telephony References

•Redundancy

Additional Cisco Documentation

•Cisco CallManager Administration Guide