Cisco has now announced end-of-sale and end-of-life dates for the Cisco TelePresence Video Communication Server (VCS) product. Details are available at https://www.cisco.com/c/en/us/products/collateral/unified-communications/telepresence-video-communication-server-vcs/eos-eol-notice-c51-743969.html.

This section applies to hardware support services only.

CE500 and CE1000 appliances - End-of-sale notice

The Cisco Expressway CE500 and CE1000 appliance hardware platforms are no longer supported by Cisco. See the End-of-sale announcement for more details.

CE1100 appliance - end-of-sale and advance notice of hardware service support withdrawl.

As of 13 November 2018, you cannot order the CE1100 appliance from Cisco. Cisco will withdraw hardware support services for the appliance in a future release. See the End-of-sale announcement for other important dates in the lifecycle of this platform.

The Cisco Expressway Administrator Guide details which Cisco VCS services can coexist on the same Cisco VCS system or cluster. See the table "Services That Can be Hosted Together" in the Introduction section. For example, if you want to know if MRA can coexist with CMR Cloud (it can) the table will tell you.

Follow the links below to read the most recent information about the open and resolved issues in this release.

• All open issues, sorted by date modified (recent first)

• Issues resolved by X14.0

We aim to provide new Cisco VCS features as speedily as possible. Sometimes it is not possible to officially support a new feature because it may require updates to other Cisco products which are not yet available, or known issues or limitations affect some deployments of the feature. If customers might still benefit from using the feature, we mark it as "preview" in the release notes. Preview features may be used, but you should not rely on them in production environments. Occasionally we may recommend that a feature is not used until further updates are made to Expressway or other products. Cisco VCS features which are provided in preview status only in this release, are listed in the "Feature History table" earlier in these notes.

Currently, if one Cisco VCS node in a clustered deployment fails or loses network connectivity for any reason, or if the Unified CM restarts, all active calls going through the affected node will fail. The calls are not handed over to another cluster peer. This is not new behavior in X12.5.x, but due to an oversight it was not documented in previous releases. Bug ID CSCtr39974 refers.

Cisco VCS does not terminate DTLS. We do not support DTLS for securing media and SRTP is used to secure calls. Attempts to make DTLS calls through Cisco VCS will fail. The DTLS protocol is inserted in the SDP but only for traversing the encrypted iX protocol.

From X12.5, Expressway provides limited SIP UPDATE support over MRA connections for session refresh purposes only, as specified by RFC 4028. However, you should not switch this on unless you have a specific requirement to use this capability. Any other use of SIP UPDATE is not supported and features that rely on this method will not work as expected.

Cisco VCS does not support the SIP UPDATE method (RFC 3311), and features that rely on this method will not work as expected.

Audio calls may be licensed as video calls in some circumstances. Calls that are strictly audio-ONLY consume fewer licenses than video calls. However, when audio calls include non-audio channels, such as the iX channel that enables ActiveControl, they are treated as video calls for licensing purposes.

From X12.6.1, due to security enhancements, the Cisco VCS Expressway TURN server no longer functions as a generic STUN server and will not accept unauthenticated STUN binding requests.

This leads to the following scenarios:

• Scenario A: If you use the B2BUA as a TURN client for Microsoft interoperability (as described in the Cisco Expressway with Microsoft Infrastructure Deployment Guide) the B2BUA will not send any STUN binding requests to the TURN server to check if it is alive or not. This means that from Cisco VCS X12.6.1, the B2BUA may try to use a TURN server that is not reachable and hence that calls may fail.

• Scenario B: If you use Meeting Server WebRTC with Expressway (and Expressway-E is configured as a TURN server) before you install Cisco VCS X12.6.1 or later, first upgrade the Meeting Server software to version 3.0 or to a compatible maintenance release in version 2.9.x or 2.8.x. Bug ID CSCvv01243 refers. This requirement is because other Meeting Server versions use STUN bind requests towards the TURN server on Cisco VCS Expressway (For more information about Cisco VCS Expressway TURN server configuration, see the Cisco Expressway Web Proxy for Cisco Meeting Server Deployment Guide.).

Expressway X12.6 and later does not work for hosting the Call Connector software that is required in a Hybrid Call Service deployment and you need to use an earlier supported version for the Expressway connector host. See the Hybrid Call Service known issues and Expressway version support documentation on https://help.webex.com/ for more information.

This item applies if you want to convert existing Expressway licenses (RMS, Desktop, or Room) to Smart Licensing entitlements. In this case do not use the option in the Cisco Product License Registration portal to partially convert just some of the licenses. Due to a known issue, if you opt to convert only some licenses, the system automatically forfeits/removes the remaining licenses as well. So the licenses that are not converted are also removed, and a licensing case will be required to retrieve them.

To avoid this happening, please ensure that the Quantity to Convert field is the same value as the Quantity Available field; this is the default when you open the page.

From X12.5.5, support for static NAT functionality on TURN is extended to clustered systems (support for standalone systems was introduced in X12.5.3). However, peers which are configured as TURN servers must be reachable using the private addresses for their corresponding public interfaces.

