Table Of Contents

Device Support

Supported Devices

Device Configuration Files

Device Firmware Loads

Updating Device Loads

Device Pools

Call Preservation

Call Preservation Scenarios

Where to Find More Information

Device Support

---

This section provides general information about how Cisco CallManager interacts with Cisco IP telephony devices in your network and covers the following topics:

•Supported Devices

•Device Configuration Files

•Device Firmware Loads

•Device Pools

•Call Preservation

•Where to Find More Information

Supported Devices

The Cisco CallManager supports many types of devices, including those in the following list:

•Cisco IP phones

•Analog gateway ports

•T1 gateway

•E1 gateway

•Transcoding resource

•Software Media Termination Point (MTP)

•Conference resource (hardware)

•Conference resource (software)

•CTI port (TAPI and JTAPI)

•Cisco SoftPhone

•Messaging (voice mail)

•Intercluster trunk

Device Configuration Files

The Cisco Trivial File Transfer Protocol (Cisco TFTP), a Windows 2000 service, builds configuration files from information found in the Cisco CallManager database.

The device-specific configuration files use the name format SEP, SAA, SDA, CFB, VGC, or MTP + MAC address:

•SEP—Selsius Ethernet Phone (Cisco IP Phone model 12 SP+, Cisco IP Phone model 30 VIP, Cisco IP Phone 7910, Cisco IP Phone 7940, and Cisco IP Phone 7960)

•SAA—Selsius Analog Access (AT-2, 4, 8 and AS-2, 4, 8, and Cisco Catalyst 6000 24-Port FXS Analog Interface Module)

•SDA—Selsius Digital Access (DT-24+, DE-30+, Cisco Catalyst 6000 8-Port Voice E1/T1)

•VGC—Cisco VG248 Analog Phone Gateway (Cisco VG248 ports and units appear as distinct devices in the same Cisco CallManager. All 48 device ports register within the same Cisco CallManager cluster as device type "Cisco VGC Phone")

•MTP—Media Termination Point

Configuration files also contain a list of Cisco CallManagers in priority order. Network addresses comprise either the fully qualified domain name, for example, "cm1.cisco.com," or dotted IP address "172.116.21.12" plus a TCP port. See the "Cisco TFTP" section on page 8-1 for more information.

When a device has a communication request record that needs to download a configuration file, the following list describes the process used by a device to get to the configuration file:

•A device specifies a device pool.

•A device pool specifies a Cisco CallManager group.

•A Cisco CallManager group specifies a list of Cisco CallManagers.

•Cisco CallManagers contain the TCP connection port for the three device types (IP phone, analog gateway, and digital gateway).

---

Note If the device is a Cisco IP Phone 7960, you can specify button URLs in device configuration. If the URL is blank, Cisco CallManager uses the enterprise values. Refer to the "Enterprise Parameters Configuration" section in the Cisco CallManager Administration Guide.

---

Device Firmware Loads

Loads comprise files that contain updated firmware for devices. Four types of firmware loads exist: phone loads, gateway loads, MTP loads, and conference bridge loads. During installation or upgrade, Cisco CallManager provides the latest loads. However, you can also receive a load between releases that can contain patches or other information important to the devices that use loads, such as phones or gateways.

The Cisco\TFTPPath subdirectory stores these load files as *.bin files; for example, D501A022.bin. During installation or upgrade, this location stores the latest loads. You must copy new loads that you receive between releases to this location for the system to access them.

Table 9-1 describes the loads for each device type.

Table 9-1 Device Load Descriptions 

