Hardware resource allocation rules

A number of different types of connections to Transcoding Conferencing Nodes are required for a conference to take place, or for a gateway call to be made.

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.

Each of these connections requires a certain amount of resource, or capacity. In general, the amount of resource required for each connection to a Transcoding Conferencing Node can be categorized as:

  • audio-only
  • standard definition (SD)
  • high definition (HD - 720p), or
  • Full HD (1080p).

The following rules determine how hardware resources are allocated and consumed by conference and gateway calls in a Pexip Infinity deployment:

  • Each HD participant uses one HD connection.
  • If these are Skype for Business / Lync participants, they each require one additional HD connection when sending or receiving presentation.
  • If these are WebRTC participants:

    • the presenter requires one additional HD connection when sending presentation
    • the participant requires one additional HD connection when receiving full motion presentation.
  • Standards-based endpoints (SIP or H.323) do not require an additional connection when sending or receiving presentation.
  • 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.
  • Only one backplane connection is used for each conference on each Transcoding Conferencing Node, regardless of the number of other transcoding nodes that are involved in the conference.
  • Pexip Infinity always tries to optimize gateway calls:

    • a gateway call does not reserve resource for a backplane, but will use one if required (for example, if the participants are connected via different Transcoding Conferencing Nodes)
    • if the gateway call participant is a Skype for Business / Lync client, Pexip Infinity reserves 1 HD connection in case the SfB/Lync client needs to send or receive presentation.
  • SD quality can be enforced by reducing the bandwidth of a service or gateway call to 960 kbps or less. Pexip Infinity will consume less resource per-call, however, it will still reserve an HD connection for the backplane.
  • Note that if an API participant is the first participant to join a conference, it will reserve a backplane for the conference.

Proxying Edge Node resource requirements

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.

Extra information

See Pexip Infinity license installation and usage for full information about how call licenses are consumed.

We have provided some resource allocation examples and a deployment case study to help illustrate these rules in practice.