Configuring existing Conferencing Nodes
To reconfigure or delete an existing Conferencing Node, go to 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:
|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.|
This determines the Conferencing Node's role:
If you change the role of a Conferencing Node, all existing calls will be disconnected and the Conferencing Node will be restarted.
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.
|SIP TLS FQDN||A unique identity for this Conferencing Node, used in signaling SIP TLS Contact addresses. For more information, see SIP TLS FQDN.|
|TLS certificate||The TLS certificate to use on this node. This must be a certificate that contains the above SIP TLS 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.|
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 ( ).
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.
You can also change the node's SNMP settings (see Monitoring via SNMP for more information):
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 (18.104.22.168.2.1).
The SNMP group to which this node belongs. This setting applies to SNMPv2c only.
|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:
|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.
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.
If your deployment includes Microsoft Skype for Business / Lync, you must configure each Conferencing Node with a SIP TLS FQDN. However, for security purposes we recommend that all deployments use SIP TLS FQDNs.
In summary, the node's SIP TLS FQDN is used:
- in SIP signaling (if configured)
- MS-SIP signaling (mandatory)
- for any self-referential redirects in web requests.
To configure the SIP TLS FQDN, go to and select each Conferencing Node in turn.
The FQDN in the SIP TLS 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 SIP TLS FQDN.
The SIP TLS 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 SIP TLS FQDN can be the same as the Conferencing Node's FQDN (made up of its Hostname and Domain).
If the SIP TLS 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.
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:
- Put the Conferencing Node whose IP address you want to change into maintenance mode.
- When all calls on that Conferencing Node have terminated, delete the Conferencing Node.
- Wait at least 90 seconds to allow the deletion to be synchronized across the platform.
- Add a new Conferencing Node with the new IP address (but using the same Name, Hostname and Domain etc. as used before, if required).
- 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. There is no limit on the number of Conferencing Nodes that you can add to the Pexip Infinity platform.
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.