Tech Docs

Distributed Proxying Edge Nodes

When designing your Pexip Infinity deployment, one of the main considerations is how and where to deploy your Conferencing Nodes. A Conferencing Node can perform one of two roles:

  • Proxying: 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: 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.

You can deploy your Pexip Infinity system as either a mix of Proxying Edge Nodes and Transcoding Conferencing Nodes, or as a system that only contains Transcoding Conferencing Nodes. Prior to version 15 of Pexip Infinity, all Conferencing Nodes were, in effect, Transcoding Conferencing Nodes.

A typical deployment scenario is to use Proxying Edge Nodes as a front for many privately-addressed Transcoding Conferencing Nodes. Those outward-facing proxying nodes would receive all the signaling and media from endpoints and other external systems, and then forward that media onto other internally-located transcoding nodes to perform the standard Pexip Infinity transcoding, gatewaying and conferencing hosting functions.

How it works

When you deploy a new Conferencing Node, you must decide on its role — either transcoding or proxying (although you can change its role later).

  • If an endpoint connects to a Transcoding Conferencing Node, that node will handle all aspects of the media connection with that endpoint, and (subject to media allocation rules) it may also host the associated conference or gateway call on that node.
  • If an endpoint connects to a Proxying Edge Node, that node will still handle all of the signaling and media connections to the endpoint (including any encryption and decryption of the media stream), but it will then proxy the media on to a Transcoding Conferencing Node for processing.

The benefits of using Proxying Edge Nodes to handle all connections from endpoints and other systems — and leaving the media processing to internally-located Transcoding Conferencing Nodes — are:

  • You only need to deploy certificates on your Proxying Edge Nodes — only those nodes that handle the signaling connection to an endpoint or other system (such as a Skype for Business / Lync Edge Server) need to be configured with the appropriate certificates to allow that endpoint/system to communicate with Pexip Infinity. If you subsequently deploy more Transcoding Conferencing Nodes to increase conferencing capacity, you do not need to add certificates onto those additional nodes.
  • You only need to set up and maintain DNS records for the Proxying Edge Nodes. If you subsequently add more Transcoding Conferencing Nodes you will not have to update any call routing logic on third-party systems that connect to Pexip Infinity.
  • When an endpoint has established a signaling and a media connection to one or more Proxying Edge Nodes, the ports used for that connection will not change (even if, for example, the call is transferred to a VMR via a Virtual Reception).
  • The servers hosting Proxying Edge Nodes do not need to have as high a specification as those servers hosting Transcoding Conferencing Nodes. This is because proxying nodes are not as processor intensive as transcoding nodes. However, you still need multiple proxying nodes for resilience and capacity. 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.

For more information, see Deployment guidelines for Proxying Edge Nodes.