Configuring Pexip Infinity as a Lync / Skype for Business gateway
Pexip Infinity can act as a gateway between Lync / Skype for Business
- invite H.323/SIP endpoints and registered Infinity Connect clients into a Lync AVMCU multi-party conference
- use the Pexip Distributed Gateway service to route incoming calls directly into an ad hoc or scheduled Lync AVMCU multi-party conference
- when dialed into a Pexip VMR conference, invite other Lync or external contacts into that same Pexip VMR (this creates a new Lync AVMCU conference which is merged with the existing Pexip VMR)
- receive and initiate point-to-point calls with standards-based devices.
This topic covers:
- Using the Pexip Distributed Gateway service
- Configuring rules to allow Lync / Skype for Business to dial out to other devices via the gateway
- Configuring rules to allow devices to call Lync / Skype for Business clients via the gateway
- Configuring rules to use Pexip Infinity as a Lync gateway into AVMCU conferences
- Ensuring each Conferencing Node's TLS FQDN is set (all gateway scenarios)
* Note that where this documentation refers to "Lync", it represents both Microsoft Lync and Skype for Business unless explicitly stated otherwise.
Using the Pexip Distributed Gateway service
The Pexip Distributed Gateway is configured as a series of Call Routing Rules that specify which calls should be interworked and to where.
Incoming calls received by Pexip Infinity are routed as follows:
- Pexip Infinity receives an incoming call via one of its Conferencing Nodes.
- It checks whether the destination alias belongs to any Pexip Infinity Virtual Meeting Rooms, Virtual Auditoriums or Virtual Receptions; if so, it directs the call to that service.
- 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 outgoing call to the destination alias according to the rule's call target settings (which protocol 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 Virtual Meeting Rooms, Virtual Auditoriums or Virtual Receptions.
If you configure your Pexip Distributed Gateway to support all of the Lync scenarios described here, you will have Call Routing Rules similar to those shown below:
You can configure a Call Routing Rule that enables Lync clients to initiate point-to-point calls with standards-based devices, and to invite other endpoints into a Lync AVMCU multi-party conference.
To configure the rule:
- Go to and select .
-
Configure the following fields (leave all other fields with default values or as required for your specific deployment):
Option Description Name The name you will use to refer to this rule. Priority Assign the priority for this rule. Incoming gateway calls Ensure this option is selected. Outgoing calls from a conference Leave unselected. Match Infinity Connect (WebRTC / RTMP)
Match SIP
Match Lync (MS-SIP)
Match H.323Select Match Lync (MS-SIP) and leave the other protocols unselected.
(This rule is only handling call requests received from the Lync environment.)
Match against full alias URI Leave unselected. Destination alias regex match Enter a regular expression that will match the calls received from the Lync environment. For example, to match any alias in the vc.example.com domain:
.+@vc.example.com
Destination alias regex replace string If required, enter the regular expression string to transform the originally dialed (matched) alias into the alias to use to place the outbound call. If you do not need to change the alias, leave this field blank.
Call target Select either Registered device or external system or Registered devices only, depending upon your requirements. Protocol The protocol used to place the outgoing call. This will be either SIP or H.323.
If you want to place the call over both SIP and H.323, you will need to create 2 rules, one per protocol.
Note that if the call is being placed to a registered device, such as an Infinity Connect desktop client, Pexip Infinity will always use the protocol that the device used to make the registration.
SIP Proxy You can optionally specify the SIP Proxy to use to place an outgoing SIP call. H.323 Gatekeeper You can optionally specify the H.323 Gatekeeper to use to place an outgoing H.323 call. - Select .
You can configure a Call Routing Rule that enables non-Lync devices, such as SIP and H.323 endpoints or Infinity Connect clients, to make point-to-point calls to Lync clients.
To configure the rule:
- Go to and select .
-
Configure the following fields (leave all other fields with default values or as required for your specific deployment):
Option Description Name The name you will use to refer to this rule. Priority Assign the priority for this rule. Incoming gateway calls Ensure this option is selected. Outgoing calls from a conference Leave unselected. Match Infinity Connect (WebRTC / RTMP)
Match SIP
Match Lync (MS-SIP)
Match H.323Select one or more of Match Infinity Connect (WebRTC / RTMP), Match SIP and Match H.323 as appropriate.
(Do not select Match Lync (MS-SIP) as this rule is only handling call requests received from outside the Lync environment.)
Match against full alias URI Leave unselected. Destination alias regex match Enter a regular expression that will match the calls to be sent to the Lync environment. For example, to match any alias in the example.com domain:
.+@example.com
Destination alias regex replace string If required, enter the regular expression string to transform the originally dialed (matched) alias into the alias to use to place the Lync call. If you do not need to change the alias, leave this field blank.
Call target Select Lync clients or Lync AVMCU conferences via a Virtual Reception (we want to route the calls to Lync clients via an external Lync server). Outgoing location If required, you can ensure that the outgoing call to Lync is handled by a Conferencing Node in a specific location.
If an outgoing location is not specified, the call is placed from a Conferencing Node in the ingress location (the same location as the Conferencing Node that is handling the incoming call).
Lync server Select the Lync server that you want to use to handle the call, for example eu-lyncpool. - Select .
In addition to Pexip Infinity acting as a point-to-point gateway between non-Lync devices, such as SIP and H.323 endpoints or Infinity Connect clients, and Lync clients, you can also configure the Pexip Distributed Gateway such that it can route calls from those external devices directly into ad hoc or scheduled Lync AVMCU multi-party conferences.
All calls are routed into the AVMCU conferences by means of the Lync Conference ID that is associated with the AVMCU conference. The Lync Conference ID is typically a 5 or 6 digit number. For scheduled meetings it will normally be included in the meeting invitation.
For ad hoc conferences, existing Lync participants in the conference can find the Conference ID by selecting the option (see picture).
There are two ways you can configure these gateway calls within Pexip Infinity:
- Routing indirectly via a Virtual Reception: here you configure Pexip Infinity to act as a Lync IVR gateway or "lobby" by configuring a Virtual Reception to capture the Conference ID of the required conference, and then use a Call Routing Rule to route the call into the AVMCU conference.
- Routing directly via the Pexip Distributed Gateway: here you use a single Call Routing Rule to route incoming calls for specific alias patterns — that will typically include the Conference ID — directly into the relevant AVMCU conferences.
You can use either or both of these two methods, depending upon your requirements. The configuration required for these methods is explained below (see Routing indirectly via a Virtual Reception (IVR gateway) and Routing directly via the Pexip Distributed Gateway). Also included are some guidelines for Lync configuration to use Pexip Infinity as a Lync AVMCU gateway.
Note that:
- The Lync gateway features are only supported within on-prem Lync deployments, as the Conferencing Nodes must be trusted applications within the Lync environment.
- Non-Lync video callers will see a holding screen until a Lync client joins the conference with video.
To route calls to AVMCU conferences via a Virtual Reception (IVR gateway) you need:
- A Virtual Reception configured specifically to handle Lync conferences.
- A Call Routing Rule to route the calls handled by the Virtual Reception into the relevant Lync conference (typically you will adapt your existing rule configured above that routes point-to-point calls to Lync clients).
The Virtual Reception requests the caller to enter the Lync Conference ID (typically a 5 or 6 digit number) which it then uses to retrieve the full conference URI from the Lync server. The Pexip Distributed Gateway then matches this conference URI and routes the caller to the appropriate Lync AVMCU conference.
To configure the Virtual Reception:
- Go to and select .
-
Configure the following fields (leave all other fields with default values or as required for your specific deployment):
Option Description Name The name you will use to refer to this Virtual Reception, for example "Lync IVR gateway". Theme Optionally, you may want to assign a specific theme to this Virtual Reception to brand it as the gateway to Lync conferences, for example by customizing the voice prompts. Lync server (in the Advanced options) Select the Lync server that you want to use to resolve the Lync Conference ID, for example eu-lyncpool. Lync conference lookup location You can optionally specify the system location that will perform the Lync Conference ID lookup on the Lync server. If a location is not selected, the IVR ingress node will perform the lookup.
This can assist in scenarios where an external device connects to a Virtual Reception via a Conferencing Node in the DMZ and that node is not trusted by the Lync FEP. This allows you to nominate the location (in which the Conferencing Nodes are trusted by Lync) to perform the lookup.
Alias Enter the alias that users will dial to use this Lync gateway Virtual Reception, for example lync.lobby@example.com. - Select .
To configure the Call Routing Rule:
- Go to .
- Select the existing Call Routing Rule that currently routes calls to your Lync clients (as configured in Configuring rules to allow devices to call Lync / Skype for Business clients via the gateway above).
-
Modify the following fields (leave all other fields unchanged):
Option Description Match against full alias URI Select this option.
(The alias of the Lync conference contains various parameters that must not be stripped away.)
Destination alias regex match Amend the regular expression to also match against aliases that contain parameters after the domain portion, for example:
.+@example.com.*
Note that this rule will still continue to support the routing of point-to-point calls to Lync clients. This modification just enhances the scope of the rule to also include routing to Lync AVMCU conferences.
- Select .
Using the Lync IVR gateway service
After the Virtual Reception and Call Routing Rule have been configured, non-Lync users can now dial the alias of the Virtual Reception (e.g. lync.lobby@example.com) and then, when prompted by the IVR service, enter the Lync Conference ID of the conference they want to join.
The Pexip Distributed Gateway will then route the call into the appropriate Lync conference.
Note that:
-
SIP and H.323 endpoints can bypass having to enter the destination alias via DTMF tones. They would do this by including the Lync Conference ID in their dial string when dialing the Virtual Reception. The dial string should be in the format: <reception_alias>**<conference_id>@<domain>.
For example, if the alias of the Virtual Reception is lync.lobby@example.com and the Lync Conference ID is 572450, then the endpoint can dial lync.lobby**572450@example.com to be transferred directly into the Lync conference.
- Infinity Connect Web App users can also be provided with a preconfigured link URL that, when clicked, will automatically provide the Lync Conference ID to the Virtual Reception and take the user directly into the Lync conference. The URL needs to be in the format:
https://<address>/webapp/?conference=<reception_alias>&name=<name>&join=1&extension=<Conference ID>
for example https://node.example.com/webapp/?conference=lync.lobby@example.com&name=Alice&join=1&extension=572450
To route calls to AVMCU conferences directly via the Pexip Distributed Gateway you need:
- To decide on an alias pattern that participants will dial to access the Lync AVMCU conferences. The alias pattern will typically include the Lync Conference ID, for example the pattern could be: 88<ConferenceID>@example.com i.e. a prefix of 88 followed by the Conference ID, and thus the participant would dial 8812345@example.com to access an AVMCU conference with a Conference ID of 12345.
- A Call Routing Rule that matches that alias pattern and transforms it such that it contains just the Lync Conference ID which it can then pass on to the target Lync server.
To configure the rule:
- Go to and select .
-
Configure the following fields (leave all other fields with default values or as required for your specific deployment):
Option Description Name The name you will use to refer to this rule. Priority Assign the priority for this rule. Incoming gateway calls Ensure this option is selected. Outgoing calls from a conference Leave unselected. Match Infinity Connect (WebRTC / RTMP)
Match SIP
Match Lync (MS-SIP)
Match H.323Select one or more of Match Infinity Connect (WebRTC / RTMP), Match SIP and Match H.323 as appropriate.
(Do not select Match Lync (MS-SIP) as this rule is only handling call requests received from outside the Lync environment.)
Match against full alias URI Leave unselected. Destination alias regex match Enter a regular expression that matches the calls to be sent to the AVMCU. For example, to match any alias in the style of 88<ConferenceID>@example.com you could use:
88(\d{5,6})@example\.com
Note that \d{5,6} which matches the numeric 5-6 digit Conference ID, is enclosed in a ( ) group.
Destination alias regex replace string This must transform the dialed alias so that it only contains the Conference ID.
In our example, to extract the Conference ID from the dialed alias we would use:
\1
which replaces the originally dialed alias with just the Conference ID group from the regex match field.
Call target Select Lync AVMCU conference direct (not via Virtual Reception).
This type of call target is specifically designed to take the Conference ID (that we extracted via the regex strings) and send it to the nominated Lync server so that the call can be routed into the AVMCU conference.
Outgoing location If required, you can ensure that the outgoing call to Lync is handled by a Conferencing Node in a specific location.
If an outgoing location is not specified, the call is placed from a Conferencing Node in the ingress location (the same location as the Conferencing Node that is handling the incoming call).
Lync server Select the Lync server that you want to use to perform the Conference ID lookup and to handle the call, for example eu-lyncpool.
Using the Lync IVR gateway service
After the Call Routing Rule has been configured, non-Lync users can now dial an alias that matches your specified pattern (e.g. 8812345@ example.com) to be routed directly into the appropriate Lync conference (in this example the AVMCU conference with a Conference ID of 12345).
Ensuring that Lync is configured with a dial-in access number
To ensure that a numeric Lync Conference ID is generated, your Lync environment must be configured with a conferencing dial-in access number.
For information about configuring this via Lync's administrative tools in Lync Server 2013, see https://technet.microsoft.com/en-us/library/gg398126%28v=ocs.15%29.aspx.
Waiting in Lync's meeting lobby
Participants joining the Lync conference may also be held in a Lync conference lobby.
In Lync, you can select the PSTN callers bypass lobby option to allow phone participants to bypass the lobby. For information about configuring this setting in Lync Server 2013, see https://technet.microsoft.com/en-us/library/jj721889(v=ocs.15).aspx.
Custom footer for meeting invites
You may also want to add a custom footer to the meeting invites that are sent out for scheduled conferences, so that it includes the alias details for the Pexip Infinity Virtual Reception that users will need to call (and from where they will enter the Conference ID).
For more information about configuring meeting invitations in Lync Server 2013, see https://technet.microsoft.com/en-us/library/gg398638.aspx.
Trusting Conferencing Nodes
When calling into a Lync AVMCU conference, by default, the Lync Conference ID lookup is invoked from the ingress node (the same Conferencing Node that is handling the incoming call) and the call to Lync is placed from the ingress location (the same location as the Conferencing Node that is handling the incoming call). In both cases you can override the default behavior by specifying the location that will perform the Conference ID lookup and the location that will place the outbound call.
The nodes that perform the lookup and place the call must be trusted by the Front End Pool to ensure call success.
For any Pexip Infinity and Lync integration, you must ensure that each Conferencing Node is configured with its respective DNS hostname as the SIP TLS FQDN. Pexip Infinity will present this as being the server name, and it must match the name on the certificate installed on the node. Each Conferencing Node must have a unique SIP TLS FQDN.
This is done on the Management Node, by going to , choosing each node in turn and populating the SIP TLS FQDN field.
The example above shows the SIP TLS FQDN for the eu-px01 Conferencing Node, which is set to eu-px01.example.com.
The SIP TLS FQDN must be set even if you are using a TCP connection to Lync.