Device	Description
Cisco IP Phone models 12 S, 12 SP, 12 SP+, and 30 VIP	Loads for these devices begin with P002...; and are 12 characters.
Cisco IP Phone model 30 SP+	Loads for these devices begin with P001...; and are 12 characters.
Cisco IP Phone 7960, 7940	Loads for these devices begin with P003...; and are 12 characters.
Cisco IP Phone 7910	Loads for these devices begin with P004...; and are 12 characters.
Cisco IP Conference Station 7935	Loads for these devices begin with P005...; and are 12 characters.
14-Button Line Extension Module	Loads for these devices begin with S001...; and are 12 characters.
Cisco Access Analog gateway	Loads for these devices begin with A001...; and are 12 characters.
Cisco Access Digital gateway	Loads for these devices begin with D001...; and are 12 characters.
Cisco Access Digital + gateway	Loads for these devices begin with D003...; and are 12 characters.
Cisco Voice Gateway 200	Not applicable.
Cisco VG248 Analog Phone Gateway	Loads for these devices begin with VGC00... The MAC Address is converted for each device by: •Dropping the first two digits of the MAC Address •Shifting the MAC address two places to the left •Adding the two-digit port number to the end of the MAC address (to the right of the number)
Cisco Catalyst 6000 8-Port T1/E1 and Services Module	Loads for these devices vary depending on how the device is being used: •Conference bridge loads begin with C001. •Digital gateway loads begin with D004. •Transcoder loads begin with M001. These loads are 12 characters.
Cisco Catalyst 6000 24-Port FXS Analog Interface Module	Loads for these devices begin with A002...; and are 12 characters.

Updating Device Loads

You can apply a new load to a single device before applying it as a system-wide default. This method can prove useful for testing purposes. Remember, however, that only the device you have updated with the new load will use that load. All other devices of that type use the old load until you update the system-wide defaults for that device with the new load.

Device Pools

Device pools scale and simplify the distribution of Cisco CallManager redundancy groups. A device pool allows the following three primary attributes to be assigned globally to a device:

•Cisco CallManager group—This group specifies a list of up to three Cisco CallManagers, which can be used for call processing in a prioritized list.

•Date/Time Group—Date/Time group specifies the date and time zone for a device.

•Region—You require regions only if multiple voice codecs are used within an enterprise. Regions define the voice codecs used within and between regions.

Optional calling search space can prevent rogue installations of IP phones on your network. For example, rogue phones that are plugged into the network autoregister in a device pool that has a calling search space restricted only to the Cisco CallManager administrator. This search space can have a Primary Line Automatic Ringdown assigned to it, so, when the user goes off hook, the call immediately connects to security or the Cisco CallManager administrator.

Typically, the following scenario applies with respect to configuring device pools. The deployment model drives the exact model of clustering and device pools used:

•Single-site cluster no WAN voice interconnectivity—Device pool configuration uses only Cisco CallManager redundancy groups as basis: typically, this includes a maximum of four device pools assuming six Cisco CallManagers A, B, C, D, E, and F with the redundancy groups AEF, BEF, CFE, and DFE. The scenario does not require use of regions as all calls use the G.711 codec for calls.

•Multisite WAN centralized call processing—In this case only a single Cisco CallManager redundancy group exists; however, each location requires a G.711 and G.729 region to permit intrabranch calls to be placed as G.711 and interbranch calls to be placed as G.729, for example.

•Multisite WAN distributed call processing—Device pools configured as in preceding scenario also include the additional complexity of regions for codec selection. Each cluster could potentially have a G.711 and G.729 region per Cisco CallManager redundancy group.

•Total device pools = number of sites x regions.

Total device pools = regions x Cisco CallManager redundancy groups.

Refer to the "Device Pool Configuration" section in the Cisco CallManager Administration Guide for information on how to configure device pools.

Call Preservation

The call preservation feature of Cisco CallManager ensures that an active call will not be interrupted when a Cisco CallManager fails or when communication fails between the device and the Cisco CallManager that set up the call.

Beginning with Release 3.1, Cisco CallManager supports full call preservation for an extended set of Cisco IP telephony devices. Limited call preservation support existed for the Cisco CallManger 3.0 and 3.0(5) releases. This support includes call preservation between Cisco IP phones, Media Gateway Control Protocol (MGCP) gateways supporting Foreign Exchange Office (FXO) (non-loop-start trunks) and Foreign Exchange Station (FXS) interfaces, and, to a lesser extent, conference bridge, MTP, and transcoding resource devices.

