Table of Contents
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.
- System Requirements
- Virtualization Requirements
- Product Documentation
- Installation and Upgrade Notes
- Important Notes
- Limitations and Restrictions
- New Features in Cisco TelePresence Exchange System Release 1.3
- Other Changes and Improvements
- Obtaining Documentation and Submitting a Service Request
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:
- 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.
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 .
- Two physical Cisco Unified Computing System (UCS) B-series blade servers that meet the specifications in the “Tested Reference Configuration for Virtualization” section and that are supported for use in a virtualized environment.
– 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.
- VMware ESXi Version 5.1 installed on the UCS servers on which the Cisco TelePresence Exchange System virtual machines will run. For instructions, see the Cisco UCS B-Series Blade Servers VMware Installation Guide , at http://www.cisco.com/en/US/products/ps10280/products_installation_and_configuration_guides_list.html .
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 .
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 .
150 GB, thick provisioned1, lazy zeroed
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.
- 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
- 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
- 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
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 .
- Installing Cisco TelePresence Exchange System Release 1.3 for the First Time
- Upgrading to Cisco TelePresence Exchange System Release 1.3
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 .
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 .
- 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
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:
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.
- 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 .
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.Step 1 Log in to the Unified CM Administration portal as the ccmadministrator user.
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:
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).
- 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 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
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.Router(config-sbc-sbe-mep-hdr-ele-act)# condition header-name Contact header-value regex-match "\(.*\);+sip.instance=[^;]*\(.*\)" store-as c1 c2
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.
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 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.
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.
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.
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.
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.
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.
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 .
- Max Screens Enforcement
- Ports in the Cloud
- Resource Consumption Optimization for Cisco TelePresence Server Version 3.0
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.
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.
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.
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 .
- 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
- 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 .
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.
- 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.
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.
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 .
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.
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.
For the latest information on resolved caveats for this release, access Bug Toolkit as described in the “Accessing Bug Toolkit” section.
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.Step 1 To access the Bug Toolkit, go to the following link:
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:
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.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: 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. (1110R)
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.