VQ Conference Manager 3.12.x

This document provides guidance for :

• VQ Conference Manager VQCM 3.12.1
• Outlook Add-in for Office 2016 or Office 365
• Outlook Plug-in 3.1.34 for Outlook 2013 or above
• iOS App
• Appendix D provides a full list of VQCM documentation

Network Port Usage

VQ Conference Manager only accepts traffic on ports 443 (HTTPS), 80 (HTTP), 22 (SSH) (if SSH is enabled via CM-Admin), 6443 (Kubernetes API) and port 1234 (CM-Admin; see section “Conference Manager Admin (CM-Admin))

HTTP Port 80 is open as a convenience for browsers that default URIs to HTTP. A HTTP request on port 80 is automatically redirected to HTTPS on 443.

The Kubernetes API Port 6443 can only be accessed with a valid service account bearer token (signed JSON Web Token) derived from a certificate generated at system install.

CAUTION: The internet is a very unforgiving place. We do not recommend running VQCM with direct public access from the Internet. Please contact our support team if you have this requirement and we will advise on the possibility of service risk caused by the discovery of new CVEs.

What's new in VQ Conference Manager 3.12.1

VQCM 3.12.1 is a patch release and fixes issues found in the field with 3.12.0. Most are DMA specific but there are several that impact Meeting Services functionality. One in particular places substantial additional load on the processor and would impact large systems.

We recommend all customers running large (or even largish) workloads on versions above 3.9.2 to upgrade to 3.12.1.

Please contact support@vqcomms.com if you are unsure.

Fixed Issues

Please see Fixed issues for the list of bug fixed in 3.12.1.

What's new in VQ Conference Manager 3.12.0

VQCM 3.12 represents a major milestone; it completes the first phase of DMA releases (3.9, 3.10, 3.11 and, finally, 3.12) with the addition of Device Maintenance.

Device Maintenance

Device Maintenance adds:

• Device Status and Activity Monitoring

• Device Health Checks

• Device Onboarding

• Trouble Shooting (interactivity changing settings)

• Security Configuration management (certificates)

• Kibana based visualizations including Mapping

More details on the new DMA functionality added at 3.12 can be found the DMA chapters in this document.

VQ Conference Manager Metro Client

In addition, 3.12 provides the platform infrastructure to allow playbook-based feature upgrades. The first of these will be the VQ Conference Manager Metro client. Metro is a cross-platform user interface designed for end-users. The goal is that it provides a VQ user interface wherever users need one; browser, Windows, Mac and Mobile Web in the first instance. It includes a WebRTC based voice, video and data client that works with CMS.

Metro is being released as a playbook upgrade which means it can evolve more quickly than the 3 releases per year of the Conference Manager platform.

The Metro client will be licensed as part of the Self-Service Applications Pack licensing bundle. Existing Self-Service-Applications-Pack will be entitled to use Metro.

The first version of Metro released with 3.12 will be followed by refinements; these include Metro for Outlook and Metro for Teams.

Metro details can be found in Metro Overview.

Fixed Issues

Please see Fixed issues for the list of bug fixed in 3.12.

Important Notices

1. The Operating System that underpins the 3.x series is called “CentOS” and the formal end of support for CentOS has been announced as June 2024 by the Open Source community who maintain it.

We are announcing that 3.12 will be the last major release on the 3.x platform. All further Conference Manager and DMA development will take place on the 4.x platform. Patch releases of 3.12 (e.g., 3.12.1, 3.12.2) are possible but will only contain critical bug fixes that are fixable (see note below). No new feature work will be performed on 3.12.

We have invested massively in the 4.x platform over the last couple of years and we’re now at the stage where we can release 4.x on a similar cadence to that we achieved with the 3.x series. We expect 4.2 to follow 3.12 within about 4 weeks; 4.2 will contain the same DMA and Conference Manager functionality as 3.12.

We strongly advise customers to start planning to migrate to the 4.x platform sooner than later. There is a real risk that vulnerabilities are found within the CentOS Operating System and because of the end of support and declining activities of the CentOS community, they are not fixed and are not fixable.

