Guest

Cisco TelePresence Exchange System

Release Notes for Cisco TelePresence Exchange System Release 1.3

  • Viewing Options

  • PDF (235.0 KB)
  • Feedback

Table of Contents

Release Notes for the Cisco TelePresence Exchange System Release 1.3

Contents

Introduction

System Requirements

Virtualization Requirements

Requirements for Virtualization

Tested Reference Configuration for Virtualization

Virtual Machine Specifications

Product Documentation

Installation and Upgrade Notes

Installing Cisco TelePresence Exchange Exchange System Release 1.3 for the First Time

Upgrading to Cisco TelePresence Exchange Exchange System Release 1.3

Important Notes

Licensing

Change to SIP Trunk Configuration Required to Enable CTS Endpoints to Join TPS Meetings

Enabling Cisco TelePresence Endpoints Running TC Release 5.x to Join Meetings Hosted on the Cisco TelePresence Multipoint Switch

Special Considerations for Interoperability with the Cisco TelePresence Manager

Limitations and Restrictions

Additional Header Editor Required to Allow Polycom Endpoints to Use IVR

Administration Console Access During Database Failover

Calls to CTMS Bridges Incur 20% Additional Overhead on CTS Endpoints

CTS Endpoints Do Not Support 1080p Content Quality on TPS Resources

Do Not Change the Hostname or IP Address of Cisco TelePresence Exchange Exchange System Servers

Do Not Disconnect the Network Adapter on Virtual Machines

Duplicate Failed Events Limitation for H.323 Endpoints

Grouped Endpoints in Active Meeting Management Limitation

ISDN Connection Limitation

Meeting Scheduling Race Condition Limitation

Number of Screens Configuration Limitation

Presentation Viewing Limitation on Cisco Unified IP Phone 9971/9951

Solution Caveats

New Features in Cisco TelePresence Exchange Exchange System Release 1.3

Max Screens Enforcement

Ports in the Cloud

Resource Consumption Optimization for Cisco TelePresence Server Version 3.0

Other Changes and Improvements

API Improvements

Choose Fields on Meeting List Page

Dial-Out Normalization

Host PINs Can Be Included in One-String-Dial Strings

Reduced Hard Disk Size Requirements for Virtual Machines

Security Certificate Management in Full-Feature Configurations

Caveats

Open Caveats

Resolved Caveats

Accessing Bug Toolkit

Obtaining Documentation and Submitting a Service Request

Release Notes for the Cisco TelePresence Exchange System Release 1.3

Revised March 28, 2014

 

These release notes describe the new features and caveats of the Cisco TelePresence Exchange System Release 1.3. For lists of open and resolved caveats that are pertinent to this release, see the “Caveats” section.

Introduction

The Cisco TelePresence Exchange System is an integrated video service-creation platform that enables service providers and strategic partners to offer secure cloud-based managed and hosted Cisco TelePresence and business video services. The Cisco TelePresence Exchange System is a software environment that provides the following benefits:

• Simplifies end-to-end subscriber service provisioning

  • Optimizes intelligent call routing for endpoints and network bandwidth
  • Manages the call processing and allocation of media resources for conferencing
  • Consolidates a centralized control point for management, billing, and administration
  • Presents an open application programming interface (API) for application integration such as scheduling, management of active meetings, and billing

Based on proven technology and powered by a fully redundant and horizontally scalable architecture, it delivers an open, scalable, and robust multi-tenant solution that can grow in scale and functions based on service needs. As a result, it accelerates time to market by simplifying the process of new services production and promotes service innovation through APIs that support service customizing.

System Requirements

For information on the required hardware and minimum software releases that the Cisco TelePresence Exchange System solution requires, see the System Requirements and Compatibility Matrix for the Cisco TelePresence Exchange System at http://www.cisco.com/en/US/docs/telepresence/tx/exchange_system/compatibility/matrix/ctxmatrix.html .

Virtualization Requirements

You can install Cisco TelePresence Exchange System Release 1.3 on virtual machines, upgrade from Release 1.2 on virtual machines, or migrate from physical servers to virtual machines.

Requirements for Virtualization

Virtualization has the following requirements:

You install the three Cisco TelePresence Exchange System server components—administration server, call engine server, and database server—on each UCS server. Having each of the components on each UCS server eliminates the possibility of having a single point of failure for the system.

The UCS servers must be dedicated to the Cisco TelePresence Exchange System (no other virtual machines are installed on the servers) to ensure that the virtual machines have sufficient resources available to them.

For additional guidelines on deploying the Cisco TelePresence Exchange System on virtual machines, see the “Preparing for Installation” chapter of the Installation and Upgrade Guide for the Cisco TelePresence Exchange System Release 1.3 , at http://www.cisco.com/en/US/products/ps11276/prod_installation_guides_list.html .

