Implementing a dial plan

When you deploy the Pexip Infinity platform in your network, you must consider your dial plan and ensure that calls are routed appropriately. This includes:

  • aliases that are associated with a conferencing service (Virtual Meeting Room, Virtual Auditorium, Virtual Reception, scheduled conference, Media Playback Service, or Test Call Service)
  • person-to-person calls handled by the Infinity Gateway
  • calls routed via the Infinity Gateway into an externally-hosted conference, such as a Microsoft Teams or Skype for Business meeting, or Google Meet.

If your environment includes a PSTN gateway or uses an ITSP (Internet telephony service provider), consider the potential for toll fraud if you have Call Routing Rules that can route calls to the PSTN gateway or ITSP, or if you allow conference participants to dial out to other participants via the PSTN gateway or ITSP. See PSTN gateways and toll fraud for more information.

Service precedence

Incoming calls received by Pexip Infinity are routed as follows:

  1. Pexip Infinity receives an incoming call via one of its Conferencing Nodes.
  2. It checks whether the destination alias belongs to a Virtual Meeting Room, Virtual Auditorium, Virtual Reception, scheduled conference, Media Playback Service, or Test Call Service; if so, it directs the call to that service.
  3. If the alias does not belong to any of the above services, Pexip Infinity checks the Call Routing Rules to see if the alias matches any rules specified there for incoming calls. If so, it places an Infinity Gateway call to the destination alias according to the rule's call target settings (which protocol, location and call control system to use, whether to route to registered devices only, etc).

This means that if an alias matches both a Virtual Meeting Room and a Call Routing Rule, the former will always take precedence and the call will be routed to the Virtual Meeting Room. You must therefore ensure that any regular expressions used in a Call Routing Rule do not unintentionally overlap with any aliases used by a Virtual Meeting Room, Virtual Auditorium, Virtual Reception, scheduled conference, Media Playback Service, or Test Call Service.

Pexip Infinity's call routing logic i.e. the order in which calls are processed, is shown in the following diagram:

For more information about incoming and outgoing Call Routing Rules and how to specify where calls are routed, see Configuring Call Routing Rules.

Using a standard format for aliases

We recommend that you use a standard format for all Virtual Meeting Room and Virtual Auditorium aliases within your Pexip Infinity deployment. A simple way to do this would be to have a set prefix such as meet., followed by a user name, followed by your domain. For example:

  • meet.alice.smith@example.com (for Alice's VMR)
  • meet.bob.jones@example.com (for Bob's VMR)
  • meet.sales@example.com (for the sales team's Virtual Auditorium)
  • meet.reception@example.com (for the Virtual Reception)

Using this standard format will then make it simple to configure your call management system to route calls matching the format to the appropriate Conferencing Nodes.

Routing calls to the local Conferencing Node

When your call management system receives a call to a Virtual Meeting Room, Virtual Auditorium or Virtual Reception alias, it must then decide where to route the call.

A single conference can be hosted across one, two or more Conferencing Nodes with no difference in conference experience from the users' perspective. We recommend that in the first instance, calls are routed to a Conferencing Node that is geographically nearest to the endpoint that placed the call. This reduces the WAN bandwidth used for the conference in two ways: firstly, endpoints are only making local calls; and secondly, if the same conference is hosted in more than one location, only one set of media has to be sent between those locations.

We recommend that you set up rules on your call management system so that calls originating from a particular location (defined by zone, subzone or IP address range) and placed to a Pexip Infinity alias are routed to a specific Conferencing Node. If you are deploying Proxying Edge Nodes, we recommend that you ensure that calls are routed only to those Proxying Edge Nodes and not to Transcoding Conferencing Nodes. To build on the previous example, we have configured subzones on our call management system which group together endpoints in a particular physical location, and we have then set up the following call routing rules:

Source Alias Destination zone
Oslo subzone meet.*@example.com.* Norway Conferencing Node
New York subzone meet.*@example.com.* Americas Conferencing Node
Boston subzone meet.*@example.com.* Americas Conferencing Node

In this case, users in Oslo, New York and Boston could all call meet.sales@example.com and be routed to the same conference.

See Regular expression (regex) reference for information about writing regular expressions.

Further information

For further information about how to configure your specific call management system to work with Pexip Infinity, see the following documentation: