New and Changed Information for Cisco Unified Communications Manager 8.0(x)
New and Changed Information for Cisco Unified Communications Manager 8.0(3)
Downloads: This chapterpdf (PDF - 172.0KB) The complete bookPDF (PDF - 11.5MB) | Feedback

New and Changed Document for Cisco Unified Communications Manager Release 8.0(3)

Table Of Contents

New and Changed Document for Cisco Unified Communications Manager Release 8.0(3)

Installation, Upgrade, and Migration

Cisco UCS C210 Rack-Mount Server Support

Command Line Interface

Changes to Available CLI Commands

Cisco Unified Communications Manager Administration

Cisco Unified Communications Manager Assistant Browser Changes

Cisco Unified Communications Manager Features and Applications

De-allocation of Transcoder

Cisco Unified Communications Manager Call Detail Records

New CDR Field for Hunt List Support

APIs

Extension Mobility Memory Optimization

Cisco Unified IP Phones

Assisted Directed Call Park

Call-Forward-All Upgrade for CTI New Call Event

Dual Bank Firmware Upgrade

Headset Profile Changed to Handsfree Profile

Mute

Secure and Nonsecure Indication Tone

Secure Extension Mobility

Secure SIP Failover for SRST

Trust Verification Service and Security

Using a USB Hub During an Active Call

Cisco Intercompany Media Engine


New and Changed Document for Cisco Unified Communications Manager Release 8.0(3)


Published: July 23, 2010
Revised: August 18, 2010

This document contains the following topics:

Installation, Upgrade, and Migration

Command Line Interface

Cisco Unified Communications Manager Administration

Cisco Unified Communications Manager Features and Applications

Cisco Unified Communications Manager Call Detail Records

APIs

Cisco Unified IP Phones

Cisco Intercompany Media Engine

Installation, Upgrade, and Migration

This following sections describe the changes for installation, upgrade, and migration in Cisco Unified Communications Manager Release 8.0(3):

Cisco UCS C210 Rack-Mount Server Support

Cisco UCS C210 Rack-Mount Server Support

Cisco Unified Communications Manager Releases 8.0(2c) and later can operate on virtualized servers on VMware ESXi 4.0 and later only. Cisco supports VMware ESXi 4.0 and later on the Cisco UCS C210 Rack-Mount Server in Reference Configurations 1, 2 and 3.

For more information, refer to the document Installing Cisco Unified Communications Manager on Virtualized Servers and to the Unified Communications Virtualization wiki at http://docwiki.cisco.com/wiki/Unified_Communications_Virtualization.

Command Line Interface

This section contains information about the Command Line Interface (CLI).

Changes to Available CLI Commands

Changes to Available CLI Commands

The following changes were made to the available CLI commands:

The file list sftpdetails command was removed. In its place, the file dump sftpdetails command is now interactive and provides a list of files that the user can dump (display).

The utils disaster_recovery history command got added. This command displays the history of previous backups and restores.

The utils disaster_recovery show_tapeid is disabled for VM deployments.

The utils disaster_recovery show_backupfiles command now takes a device name and the tape and network options are removed.

The utils disaster_recovery backup tape command is disabled for VM deployments.

The utils disaster_recovery restore tape command is disabled for VM deployments.

The utils disaster_recovery device add tape command is disabled for VM deployments.

The utils disaster_recovery device add network command now accepts a server name or IP address (previously the server name was required).

Cisco Unified Communications Manager Administration

This section contains information on the following topics:

Cisco Unified Communications Manager Assistant Browser Changes

Cisco Unified Communications Manager Assistant Browser Changes

Cisco Unified Communications Manager Assistant administration (using Cisco Unified Communications Manager Administration) adds support for Mozilla Firefox 3.x.

Microsoft Internet Explorer (IE) 7 no longer gets supported.

Cisco Unified Communications Manager Features and Applications

This section contains information on the following Cisco Unified Communications Manager Administration features and applications:

De-allocation of Transcoder

De-allocation of Transcoder

The de-allocation of transcoder feature enables Cisco Unified Communications Manager to support mid-call de-allocation of unused transcoder resources. Cisco Unified Communications Manager can now de-allocate a transcoder allocated due to codec mismatch, for scenarios when it receives a mid-call invite with updated codec change from the SIP trunk or the SIP line side device.

