Configuring existing Conferencing Nodes

To reconfigure or delete an existing Conferencing Node, go to Platform > Conferencing Nodes and click on the name of the Conferencing Node.

Any changes to the configuration of the Conferencing Node should be made using the Pexip Infinity Administrator interface. Do not make any changes using other tools (such as VMware or Hyper-V); doing so may cause the Conferencing Node to fail. The only exception is any change to the CPU and RAM allocated to the Conferencing Node — these changes should be made using the hypervisor and should only be done while the Conferencing Node is powered off.

When reconfiguring existing Conferencing Nodes, the following information can be changed:

Option Description
Name The name used to refer to this Conferencing Node in the Pexip Infinity Administrator interface. Each Conferencing Node must have a unique name.
Description An optional field where you can provide more information about the Conferencing Node.
Role

This determines the Conferencing Node's role:

  • Proxying Edge Node: a Proxying Edge Node handles all media and signaling connections with an endpoint or external device, but does not host any conferences — instead it forwards the media on to a Transcoding Conferencing Node for processing.
  • Transcoding Conferencing Node: a Transcoding Conferencing Node handles all the media processing, protocol interworking, mixing and so on that is required in hosting Pexip Infinity calls and conferences. When combined with Proxying Edge Nodes, a transcoding node typically only processes the media forwarded on to it by those proxying nodes and has no direct connection with endpoints or external devices. However, a transcoding node can still receive and process the signaling and media directly from an endpoint or external device if required.

See Distributed Proxying Edge Nodes for more information.

If you change the role of a Conferencing Node, all existing calls will be disconnected and the Conferencing Node will be restarted.

System location

The physical location of this Conferencing Node. A system location should not contain a mixture of proxying nodes and transcoding nodes.

If you change the system location of a Conferencing Node, all existing calls will be disconnected and the Conferencing Node will be restarted.

Enable maintenance mode

While maintenance mode is enabled, this Conferencing Node will not accept any new conference instances. For more information, see Taking a Conferencing Node out of service.

The maintenance mode setting will persist after a reboot.

Configured FQDN A unique identity for this Conferencing Node, used in signaling SIP TLS Contact addresses. For more information, see Assigning a Configured FQDN.
TLS certificate The TLS certificate to use on this node. This must be a certificate that contains the above Configured FQDN. Each certificate is shown in the format <subject name> (<issuer>).
IPv6 address The IPv6 address for this Conferencing Node. Each Conferencing Node must have a unique IPv6 address.
Gateway IPv6 address

The IPv6 address of the default gateway.

If this is left blank, the Conferencing Node listens for IPv6 Router Advertisements to obtain a gateway address.

IPv4 static NAT address The public IPv4 address used by this Conferencing Node when it is located behind a NAT device.
Static routes From the list of Available Static routes, select the routes to assign to the node, and then use the right arrow to move the selected routes into the Chosen Static routes list. For more information, see Managing static routes.
Enable SSH

Determines whether this node can be accessed over SSH.

Use Global SSH setting: SSH access to this node is determined by the global Enable SSH setting (Platform > Global settings > Connectivity > Enable SSH).

Off: this node cannot be accessed over SSH, regardless of the global Enable SSH setting.

On: this node can be accessed over SSH, regardless of the global Enable SSH setting.

Default: Use Global SSH setting.

SSH authorized keys

You can optionally assign one or more SSH authorized keys to use for SSH access.

From the list of Available SSH authorized keys, select the keys to assign to the node, and then use the right arrow to move the selected keys into the Chosen SSH authorized keys list.

Note that in cloud environments, this list does not include any of the SSH keys configured within that cloud service.

For more information, see Configuring SSH authorized keys.

Use SSH authorized keys from cloud service

When a node is deployed in a cloud environment, you can continue to use the SSH keys configured within the cloud service where available, in addition to any of your own assigned keys (as configured in the field above). If you disable this option you can only use your own assigned keys.

Default: enabled.

You can also change the node's SNMP settings (see Monitoring via SNMP for more information):

Option Description
SNMP mode

Configures the SNMP access mode for the selected node:

Off: SNMP is disabled. You cannot use SNMP to query the node for its status.

SNMPv2c read-only: enables insecure, read-only access.