Tested Reference Configuration for Virtualization

The Cisco TelePresence Exchange System uses a “Tested Reference Configuration” model to describe supported configurations of compute, storage and network hardware for virtualization. The Tested Reference Configuration supported in Release 1.3 is described in Table 1 .

 

Table 1 Tested Reference Configurations for Cisco TelePresence Exchange System Release 1.3

Base Server Model and Generation
CPU
RAM
Storage
Adapters
VMware Environment

UCS B200 M3 D

Dual E5-2690 (2.9 GHz, 16 physical cores total)

64 GB (8x8GB)

  • DAS (RAID1) for VMware
  • FC SAN for Cisco TelePresence Exchange System applications

200 - 300 IOPs

300 GB Fastcache

4Gbps minimum FC interface speed

Cisco UCS M81KR

  • vCenter 5.1.0 (build 947673)
  • ESXi 5.1.0 (build 799733)

Virtual Machine Specifications

Each Cisco TelePresence Exchange System virtual machine is configured to the following specifications:

 

Hard Disk

150 GB, thick provisioned1, lazy zeroed

RAM

8 GB

CPU

1 CPU, 5 cores

Network

1 network adapter

1.We highly recommend that you use thick provisioning. Use thin provisioning only if you have effective storage monitoring in place and can ensure that the Cisco TelePresence Exchange System servers do not exceed the available storage capacity.

Product Documentation

For more information about the Cisco TelePresence Exchange System, see the following documentation:

To access the documentation suite for previous releases of the Cisco TelePresence Exchange System, go to the following URL: http://www.cisco.com/go/ctx-docs .

Installation and Upgrade Notes

Installing Cisco TelePresence Exchange System Release 1.3 for the First Time

For information related to installing the 1.3 version of the Cisco TelePresence Exchange System, see the “Preparing for Installation” chapter of the Installation and Upgrade Guide for the Cisco TelePresence Exchange System Release 1.3 .

Upgrading to Cisco TelePresence Exchange System Release 1.3

The upgrade process requires you to have Release 1.2 with patch 2 installed. For additional requirements and prerequisites and for the full upgrade procedure, see the applicable chapter of the Installation and Upgrade Guide for the Cisco TelePresence Exchange System Release 1.3 :

  • If you have Release 1.2 with patch 2 installed on virtual machines, see the “Upgrading the Software on Virtual Machines” chapter.
  • If you have Release 1.2 with patch 2 installed on MCS server hardware, there are two ways to upgrade to Release 1.3. You can either upgrade the software on the MCS server hardware, or migrate from the MCS servers to virtual machines on UCS server hardware while you do the upgrade. For instructions on how to upgrade the software on the MCS servers, see the “Upgrading the Software on MCS Servers” chapter. For instructions on upgrading while migrating to virtual machines, see the “Migrating from MCS Servers to Virtual Machines” chapter.

For information about how the Cisco TelePresence Exchange System migrates data from Release 1.2 to Release 1.3, see the “Data Migration” appendix of the Installation and Upgrade Guide for the Cisco TelePresence Exchange System Release 1.3 .

You can download patches from the Cisco TelePresence Exchange System Downloads page at http://www.cisco.com/go/ctx-download .

Important Notes

The following sections highlight items that might affect full operation of the Cisco TelePresence Exchange System:

Licensing

The Cisco TelePresence Exchange System Release 1.3 uses the port-based licensing model that was introduced in Release 1.2. In this model, you install a base license which provides 48 1080p HD ports. When you provision a media bridge resource on the system, the maximum capacity that you configure for the resource determines how many licensing ports it consumes, as follows:

 

Media Bridge Resource Type
Ratio of Max Capacity:License Ports

Cisco TelePresence Multipoint Switch (CTMS)

3 : 1

Cisco TelePresence Server MSE 8710 (TPS)

1 : 1

Cisco TelePresence MCU MSE 8510

2 : 1

For example, for a CTMS resource that is configured in the system with Max Capacity set to 24, eight license ports (24 / 3) are consumed. For a TPS resource with Max Capacity set to 24, 24 license ports are consumed. For an MCU MSE 8510 resource with Max Capacity set to 24 segments, 12 license ports (24 / 2) are consumed.

The system checks the HD port license capacity when you configure media bridge resources, which means that you cannot configure additional media bridge capacity if no unused port licenses are available. When your needs exceed the 48 base license ports, you can purchase and install additional HD license ports.