In previous releases of Cisco Unified Communications Manager, if the transcoder was allocated because of codec mismatch and if a SIP trunk or SIP line side device with incoming re-invite changed the codec, the previously negotiated codecs were retained and the transcoder continued to be used. Also, if the codec completely changed from the previously negotiated one, then it depended on whether the allocated transcoder supported the new codec combination. In case the transcoder was not universal, it was not able to support the call and the call ended.

With the introduction of the de-allocation of transcoder feature, Cisco Unified Communications Manager 8.5(1) is able to free up the expensive transcoder devices by de-allocating these when not required. Based on the mid-call changes, Cisco Unified Communications Manager can now de-allocate transcoders and allocate MTPs instead, if required.

If the new SDP has the previously negotiated codec along with new codecs and if one of the new codecs, after filtering for bandwidth limitations, matches with any of the codec(s) supported by the peer endpoint, the transcoder is de-allocated.

Exceptions

There are a few exceptions to de-allocating a transcoder. The de-allocation of transcoder feature does not support the following, if not supported already:

De-allocation of transcoder when inbound mid call updated capabilities come in from a non-SIP endpoint.

De-allocation of transcoder when updated video codecs come in the mid-call re-invite.

Currently transcoders do not support transcoding for video codec mismatch. If a transcoder is present because of audio codec mismatch, then there will be no video on the call.

The allocation/de-allocation of transcoder resources and MTPs due to DTMF mismatch is already being taken care of by Cisco Unified Communications Manager, and this feature does not modify any existing functionality related to DTMF. Therefore, this feature does not support any unsupported cases of transcoder de-allocation due to DTMF mismatch.

In scenarios where more than one media resource is allocated for the media leg of a call, the transcoder does not get de-allocated. For example, a scenario where a transcoder as well as an MTP get allocated because of the "MTP required" checkbox being selected on a party.

This feature is disabled when there is an RSVP agent in the media call leg.

This feature is disabled when call flows with mid call re-Invites without SDP are received.

Cisco Unified Communications Manager Call Detail Records

This section contains these subsections:

New CDR Field for Hunt List Support

New CDR Field for Hunt List Support

Table 1-1 describes the new CDR field for the hunt list support.

Table 1-1 New CDR Field for Hunt Lists

Name
Range of Values
Description

calledPartyPatternUsage

Positive Integer

This field indicates the pattern of the called party.

Default value is 5 (PATTERN_ROUTE).

If the huntPilotDN is populated, use the field value of huntPilotDN as the hunt pilot.

If the huntPilotDN is not available, check the pattern usage (7 = PATTERN_HUNT_PILOT) in the CDR table to identify the call type. If this call is a hunt list call, use the finalCalledPartyNumber as the huntPilotDN.


APIs

This section describes the new and changed API features in Cisco Unified Communications Manager Release 8.0(3). It contains the following sections:

Extension Mobility Memory Optimization

Extension Mobility Memory Optimization

Cisco TSP uses TAPI LINE_CREATE / LINE_REMOVE mechanism to dynamically create and remove line devices resulting from Extension Mobility login or logout activities. TAPI, by design, does not dynamically remove a device, but marks the device as "not available" and keeps it until the TSP provider is shut down. As a result, when Extension Mobility is used, memory utilization increases over time and is interpreted by customers as memory leak.

The only work around is to minimize the usage of LINE_CREATE / LINE_REMOVE in Extension Mobility-related scenarios. To achieve this, Cisco TSP reuses TAPI device IDs and notifies applications of changes in device capabilities when an ID is reused.

If this feature is enabled, Cisco TSP sends the LINE_CREATE message, only for the first instance, when a new line is created for Extension Mobility log in. After the line is created, it is not removed at the Extension Mobility log out (with LINE_REMOVE message) but is instead placed in "inactive" state. The line is reactivated when an Extension Mobility profile is loaded again on the IP Phone for a new Extension Mobility login.

This feature can be enabled or disabled by using Microsoft Windows registry settings. By default, the feature is disabled so the existing applications are not affected. A supplementary feature, other device state change notification, is implemented for Cisco TSP to notify TAPI applications about status changes of "non-opened" devices.

Cisco Unified IP Phones

This section provides information for the following features:

Assisted Directed Call Park

