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, and whether any overflow locations have been configured.
In all cases, when a call is placed to a Pexip Infinity service, the call will be received by whichever Conferencing Node was selected by your call control system or routed via DNS. This Conferencing Node will always continue to handle the signaling for that call. The following sections describe how the media is routed in different situations:
A conference is locally distributed when all participants are connected to Conferencing Nodes in a single location.
Media and signaling for a single call may take different paths within a single location, as follows:
- When an alias that belongs to a Pexip Infinity service is dialed from an endpoint, the call will be placed to whichever Conferencing Node your call control system directs the call to. This Conferencing Node will always continue to handle the signaling for that call, regardless of where the media is routed.
- If the conference does not already exist in this Conferencing Node's location, Pexip Infinity will check the loading of all Conferencing Nodes in the location and will allocate the conference to the Conferencing Node that currently has the most available capacity. The media for the call will go directly to that Conferencing Node, but the signaling will continue to be handled on the Conferencing Node to which the endpoint connected.
- If this is a call to a conference already running on another Conferencing Node within the same location, the media will be set up on the node where the conference is running, but the signaling will be handled on the node to which the endpoint connected.
- If the Conferencing Node on which the conference is running reaches capacity, Pexip Infinity will allocate a secondary (and a then a tertiary) node within that location to handle media for that conference, and automatically create a local backplane between these Conferencing Nodes so all participants are part of the same conference, with the same layout.
- Up to three Conferencing Nodes within one location can be involved in media handling for one conference instance.
- Within one location, when all of the local Conferencing Nodes that can handle the media for a conference instance have reached their capacity, "overflow" locations may be utilized, thus escalating it to a globally distributed conference.
In such cases, one Conferencing Node in each location will act as the proxy for any other Conferencing Nodes in the same location that are handling the media for that conference. Call media for each location is sent between the proxies only, thus minimizing WAN bandwidth usage between locations.
- When all of the local Conferencing Nodes and all of the nodes in the overflow locations that can handle the media for a conference instance have reached their capacity, no further calls can be placed to that conference from endpoints connected to nodes within that local location. Other endpoints connected to Conferencing Nodes in other locations may still connect to the conference, assuming that there is sufficient capacity in those locations.
- Alice dials email@example.com and is connected to Conferencing Node USConf01.
- Pexip Infinity determines that another Conferencing Node within that location, USConf02, has the most 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 firstname.lastname@example.org. 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 email@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.
- Dave dials firstname.lastname@example.org. 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.
A conference is globally distributed when Conferencing Nodes in two or more different locations are involved in a single conference instance. For example, a globally distributed conference will occur when a participant in the USA location and a participant in the UK location access the same conference instance via their local Conferencing Nodes.
In such cases, Pexip Infinity will establish a "geo backplane" between the Conferencing Nodes that are handling the media for the call in each location and use this backplane to send media between the two locations.
If more than one Conferencing Node in a single location is involved in handling the media for the call (in other words the conference is also locally distributed), Pexip Infinity will nominate one of the Conferencing Nodes in that location as the proxy. The proxy will send media between locations, on behalf of itself and any other Conferencing Node in its own location that are handling the media for the call. This minimizes WAN bandwidth usage between locations.
To maintain efficiency, no more than three Conferencing Nodes in a single location can handle the media for a particular conference instance. However, if all three Conferencing Nodes allocated to handle the media for that conference have reached capacity, additional "overflow locations" can be utilized. These overflow locations will handle the media for new conference participants that are connected (for signaling purposes) to nodes within the original location.
Pexip Infinity deployments also have the ability to overflow into temporary Conferencing Node resources in the Amazon Web Services (AWS) cloud (also referred to as "bursting"). The AWS cloud Conferencing Nodes instances are only started up when required and are automatically stopped again when capacity demand normalizes.
Each location can be optionally configured with a Primary overflow location and a Secondary overflow location.
- When a location reaches its capacity for a conference instance, new participants joining that conference at that location will have their media routed directly to a Conferencing Node in the Primary overflow location. Their signaling will remain routed to the original node in the local location.
- If the conference instance running at the Primary overflow location is at that location's capacity, the new participants joining the conference at the original location will have their media routed directly to a Conferencing Node in the Secondary overflow location instead.
If you are using dynamic cloud bursting, your bursting location containing your overflow nodes must be a Primary overflow location; the Secondary overflow location can only be used for standard overflow i.e. to other "always on" nodes.
- If the conference instance is at full capacity at the original location, and its primary and secondary locations, then no further calls can be placed to that conference from endpoints connected to nodes within that original location.
Note that endpoints connected to nodes at other locations may still be able to join the conference. This includes endpoints connected to the primary and secondary overflow locations that are associated with a location that can no longer accept calls for that conference (this is because each location has its own set of overflow locations that it can use for its local endpoints).
- If participants leave a conference and capacity becomes available again at some locations, existing participants' media connections are not rebalanced to their local location. However, any new participants will be able to take advantage of that freed-up capacity and join the conference at those locations.
- Location overflow is triggered whenever a location reaches its capacity for a conference instance — in other words, whenever all the Conferencing Node in that location that can take the media for that conference instance have reached capacity. You do not have to deploy three Conferencing Nodes at a location before it can overflow to a different location. Examples of when overflow could happen are:
- if there is only one node at that location and it has reached capacity
- if there are four nodes at that location, but the three that have been allocated the media are at capacity.
- Whenever an overflow location is utilized, a "Capacity reached in the location. Allocating the media node in the overflow location." entry is written to the administrator log. The log message indicates the conference name, the original location and the overflow location.
- When each new location is brought into the conference, Pexip Infinity nominates a single Conferencing Node in that location as the proxy node for that conference instance, and a geo backplane is established between each of the proxy nodes.
- You must ensure that endpoints in their local locations are able to route their media to the Conferencing Nodes in the overflow locations.
Note that in very rare scenarios, depending on existing media allocation and timing, a conference could span four media nodes in the same location. For example, assume that two new participants connect at the same time to an existing conference spanning two media nodes, and that those two existing media nodes are at capacity. If the two new participants' signaling is being handled by different nodes, it is possible that each signaling node could expand the conference onto a different media node in that location, resulting in four nodes handling the conference media.
This example builds on the previous example described above in Locally distributed conferences. It assumes that the conference email@example.com is in progress and currently has all of its media and signaling in a locally distributed conference in location USA.
In addition, the Pexip Infinity deployment has locations configured for USA, Mexico, Canada and Brazil, and that 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 firstname.lastname@example.org and is connected to USConf01 in location USA.
Assume that all three Conferencing Nodes currently handling the media for this conference 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 email@example.com and is connected to MexConf01 in location Mexico.
Assume that all of the Conferencing Nodes currently handling the media for this conference 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 firstname.lastname@example.org and is connected to USConf03 in location USA.
Assume that all of the Conferencing Nodes currently handling the media for this conference in location USA have reached their capacity, as have all of the nodes handling the media for this conference in the USA location's primary failover 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 the location overflow logic applied by Pexip Infinity.
The same principles described above also apply to calls placed via the Pexip Distributed Gateway:
- The call signaling will always be handled by the Conferencing Nodes that receive and place the call (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 will be handled by the Conferencing Node that has the most available capacity in that location.
- If there is no available capacity in that location and one or more overflow locations have been configured that do have available capacity, the media will be handled by one of the Conferencing Nodes in an overflow location.