The capacity of each Transcoding Conferencing Node in your Pexip Infinity deployment — in terms of the number of connections* that can be handled simultaneously — depends on a variety of factors including:
- server capacity and hardware configuration
- types of calls - Full HD, HD, SD, or audio-only, and whether there is a presentation stream included
- the number of unique VMRs being used (and thus the number of backplanes being reserved)
- the type of gateway call — if the call is distributed or not, and the types of client involved in the call
- the number of licenses that are available.
* A connection can be a call or presentation from an endpoint to a Virtual Meeting Room or Virtual Auditorium, a backplane between Transcoding Conferencing Nodes, or a call into or out of the Pexip Distributed Gateway. In this context, a connection is analogous to a port.
When a connection is proxied via a Proxying Edge Node, the proxying node also consumes connection resources in order to forward the media streams on to a Transcoding Conferencing Node. A transcoding node always consumes the same amount of connection resources regardless of whether it has a direct connection to an endpoint, or it is receiving the media streams via a proxying node.
The following sections explain each of these factors. For some comprehensive examples showing how these different factors can combine to influence capacity, see Resource allocation examples.
The capacity and configuration of the server on which the Conferencing Node is running determines the number of calls that can be handled. This is influenced by a number of factors, including processor generation, number of cores, processor speed, hypervisor and BIOS settings.
The type of call (HD, SD, audio-only and so on) affects the amount of resource required by a Transcoding Conferencing Node to handle the call.
A single HD call requires roughly:
- half the resources of a Full HD call
- twice the resources of an SD call, or
- 12 times the resources of an audio-only call.
On startup, each Conferencing Node runs an internal capacity check. This capacity is translated into an estimated maximum number of Full HD, HD, SD or audio-only calls, and can be viewed on the status page ( ) for each Conferencing Node. The status also shows the current media load on each Conferencing Node as a percentage of its total capacity.
When a connection is proxied via a Proxying Edge Node, the proxying node also consumes connection resources in order to forward the media streams on to a Transcoding Conferencing Node.
A proxying node uses approximately the equivalent of 3 audio-only resources to proxy a video call (of any resolution), and 1 audio-only resource to proxy an audio call.
We recommend allocating 4 vCPU and 4 GB RAM (which must both be dedicated resource) to each Proxying Edge Node, with a maximum of 8 vCPU and 8 GB RAM for large deployments.
Each conference instance on each Transcoding Conferencing Node reserves 1 HD connection for a backplane, to allow the conference to become geographically distributed if required. The exceptions to this are:
- Deployments with a single Conferencing Node. In such cases, no backplanes will ever be required, so capacity is not reserved.
- Conferences that are audio-only (in other words, where the conference has its Conference capabilities set to Audio-only). In such cases, capacity equivalent to one audio connection is reserved for the backplane.
- Deployments with 1080p enabled. In such cases, backplanes reserve 1 Full HD connection of capacity, approximately double that of an HD connection.
For some reservation examples, see Resource allocation examples.
Gateway calls (person-to-person calls) require sufficient capacity for both the inbound leg and the outbound leg. In general, this means that each gateway call consumes resources equivalent to two connections.
Non-distributed gateway calls involving only SIP or H.323 clients do not use any additional ports. However, in other scenarios, additional ports may be used:
- Distributed gateway calls (where the outbound leg is on a different Transcoding Conferencing Node to the inbound leg) consume backplane ports — thus 1 HD video + 1 backplane for participant A plus 1 HD video + 1 backplane for participant B. This typically occurs when calling registered endpoints (where the outbound call to the registered endpoint will originate from the node the endpoint is registered to), or when using Call Routing Rules with an Outgoing location set to something other than Automatic.
- For non-distributed gateway calls involving a Skype for Business / Lync client, a backplane is reserved in case the SfB/Lync user starts presenting (as the RDP/VbSS presentation stream could connect to any Conferencing Node due to DNS). Each presentation stream counts as 1 HD port. Thus if the incoming RDP/VbSS call lands on the same node as the video call then the resource usage is equivalent to 3 HD ports (2 video + 1 presentation). If the RDP/VbSS call lands on a different node to the video call then the resource usage for the call is equivalent to 5 HD ports (2 video + 2 backplane + 1 presentation).
- For calls between SIP/H.323 clients and an Infinity Connect WebRTC client, 1 port is reserved for a full motion presentation stream (so these calls will consume 3 HD ports). A call between 2 WebRTC clients will also reserve 3 HD ports (2 video + 1 full motion presentation) but could also use 1 extra port (making 4 in total) if the receiving client chooses to receive the presentation stream in full motion.
The total number of concurrent calls that can be made in your deployment (regardless of whether those calls are HD, SD or audio-only) is limited by your license. For more information, see Pexip Infinity license installation and usage.
You can easily scale a deployment up by creating several Conferencing Nodes in the same location (i.e. the same datacenter). Capacity can even be added “on the fly” – Conferencing Nodes can be added in a couple of minutes if more capacity is needed. Alternatively, each location can be configured to overflow to another location if it reaches its capacity, including bursting to temporary resources on a cloud service.
For more information on media overflow and dynamic bursting, see: