Cisco Unified Communications Manager Features and Applications

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.

•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

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.

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.

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.

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:

•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):

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.

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.

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

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.