Call-Forward-All Upgrade for CTI New Call Event

Dual Bank Firmware Upgrade

Headset Profile Changed to Handsfree Profile

Mute

Secure and Nonsecure Indication Tone

Secure Extension Mobility

Secure SIP Failover for SRST

Trust Verification Service and Security

Using a USB Hub During an Active Call

Assisted Directed Call Park

The Assisted Directed Call Park feature enables users to park a call by pressing only one button using the Direct Park feature. This requires administrators to configure a Busy Lamp Field (BLF) Assisted Directed Call Park button. When users press an idle BLF Assisted Directed Call Park button for an active call, the active call is parked at the Direct Park slot associated with the Assisted Directed Call Park button.

This feature is supported on the following Cisco Unified IP Phones (SIP) for Cisco Unified CM 7.1(5) and later:

Cisco Unified IP Phone 7975G

Cisco Unified IP Phone 7971G-GE

Cisco Unified IP Phone 7970G

Cisco Unified IP Phone 7965G

Cisco Unified IP Phone 7962G

Cisco Unified IP Phone 7961G

Cisco Unified IP Phone 7961G-GE

Cisco Unified IP Phone 7945G

Cisco Unified IP Phone 7942G

Cisco Unified IP Phone 7941G

Cisco Unified IP Phone 7941G-GE

Cisco Unified IP Phone 7931G

Cisco Unified IP Phone 9971G

Cisco Unified IP Phone 9951G

Cisco Unified IP Phone 8961G

Where to Find More Information

Cisco Unified Communications Manager Features and Services Guide

Call-Forward-All Upgrade for CTI New Call Event

With Firmware Release 9.0(3), information was added to the Computer Telephony Integration (CTI) new call event. The JTAPI and TAPI applications can now distinguish between an actual outgoing call and a call that is created when a user presses the call-forwarding softkey (CFwdALL or Forward All depending on the IP phone model), or presses the Forward All line button on the Cisco Unified IP Phone.

This upgrade applies only if the Call Forward All feature is invoked when the phone is on hook. If the phone is off hook, such as when a user lifts the handset or presses the speakerphone before invoking the Call Forward All feature, the CTI new call event will not provide the call-forward-all information.

These Cisco Unified IP Phones (SIP) support this feature:

Cisco Unified IP Phone 8961

Cisco Unified IP Phone 9951

Cisco Unified IP Phone 9971

Dual Bank Firmware Upgrade

With this release, the firmware upgrade process has been enhanced with a dual-banking capability. Now a new firmware image can be set to download in advance of a maintenance window. Then instead of waiting for all of the phones to download the firmware, the system switches more rapidly between resetting an existing load to Inactive status and installing the new load.

This reduces delays and congestion in downloading during the maintenance windows.

This feature is supported on the following Cisco Unified IP Phones:

Cisco Unified IP Phone 8961

Cisco Unified IP Phone 9951

Cisco Unified IP Phone 9971

Headset Profile Changed to Handsfree Profile

The Bluetooth Handsfree Profile offers enhanced call-processing services (such as redial, reject, callerID, 3-way calling, etc.) while the user is connected to the Bluetooth application on the Cisco Unified IP Phone 9951 and 9971.

In Cisco Unified IP Phone Firmware Release 9.1(1), the existing Headset Profile has been replaced with the Handsfree Profile.

In addition to the Bluetooth qualified inter-operability requirements, the high level-call control, device management, and media service applications on the desktop phone have been enhanced to support the Handsfree Profile. The Cisco Unified CM Administration displays a "Handsfree" option for Bluetooth Profiles.

Mute

As of the Firmware Release 9.0(3) and Unified CM 6.1(5) or later, the Mute softkey can be used to mute and unmute active calls in off-hook, ringing, or connected state.

When users select Mute/Unmute, the following occurs:

They receive an audible alert and a "Microphone Mute On" visual alert.

When they press the softkey again, the softkey changes to Unmute, they receive an audible alert and a "Microphone Unmute Off" visual alert.

For the Mute softkey to be displayed in the phone:

Cisco Unified CM 8.0 and later—Check the Enable Mute Feature check box in the in one of these windows:

Phone Configuration (Device > Phone)

Enterprise Phone Configuration (System > Enterprise Phone Configuration)

