About the Virtual Reception IVR service

The Virtual Reception IVR service provides a way for conference participants who cannot dial Virtual Meeting Room and Virtual Auditorium aliases directly, to access these services from a central lobby using DTMF tones. It can also be used to route calls via the Pexip Distributed Gateway to join an externally-hosted conference, such as a Microsoft Teams or Skype for Business meeting, or Google Meet.

Using the Virtual Reception to access VMRs

Generally, in order to access a Virtual Meeting Room, participants dial one of the Virtual Meeting Room's aliases directly from their endpoint. However, some conference participants may not be able to do this. Reasons might include:

The participant's endpoint might not support dialing by URI - they can only dial by IP address.
The participant might be using an audio-only PSTN telephone and can only make calls to direct dial numbers.
Your enterprise might have a limited number of direct dial numbers that can be used for audio participants, and you do not want to allocate one per VMR.
Your enterprise uses local, toll-free telephone numbers that audio-only users can dial to access your VMRs and you don't want to have one of these for every VMR in your enterprise.

To allow for such cases, Pexip Infinity enables you to set up a single direct dial number or IP address that participants can dial to access a single, central lobby, known as a Virtual Reception. From here they can use the DTMF tones on their endpoint to enter the number of the specific VMR they want to join.

To implement this you must:

Create and configure your Virtual Reception.
Ensure that every Virtual Meeting Room that you want to be accessible from the Virtual Reception has at least one alias that consists of digits only. For more information, see Using multiple aliases to access the same service.
Provide conference participants with the combination of Virtual Reception alias followed by the Virtual Auditorium or Virtual Meeting Room number that they must dial to access the conference.

Note that when looking at conference status or conference history you will never see a Virtual Reception record for a WebRTC connection (WebRTC clients only send an HTTP request for the initial connection to the Virtual Reception, and no media is started until the participant connects to the VMR), but you will see a record for a video endpoint.

Providing telephone access to Virtual Meeting Rooms

For information on how to set up audio-only PSTN or mobile telephone access to your Virtual Meeting Rooms and Virtual Auditoriums via a Virtual Reception, see Integrating with telephone systems (PSTN).

Virtual Receptions and Skype for Business clients

To allow Skype for Business / Lync clients to use Virtual Receptions, you must ensure that the target VMR is configured with at least one alias in the form of a SIP URI that is routable by the SfB/Lync client. (This is in addition to the digits-only VMR alias used by the Virtual Reception.) Pexip Infinity chooses the first alias in the VMR's configuration that is a valid SIP URI; it also replaces the selected alias's domain with the Pexip Infinity domain (for Lync / Skype for Business integration) (from the relevant system location or global setting as appropriate, if configured).

Note that the SfB/Lync client will be transferred into the destination VMR or gateway call as an audio-only participant, although they can subsequently escalate to two-way video if required (providing the Call capability configuration of the VMR or Call Routing Rule allows it).

Including the numeric alias of the VMR in the Virtual Reception dial string

SIP and H.323 endpoints and Skype for Business / Lync clients can optionally bypass having to enter the destination alias via DTMF tones.

They can do this by including the numeric alias of the VMR in their dial string when dialing the Virtual Reception. The dial string should be in the format: <reception_alias>**<destination_alias>@<domain>.

For example, if the alias of the Virtual Reception is ivr@example.com and the numeric alias of the target Virtual Meeting Room is 1234, then the endpoint can dial ivr**1234@example.com to be transferred directly into the VMR.

Note that H.323 devices can also use the dial format <reception_alias>#<destination_alias>@<domain>.

Restricting or transforming the aliases entered into a Virtual Reception

To increase the security of your Virtual Reception services you may want to:

Restrict the aliases or alias patterns that can be entered into a Virtual Reception.
Optionally transform the entered alias before the Virtual Reception attempts to route the call to that new destination.

You can do this when configuring your Virtual Reception by expanding the Advanced options and specifying the Destination alias regex match and Destination alias regex replace string fields.

For example, you could:

Lock down the number ranges that can be reached via the Virtual Reception, e.g. by specifying a regex match of 8(.*) to only allow calls to numbers starting with "8".
Restrict and then transform the aliases that are entered, e.g. by specifying a regex match of (\d{4}) to only allow 4 digit extensions to be entered and then to prepend the entered alias with a prefix of "88" by entering a replace string of 88\1.
Append a domain onto any numbers entered (so that you don't need to configure so many alternative VMR aliases), e.g. by specifying a regex match of (\d{4}) and then appending a domain by using a replace string of \1@example.com.
Only allow access to a specified shortlist of aliases, e.g. by configuring a match string of (1111|1112|1113) to reject any other alias than 1111, 1112 or 1113.

Using the Virtual Reception with the Infinity Gateway

You can also use the Virtual Reception to route calls via the Infinity Gateway. This would allow you, for example, to route phone calls towards a Cisco VCS as E.164 numbers, or to join 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.

Routing phone calls towards a Cisco VCS as E.164 numbers

To implement this you must:

Create and configure your Virtual Reception in the normal way.
Configure a Call Routing Rule that matches the desired E.164 pattern and then routes the call via the specified Cisco VCS (where the Cisco VCS is the SIP proxy or H.323 gatekeeper as specified in the rule).
Ensure that the E.164 pattern does not match a Virtual Meeting Room alias (as Virtual Meeting Room routing takes precedence).

Now, if someone dials in to the Virtual Reception and then enters the E.164 number that matches the Call Routing Rule, their call will be routed via the Cisco VCS.