If you use Cisco VCS for Mobile and Remote Access (MRA), some unsupported features and limitations currently exist. A list of key unsupported features that we know do not work with MRA is detailed in Key Supported and Unsupported Features with Mobile and Remote Access in the Mobile and Remote Access Through Cisco Expressway Guide.

For details of which 7800/8800 Series phones and other endpoints support MRA, see the MRA Requirements section of the Mobile and Remote Access Through Cisco Expressway Guide.

1. SIP UPDATE for session refresh support over MRA has some limitations. For example, the following features that rely on the SIP UPDATE method (RFC 3311) will fail:

• Request to display the security icon on MRA endpoints for end-to-end secure calls.

• Request to change the caller ID to display name or number on MRA endpoints.

2. Unity Voicemail over Mobile and Remote Access (MRA) does not work with X14.0 release. This issue will be fixed in our future release(bug ID CSCvy29217 refers.

Note	Do not upgrade if the Unity Voicemail feature is sufficiently significant.

Expressway X12.7 can support IM&P dual connection mode. However, please do not use this feature as it is not yet implemented throughout the wider solution.

In standard MRA mode (no ICE) regardless of any MRA access policy settings configured on Unified CM, Cisco Jabber users will be able to authenticate by username and password or by traditional single sign-on in the following case:

• You have Jabber users running versions before 11.9 (no refresh token support) and Cisco VCS is configured to allow non-token authentication.

In ICE passthrough mode, the ICE MRA call path must be encrypted end-to-end (see Signaling Path Encryption Between Expressway-C and Unified CM in the Expressway MRA Deployment Guide). Typically for end-to-end encryption, Unified CM must be in mixed mode for physical endpoints. For Jabber clients however, you can achieve the end-to-end encryption requirement by leveraging SIP OAuth with Unified CM clusters that are not in mixed mode.

Note	You must enable SIP OAuth if the Unified CM is not in mixed mode, but SIP OAuth is not required for Jabber if you're able to register using standard secure profiles.

More information is in the Configure MRA Access Control section of the Expressway MRA Deployment Guide and in the Deploying OAuth with Cisco Collaboration Solution Release 12.0 White Paper.

When a new peer is added to a cluster, the system may raise multiple 20021 Alarms (Cluster communication failure: Unable to establish...) even if the cluster is in fact correctly formed. The alarms appear on the existing peers in the cluster. The unnecessary alarms are typically lowered after at least 5 minutes elapses from the time that the new peer is successfully added.

These alarms also occur if a peer is removed from a cluster. This is generally valid alarm behavior in the case of removing a peer. However, as in the case of adding a peer, the alarms may not be lowered for 5 minutes or more.

• This issue applies to Cisco VCSs running as virtualized systems with certain ESXi versions using VMWare vCenter 7.0.x. It was found during testing using VMWare vCenter 7.0.1 with ESXi 6.7.0 to deploy a VCS OVA. The Ready to complete final page of the Deploy OVF Template wizard displays template values instead of the actual values entered on the earlier wizard pages. The issue is cosmetic, and when you click "FINISH" the OVA will deploy as expected using the entered values. Bug ID CSCvw64883 refers.

• Video calling capacity may be restricted if the ESXi Side-Channel-Aware Scheduler is enabled, and CPU load exceeds 70%.

• With physical Cisco VCS appliances, the Advanced Networking feature allows the speed and duplex mode to be set for each configured Ethernet port. You cannot set port speeds for virtual machine-based Cisco VCS systems.

  Also, virtual machine-based systems always show the connection speed between Cisco VCS and Ethernet networks as 10000 Mb/s, regardless of the actual physical NIC speed. This is due to a limitation in virtual machines, which cannot retrieve the actual speed from the physical NIC(s).

If you translate the Cisco VCS web user interface, new Cisco VCS language packs are available from X8.10.3. Older language packs do not work with X8.10.n software (or X8.9.n). Instructions for installing or updating the packs are in the Cisco VCS Administrator Guide.

If you use XMPP external federation, be aware that if an IM and Presence Service node fails over to a different node after an outage, the affected users are not dynamically moved to the other node. Cisco VCS does not support this functionality, and it has not been tested.

This issue applies if you deploy Cisco VCS with a dual-NIC Cisco VCS Expressway. Cisco Webex Calling requests may fail if the same (overlapping) static route applies to both the external interface and the interface with the Cisco VCS Control. This is due to current Cisco VCS Expressway routing behavior, which treats Webex INVITES as non-NAT and therefore extracts the source address directly from the SIP Via header.

Note	We recommend that you make static routes as specific as possible, to minimize the risk of the routes overlapping, and this issue occurring.

If you use dual homed conferencing through Cisco VCS and Meeting Server with an AVMCU invoked on the Microsoft side, the maximum SIP message size must be set to 32768 bytes (the default) or greater. It's likely that you will need a greater value for larger conferences (that is, from around nine or more participants upwards). Defined via SIP max size on Configuration > Protocols > SIP.

If you try to add more than 65 option keys (licenses), they appear as normal in the Cisco VCS web interface (Maintenance > Option keys). However, only the first 65 keys take effect. Additional keys from 66 onwards appear to be added, but actually the Cisco VCS does not process them. Bug ID CSCvf78728 refers.