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 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 signaling and receive and send the media to/from an endpoint or device, and then forward it on to a Transcoding Conferencing Node for processing.
Media and signaling handling for a conference follows these rules:
- 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).
- 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 where the call signaling is being handled. In the first case it tries to use a transcoding node in the Transcoding location. It will initially select a node in that location 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 least-loaded proxying node in the location that receives 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 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 Edge Nodes and Transcoding Conferencing 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.
More details about all of these rules and some example scenarios are explained in the sections below:
- Locally and globally distributed conferences
- How nodes for signaling and media proxying (if applicable) are determined
- How Pexip Infinity decides which Transcoding Conferencing Node will process the media
- Overflow locations
- Pexip Distributed Gateway calls
- Nominating the outgoing location for outbound calls
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.
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 least-loaded proxying node 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.
Pexip Infinity intelligently load-balances the call media across all Transcoding Conferencing 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 where the call signaling is being handled.
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 least loaded transcoding node in that location 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 Conferencing Node in an 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 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 least loaded node in the overflow location 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.
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 "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.
You can also overflow into dynamic Conferencing Node resources in a cloud service (also referred to as "bursting").
When configuring a location, you can optionally assign a Primary overflow location and a Secondary overflow 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.
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 (see the examples below).
- If you are not using Proxying Edge Nodes, you must ensure that endpoints are able to route their media to the Transcoding Conferencing Nodes in the overflow locations.
- If you are using dynamic
cloud bursting, the overflow location containing your bursting nodes must be the Primary overflow location (the Secondary overflow location can only be used for standard overflow i.e. to other "always on" nodes).
- When each new location is brought into the conference, Pexip Infinity nominates a single Transcoding Conferencing Node in each location as the intermediary node for that conference instance, and a geo backplane is established between those intermediary nodes.
- You can track how often your overflow locations are used by searching the administrator log for "Capacity reached in the location. Allocating the media node in the overflow location." entries. The log message indicates the conference name, the original location and the overflow location.
The same principles described above also apply to calls placed via the Pexip Distributed 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 Conferencing 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.
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 least-loaded proxying node in that signaling node's location 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 least-loaded 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) 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.
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
- Media and signaling flows in a globally distributed conference
- Media and signaling flows when using Proxying Edge Nodes and Transcoding Conferencing Nodes
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.
- Alice dials firstname.lastname@example.org and is connected via DNS to Conferencing Node USConf01.
- 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.
- Bob dials email@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.
- Carol dials firstname.lastname@example.org. She is connected to USConf03. Her signaling is handled by USConf03 but the media is routed directly to USConf02, where the conference is running.
- Dave dials email@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.
This example builds on the previous example described above. It assumes that the conference firstname.lastname@example.org 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 primary and secondary overflow locations as follows:
|Location||Primary overflow location||Secondary overflow location|
This example now shows what could happen when three new participants, two from the USA and one from Mexico, join the conference.
Emma, who lives in USA, dials email@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.
Frank, who lives in Mexico, dials firstname.lastname@example.org 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.
Greta, who lives in USA, dials email@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.
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 Transcoding location, and that location is configured with a Primary overflow location of USA Transcoding.
- Alice dials firstname.lastname@example.org 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. There are no Transcoding Conferencing Nodes in the USA Proxying location so Pexip Infinity chooses the node with the most available capacity in the primary overflow location of USA Transcoding — in this case UStrans01. Therefore USprox01 forwards Alice's media onto UStrans01 which hosts the conference meet.alice.
- Bob dials email@example.com and he is connected to USprox02 for signaling purposes. USprox02 is also chosen to handle his media (as it is the least loaded proxying node in that location) and it needs to proxy his media onto a transcoding resource in the overflow location. The meet.alice conference is already running on UStrans01 and has spare capacity, so USprox02 forwards Bob's media onto UStrans01.
- Carol dials firstname.lastname@example.org 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 overflow 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.
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 only contains Proxying Edge Nodes and it is configured with an overflow location of Canada Transcoding.
Harry dials email@example.com and he is routed via DNS to his local Proxying Edge Node Canprox01. His media proxying is allocated to Canprox02. There is no transcoding resource in the Canada Proxying location so his media is forwarded by Canprox02 to Cantrans01 in the overflow 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.