Handling of media and signaling

Media and signaling for each call to a Pexip Infinity service (VMR, gateway call etc.) may take different paths, depending on the location of the caller, the available capacity of Conferencing Nodes, whether any media overflow locations have been configured, and the role of the Conferencing Node that receives the call signaling.

A Conferencing Node can have either a transcoding or a proxying role:

  • Transcoding Conferencing Nodes are required in all deployments; they manage all of the media processing required to host a conference, and can also handle direct connections to/from endpoints if required.
  • Proxying Edge Nodes are optional; they handle call signaling and the media connection with the endpoint, but forward the media on to a Transcoding Conferencing Node for processing. For full information, see Deployment guidelines for Proxying Edge Nodes.

Behavior summary

Media and signaling handling for a conference follows these rules:

  • Conferencing Nodes handle all conference signaling and media (except for direct media scenarios).
  • A single conference instance can span any number of locations and any number of Conferencing Nodes, but with a limit of 3 nodes per location that are processing media for that conference.
  • The Conferencing Node that receives the call signaling always continues to handle the signaling, regardless of where or how the media is routed (which may be through a different node). There is no concept of signaling overflow.
  • When a call is received on a Transcoding Conferencing Node, Pexip Infinity selects a transcoding node to process the conference media and perform the lineside media handling. The selection process is based on the Transcoding location, and the optional Primary overflow location and Secondary overflow location configured against the location of the node that is handling the call signaling. In the first case it tries to use a transcoding node in the Transcoding location: it will initially select a node that is already transcoding media for that conference (if that node has sufficient capacity to take the new call), otherwise it selects the transcoding node that currently has the most available capacity. If there is not a suitable node in the Transcoding location with sufficient capacity to take the media, or it has reached the limit of 3 nodes in that location, it uses a transcoding node in the Primary overflow location, or a node in the Secondary overflow location.
  • When a call is received on a Proxying Edge Node, lineside media handling is allocated to the proxying node with the most available capacity in the location receiving the signaling. That proxying node must then forward the media onto a transcoding node using the same allocation/overflow rules (based on the signaling location's configured transcoding and media overflow locations) as when a call is received on a transcoding node, as described above. A system location should not contain a mixture of proxying nodes and transcoding nodes.
  • The transcoding nodes send the call media for the conference to each other over a backplane, with each node sending the media on behalf of all the endpoints connected (or proxied) to it. If two or more transcoding nodes in the same location are processing conference media, a single node per location acts as an intermediary and sends the conference media over a backplane to another intermediary node in the other locations that are also handling that conference.

You should ensure that any locations specified as a Transcoding location or as a Primary or a Secondary overflow location contain only Transcoding Conferencing Nodes.

Note that if you change the media-handling locations for a proxying location (i.e. its transcoding, primary or secondary overflow locations), any proxied calls from that location that are currently being handled by the previously configured media locations will be dropped.

More details about all of these rules and some example scenarios are explained in the sections below:

Locally and globally distributed conferences

Conferences that span more than one Transcoding Conferencing Node can be locally or globally distributed. Locally distributed conferences exist across multiple transcoding nodes in the same system location and send conference media between nodes via a local backplane.

Globally distributed conferences exist across several Transcoding Conferencing Nodes, where each node is in a different system location. As system locations are typically used to represent different physical locations, this allows participants in different regions to access the conference from their local Conferencing Node. The nodes send the call media for the conference to each other over a single geo backplane, with each node sending the media on behalf of all the endpoints connected (or proxied) to it, thus minimizing WAN bandwidth usage between locations.

A conference can be locally and globally distributed at the same time, if two or more Transcoding Conferencing Nodes in one location and at least one other transcoding node in a different location are involved. In such cases, one transcoding node in each location acts as the intermediary for any other transcoding nodes in the same location that are handling the media for that conference. Call media for each location is sent between the intermediaries only, thus minimizing WAN bandwidth usage between locations.

A single conference instance can span any number of locations and any number of transcoding nodes, but with a maximum limit of 3 nodes per location that are performing media transcoding for that conference.

How nodes for signaling and media proxying (if applicable) are determined

In all cases, when a call is placed to a Pexip Infinity service, the call (signaling) is received by whichever Conferencing Node was selected by your call control system or routed via DNS.

  • Signaling always remains routed to the node that received the call. This could be a Proxying Edge Node or a Transcoding Conferencing Node.
  • If the signaling is received on a Proxying Edge Node, media proxying is allocated to the proxying node with the most available capacity in the location that received the signaling. The selected proxying node will always handle the media connection with the endpoint, acting as a proxy between the endpoint and a Transcoding Conferencing Node (which should be in a different location).
  • If the signaling is received on a Transcoding Conferencing Node, then whichever transcoding node is selected to process the media (which may be a different node to the signaling node) will also directly handle the media connection with the endpoint.

How Pexip Infinity decides which Transcoding Conferencing Node will process the media

Pexip Infinity intelligently load-balances the call media across all transcoding nodes that are grouped within a system location. It uses the same load-balancing rules to decide which transcoding node will process the media and host the conference, regardless of whether the media is being proxied or not, and whether the signaling is being handled by a proxying node or by a transcoding node:

  • The selection process is based on the Transcoding location, and the optional Primary overflow location and Secondary overflow location configured against the location of the node that is handling the call signaling.
  • Initially, Pexip Infinity tries to use a Transcoding Conferencing Node that is in the Transcoding location:

    • If there is a transcoding node that is already handling media for the conference, and it has spare capacity, then that node will also process the media on the new call.
    • If there are no transcoding nodes that are currently processing media for the conference, or those that are currently processing media for the conference are at full capacity, then the transcoding node in that location that currently has the most available capacity is selected (up to a maximum of three transcoding nodes per location per conference instance).
  • If there is no transcoding resource available in the Transcoding location, then a transcoding node in a media overflow location (if configured) is used. The reasons why there may be no transcoding resource available in the Transcoding location are:

    • all of the transcoding nodes in that location are fully-loaded in hosting other conferences
    • there are three fully-loaded transcoding nodes already managing that conference in that location
    • all of the nodes in the Transcoding location are proxying nodes (for example, if a location containing proxying nodes has its Transcoding location set to This location).

    The selection of the transcoding node in the media overflow location follows the same balancing rules: if a node is currently processing the conference media and has capacity to take the new call then that node is selected, otherwise the node in the overflow location that currently has the most available capacity is selected.

  • The call is rejected if there is no transcoding capacity available in the transcoding location or either of the overflow locations associated with the signaling location. Note that endpoints connected (for signaling purposes) to nodes at other locations may still be able to join the conference — this is because each location has its own configurable set of transcoding and overflow locations that it can use for its local endpoints.

Example flows when only using Transcoding Conferencing Nodes and transcoding is performed in the same location as the signaling location

Example flows when using Proxying Edge Nodes and transcoding is performed in a separate location containing Transcoding Conferencing Nodes

Media overflow locations

Media overflow locations are used to tell Pexip Infinity where to process the call media when there is no transcoding resource currently available in the Transcoding location associated with the location where the call has been received.

Locations are not explicitly configured as "media overflow" locations — their use depends upon how you have configured your system. For example, you could have one dedicated location that never initially handles any calls, but is used as a common overflow location for all of your other locations. Alternatively, you could configure your locations to overflow to each other — which may be useful if you have locations around the world, so that a location that is experiencing heavy demand during its working day can make use of idle resources in a location in a different timezone.

The nodes in your overflow location can be "always-on" nodes or you can use dynamic node resources in a cloud service (referred to as "bursting").

To enable overflow, you must configure a location with a Primary overflow location and a Secondary overflow location (in addition to its standard Transcoding location). When overflow resources are required, Pexip Infinity will use any available transcoding resource in the primary overflow location first (using the same rules and limitations as described above), and if there is no suitable resource in the primary overflow location it will use resource in the secondary overflow location.

If you need to nominate more than two overflow locations, you can use local or external policy to specify a list of multiple overflow locations in its response to a media location request.

When determining where to handle the media for any given call, the transcoding location, primary overflow location and secondary overflow location options are all based on what is configured directly against the location containing the Conferencing Node that is handling the signaling for that call — i.e. if an overflow location is configured with its own overflow locations, then those indirectly-configured overflow locations are ignored. For example, if a call is received in location A, and location A is configured to transcode in location B but location B is full, it next uses the overflow location as configured in location A (what is configured in location B is irrelevant to this call). See the examples below for more details and conferencing scenarios.

Note that:

  • If you are not using proxying nodes, you must ensure that endpoints can route their media to the transcoding nodes in the overflow locations.
  • When each new location is brought into the conference, Pexip Infinity nominates a single transcoding node in each location as the intermediary node for that conference instance, and a geo backplane is established between those intermediary nodes.

Infinity Gateway calls

The same principles described above also apply to calls placed via the Infinity Gateway:

  • The call signaling is always handled by the Conferencing Nodes that receive and place the call (note that you can configure Call Routing Rules to call out from a Conferencing Node in a different location to that which received the call).
  • The call media is handled by a transcoding node that has the most available capacity in the Transcoding location associated with the signaling node's location, or its overflow location. However, see below for additional information about the outgoing location.

Nominating the outgoing location for outbound calls

When specifying the outgoing location for a Call Routing Rule, automatically dialed participant, or when manually dialing out from a conference:

  • The call (signaling) is placed from a Conferencing Node in the nominated outgoing location, unless the device being called is registered to Pexip Infinity, in which case the call is always placed from the Conferencing Node where the registration is held.
  • If the node placing the call is a Proxying Edge Node, then the proxying node in that signaling node's location with the most available capacity will handle the lineside media connection with the called device and it will proxy the media to a transcoding node in the Transcoding location associated with that location (or to an overflow location if there is no transcoding capacity in the Transcoding location).
  • If the node placing the call is a Transcoding Conferencing Node, then the transcoding node in the Transcoding location associated with that signaling node's location (or in an overflow location if there is no transcoding capacity in the Transcoding location) with the most available capacity will handle the lineside media connection and the media transcoding.
  • Note that if the nominated outgoing location contains a mixture of proxying nodes and transcoding nodes (although we do not recommend this) then Pexip Infinity will choose any node from the location and it will behave as described above according to the selected node's role.

Examples

Based on these rules, here are some examples of how signaling and media are routed in different situations:

Media and signaling flows in a locally distributed conference

This example shows the signaling and media flows for a locally distributed conference (the conference is hosted on nodes all within the same location). In this example, all of the Conferencing Nodes involved are Transcoding Conferencing Nodes.

  1. Alice dials meet.alice@example.com and is connected via DNS to Conferencing Node USConf01.
  2. Pexip Infinity determines that another Conferencing Node within that location, USConf02, has the most available capacity and so sets up the conference on that node. Alice's signaling is handled by USConf01 and the media is being sent directly to USConf02.
  3. Bob dials meet.alice@example.com. He is connected to USConf02. The conference is already running on that Conferencing Node, so USConf02 handles both the media and the signaling for Bob.
  4. Carol dials meet.alice@example.com. She is connected to USConf03. Her signaling is handled by USConf03 but the media is routed directly to USConf02, where the conference is running.
  5. Dave dials meet.alice@example.com. He is connected to USConf01. Pexip Infinity determines that USConf02 is now out of capacity, and USConf03 has the most available capacity. Dave's media is routed to USConf03, but USConf01 continues to handle his signaling.

Media and signaling flows in a globally distributed conference

This example builds on the previous example described above. It assumes that the conference meet.alice@example.com is in progress and currently has all of its media and signaling in a locally distributed conference in location USA. Again, in this example, all of the Conferencing Nodes involved are Transcoding Conferencing Nodes.

This deployment has locations configured for USA, Mexico, Canada and Brazil, and the USA and Mexico locations are configured with transcoding, primary and secondary overflow locations as follows:

Location Transcoding location Primary overflow location Secondary overflow location
USA This location i.e. USA Mexico Canada
Mexico This location i.e. Mexico Brazil   -

This example now shows what could happen when three new participants, two from the USA and one from Mexico, join the conference.

  1. Emma, who lives in USA, dials meet.alice@example.com and is connected to USConf01 in location USA.

    Assume that all three Conferencing Nodes in location USA have reached their capacity, so Emma's media is routed directly to MexConf01 in location Mexico (because Mexico is the primary overflow location for the USA location). USConf01 continues to handle her signaling.

  2. Frank, who lives in Mexico, dials meet.alice@example.com and is connected to MexConf01 in location Mexico.

    Assume that all of the Conferencing Nodes in location Mexico have reached their capacity, so Frank's media is routed directly to BraConf01 in location Brazil (because Brazil is the primary overflow location for the Mexico location to which Frank is connected). MexConf01 continues to handle his signaling.

  3. Greta, who lives in USA, dials meet.alice@example.com and is connected to USConf03 in location USA.

    Assume that all of the Conferencing Nodes in location USA have reached their capacity, as have all of the nodes in the USA location's primary overflow location of Mexico, so Greta's media is routed directly to CanConf01 in location Canada (because Canada is the secondary overflow location for the USA location to which Greta is connected; it is irrelevant if location Brazil has spare capacity as Brazil is not an overflow location for endpoints connected to the USA location). USConf03 continues to handle her signaling.

Note that this example deliberately describes an extreme scenario as its purpose is to demonstrate how location overflow logic is applied.

Conference escalation from locally to globally distributed is handled automatically by Pexip Infinity and is seamless to conference participants.

Media and signaling flows when using Proxying Edge Nodes and Transcoding Conferencing Nodes

These examples show the signaling and media flows when you have Proxying Edge Nodes in your deployment. Here, we assume that all callers located in the USA are routed via DNS to a Proxying Edge Node in the USA Proxying location, and that location is configured with a Transcoding location of USA Transcoding as follows:

Location Transcoding location Primary overflow location Secondary overflow location
USA Proxying USA Transcoding Mexico Transcoding   -
Canada Proxying Canada Transcoding Mexico Transcoding   -

  1. Alice dials meet.alice@example.com and is connected via DNS to Proxying Edge Node USprox01. Her signaling remains routed to USprox01 throughout the call. USprox01 is also selected as the proxying node to handle Alice's media, from where it needs to be proxied to a transcoding resource. Pexip Infinity chooses the node with the most available capacity in the transcoding location of USA Transcoding — in this case UStrans01. Therefore USprox01 forwards Alice's media onto UStrans01 which hosts the conference meet.alice.
  2. Bob dials meet.alice@example.com and he is connected to USprox02 for signaling purposes. USprox02 is also chosen to handle his media (as it is the proxying node in that location with the most available capacity) and it needs to proxy his media onto a transcoding resource in the transcoding location. The meet.alice conference is already running on UStrans01 and has spare capacity, so USprox02 forwards Bob's media onto UStrans01.
  3. Carol dials meet.alice@example.com and she is connected to USprox02. Her media is also allocated to USprox02. However, this time UStrans01 has no spare capacity, so Pexip Infinity chooses another node in the transcoding location as the forwarding destination — UStrans02 in this case. The conference is now locally distributed within the USA Transcoding location and a local backplane is established between UStrans01 and UStrans02.

As before, if the nodes in the transcoding location reach their capacity, the media would be forwarded instead onto any overflow locations that are configured against the location handling the signaling, which is Mexico Transcoding in this example.

Escalated to a globally distributed conference

We can now extend this example to show how the conference could become globally distributed when a participant in Canada joins. Here, the Canada Proxying location contains Proxying Edge Nodes and it is configured with a transcoding location of Canada Transcoding.

Harry dials meet.alice@example.com and he is routed via DNS to his local Proxying Edge Node Canprox01. His media proxying is allocated to Canprox02 from where it is forwarded to Cantrans01 in the transcoding location. The meet.alice conference is now globally distributed and therefore a geo backplane is set up between one of the nodes in location USA Transcoding (UStrans01 in this example) and Cantrans01.