There are two types of base license available for the Cisco TelePresence Exchange System:

  • Base CTX HD Ports—Applicable to the full-feature configuration of Cisco TelePresence Exchange System. There is no limit to the amount of additional port licenses you can purchase and add beyond the 48 base ports provided by this license.
  • Base CTX Starter HD Ports—Applicable to the starter package configuration of Cisco TelePresence Exchange System. With this base license, your system is limited to a maximum of 250 port licenses (including the 48 base ports provided by the license). If you reach the 250 port limit, you must purchase a CTX Starter Upgrade license and additional port licenses to continue adding ports.

The Cisco TelePresence Exchange System comes with a preinstalled 60-day evaluation license that includes 48 ports. After 60 days, you must install a permanent base license to continue to use the Meet-Me and direct-dial services, and a permanent Active Meeting Management feature license if you wish to continue to use the active meeting management feature. Permanent licenses are perpetual, meaning that they do not expire and do not need to be renewed.

For more information on licensing, including the options available for each type of base license and system changes that can affect the validity of your licenses, see the “Managing Licenses” chapter of the Administration Guide for the Cisco TelePresence Exchange System Release 1.3 at http://www.cisco.com/en/US/products/ps11276/products_installation_and_configuration_guides_list.html .

Change to SIP Trunk Configuration Required to Enable CTS Endpoints to Join TPS Meetings

To enable Cisco TelePresence System (CTS) endpoints to join meetings that are hosted on a Cisco TelePresence Server through IVR, you must configure the SIP trunk between Cisco Unified Communications Manager and the border control element (SBC or Cisco VCS Expressway) to use RFC 2833 as the DTMF Signaling Method.

If this configuration is not done, the Cisco TelePresence Exchange System could fail to send an ACK message to the Cisco TelePresence Server, resulting in the endpoint failing to join the meeting and a BYE request will not be sent to the CTS endpoint or TPS resource to terminate their sessions.

For new SIP trunks, see the “Configuring Cisco Unified Communications Manager” chapter of the Administration Guide for the Cisco TelePresence Exchange System Release 1.3. If you have already configured the SIP trunk, do the following additional procedure.

Procedure


Step 1 Log in to the Unified CM Administration portal as the ccmadministrator user.

Step 2 Choose Device > Trunk .

Step 3 Click the name of the trunk that you want to update.

The Trunk Configuration page displays.

Step 4 From the DTMF Signaling Method drop-down menu, select RFC 2833 .

Step 5 To save the new settings, click Apply Config .


 

Enabling Cisco TelePresence Endpoints Running TC Release 5.x to Join Meetings Hosted on the Cisco TelePresence Multipoint Switch

Cisco TelePresence endpoints running TC release 5.x require a configuration change on Cisco TelePresence Multipoint Switch version 1.8 in order to join meetings hosted on the switch. For new installations, the Administration Guide for the Cisco TelePresence Exchange System Release 1.1 includes the procedure to make the configuration change when you configure the Cisco TelePresence Multipoint Switch to work with the Cisco TelePresence Exchange System.

If you have already configured a Cisco TelePresence Multipoint Switch to work with the Cisco TelePresence Exchange System, do the following additional procedure to enable Cisco TelePresence TC5.x endpoints to join meetings hosted on the Cisco TelePresence Multipoint Switch:

Procedure


Step 1 In CTMS Administration, from the left navigation pane, choose Manage > Default Meeting Settings .

The Default Settings window displays.

Step 2 For Supported Endpoint Types, select Cisco TelePresence TC 5.0 (and later) and CTS 1.8 (and later) endpoints .

Step 3 To save the modified setting, click Apply .


 

Special Considerations for Interoperability with the Cisco TelePresence Manager

To ensure proper interoperability between the Cisco TelePresence Manager and the Cisco TelePresence Exchange System, a Cisco support engineer must perform additional configuration to enable the API and hosted mode for OBTP functionality on the Cisco TelePresence Manager during system installation. To arrange for this support, contact your local Cisco system engineer or file a support case at Cisco.com.


Note During initial configuration of the Cisco TelePresence Manager, ensure that you select the scheduling API option. If you proceed with configuration of the Cisco TelePresence Manager without selecting this option, you must perform a reinstall to correct this issue.


Be aware that if the necessary configuration is not done, the Cisco TelePresence Exchange System might fail to authenticate with the Cisco TelePresence Manager or might report the following API exception value and cause code: ERC_CTSMAN_COMMUNICATION_FAILURE (exception value), CTSMAN_INTERCOMPANY_NOT_CONFIGURED (cause code).

Limitations and Restrictions

The following sections detail limitations and restrictions related to the use of and interoperability with the Cisco TelePresence Exchange System:

Additional Header Editor Required to Allow Polycom Endpoints to Use IVR

Added September 6, 2013

