VQ Conference Manager commissioning checklist

Introduction

This commissioning checklist document has been created to help with the verification of a correct and optimal configuration of the VQ Conference Manager solution (which will be referred as VQCM in this document).

Please note that the points shared below are some of the most common elements that can easily be overlooked, potentially leading to errors or problems as part of bringing the system to a live and use-able state.

Please note that all points mentioned below relate to the implementation of VQCM release 4.x.

As of the 30th of June 2024, VQCM 3.x will no longer be supported. We strongly encourage any customer who is still using 3.x to get in touch with our support team so we can assist with the migration to the 4.x platform.

CMS Node unique name

In a clustered CMS deployment, each cluster node has a unique name. This unique cluster node name forms part of the information that we use in VQCM to configure the CMS connection. It is essential that these unique names in VQCM match the unique node names exactly, including case sensitivity. (Note: we plan to auto-detect the cluster node names in a future release and remove this potential for a misconfiguration).

Symptoms of an incorrect node name include mutes or disconnects not working. For example, a user attempts to disconnect a participant via VQCM, the participant goes to a disconnecting state, nothing happens at the device end and seconds later, VQCM shows the participant as in call again.

Configuring your CMS Command Node

When adding a new Call Bridge to VQCM, please note the 'Cluster Priority' setting. This tells VQCM which is the 'best' CMS node to send commands to. 'Better' nodes have lower numbers; the best has the lowest number.

Cluster Priority is used to ensure that VQCM sends API commands to the nearest, or best, available, online, CMS.

As an example, if your VQCM is hosted in New York and there are CMS nodes in New York and Tokyo, the round-trip delay sending an API command to Tokyo is substantially longer than sending it to New York.

The throughput of API commands to the CMS node(s) is directly proportional to how quickly things happen on the user interface (for example, muting a participant).

Make sure, therefore, that your CMS nodes are configured within VQCM to have the 'nearest' (or lowest network latency) CMS node set to the lowest Cluster Priority.

System configuration for Self-Service and Scheduling modes

Self-Service mode

This mode describes the usage model where users dial into their Spaces and VQCM is working in a reactive mode. As the Participants dial into the Space, a call on the Space is dynamically created by CMS and VQCM detects the new Call coming into existence via events posted by CMS to VQCM.

This is the mode that allows the greatest call volumes; customers have systems deployed hosting over a million call participants per month (1.1 and 1.3 million; 50k/70k call participants per day respectively).

On systems hosting large numbers of calls per month in Self-Service mode, we advise changing the ‘CallAgeing’ setting in the System Configuration database to a value of 1 (one) from its default of 40.

Please see 'VQCM Configuration Options' document available from our Customer Portal - vqcomms.com/login)

The 'CallAgeing' setting controls when Calls are deleted once the call has completed. Setting the value to one results in completed calls being deleted 24 hours after completion rather than 40 days later. On large systems, substantial numbers of Calls are generated which results in two things:

  • Over 40 days, the system becomes slower and less responsive because it can have tens of thousands of Calls that it is repeatedly needing to scan and loop through

  • If the system restarts, it can take the system minutes to initialize on account of the large number of calls. This can result in 504 Errors being displayed on the User Interface because the Core VQ service is unresponsive (it’s still initializing)

Scheduled Call mode

This mode describes the usage model where Meetings are scheduled via the 'Meetings List' or the 'Schedule New Meeting' coApp.

Systems in this usage mode will typically be limited to less than 400 meetings per day.

In Scheduled Call mode, you might want to consider enabling 'Call Ending' messaging where VQCM will display 'The call is about to end' messages into the video stream of each video participant when the call reaches 10 minutes before its scheduled completion time. The Message repeats at 5 minutes and then every minute to call end time. The message content and intervals can be configured.

Please see the 'VQCM Configuration Options' document available from our Customer Portal - vqcomms.com/login.

Default Call Duration for non-scheduled calls starting on Spaces

Service impact : High - Please note that incorrect configuration of the settings below, can lead to calls dropping in an unexpected manner.

Changing the maximum call length of calls initiated on Spaces (inbound first participant)

When the first Participant joins a call (dials into a Space) on an idle Space, a new call is instantiated on CMS and within VQCM. The default length of the new call created within VQCM is 12 hours. For most customers, this maximum limit works but for some it does not. When the call reaches its duration limit, VQCM shuts the call down, terminating the call on CMS.

