Signaling and media paths for remotely-located Skype for Business clients

This topic shows how signaling and media paths may be determined when externally-located Microsoft Skype for Business clients connect to Pexip services.

This information is particularly important if you need to support RDP presentations from a SfB client who has called into a Pexip VMR and the client is homed on the internal SfB Front End Pool, is connected via the SfB Edge server, and where your corporate firewalls block certain media flows. In some scenarios the solutions may involve hairpinning the firewall with media.

The scenarios shown here deal with two types of external SfB users:

Traveling user: a user who is part of the organization but is working offsite and connecting back to their Front End Pool via the SfB Edge.
Federated user: a SfB user outside of the organization, from a Federated organization.

To understand the various signaling and media flows, it is useful to first understand how a normal SfB environment operates and then build on this to show what happens when the on-premises SfB platform is integrated with Pexip Infinity.

The selection of media paths makes use of ICE (Interactive Connectivity Establishment). ICE is a framework that allows endpoints to discover paths through which they can exchange media — such as via a TURN server — where direct routing between those devices may not be possible, e.g. when a device is on a private network or is behind a NAT.

Peer-to-peer calling between internal and traveling users

This scenario shows what happens when an internal SfB user calls a traveling user:

Signaling goes via the SfB Front End Pool (FEP) and SfB Edge server.
As the internal user has authenticated via the FEP, they are allowed to send media to the internal Interface of the SfB Edge, multiplexed to UDP port 3478 (or TCP port 443), and the SfB Edge will proxy the media to the traveling user.

Peer-to-peer calling between traveling and federated users

When a traveling SfB user calls a federated SfB user:

Signaling goes via the traveling user’s SfB FEP and Edge server (the federated user’s FEP is omitted from the diagram for convenience).
A possible route for media from the traveling user is via the SfB External Edge server interface. As the traveling user has authenticated with the FEP, it can offer Relay candidates on the External Edge interface in the 50000-59999 port range (along with its own Host and Server Reflexive ICE candidates), which are offered to the far side as possible media paths. The federated user will offer similar information from its environment. ICE will test all possible media paths, and this example assumes that direct media between the users is blocked and thus the media routes through the traveling user's SfB Edge server.

Internal SfB user calls into a Pexip VMR (on-prem Pexip integration)

The example scenarios are now expanded to include integration with the Pexip Infinity platform for VTC interoperability.

An internal SfB user calling into a Pexip VMR is very similar to when an internal SfB user calls another internal SfB user. You can think of Pexip as another internal endpoint, from a media point of view.

When the internal user dials into a Pexip VMR, signaling goes via the SfB FEP as there is a static route in place pointing to the Pexip Trusted Application.
Media will likely flow directly from the SfB client to Pexip (Host <-> Host ICE candidates), which is the shortest possible path.

Federated user calls into a Pexip VMR (public DMZ Pexip integration)

When a federated user calls into a Pexip VMR in a public DMZ Pexip integration, the internal Pexip nodes take the media from any local VTC endpoints and the Pexip Edge nodes take the federated SfB user's media.

The Pexip deployment will usually be in its own domain name space, and so the external user will place a federated call directly to Pexip, as if they were simply dialing another SfB user. Again, the external user’s SfB environment is not shown for convenience.
Media arrives into the Pexip DMZ Edge node either directly to its Host address, or via a statically NATted Server Reflexive address.
A Pexip backplane sends the media between the enterprise and DMZ Pexip nodes.

Traveling user calls into a Pexip VMR (on-prem Pexip integration)

This scenario shows what happens when a traveling user calls into a Pexip VMR. Even though the media hairpins the firewall, it is the only simple solution that should work for all media types sent between Pexip and the traveling user.

Signaling comes in from the traveling user via the SfB Edge and the FEP, and is routed to the internal Pexip node using the static route.
By default, Pexip uses nodes for media that are in the same location as the node that is handling signaling, so establishing a media path between the Pexip internal node and the traveling user is now tricky. Pexip does not use the DMZ nodes as a TURN server, therefore it will only offer its own Host address as a candidate – which is an internal address. Pexip cannot use the SfB Edge as a TURN server like the SfB clients do, as it uses a different authentication process (Pexip only supports the use of an RFC5766 TURN server, whereas SfB clients authenticate via the FEP using MRAS). However, the external SfB client (as seen in Peer-to-peer calling between traveling and federated users above) can offer Relay candidates on the External Edge in the 50000-59999 port range (plus its own Host and Server Reflexive ICE candidates, as usual).
It is unlikely that Pexip will be able to send or receive media directly to/from the SfB client, so the only possible path is via the External Edge interface. This means the media traffic must be able to route between the external interface of the Edge server and the internal Pexip node.

If there is a NAT between the Pexip signaling interface and the External Edge, Pexip is likely to need a STUN server in the DMZ so that it can discover its Server Reflexive address in the DMZ.

Traveling user calls into a Pexip VMR (on-prem Pexip integration with TURN server)

When a TURN server is available in the public DMZ, some — but not all — of the routing issues are alleviated, when a traveling user needs to call into a Pexip VMR.

Signaling is as per the previous scenario.
For media, now that Pexip has a TURN server deployed and configured, it can allocate its own Relay candidates on the TURN server, and it should then be possible for the SfB client to send media toward the TURN server. However, a Pexip Conferencing Node only requests the use of UDP relays, not TCP. This means that if the traveling SfB user sends media that uses TCP as a transport (as would be the case if it sends an RDP presentation), then that media cannot be routed via the TURN server. If the presentation is via VbSS (which uses UDP as a transport), then the media via the TURN server would work.

Note that the media may end up taking a combination of a routes through the TURN server and via the External Edge server as shown in the previous scenario.

SfB user hosts a SfB meeting and VTC user gateways into SfB meeting (on-prem Pexip integration)

One scenario that avoids the RDP presentation issue is to host a SfB meeting instead.

A SfB user starts a meeting which is hosted on the FEP they are homed on.
When a VTC user calls (gateways) into the SfB meeting, Pexip forwards all media and signaling to the Front End. If a VTC user sends a presentation, media is directed via the Front End to all other participants within the Skype for Business meeting, including the traveling users.
All SfB participants (including traveling users) have their signaling and media — including RDP presentations — routed to the Front End, and on to any VTC users.

Note that if there are multiple VTC users that are gatewayed into the same SfB meeting, media between those VTC users is hairpinned via the Front End.

Traveling SfB user calls into a Pexip VMR (public DMZ pexip integration)

Another way to avoid the RDP presentation issue is to set up the SfB integration as per the public DMZ instructions.

When a traveling user calls into a Pexip VMR, signaling goes via their SfB Edge to their Front End Pool. A Front End server will then forward the request back to the Edge, which will then perform a DNS lookup of the _sipfederationtls._tcp SRV record to discover the Pexip node and send the signaling towards the Pexip node in the DMZ.
Media to the traveling user would likely be sent from the Pexip DMZ node to the traveling user's NATted Server Reflexive address candidate (as shown in the diagram below), but could also be directed to the SfB Edge’s external A/V interface.
A Pexip backplane sends the media between the enterprise and DMZ Pexip nodes.