Common Phone Profile (Device > Device Settings > Common Phone Profile)

Earlier versions of Cisco Unified CM—Check the Enable Mute Feature check box in the Phone Configuration menu in Cisco Unified CM Administration.

This feature is supported on the following IP phones running the SCCP and SIP protocol:

Cisco Unified IP Phone 7911G

Cisco Unified IP Phone 7906G

Where to Find More Information

Cisco Unified IP Phone 7906G and 7911G Phone Guide for Cisco Unified Communications Manager

Cisco Unified IP Phone 7906G and 7911G Administration Guide for Cisco Unified Communications Manager

Secure and Nonsecure Indication Tone

With Firmware Release 9.0(3), the secure indication tone functionality was updated, and the nonsecure indication tone was added to the Secure and Nonsecure Indication Tone feature for the Cisco Unified IP Phones. The 8.0(3) release of Cisco Unified Communications Manager (Unified CM) is a requirement for these changes to function.

If phone is configured as secure (encrypted and trusted) in Unified CM, it can be given a "protected" status (which is separate from the status a call). After that if desired, the protected phone can be configured to play an indication tone at the beginning of a call:

Protected Device—To change the status of a secure phone to protected, check the "Protected Device" check box in Cisco Unified Communications Manager Administration > Device > Phone > Phone Configuration.

Play Secure Indication Tone—To enable the protected phone to play a secure or nonsecure indication tone, set the "Play Secure Indication Tone" to True. (The default is False.) You set this option in Cisco Unified Communications Manager Administration > System > Service Parameters. Select the server and then the Unified CM service. In the Service Parameter Configuration window, select the option in the Feature - Secure Tone area. (The default is False.)

Only protected phones hear secure or nonsecure indication tones. (Nonprotected phones never hear tones.) Because the condition for playing the secure indication tone is now based on the overall secure status of the call end to end and not the protected status of the phone, users hear a tone between a protected phone and a nonprotected phone if the Secure Real-Time Transfer Protocol (SRTP) or Real-Time Protocol (RTP) is established.

If the overall call status changes during the call, the indication tone changes accordingly. At that time, the protected phone plays the appropriate tone.

A protected phone plays a tone or not under these circumstances:

When the option to play a tone, "Play Secure Indication Tone," is enabled (True):

When end-to-end secure media is established through the Secure Real-Time Transfer Protocol (SRTP) and the call status is secure, the phone plays the secure indication tone (three long beeps with brief pauses).

When end-to-end nonsecure media is established through the Real-Time Protocol (RTP) and the call status is nonsecure, the phone plays the nonsecure indication tone (six short beeps with brief pauses). (This capability is a change with this release.)

When the Play Secure Indication Tone option is disabled (False), no tone is played.

These changes were also made with this release:

Users can invoke supplementary services, such as Transfer or Conference, from protected phones without a software limitation.

In the past if calls were transferred from a protected phone to another protected phone with RTP established, the call would be dropped. Now users hear a secure or nonsecure indication tone instead of the call being dropped.

The Secure and Nonsecure Indication Tone feature is supported on these IP phones running the SCCP and SIP protocol:

Cisco Unified IP Phone 7975G

Cisco Unified IP Phone 7971G-GE

Cisco Unified IP Phone 7970G

Cisco Unified IP Phone 7965G

Cisco Unified IP Phone 7962G

Cisco Unified IP Phone 7961G-GE

Cisco Unified IP Phone 7961G

Cisco Unified IP Phone 7945G

Cisco Unified IP Phone 7942G

Cisco Unified IP Phone 7941G-GE

Cisco Unified IP Phone 7941G

Cisco Unified IP Phone 7931G

Cisco Unified IP Phone 7911G

Cisco Unified IP Phone 7906G

Cisco Unified IP Phone 9971

Cisco Unified IP Phone 9951

Cisco Unified IP Phone 8961

Secure Extension Mobility

The Extension Mobility HTTPS Support feature ensures that when communications are exchanged between a Cisco Unified IP Phone service and other applications, that the communications use the HTTPS protocol to ensure that the communications are secure. Users must log into the Cisco Unified CM applications by providing their authentication information. Their credentials are encrypted after the communication protocol changes to HTTPS.

When a visiting Extension Mobility (EM) application fails to locate a user's identification in the local database, the following occurs:

1. Cisco Extension Mobility Cross Cluster (EMCC) sends a request to the local EM service to determine the home cluster of that user (the cluster which owns the user's identification, and which can handle the EM login).

2. The visiting EM service sends a user identification message over HTTPS to all the remote clusters added in the local database.

3. The visiting EM service then parses the response received from the home cluster to get the list of device profiles associated with that user.

All further communication between the visiting EM service and home EM service takes place over HTTPS.

Similarly, visiting logout requests are also sent from the home EM service to the visiting EM service over HTTPS.

The Extension Mobility HTTPS Support feature is supported on the following IP phones (SIP):

Cisco Unified IP Phone 8961

Cisco Unified IP Phone 9951

Cisco Unified IP Phone 9971


Note Configure Cisco Extension Mobility on Cisco Unified IP Phones before configuring EMCC.


Where to Find More Information

Cisco Unified Communications Manager Features and Services Guide, "Cisco Extension Mobility" chapter

Cisco Unified Communications Manager Features and Services Guide, "Cisco Extension Mobility Cross Cluster" chapter

Secure SIP Failover for SRST

Firmware Release 9.1(1) provides security support for calls on a Cisco Unified IP Phone running the Session Initiation Protocol (SIP) protocol. Secure SIP Failover for SRST enables calls to remain secure once the call fails over to Survivable Remote Site Telephony (SRST) from Cisco Unified Communications Manager.

The Secure SIP Failover for SRST feature enables VoIP calls that fail over to SRST devices to provide secure and encrypted transport using SIP. These voice calls originate from IP phones running the SIP protocol. In addition, this feature enables the user to verify that the call is still secure by the Lock icon that remains on the phone display.

Depending on the security configuration security settings are configured, the SRST supports RTP and SRTP media connections on the IP phone.

The system administrator configures SRST on a Cisco router to allow SIP phones to register to SRST using SIP/User Datagram Protocol (UDP), SIP/TCP, and SIP/Transfer Layer Security (TLS)/TCP.

For Firmware Release 9.1(1), when a SIP phone is in a secure call that fails over to SRST from Unified CM, the user will continue to see the a Lock icon will be displayed to indicate that the call is secure.

When IP phones register to the SRST, if all segments of the call are SIP phones, then all the supplementary features are supported—Conference, Transfer, Blind Transfer, and Call Forward. If the segments of the call are both SIP and SCCP phones, then only basic call is supported.

This feature is supported on the following SIP phones:

Cisco Unified IP Phone 8961

Cisco Unified IP Phone 9951

Cisco Unified IP Phone 9971

Where to Find More Information

Cisco Unified IP Phone 8961, 9951, and 9971 Administration Guide for Cisco Unified Communications Manager 8.5 (SIP)

Cisco Unified Communications Manager Release Notes

Trust Verification Service and Security

To support secure connections with other components, a Cisco Unified IP Phone authenticates component certificates by validating the certificates with entries in the Certificate Trust List (CTL) file, which has a 32-character maximum limit.

The Trust Verification Service (TVS) allows the phone to authenticate components without adding a CTL file entry. Adding new components or services does not require the CTL file to be updated on all of the phones.

The Security by Default feature removes the restriction that requires the user to create the CTL file by using eTokens to provide and enable security features. The signed file is enabled automatically by default.

The Trust Verification Service and Security by Default feature is supported on the following phones:

Cisco Unified IP Phone 8961

Cisco Unified IP Phone 9951

Cisco Unified IP Phone 9971

Using a USB Hub During an Active Call

If you use a USB hub on your IP phone or expansion module, do not unplug the hub while you are on an active call. Unplugging the hub in this scenario may cause the IP phone or expansion module to reboot. For more information, refer to CSCtf46146 using the Software Bug Toolkit.

Where to Find More Information

Cisco Unified IP Phone 8961, 9951, and 9971 Administration Guide for Cisco Unified Communications Manager 8.5 (SIP)

Release Notes 9.0(3)

Cisco Intercompany Media Engine

Enhancements to the Cisco Intercompany Media Engine (Cisco IME) server software in this release facilitate troubleshooting and allow for directed communications to individual servers on the network. For more information on the Cisco IME server software updates, refer to the Release Notes for Cisco Intercompany Media Engine Release 8.0(3).