In Release 1.2 and 1.3, Polycom endpoints are unable to use the IVR to join Cisco TelePresence Exchange System meetings unless you add an outbound SIP header editor on the Cisco Session Border Controller and apply the header editor to the adjacencies for the Cisco Application Control Engine and the two Cisco TelePresence Exchange System call engine servers. (Polycom endpoints are able to join meetings when bypassing the IVR by using a single dial string with the service number and conference ID, for example 18005551212**12345678.)

Procedures and examples in the “Configuring Cisco Session Border Controllers” chapter of the Administration Guide for the Cisco TelePresence Exchange System Release 1.3 have been updated to include configuring the outbound editor and setting the editor when creating adjacencies. If you have already configured the inbound SIP header editor and created adjacencies, you can use the examples in this section to add to an existing configuration.

The following example shows how to define the outbound SIP header editor for Polycom endpoints:

Router(config)# sbc mmsbc
Router(config-sbc)# sbe
Router(config-sbc-sbe)# sip header-editor HE_POLYCOM
Router(config-sbc-sbe-mep-hdr)# store-rule entry 1
Router(config-sbc-sbe-mep-hdr-ele-act)# condition header-name Contact header-value regex-match "\(.*\);+sip.instance=[^;]*\(.*\)" store-as c1 c2
Router(config-sbc-sbe-mep-hdrele-act)# exit
Router(config-sbc-sbe-mep-hdr-ele-act)# header contact entry 1
Router(config-sbc-sbe-mep-hdr-ele)# action replace-value value "${c1}${c2}"
Router(config-sbc-sbe-sip-hdr-ele-act)# condition variable c1 is-defined eq true
 

The following example shows how to add the outbound header editor to the Cisco Application Control Engine and Cisco TelePresence Exchange System call engine adjacencies:

Router(config)# sbc mmsbc
Router(config-sbc)# sbe
Router(config-sbc-sbe)# adjacency sip TEST-ACE
Router(config-sbc-sbe-adj-sip)# no attach
Router(config-sbc-sbe-adj-sip)# header-editor outbound HE_POLYCOM
Router(config-sbc-sbe-adj-sip)# attach
Router(config-sbc-sbe-adj-sip)# adjacency sip TEST_CTX_ENGINE1
Router(config-sbc-sbe-adj-sip)# no attach
Router(config-sbc-sbe-adj-sip)# header-editor outbound HE_POLYCOM
Router(config-sbc-sbe-adj-sip)# attach
Router(config-sbc-sbe-adj-sip)# adjacency sip TEST_CTX_ENGINE2
Router(config-sbc-sbe-adj-sip)# no attach
Router(config-sbc-sbe-adj-sip)# header-editor outbound HE_POLYCOM
Router(config-sbc-sbe-adj-sip)# attach
 

Administration Console Access During Database Failover

In the event of a database failure, the administration console may take up to two minutes to respond after database failover.

Calls to CTMS Bridges Incur 20% Additional Overhead on CTS Endpoints

Revised March 28, 2014

When a CTS endpoint calls into a meeting that is hosted on a Cisco TelePresence Multipoint Switch (CTMS) bridge, the bandwidth used by the call may be subject to 20% additional overhead. This behavior does not apply to calls to Cisco TelePresence Server or MCU bridges.

CTS Endpoints Do Not Support 1080p Content Quality on TPS Resources

When connecting to a meeting that is hosted on a TPS resource (Cisco TelePresence Server MSE 8710 media bridge), a CTS endpoint will negotiate only to 720p content quality with Cisco TelePresence Server version 3.0. Full 1080p content quality is supported only with Cisco TelePresence Server version 3.1 and later. (For current version compatibility information, see the System Requirements and Compatibility Matrix for the Cisco TelePresence Exchange System at http://www.cisco.com/en/US/docs/telepresence/tx/exchange_system/compatibility/matrix/ctxmatrix.html .)

Do Not Change the Hostname or IP Address of Cisco TelePresence Exchange System Servers

Do not change the hostname or IP address on any of the Cisco TelePresence Exchange System servers. Once the hostname and IP address are set and the Cisco TelePresence Exchange System software installed, changing the hostname or IP address is not supported.

Do Not Disconnect the Network Adapter on Virtual Machines

Do not disconnect the network adapter on any of the Cisco TelePresence Exchange System virtual machines. If you do so, you must restart the virtual machine once it is reconnected.

Duplicate Failed Events Limitation for H.323 Endpoints

If a call from an H.323 endpoint that is registered to Cisco VCS is rejected, the system will generate two “Participant Join Failed” events. The call can be rejected for various reasons including the following:

  • The call would exceed the organization's maximum port limit
  • The meeting’s maximum screens limit has been reached

The error events and call detail records (CDRs) are generated twice because of the way Require headers are handled between the Cisco VCS and the media bridges or integrated voice response (IVR) system.

Grouped Endpoints in Active Meeting Management Limitation

If grouped endpoints join a meeting, each screen will be listed in Active Meeting Management. However, you will not be able to modify any of the properties for the grouped endpoints and only the status of the main endpoint will be accurate.

ISDN Connection Limitation

ISDN calls must be connected for at least three minutes to be considered successfully connected. If an ISDN call disconnects within three minutes, the system will automatically redial the number.

Meeting Scheduling Race Condition Limitation

If you attempt to schedule two meetings at the same time for the same time slot and they both require immediate allocation, you will receive an error message, and must try again. This will only happen for two Rendezvous guaranteed meetings or two Meet-Me guaranteed meetings scheduled within 5 minutes of the start time.

Number of Screens Configuration Limitation

If the number of screens in the media profile that you select for an endpoint does not match the actual number of screens supported by the endpoint, dial-out calls to that endpoint will connect using the number specified in the media profile. For example, if you provision a three-screen endpoint as a one-screen endpoint, dial-out calls to that endpoint will always connect as one screen. This limitation does not apply to dial-in calls.

Presentation Viewing Limitation on Cisco Unified IP Phone 9971/9951

Participants who use a Cisco Unified IP Phone 9971, or Cisco Unified IP Phone 9951 to attend a Meet-Me meeting hosted on a Cisco TelePresence MCU MSE 8510 bridge are sometimes unable to view presentations shared by remote endpoints.

When scheduling a Meet-Me meeting, you can work around this issue by selecting a Custom Screen Layout option other than the default (single-screen) layout.

If you are seeing this issue when the meeting is active, you can use Active Meeting Management to modify the Custom Screen Layout to use any layout other than the single screen layout.

Solution Caveats

Note the following open caveats that may affect the operation or functionality of the Cisco TelePresence Exchange System solution:

 

Table 2 Solution Caveats

Product
Identifier
Headline
Fixed In Version

CTMS

CSCue06577

EX90 can hear audio from CTS 3000 even if they are muted

1.9.4

CTMS

CSCug72246

ALARM_PROCESS_DEAD Execution Manager detected a process

1.9.4

CTMS

CSCuh56345

Execution Manager detected a process(MediaProcessor signal=11) dead

1.9.4

CTS

CSCuh76864

CTS advertises num TX as 0 when it receives recvonly in SDP

1.10.2

CTS

CSCuh04542

Endpoint unable to join due to TIP/MUX negotiation failure on TPS

1.10.2

CUCM

CSCuh88764

Cisco Tomcat service - Failed to open https ports, OutOfMemoryError

9.1.2

TPS

CSCuh39241

192 audio tokens in non-TIP CTS call gives incorrect near-end values

New Features in Cisco TelePresence Exchange System Release 1.3

This section includes information about new features in Cisco TelePresence Exchange System Release 1.3 only. For information about features that were introduced in other Cisco TelePresence Exchange System releases, see the applicable release notes at http://www.cisco.com/en/US/products/ps11276/prod_release_notes_list.html .

See the following sections:

Max Screens Enforcement

The Max Screens feature provides a simple mechanism to limit meeting size at attend time on a per-meeting basis, for meetings hosted on TPS resources (Cisco TelePresence Server MSE 8710 media bridges). With this enhancement, the system automatically calculates the maximum number of screens that are allowed to join a meeting on a TPS resource based on the parameters you specify when scheduling the meeting. Once the maximum limit is reached, additional participants attempting to dial in to the meeting hear the Max Participants Prompt and are disconnected.

The system calculates the Max Screens limit based on the meeting type and meeting parameters, as follows:

 

Meet-Me meetings

Sum total of the number of screens defined in the media profile of each invited endpoint + Additional Capacity defined for the meeting

Rendezvous meetings

Number of Screens + Additional Capacity

This limit considers only the number of screens of an endpoint and does not take into account other factors such as video resolution. Each audio-only participant that joins the meeting is counted as a single screen. If an endpoint is provisioned for three screens but joins as a single screen, the system counts the endpoint as a single screen (thereby allowing two additional screens to join provided that the required capacity is available).

For either type of meeting, if additional endpoints are added to the meeting by using active meeting management, the system increases the Max Screens limit accordingly. You can also change the limit by adjusting the Additional Capacity. You can view the Max Screens value on the meeting details page or on the Active Meetings List page. The value is also returned in the Scheduling API apiMeeting element in response to a meeting scheduling, modification, or get request.

Ports in the Cloud

The Ports in the Cloud feature enables you to create a volume-based best-effort meeting service on the Cisco TelePresence Exchange System. The feature is implemented as two capacity limits that you can apply to Rendezvous and Meet-Me meetings for an organization:

  • Organization Allowed Ports—Using this limit, an organization can purchase a fixed number of virtual ports and then utilize as many Rendezvous or scheduled Meet-Me meetings as necessary. Usage that exceeds the purchased baseline can be tracked separately, for premium billing.
  • Organization Maximum Allowed Ports—This limit is optional. If it is applied, usage can be capped at a maximum level above which additional attempts to add meeting participants are rejected.

As each endpoint joins a meeting belonging to the organization (as determined by the organization of the meeting scheduler) the capacity allocated for the endpoint is added to the current usage total for the organization, which is checked against the limits. When the Organization Allowed Ports limit is met, the system raises an alarm.

If the Organization Maximum Allowed Ports limit is configured, when usage meets the limit the system raises an alarm and will not dial out to add participants. Any endpoints that attempt to dial in to a meeting scheduled for the organization will hear the recording for the new Organization Max Allowed Ports Prompt and the Goodbye Prompt before being disconnected. If the Organization Maximum Allowed Ports limit has not been met but would be exceeded by the addition of an endpoint, the system will not allow the endpoint to join, though an alternate endpoint that uses less capacity may still be able to join.

You can configure aspects of the Ports in the Cloud feature at the service provider, organization, and meeting levels. When you enable the feature at the service provider level, you configure the Organization Allowed Ports and Organization Maximum Allowed Ports limits, both of which will be applied to any organizations that inherit the configuration from the service provider. At the organization level, you can configure the organization to inherit the settings (including the limits and whether or not the feature is enabled) from the service provider, disable the feature for the organization or set individual limits for the organization. At the meeting level, you can either enable or disable the feature, which dictates whether the meeting capacity is counted towards the limits for the organization.

Resource Consumption Optimization for Cisco TelePresence Server Version 3.0

In Release 1.3, the Cisco TelePresence Exchange System utilizes the dynamic optimization of resources provided by the new remote management API in version 3.0 of the Cisco TelePresence Server. This feature provides the following optimizations for use with TPS resources (Cisco TelePresence Server MSE 8710 media bridges):

  • When scheduling a meeting on the Cisco TelePresence Exchange System, you can specify that the meeting must be hosted on a TPS resource and select a meeting quality profile that specifies the maximum resolution at which meeting participants can send and receive main video, audio, and content. This allows you to limit the usage of TPS screen licenses for the meeting, and to better utilize capacity on the media bridge resource based on the capabilities of most participant endpoints. Reserved capacity for the meeting is based on the selected meeting quality profile.
  • When an endpoint joins the meeting at attend time, the Cisco TelePresence Exchange System internally calculates the amount of capacity to allocate for the endpoint based on the number of screens reported in the SIP header and the capacity needed for the quality levels defined in the meeting quality profile. Whenever the system receives updated information from the Cisco TelePresence Server API about the amount of capacity actually used by the endpoint, it updates the allocation. Unused capacity can be returned to the resource pool for best-effort meetings or to the meeting itself for guaranteed meetings. For example, if a single-screen endpoint joins a meeting configured with 1080p max video quality but only comes in at 720p, the system will reclaim the surplus resources so that another endpoint from the same meeting (guaranteed) or from the same pool (best-effort) can use it.
  • Active Meeting Management and meeting diagnostic event logs track the capacity used by an endpoint when the endpoint joins and when any changes occur, both for dial-in and dial-out endpoints. The call detail records list the last capacity and video quality, audio quality, and content quality used by the endpoint.
  • Audio-only participants joining the meeting are optimized to utilize only 1/52 of a TPS screen license. (When initially connecting to the meeting, such participants are treated as single-screen video calls until the Cisco TelePresence Server API notifies the Cisco TelePresence Exchange System that the endpoint is audio-only, at which time the system adjusts and reclaims the excess capacity.)

Release 1.3 requires all TPS resources to be running Cisco TelePresence Server version 3.0 and to be operating in remotely managed mode. If you upgrade from Release 1.2, any TPS resources that do not meet these requirements are placed offline during data migration.

When scheduling a meeting on a TPS resource in Release 1.3, the system provides 10 predefined media quality profiles to choose from, with audio, video, and content-sharing levels that are based on the most common meeting scenarios. For existing Rendezvous and future Meet-me meetings that were scheduled on TPS resources in Release 1.2, during migration to Release 1.3 the system recalculates the reserved meeting capacity using a default media quality profile that depends on whether the meeting was scheduled with a FullHD, HD, or mixed mode resource pool. For more information about the migration of TPS resources and associated meetings, see the “Data Migration” appendix of the Installation and Upgrade Guide for the Cisco TelePresence Exchange System Release 1.3 , at http://www.cisco.com/en/US/products/ps11276/prod_installation_guides_list.html .

For more information on the dynamic optimization of resources and the screen license model in Cisco TelePresence Server version 3.0, see the Cisco TelePresence Server 7010 and 8710 Release Notes at http://www.cisco.com/en/US/products/ps11339/prod_release_notes_list.html .

Other Changes and Improvements

This section includes information about changed functionality and improvements in Cisco TelePresence Exchange System Release 1.3.

See the following sections:

API Improvements

In addition to updates for new features, the Release 1.3 API includes the following improvements:

  • In the Active Meeting Management API, the apiMeetingStatus element (returned in the Get Current Meeting Status result) includes the previousParticipants element, containing one or more participantsInCurrentMeeting elements representing participants that have left the meeting. In addition, the participantsInCurrentMeeting element now includes the guid, leaveTime, and isAudioOnly attributes.
  • In the Active Meeting Management API, the activeMeeting element (returned in the Get Active Meetings result) and the apiMeetingStatus element (returned in the Get Current Meeting Status result) both return a common basicActiveMeeting element. The common element contains three additional attributes compared to the set returned by activeMeeting and apiMeetingStatus in Release 1.2: meetingInstanceId, meetingType, and scheduler. It also includes the isLocked attribute, which is new to the activeMeeting element.
  • In the Scheduling API, the apiMeeting element (returned from a getMeeting request) includes the meetingType attribute, an enumeration that specifies the type of meeting—MEETME, RENDEZVOUS, REMOTE, or TWOPARTYDIRECT. The attribute replaces the isRemote, isRendezvous, and isTwoPartyDirect attributes that were returned in previous releases.

For the full list of changes to the APIs between Release 1.2 and Release 1.3, see the “Backward Compatibility” appendix of the API User Guide for the Cisco TelePresence Exchange System Release 1.3 , at http://www.cisco.com/en/US/products/ps11276/products_programming_reference_guides_list.html .

Choose Fields on Meeting List Page

In Release 1.3, the Collaboration Services > Meetings page is enhanced to allow you to customize the meeting fields that you want to display by clicking Choose Fields .

For more information on the meetings list page, see the “Viewing Meetings” section in the “Configuring Collaboration Services” chapter of the Administration Guide for the Cisco TelePresence Exchange System Release 1.3 , at http://www.cisco.com/en/US/products/ps11276/products_installation_and_configuration_guides_list.html.

Dial-Out Normalization

Release 1.3 includes changes to the dial-out and dial-in implementation, resulting in the following improvements for active meetings:

  • When modifying an active meeting, you can change the dial type of invited endpoints that are not currently in the meeting from dial-in to dial-out. The system then dials out to add the endpoint. Use this method to reach a participant who was not previously in the meeting. (You can also change the type from dial-out to dial-in.)
  • You can use the Active Meeting Management “redial” button to have the system dial out to a disconnected endpoint that was previously in the meeting as a dial-in participant. Use this method to redial instead of changing the dial type of the endpoint to dial-out. If a dial-in endpoint was previously connected to the meeting, the system will not dial out to that disconnected endpoint if you change its dial type from dial-in to dial-out.

Note that the changes also impact the way the system allocates resources for participants that you add via active meeting management. As a result, you no longer see a pop-up warning message in the administration console if you try to add a participant when resource capacity is unavailable. Instead, the failure details are available in the Events view of the Active Meeting Diagnostics area for the meeting.

Host PINs Can Be Included in One-String-Dial Strings

In Release 1.3, the one-string-dial capability allows clients that do not support sending DTMF tones during a call to enter both the conference ID and the host PIN for a host-enabled meeting without going through the IVR. When dialing in to a meeting, the participant can dial a single string of digits that combines the service number and conference ID with the host PIN, with ** separating each part. For example, for service number 18005551212, conference ID 12345678, and host PIN 333333, the client can dial 18005551212**12345678**333333 to enter and start the meeting as a host.

In previous releases, only the conference ID could be included in the one-string-dial string. Note that in order to support this expanded capability, the route pattern or search rule on the call control element that routes calls to the Cisco TelePresence Exchange System must be configured to support the additional ** characters and six-digit host PIN string.

Reduced Hard Disk Size Requirements for Virtual Machines

The Release 1.3 OVA template creates a virtual machine with an 150-GB hard disk. The previous Release 1.2 OVA created a 400-GB hard disk for each virtual machine.

If you are upgrading from Release 1.2, during the upgrade process, you must recreate the virtual machines with the new Release 1.3 OVA template. For instructions on the upgrade process, see the “Upgrading the Software on Virtual Machines” chapter of the Installation and Upgrade Guide for the Cisco TelePresence Exchange System Release 1.3 .

Security Certificate Management in Full-Feature Configurations

In Release 1.3, self-signed certificates and Certificate Signed Requests (CSRs) are generated during the installation process based on the server information that you enter during installation, regardless of whether you choose to install the full-feature configuration or starter package configuration of the Cisco TelePresence Exchange System. After installation, you can use the System > Security Certificates window in the administration console to manage the certificates.

In Release 1.2, the self-signed certificates and CSRs were generated only for starter package configurations, and the Manage Security Certificates window was not available for full-feature configurations. In both releases, the certificates are used only for the Cisco TelePresence Exchange System call engine nodes.

For more information on the Manage Security Certificates window, see the “Managing Security Certificates” section in the “Configuring System Settings” chapter of the Administration Guide for the Cisco TelePresence Exchange System Release 1.3 , at http://www.cisco.com/en/US/products/ps11276/products_installation_and_configuration_guides_list.html.

Caveats

This section addresses the open caveats in this release and provides information on how to use the Bug Toolkit to find further details on those caveats. Topics in this section include:

Open Caveats

Table 3 describes the open caveats in this release of the Cisco TelePresence Exchange System. Caveats are listed in order by severity, then by component, then by caveat number.

 

Table 3 Open Caveats in Cisco TelePresence Exchange System Release 1.3

Identifier
Component
Severity
Headline

CSCui18483

admin_ui

Moderate

Endpoint with mono audio quality displays as stereo

CSCui20371

admin_ui

Moderate

No alarm is raised when newly added or modified resource is unreachable

CSCui20383

admin_ui

Moderate

Change to MQP does not take effect for certain guaranteed meetings

CSCui20426

admin_ui

Moderate

Internal error while trying to extend admin session

CSCui20420

admin_ui

Moderate

Cannot delete ReservationType once referenced

CSCui36401

admin_ui

Moderate

Successful backup of 1.2 erroneously listed as failed in 1.3

CSCui36411

admin_ui

Moderate

Cannot modify 2-party or remote meeting parameters via admin console

CSCui20397

api

Moderate

Unprovisioned endpoint can be added without a media profile

CSCui18474

call_control

Moderate

Duplicate events are generated for CTMS dialout calls

CSCui20391

call_control

Moderate

Disconnect cause is unknown when endpoint cannot join a locked meeting

CSCui20414

call_control

Moderate

One call engine cannot process calls after both engines are restarted

CSCui20341

licensing

Moderate

No alarms are raised for invalid base or incremental port licenses

CSCui18498

other

Moderate

Dial-in to Meet-Me meeting on TPS fails with XmlRpcException: URI in use

CSCui20367

other

Moderate

Error dropping participant displayed in Active Meeting Management

CSCui20432

other

Moderate

Resource allocation may fail for best-effort Rendezvous meeting

CSCui20411

system_management

Moderate

After an 8510 resource comes online, first caller’s details may be lost

Resolved Caveats

For the latest information on resolved caveats for this release, access Bug Toolkit as described in the “Accessing Bug Toolkit” section.

Accessing Bug Toolkit

You can use the Bug Toolkit to find information about caveats for this release, including a description of the problems and available workarounds. The Bug Toolkit lists both open and resolved caveats.

To access Bug Toolkit, you need the following items:

  • Internet connection
  • Web browser
  • Cisco.com user ID and password

To use the Bug Toolkit, do the steps in the following procedure.

Procedure


Step 1 To access the Bug Toolkit, go to the following link:

http://tools.cisco.com/Support/BugToolKit/action.do?hdnAction=searchBugs

Step 2 Log in with your Cisco.com user ID and password.

Step 3 To look for information about a specific problem, enter the bug ID number in the Search for Bug ID field and click Go.

Step 4 To look for information when you do not know the bug ID number, do the following:

a. From the Select Product Category menu, choose TelePresence .

b. From the Select Products menu, choose the desired product.

c. From the Software Version menu, choose the version number.

d. Under Advanced Options, choose either Use default settings or Use custom settings .

When you select Use default settings , the system searches for severity 1, 2, and 3 bugs, open and fixed bugs, and only those bugs containing bug details.

When you select Use custom settings , you can specify the severity and status parameters or search for keywords within the bug headline and description.


 

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What’s New in Cisco Product Documentation , which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to the What’s New in Cisco Product Documentation as an RSS feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service. Cisco currently supports RSS Version 2.0.

This document is to be used in conjunction with the documents listed in the “Product Documentation” section.