The following devices and applications support call preservation. If both parties are connected through one of the following devices, Cisco CallManager maintains call preservation:

•Cisco IP phones

•Software conference bridge

•Software MTP

•Hardware conference bridge (Cisco Catalyst 6000 8-Port Voice E1/T1 and Services Module, Cisco Catalyst 4000 Access Gateway Module)

•Transcoder (Cisco Catalyst 6000 8-Port Voice E1/T1 and Services Module, Cisco Catalyst 4000 Access Gateway Module)

•Non-IOS MGCP gateways (Catalyst 6000 24-Port FXS Analog Interface Module, Cisco DT24+, Cisco DE30+, Cisco VG200)

•Cisco IOS MGCP Gateways (Cisco VG200, Catalyst 4000 Access Gateway Module, Cisco 2620, Cisco 3620, Cisco 3640, Cisco 3660, Cisco 3810)

•Cisco VG248 Analog Phone Gateway

•Cisco uOne voice-mail application

•Cisco WebAttendant

The following devices and applications do not support call preservation in this release:

•H323 devices

•CTI applications

•TAPI applications

•JTAPI applications

Call Preservation Scenarios

Table 9-2 lists and describes how call preservation is handled in various scenarios.

Table 9-2 Call Preservation Scenarios 

Scenario	Call Preservation Handling
Cisco CallManager fails	A Cisco CallManager failure causes the call-processing function for all calls that were set up through the failed Cisco CallManager to be lost. The affected devices recognize that their current Cisco CallManager failed. Similarly, the other Cisco CallManagers in the cluster detect the Cisco CallManager failure. Cisco CallManager maintains affected active calls until the end user hangs up or until the devices can determine that the media connection has been released. Users cannot invoke any call-processing features for calls maintained as a result of this failure.
Communication failure between Cisco CallManager and device	When communication fails between a device and the Cisco CallManager that controls it, the device recognizes the failure and maintains active connections. The Cisco CallManager recognizes the communication failure and clears call-processing entities that are associated with calls in the device where communication was lost. However, the Cisco CallManagers still maintain control of the surviving devices associated with the affected calls. Cisco CallManager maintains affected active calls until the end user hangs up or until the devices can determine that the media connection has been released. Users cannot invoke any call-processing features for calls maintained as a result of this failure.
Device failure (Phone, gateway, conference bridge, transcoder, MTP)	When a device fails, the connections that exist through the device stop streaming media. The active Cisco CallManager recognizes the device failure and clears call-processing entities that are associated calls in the failed device. However, the Cisco CallManagers maintain control of the surviving devices associated with the affected calls. Cisco CallManager maintains the active connections (calls) associated with the surviving devices until the surviving end users hang up, or until the surviving devices can determine that the media connection has been released.
WebAttendant	Call preservation does not apply for Computer Telephony Integration (CTI) route point devices because a call is only accepted for redirect. If a Cisco CallManager goes down before the call is extended to Telephony Call Dispatcher (TCD), the call does not transfer to TCD. If the Cisco CallManager goes down before the call arrives at a phone after TCD redirects the call, the call will be lost. Cisco WebAttendant client inherits call preservation from the phone because it is a third-party control for a phone. Any active calls continue after Cisco CallManager goes down, but calls on hold do not. Cisco WebAttendant only supports call preservation via the associated phone.

Where to Find More Information

Related Topics

•Cisco TFTP, page 8-1

•Understanding Voice Gateways, page 32-1

•Cisco IP Phones, page 33-1

Additional Cisco Documentation

•Device Defaults Configuration, Cisco CallManager Administration Guide

•Device Pool Configuration, Cisco CallManager Administration Guide

•Gateway Configuration, Cisco CallManager Administration Guide

•Cisco IP Phone Configuration, Cisco CallManager Administration Guide

•Cisco CallManager Group Configuration, Cisco CallManager Administration Guide

•Date/Time Group Configuration, Cisco CallManager Administration Guide