Migrating to 4.x will require a new VM; we provide tooling to export and import the data from 3.x into 4.x (3.12 to 4.1). Please see the “Migration policy for VQCM 4.x (US DOD Approved Product List (APL) certified)”.

2. The DMA mapping functionality in 3.12 results in references to external Elastic mapping servers. For environments where that is not appropriate, please contact support@vqcomms.com and they will assist in removing the mapping based visualizations. In a future release, we will include the Elastic mapping data as part of the VQ Virtual Machine.

Recurring Meetings

Recurring Meetings with Pin per meeting instance are still considered experimental. Bugs have been fixed in 3.12 that addressed issues found in the field. We will review customer feedback and based on that, hope that we can remove the ‘Experimental’ designation at 4.3 (the follow-on release to 3.12).

Migration policy for VQCM 4.x (US DOD Approved Product (APL) certifie)

VQCM 4.0 was granted APL status (June 2022) and was released in November 2022.

The first two versions of 4.x (4.0 and 4.1) did not contain DMA.

The 4.x platform will get to DMA parity with 3.12 at 4.2; we expect 4.2 to release about 4 weeks after 3.12.

VQCM 4 requires a new Virtual Machine and is based on RedHat Enterprise Linux 8.4.

The migration process will be to export data from VQCM 3.12 and import it into VQCM 4.x.

Please also be aware that VQCM 4 uses an updated license file format and legacy VQCM licenses will not be valid on VQCM 4.

VQCM 4 includes RedHat Enterprise Linux 8.4 which has required the introduction of some new pricing options. The summary of the pricing changes is that the first node of VQCM 4 will be included as part of the purchase price. Customers with Enterprise Agreements and multiple instances of VQCM will be charged for the second and subsequent VQCM nodes.

When High Availability is released, it will be for a 3-node topology. The first node will be included in the purchase price; nodes 2 and 3 will be charged for. Details of the pricing model can be obtained via sales@vqcomms.com or via your Cisco partner. Cisco pricelists have been updated to reflect these changes. The node licensing model is in addition to the existing VQCM licensing options and covers a VQCM 4 node for the duration of the subscription.

Upgrade issue impacts service experience

Warning:

If your CMS has been configured to support default Profiles at the Tenant level, please read the following carefully:

New Space Template Role settings were added at 3.11. As part of the upgrade process, VQ updates the Default Profile values on CMS Tenants so that any new instance of a Space will pick up the new default values.

The profiles and their default values that VQ writes to each CMS Tenant’s defaults are:

CallProfile

• notesAllowed - false

• captionsAllowed - false

• backgroundblurAllowed - false

• raisehandEnabled - false

CallLegProfile

• chatcontributionAllowed - false

• captioncontributionAllowed – false

• changeroleAllowed – false

Two problems can occur as a result of this change:

1. If a customer already uses CMS Tenant specific default Call and Call leg Profiles, the existing customer settings will be overwritten by VQ.

2. Compounding this problem, VQ overwrites the default Call and Call Leg Profile values on the Tenant; it doesn’t just overwrite the default settings. Any values that were set will be cleared as, for example, VQ writes a default Call Leg Profile with Chat, Caption and ChangeRole set to false.

The problem only happens if VQ Conference Manager created the Tenant on CMS.

These two issues can result in breaking changes to the customer service and calls behaving differently after the upgrade.

There are two possible approaches that can be taken to resolve this problem:

1. One that is simple, works and is quick. The negative is that it will need performing each upgrade.

2. Running the Template Manager utility. This could, potentially, be quite a long running process but has the advantage that once it’s done, future upgrades will not require an action (assuming that no changes are made available features on Call and Call Leg profiles).

For most customers, we recommend option 1. For customers who would like to discuss option 2, please contact support@vqcomms.com. Details on option 1 follow:

To rectify the problem, before upgrading, please take a note of the original Tenant call and call leg profile default values on your system and then restore them once the upgrade to VQ 3.12.0 has been performed.

The bug has been partially fixed at 3.12; any new values set on Space Template Roles need to be checked for clashes but 3.12 no-longer overwrites all values in the CMS profiles on the Tenant.