SNMPv3 read-only: enables secure, read-only access, using the authPriv security level with SHA1 authentication and AES 128-bit encryption.

When enabled, access is provided to the basic RFC 1213 MIB-II tree (1.3.6.1.2.1).

Default: Off.

SNMP community

The SNMP group to which this node belongs. This setting applies to SNMPv2c only.

Default: public

SNMPv3 username The node's SNMPv3 username, used to authenticate SNMPv3 requests.
SNMPv3 privacy password

The node's SNMPv3 privacy password used for encrypting messages between the node and the management station.

AES encryption must be used; DES is not supported.

SNMPv3 authentication password

The node's SNMPv3 authentication password, used to authenticate the associated username.

The SHA authentication protocol must be used; MD5 is not supported.

SNMP system contact The contact details (for example, email address) of the person responsible for this particular node.
SNMP system location A description of the node's location.

Other details of the Conferencing Node that cannot be directly changed (however, see Changing the node's IP address below) are also shown on this page for your information, as follows:

Option Description
IPv4 address The IPv4 address of this Conferencing Node.
Network mask The IP network mask for this Conferencing Node.
Gateway IPv4 address The IPv4 address of the default gateway.
Secondary interface IPv4 address and network mask

The optional secondary interface IPv4 address and network mask for this Conferencing Node.

These fields are only displayed if the Conferencing Node has been deployed with dual network interfaces.

Hostname

Domain

The DNS hostname and domain of this Conferencing Node. Together these make up the machine's FQDN, or DNS Name in VMware.

For more information, see Assigning hostnames and FQDNs.

Enable distributed database

This should usually be enabled (checked) for all Conferencing Nodes that are expected to be "always on", and disabled (unchecked) for nodes that are expected to only be powered on some of the time (e.g. cloud bursting nodes that are likely to only be operational during peak times).

You should avoid frequent toggling of this setting. When changing this setting on multiple Conferencing Nodes, update one node at a time, waiting a few minutes before updating the next node.

Assigning a Configured FQDN

If your deployment includes Microsoft Skype for Business / Lync, you must assign each Conferencing Node with a Configured FQDN. However, for security purposes we recommend that all deployments use Configured FQDNs.

In summary, the node's Configured FQDN is used:

  • in SIP signaling (if configured)
  • MS-SIP signaling (mandatory)
  • for any self-referential redirects in web requests.

To define the Configured FQDN, go to Platform > Conferencing Nodes and select each Conferencing Node in turn.

The name in the Configured FQDN field is used in SIP signaling over TLS, and specifies the identity that the Conferencing Node service will use when identifying itself to the systems connecting to it. Each Conferencing Node must have a unique Configured FQDN.

The Configured FQDN:

  • must match one of the identities returned in the certificate for the Conferencing Node, and
  • must have an entry in DNS

so that the identity of the Conferencing Node can be verified by the systems connecting to it.

The Configured FQDN can be the same as the Conferencing Node's FQDN (made up of its Hostname and Domain).

If the Configured FQDN field is left blank, the IP address of the Conferencing Node is used in SIP TLS signaling, and, depending on your call control configuration, this may result in calls failing.

For more details on the use of domain certificates in SIP, see section 4 of RFC 5922.

Changing the node's IP address

You can change the IPv4 address of a Conferencing Node by adding a new node with the new address, and deleting the node with the old address.

If you want to preserve the Conferencing Node's existing FQDN, you should:

  1. Put the Conferencing Node whose IP address you want to change into maintenance mode.
  2. When all calls on that Conferencing Node have terminated, delete the Conferencing Node.
  3. Wait at least 90 seconds to allow the deletion to be synchronized across the platform.
  4. Add a new Conferencing Node with the new IP address (but using the same Name, Hostname and Domain etc. as used before, if required).
  5. If necessary, make any changes to your call control system so that calls are routed to the Conferencing Node's new IP address.

If you want to maintain full service capacity, and do not need to preserve the node's FQDN, then you can add the new node with the new IP address before deleting the old node with the old IP address.

Do not attempt to change the IP address of a Conferencing Node using utilities available in external tools (such as VMware or Hyper-V) because this will cause Pexip Infinity services to fail.