Patch Release 14.6.1

14.6.1

QA PASSED

2026-04-15

This patch introduces enhancements to VRS for the Cisco deployment profile. The dependency on CX multi tenancy variables has been removed when using Cisco as the deployment profile. A dedicated authentication application container is now included in the VRS Cisco setup (non-HA), eliminating reliance on EFCX authentication application. Additionally, compatibility with Cisco CUCM and UCCX 15.0 has been added, along with support for Extension Mobility using hard phones.

Upgrade Guide VRS14.6 to VRS14.6.1

Issue: The record.lua script was not properly handling SIP events when a display name was included in the SIP INVITE, which resulted in interruptions in call recording processing.

Resolution: The issue has been resolved. The updated record.lua script now correctly processes SIP events containing a display name, ensuring that recordings are handled smoothly without interruption.

Issue: The VRS login functionality was impacted due to changes in the EFCX profile APIs, which caused login failures for users.

Resolution: The issue has been resolved, and VRS login is now working correctly after adapting to the updated EFCX profile APIs.

Issue: Previously, VRS Cisco deployments depended on the external EFCX authentication application for handling authentication services. This created an additional dependency and reduced deployment flexibility and service isolation.

Resolution: A dedicated authentication application container has been introduced within VRS for Cisco deployments. This removes the dependency on the EFCX authentication service, allowing VRS to handle authentication independently while improving deployment simplicity and service isolation.

The authentication application container included in the Cisco deployment profile is currently supported only for non-HA deployments. Support for HA deployments will be introduced in future releases after completing HA validation and testing.

• In the outbound queue consult scenario, two additional call legs (A1A2) are displayed along with their audio.

• In consult (extension/queue) conference scenarios where A2 leaves the conference, three call legs for A1A2 are displayed with the same audio, whereas typically an A1A2 conversation should produce only two legs.

• In consult (extension/queue) conference scenarios where C1 leaves the conference, A1A2 may result in three call legs instead of the expected two.

When a call is initiated on a fresh database or after a database restart, the JTAPI Connector may encounter issues connecting with the application user on CUCM, leading to problems in call correlation.