Use the following CMS API commands to see the existing default profile values on a Tenant:

/api/v1/tenants/<Tenant GUID>

XML View:

<?xml version="1.0"?>
<tenant id="<Tenant GUID>">
  <name>A Tenant</name>
  <callLegProfile>d6a892ee-2746-4fd2-abd8-81e057042c98</callLegProfile>
  <callProfile>f59acdc3-7dd6-4d45-a6fc-4631495536eb</callProfile>
</tenant>

Call Leg Profile (clicking on the GUID link returned by Tenants when logged into the API page on CMS):

Table View:

XML View:

<?xml version="1.0"?>
<callLegProfile id="d6a892ee-2746-4fd2-abd8-81e057042c98">
  <defaultLayout>allEqual</defaultLayout>
  <presentationDisplayMode>singleStream</presentationDisplayMode>
  <joinToneParticipantThreshold>0</joinToneParticipantThreshold>
  <leaveToneParticipantThreshold>0</leaveToneParticipantThreshold>
  <audioPacketSizeMs>0</audioPacketSizeMs>
  <videoMode>auto</videoMode>
  <sipMediaEncryption>optional</sipMediaEncryption>
  <deactivationMode>deactivate</deactivationMode>
  <deactivationModeTime>0</deactivationModeTime>
  <videoMuteOthersAllowed>true</videoMuteOthersAllowed>
  <muteSelfAllowed>true</muteSelfAllowed>
  <videoMuteSelfAllowed>true</videoMuteSelfAllowed>
  <bfcpMode>serverOnly</bfcpMode>
  <setImportanceAllowed>false</setImportanceAllowed>
  <addParticipantAllowed>false</addParticipantAllowed>
  <participantCounter>auto</participantCounter>
  <audioGainMode>disabled</audioGainMode>
  <controlRemoteCameraAllowed>false</controlRemoteCameraAllowed>
  <chatContributionAllowed>false</chatContributionAllowed>
  <changeRoleAllowed>false</changeRoleAllowed>
  <captionContributionAllowed>false</captionContributionAllowed>
</callLegProfile

Call Profile:

Table view:

XML view:

<?xml version="1.0"?>
<callProfile id="f59acdc3-7dd6-4d45-a6fc-4631495536eb">
  <locked>false</locked>
  <lockMode>needsActivation</lockMode>
  <raiseHandEnabled>false</raiseHandEnabled>
  <notesAllowed>false</notesAllowed>
  <captionsAllowed>false</captionsAllowed>
  <backgroundBlurAllowed>false</backgroundBlurAllowed>
</callProfile>

Metro Overview

Metro, or, to give it its full name, VQ Conference Manager Metro was created to solve a couple of principal problems:

1. To provide a video client that works everywhere that CMS is installed.

2. To provide a user interface “fabric” that runs on just about everything (and just about anywhere) that VQ has control over and allows us to deliver highly integrated and easy to use functionality. Ultimately, VQ is about enabling the delivery of video services. Historically, we managed just the CMS infrastructure. Then we added DMA and can manage the video device/appliances. With Metro, we take that one step further and have end-to-end control (or, better said, the ability to control) and to create solutions that integrate the collaboration components in an integrated and easy to use manner.

In its first version, Metro is a client that can be used via a browser, mobile web or a Windows or Mac desktop application. Its cross platform and uses state of the art cross platform software technologies. It means we can consolidate our various first- and second-generation user self-service tooling onto a third generation, single tool and code base enabling more innovation, quicker.

Here are some screenshots of Metro on different hosts:

And then some drilldowns into an active call:

Metro is installed via a “drag-and-drop” playbook via CM-Admin. As you will see from the URIs in the some of the screenshots above, it is then accessed via the Metro URI of your VQ instance (https://your VQ FQDN/metro)

Metro 1.0 is the start. Coming soon are things like Metro for Outlook and Metro for Teams.

US DOD customers should note that Metro was not included in the 4.0 APL package.

Our objective with Metro is that it evolves quickly; we will therefore release playbook-based upgrade packages and, by doing so, enable Metro to be updated more frequently than 3 times a year as is the case with the underlying VQ platform.

Metro is a new feature; we’re making it available initially with the “Experimental” designation. It’s new; we hope you like it but we council cautious adoption at this stage.

For access to the Metro installation Ansible playbook, please contact support@vqcomms.com.

The WebRTC functionality within Metro is provided by a WebRTC SDK developed by VQ. The goal of the SDK is to enable the creation of applications containing WebRTC that interoperate with CMS. If that sounds interesting, please get in touch via support@vqcomms.com.

Licensing requirements for VQ Conference Manager DMA

The DMA functionality is licensed on a per device per month basis. Attractive offers are in place for customer migrating off Cisco TMS. Please contact info@vqcomms.com or your preferred reseller partner for pricing.

DMA licensing isn’t enforced at VQCM 3.12.x. It will be in later versions.

Please remember that a lot of engineering effort has been invested in DMA. Your licensing payments pay for the design and engineering work that makes DMA possible.

CMS 3.4 API compatibility break

CMS 3.4 introduced a breaking change in the CMS API that caused all CMS API Space Create commands issued by VQCM versions earlier than VQCM 3.9 to fail.

IMPORTANT: All VQCM versions earlier than VQCM 3.9 are impacted by the CMS 3.4 API change. All customers planning to use CMS 3.4 will need to upgrade the latest release above VQCM 3.9.

Please see the Upgrade process section for details on the upgrade process Please also see the CMS compatibility for a full list of CMS versions.

Things to be aware of

On a new install, a delay of up to 30 minutes should be expected before the initial network settings page displays as the system generates a 4096 bit private key. The following will be displayed after initial load and before the network settings page is displayed:

VQ Conference Manager System Health Check

The best issues are those that don’t happen. For that reason, we are moving customers to a proactive support model. On our Customer Portal, we’ve added a System Health Check section under Downloads.Here you can download VQ Conference Manager System Health Check, (which replaces the pre-upgrade-check script). The idea is that customers run it regularly (e.g., weekly or monthly) and also before system upgrades. The results are sent to our support team. They’ll check the results and if potential issues are forming, they can be addressed before they start impacting your system.

Please mail support@vqcomms.com who will assist you with this.

Digitally signed install and upgrade images

Each release file (upgrade or archived appliance) comes with an associated OpenSSL digest file or Windows security catalogue file, both of which are created using a code signing certificate provided by DigiCert.

This is being done as part of our continually maturing security requirements and will provide customers and end users with the assurance that the product(s) they are downloading have not been altered.

NOTE: In the examples that follow, 3.6.1 has been used:

Downloading the correct files

As there are now multiple files to download it is worth clarifying the required files to avoid confusion, especially for those new to this process.

The image below shows the new layout of the download page. Under the VQ Conference Manager sections where users would normally find either the VM appliance or upgrade image file there are now two additional files. A .cat (Windows Catalog file) or .signed (A OpenSSL signed digest file). Each file has it’s extension type specified on the download button and the file description will state which OS this is intended for. Only the actual appliance files themselves (the VM or upgrade image) will have a user guide or release note download option, the two signing files will have these greyed out with n/a.

Figure 1: Download Page

If a user is running a Windows machine as their host, so the machine they will either be running the VQ Conference Manager instance from or checking the file integrity on, then they will need both the appliance image and the associated .cat signing file. If they are running Linux or Mac they will need the appliance and the associated .signed file.

It is important to note that these associated files are not required for the appliance to be run or used, only if users wish to ensure the integrity of the appliance file itself. The process for verification is covered in the sections below, please refer to the section which references your host OS for further details.

Linux and Mac

For Linux or Mac you will need the release file and associated digest file. This will follow the naming convention of the release file and end with the .signed extension. For example, for the file CM-3.6.1-appliance-upgrade.img the associated digest will be called CM-3.6.1-appliance-upgrade.img.signed.

You will also require the VQ Communications public key, which is available from the VQ Communications keybase profile (https://keybase.pub/vqcomms/code_signing_public.key). Simply download the public key to the same location as the release file and signed digest.

To verify the digest and release run the following OpenSSL command:

openssl dgst -verify <public_key_file> -keyform PEM -sha256 -signature <signed_digest> -binary <release_file>

So using the files mentioned above as our example the command would be:

openssl dgst -verify code_signing_public.key -keyform PEM -sha256 -signature CM-3.6.1-appliance-upgrade.img.signed -binary CM-3.6.1-appliance-upgrade.img

This should return the message Verified OK. If you receive a Verification Failure message there has been a problem and we would recommend contacting support@vqcomms.com before continuing with your upgrade or installation.

Windows

For Windows you will need the release file and associated catalogue file. This will follow the naming convention of the release file and end with the .cat extension. For example, for the file CM-3.6.1-appliance-upgrade.img the associated catalogue will be called CM-3.6.1-appliance-upgrade.cat.

For Windows verification there is no need to access the VQ public key. Opening the .cat file you will be able to view the signature and the certificate details.

To verify the signature against the release file you will need to run the following Powershell command:

Test-FileCatalog -CatalogFilePath <catalogue_file> -Path <release_file>

If we use the above example files the command would be:

Test-FileCatalog -CatalogFilePath CM-3.6.1-appliance-upgrade.cat -Path CM-3.6.1-appliance-upgrade.img

This should return Valid. If you receive a ValidationFailure message there has been a problem and we would recommend contacting support@vqcomms.com before continuing with your upgrade or installation.

If you are running PowerShell 5.0 or earlier than the Test-FileCatalog cmdlet will not be included as default in your Microsoft.PowerShell.Security module and you will need to update your PowerShell build to 5.1 or later.

Multi node operation

Multi-node operation at VQCM 3.x is not supported.

Multi-node operation and High Availability (“HA”) will be introduced after the initial release of VQCM 4.x.

CMS compatibility

CMS Version	VQCM Compatability	VQCM Incompatability
3.8	VQCM 3.9 and above	All VQCM versions before VQCM 3.9
3.7	VQCM 3.9 and above	All VQCM versions before VQCM 3.9
3.6	VQCM 3.9 and above	All VQCM versions before VQCM 3.9
3.5	VQCM 3.9 and above	All VQCM versions before VQCM 3.9
3.4	VQCM 3.9 and above	All VQCM versions before VQCM 3.9
3.3	All versions from 3.3.0	-
3.2	All versions from 3.2.0	-
3.1	All versions from 3.1.0	-
3.0	All versions from 3.0.0	-

If you try to connect to an incompatible version of CMS, the CMS node will not come online and you will see an error of "UnsupportedSoftwareVersion".

Browser Support

VQ Conference Manager's User Interface is browser based; it uses latest web technologies to ensure it is fast and

responsive.

Evergreen browsers are recommended. We test and support the current stable release and 2 previous stable versions of Chrome, Firefox, Safari and Microsoft Edge. Internet Explorer 11 is supported but not recommended.

Kibana 7.10 does not support Microsoft IE 11.

Outlook OWA does not work with Safari on Mac. Use Chrome/Firefox

Outlook Plug-in 3.1.34

The changes in 3.1.34 covered improvements in how the plug-in interacts with the Identity Server during the authentication process.

If the plug-in is in idServerAuth mode, the plugin automatically opens a web browser (default browser) and there were some issue reported about the default browser not being able to launch. We added re-try steps to handle this condition.

This is the sequence the 3.1.34 plug-in uses:

• URI Opens in default browser

• if that fails try to open the URI in IE browser

• if that also fails we try to open the URI in browser with using shell to start the process (UseShellExecute = true)

Version 3.1.33 was not released. It was a build used for internal testing.

Version 3.1.34 can be controlled by a server-side manifest file to automatically upgrade if newer Outlook plug-in versions become available. Please read “Outlook Plug-in Automated Upgrades”.

Standards based Authentication (OAuth2, OIDC and SAML2)

The authentication model changed at 3.1 and is now based on an Open Id Connect (“OIDC”) certified Identity Server that is now part of the standard VQCM product.

OIDC is an additional layer that “wraps” the OAuth2 model and makes it more appropriate (and secure) for use with modern web-architecture applications and services.

The onboard “Identity Server” is responsible for handling the question of whether a user is authenticated or not. It works with “Identity Providers” that are responsible for the authentication process. The supported Identity Providers that VQCM will work with are Active Directory/LDAP, Windows Authentication (Single Sign-On) and four variants of SAML 2: Okta, OneLogin, Duo and Microsoft ADFS (Active Directory Federated Services).

For details on configuring Okta, Duo and OneLogin SAML2, please see section “Configuring VQ-Admin to work with Okta, Duo and OneLogin SAML2” and for ADFS, please see section “”.

All of the VQCM API work with the OIDC authentication flows. The API clients are all the things that use the VQCM API namely: the web-based user interface, the Outlook Add-in, Outlook plug-in, iOS app, Kibana and utilities such as Template Manager etc.

The default authentication mode is Active Directory/LDAP as the Identity Provider. However, the system can also authenticate against SAML 2 providers (Okta, OneLogin, Duo and Microsoft ADFS have been tested so far) and Windows Authentication.

With the introduction of Microsoft ADFS support from VQCM 3.3, the recommended path to enable Single Sign-On using Windows Authentication is to take the Microsoft ADFS route.

Microsoft ADFS is simpler to configure, requires less firewall port configuration and does not require software on an additional server.

VQCM Authentication and Expressway MRA

VQCM Authentication does not work with Expressway MRA (“Mobile and Remote Access”).

Expressway MRA does not pass all HTTPS headers transparently over the network boundary. OIDC authentication headers are included in the list of headers not passed through the boundary by Expressway MRA.

Enabling API Service Clients (Outlook Add-in/Plug-in and iOS)

By default, the Web based User Interface and access to Kibana are enabled.

The VQCM-Admin portal controls whether API clients such as the Outlook Add-in, Outlook Plug-in and iOS App are enabled.

The default mode for the Outlook Add-in, Outlook Plug-in and iOS App is disabled.

They must be explicitly enabled; this is performed from the VQCM-Admin Authenticate Clients page:

If you are running utility applications (such as TemplateManager, ImportEmailer or BulkEmailer), add new ClientID and Secret values which can then be entered into the config files for the utilities. Each utility can have their own API key or they can be shared; from a control point of view, each having their own is our recommendation.

If you do not enable the specific application (API Consumer), authentication requests from the application will fail with an error message "Unexpected authentication error" along with some explanatory text and an error instance number.

Fully Qualified Domain Names and Certificates

VQCM only works with FQDNs.

The OIDC authentication process and trust model is based on certificates; IP addresses are out and FQDNs are in.

VQCM will work with self-signed, non-trusted certificates and will detect and prompt for non-standard actions when they are used. We recommend, however, using trusted certificates; there is a growing trend by suppliers to only work with trusted certificates. A good example of this can be seen with the latest Chrome browsers. You can work with untrusted certificates but it will become increasingly difficult. It is also less secure.

DNS A-records will need creating before VQCM is installed; the install process prompts for them so please have them ready before you start installing.

If you enter FQDNs without having setup DNS A-Records, the install process will detect that no IP address has been defined on the A-Record but it does not check that the A-Record points to the IP address of the VM. If you have not setup the A-record or you set an incorrect IP address in the A-Record, this will result in Pods not being able to start and CM-Admin will show red Pod errors. You will need to restart the install process.

Three FQDNs are required:

FQDN	Description
vqcm.mydomain.com	User friendly URI for VQCM
login.vqcm.mydomain.com	Allows API clients to find the VQCM OIDC Identity Server
kibana.vqcm.mydomain.com	Admin friendly URI to access Kibana

The IP address associated with each FQDN should be the same.

NOTE: “login” and “kibana” are examples. You can use any value that are meaningful in your environment. For example, if a wild card certificate is being used, Subject Alternative Names (SANs) can be used

FQDN	Description
vqcm.mydomain.com	User friendly URI for VQCM
loginvqcm.mydomain.com	Allows API clients to find the VQCM OIDC Identity Server
kibanavqcm.mydomain.com	Admin friendly URI to access Kibana

In addition to the 3 mandatory certificates required, VQ also, by default, generates a self-signed signing certificate, that is used to sign authentication tokens. In most customer environments the self-signed authentication signing certificate is all that is required. However, customers who want to upload a CA signed signing certificate can do so via the VQCM-Admin Certificates page.

CMS works with Fully Qualified Domain Names or IP addresses

VQCM connects to CMS nodes via IP address or FQDN and will accept trusted or self-signed, non-trusted, certificates.

If your CMS nodes use FQDNs, please ensure you have DNS A-records defined for each node. We do see the occasional support ticket where customers have issues connecting their CMS nodes with VQCM and the issue is that no DNS A-records have been defined for the CMS nodes.

The other problem that can cause issues is that the CMS nodes have not been configured with a DNS server. This causes problems because it means that CMS cannot resolve the address of VQCM when posting CDR records to VQCM.

Background: when a new Call Bridge node is added to VQCM, VQCM writes the FQDN address of its CDR Listener to the CMS node. The CDR events posted by CMS to VQCM pass state change information between the two systems; without them, VQCM does not know about call starts or participant joins/leaves with the result that nothing is displayed in the Activity page.

This version fixes the following issue:

On systems with high volumes of very short calls, receiving two Call Leg Responses concurrently from CMS without a Call Leg GUID resulted in VQ marking the CMS node offline.

Please read the “Upgrade Paths" section in the Upgrade process chapter and be aware that the only upgrade path for 3.3.2 is from 3.3.1.

iOS App and Certificates

The iOS App requires trusted certificates.

Installing a self-signed root CA certificate onto an iPhone for testing

The iOS operating system will not allow connections to non-trusted sites. For testing or for customers with their own certificates that are not based on root certificates already in the phone’s certificate store, you will need to install a root certificate onto your phone.

To establish trust for self-signed server certificate, you must install the root Certificate Authority (CA) certificate onto your iPhone. Please note that only the root CA certificate must be installed, other certificates such as intermediaries do not need to be installed onto the device.

• Download the certificate
• Once the certificate is on the device, navigate to Settings > Profile Downloaded
• Install the certificate, accepting the warning that will appear
• To check that the certificate was properly installed, navigate to Settings>General>Profiles>Configuration Profiles, where the root CA will appear
• Manually installed certificates are not automatically trusted by iOS. Navigate to Settings>General>About>Certificate Trust Settings and under “Enable full trust for root certificates,” turn on trust for the certificate.

Apple documentation on the last step, here: https://support.apple.com/en-us/HT204477_

Note: These notes are for guidance only. VQ is unable to provide support on this process; please contact your Apple supplier/support if you require assistance.

VQ Conference Manager 3.x resiliency

VQCM 3 is a cluster of Pods; the cluster is managed, or orchestrated, by Kubernetes.

Each Pod contains specific functionality; for example, the Web Server (VQCM Portal), the database (PostgreSQL), the main VQCM 3.0 service, the message bus etc.

At VQCM 3, the cluster will consist of one VM. If any of the Pods fail, Kubernetes will recreate it. However, there is no resilience of certain key functionality such as the database or Master node.

If the Master node or database fails, the system will fail.

Future versions of VQCM (VQCM 4.x) will support High Availability and be configurable as a multi-node cluster.

Outlook Plug-in functionality

The Outlook Plug-in has been upgraded to include the following new functionality:

• inject details for a Space into a meeting

• schedule a meeting on a Space

• schedule a one-time meeting on a Space

• for multi-role Spaces, the role can also be selected

• configuration options for label names and functionality subsets

It will be possible to upgrade from the current 3.1.34 version of the plug-in to the newer version using the remote upgrade process.

Outlook Add-in functionality

The Outlook Add-in requires Office 2016 or Office 365. It works on the Windows and macOS platforms.

Outlook Add-in screenshot showing active Spaces:

For information on how to install the Outlook Add-in, please refer to Outlook Add-in.

Additional Documentation

We continually add to our list of additional documentation. Please see Appendix D for the full list.

User Portal enhancements

• Full set of documentation is now available online and searchable
• Micro-search feature for frequently searched material

Available from the vqcomms.com