The maximum call length can be increased via the 'InboundAdHocCallLength' setting. The setting defines the maximum call length (in hours) that will be used. For those who do not want the calls to end please enter the value of 876 000 in the database settings under the CM-Admin interface.

NOTE: the 'InboundAdHocCallLength' setting is in hours as opposed to the

'DefaultDurationMinutes setting' (described below) which is in minutes.

Please see the 'VQCM Configuration Options' document (Section 2.9) available from our Customer Portal - vqcomms.com/login.

Changing the maximum call length of calls initiated on Spaces (outbound first participant)

If the Call coApp is used to make an outbound call to a Participant from an Idle Space, a new call is instantiated on CMS and within VQ. The default length of the new call created within VQCM is 120 minutes (two hours). For most customers, this maximum limit works but for some it does not. When the call reaches its duration limit, VQCM shuts the call down.

NOTE: the 'DefaultDurationMinutes' setting is in minutes as opposed to the

'InboundAdHocCallLength' setting (described above) which is in hours.

Please see the 'VQCM Configuration Options' document (Section 2.8) available from our Customer Portal - vqcomms.com/login.

Prevent deletion of Spaces when the owner is removed from the organization

Service impact : High - Please note that by not enabling the functionality, described below, against Space(s) created by a user, these meeting Space(s) will be deleted upon this user leaving the organization, if they are associated to Active Directory / LDAP.

With the introduction of VQCM 4.3, the concept of a 'shared' Space was introduced which prevents the automatic deletion of shared Spaces (i.e., those not assigned as personal Spaces) by enabling the tagging of such Spaces as 'shared.' This is a major enhancement available through VQCM. Previously, for example, when an operator created Spaces on behalf of users and subsequently that operator left the organization, all the associated Spaces which had been created were deleted, causing severe disruption to the service. This new functionality, available as of release 4.3, prevents this issue happening.

Shared Spaces are not deleted if the owning user is deleted from Active Directory/LDAP. 'Shared Spaces' can be enabled at the User Experience Profile (UX Profile) under 'Settings coApp'; enable 'Shared Space'. From the Space details view, the Space can be marked 'Shared' and will not be deleted during an LDAP import process when the owning user has been deleted. The owner is assigned to a Space Member, Local User or System Admin.

Blast Dial/Reactive Call additional configuration option

If you have a requirement to make use of Blast Dialing capability, also known as Reactive Call, please note two further settings can be configured. Please see the 'VQCM Configuration Options' document available from our Customer Portal - vqcomms.com/login.

  • Setting the delay before Reactive/Blast Dial Calls are started - The delay in seconds is configurable in the 'Database Settings' section of the CM-Admin interface.

  • Enabling Audio Confirmation Prompt for Reactive Calls/Blast Dial - With Audio Confirmation enabled, CMS will play two messages to the called Participant. The two messages are:

    • l call_outgoing_welcome.wav

    • l cospace_join_confirmation.wav

The Participant will be prompted to 'press 1' to join the call. If they press 1, they’ll join the call and if they do not, they’ll be disconnected.

Health Check

Important : We strongly recommend checking VQCM Health check status health on a regular basis, such as weekly, to help in identifying potential issues before they escalate into larger problems.

Please check the health status of VQCM following:

  • a first-time installation of VQCM

  • prior to conducting a release upgrade

or

  • after completion of an upgrade

Health check of the functionality of the system can be accessed through the VQCM admin page.

CM-Admin is accessed via HTTPS on port 1234 for your VQCM’s FQDN

If any diagnostic information of any of the Kubernetes pod are showing as red - please take a screenshot of the page and open a support ticket, by emailing VQ Support Team at support@vqcomms.com and attach the screenshot to your mail.

Taking a snapshot of the Virtual Machine and of Cisco CMS

Taking a snapshot of the VQCM’s virtual Machine and backing up the CMS nodes on a regular basis is important.

When performing a snapshot / backup, please ensure that both the virtual machine on which VQCM is installed and CMS are backed up at the same time. A considerable amount of state information is shared between the two systems; backing up at different times can result in equally substantial differences between the two backup data sets rendering them, essentially, useless.

If you need to restore the snapshot and if you experience any issues, please contact VQ Support at support@vqcomms.com