Call Bridges

Make sure that your Call Bridge and the Web Admin Interface is up and running.

Clustered Mode

If your Call Bridges are working in a Clustered mode, please ensure that when entering the name of each Call Bridge into VQ Conference Manager on the Call Bridge details page, you provide the Call Bridge Name exactly as defined on the Call Bridge. A mismatch in names, including case, will result in VQCM 3.x being unable to identify activity on the misspelled Call Bridges.

Multi node operation

Although VQCM 3.x is multi node capable, we do not recommend users configure their system in this mode. There are several reasons:

  • At VQCM 3.x, there is very little benefit
  • Communication between the nodes is not encrypted

VQCM 4.0 will be the first version supporting beneficial and secure multi node operation.

If your Call Bridge LDAP information was set through the Web Admin Interface

VQ Conference Manager gets all information through the Call Bridge API. If you have set up your Call Bridge's LDAP configuration through the Web Admin Interface, VQ Conference Manager cannot access the LDAP configuration because the Call Bridge does not make the information available via the API.

You need to remove the information from the Web Admin Interface and configure it through the API.

  1. Backup your Call Bridge. See "
  2. Copy the LDAP Configuration Settings from the Call Bridge into VQ Conference Manager
  3. Click “Done” on the LDAP Configuration Settings page within the Default Tenant; this writes the LDAP Configuration Settings to the Call Bridge via the Call Bridge API
  4. Delete the LDAP Configuration Settings from the Cisco Call BridgeWeb Admin Interface

Tenanting

Tenanting is a feature on Call Bridges that allows users and Spaces to be grouped and each group kept separate from one another. The default state of a Call Bridge is to have no Tenants.

If you want to run your Call Bridge in a non-Tenanted (or "flat") mode, use the LDAP Configuration coApp, from System>Default Tenant. The VQ Conference Manager default Tenant maps to the non-Tenanted (flat) mode on the Call Bridge.

If you want to run your Call Bridge in Tenanted mode, define Tenants within VQ Conference Manager and define the LDAP Configuration per Tenant. This results in Users and Spaces being created on the Call Bridge with the Tenant's own, unique identifier.

Note: Do not mix the two modes on a single Call Bridge. If you think you might need to use Tenanting on your Call Bridge at some point in the future, use Tenants within VQ Conference Manager from the very start.

Adding a new Call Bridge to VQCM

When adding a new Call Bridge to VQCM, take note of 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 send 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 MCUs are configured within VQCM to have the “nearest” (or lowest network latency) MCUs set to the lowest Cluster Priority.

CMS things to check

There are several key things that need to be working correctly.

VQCM needs to receive the state change events from each CMS. These are events like “Call Started” or “Participant joined call”. If these events are not received by VQCM, no calls will appear in the Activity page and no historical data will be produced.

It is therefore critical that VQCM and CMS are talking to one another correctly; VQCM sending commands to CMS and CMS sends state changes back to VQCM via the CDR POST mechanism.

VQCM 3.x configures the CMS CDR settings with the objective of reducing the likelihood of an error being introduced (incorrect VQCM address or Port or forgetting it completely). It still leaves the possibility, however, that a firewall is blocking the HTTPS POST messages from CMS to VQCM.

Please check that no firewalls are blocking traffic between your CMS node[s] and CMS on port 443 (HTTPS).

When VQCM configures the CMS CDR settings, it writes a FQDN value. If there is no DNS server configured on the CMS node, the CMS server will not be able to resolve the FQDN address.

Please check your CMS has a DNS configured.

In a clustered CMS deployment, the node names in VQCM need to match exactly (case sensitive) the node names as configured in CMS [Note: we plan to auto-detect the cluster node names in a future release and remove this potential for a mis-configuration].

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 incall again).

When VQCM connects to a CMS node, it performs a long list of actions to discover the state of the node; one of the actions is to check that the CMS node has the same time as VQCM. If the clocks are out by more than 60 seconds, VQCM will reject the connect attempt and display the MCU in an offline state with an error state of “CallBridgeClockOutofSyncWithAM”. This may feel painful but it highlights any clock synchronization differences and prevents subtle and more difficult to track down issues caused by state change events from CMS being discarded because of NTP time differences between VQCM and CMS.

If you attempt to connect to a CMS node and see the “CallBridgeClockOutofSyncWithAM”, please check that both VQCM and the ESXi VM Host that hosts CMS are configured to use the same NTP server.

Please also note that we have experienced cases where CMS showed the correct time on its MMP interface but the time stamps included in state change events (CDR events) was different; VQCM checks against the time stamp in CDR events. Rebooting CMS normally fixes the problem.

The cdrTime value used by CMS for CDRS can be seen from the following URI on your CMS cluster:

http://<Your CMS URI>/api/v1/system/status

Result:

<status>

<hostId>006d2db4-3748-4692-aa10-f2969698a05a</hostId>

<softwareVersion>2.4</softwareVersion>

<uptimeSeconds>178598</uptimeSeconds>

 

<cdrTime>2018-10-20T12:14:01Z</cdrTime>

 

<activated>true</activated>

<clusterEnabled>false</clusterEnabled>

<cdrCorrelatorIndex>24</cdrCorrelatorIndex>

<callLegsActive>0</callLegsActive>

<callLegsMaxActive>1</callLegsMaxActive>

<callLegsCompleted>4</callLegsCompleted>

<audioBitRateOutgoing>0</audioBitRateOutgoing>

<audioBitRateIncoming>0</audioBitRateIncoming>

<videoBitRateOutgoing>0</videoBitRateOutgoing>

<videoBitRateIncoming>0</videoBitRateIncoming>

</status>

ClusterTest script

We’ve produced a bash-script called “clustertest” that allows commissioning engineers to check that each CMS node is correctly configured and place calls on a node-by-node basis to check that VQCM correctly sees state changes (confirms the firewall is OK) and that mute/disconnect commands can correctly be performed.

Please run the tool (contact support@vqcomms.com), follow its instructions and confirm that Activity sees state changes from each node and that mutes/disconnects work correctly. Longer term, the tool will become integrated into the Conference Manager Administration interface.

This is the only test you need to make to ensure VQCM is correctly functioning with CMS. Once this test has been performed, your testing should be to confirm that the functionality you require is configured on your Space Templates and Participant Roles