The Pexip Infinity Distributed Gateway Feature
A white paper by Håkon Dahle, CTO, Pexip
April 3, 2014

Introduction

Video conferencing is a highly useful tool for business communications. Enterprises have been using H.323 and SIP-based room and group systems for visual communications for over a decade. These systems have traditionally been complex to use and expensive to purchase. Lately we have seen that many enterprises are adopting new software-based technologies such as Microsoft® Lync® and WebRTC in order to provide all employees with access to video communications. These enterprises now face the challenge of making their existing video conferencing systems work seamlessly with these new software clients. There are two main use cases that need to be addressed:

  • A multi-party conference, where any number of people meet on video in a scheduled or ad-hoc virtual meeting room. 
  • A simple point-to-point call, where one user calls the number or address of another user.

Pexip Infinity is a software-based, scalable meeting platform for voice, video and data. Its two main features are distributed multi-party conferences and distributed gateway calls. This architecture is unique in the industry as it is the only distributed architecture that is widely interoperable with business video conferencing endpoints, with all versions of Microsoft Lync, as well as with new technologies such as WebRTC. 

This white paper discusses the distributed gateway feature of the Pexip Infinity Scalable Meeting Platform.

Why do we even have gateways?

In videoconferencing, gateways are used to transcode media (i.e. convert from one format of compressed voice/video to another format) so that devices that do not have any common media formats can communicate. The following are just some examples of use cases where gateways are required:

  • Calling between Lync2010 and standard H.323 or SIP endpoints
    • Lync2010 requires the use of Microsoft RTVideo for high definition video. Most H.323 videoconferencing systems do not use this codec.
    • Lync2010 can use an older technology, H.263, for low resolution video. This is supported by virtually all H.323 systems, but will result in a fuzzy image and an unsatisfactory user experience.
    • Lync2010 and Lync2013 use RDP (Remote Desktop Protocol) for screen sharing, a protocol which is not supported by H.323 or SIP videoconferencing systems. Without a transcoding gateway, screen sharing becomes impossible.
  • Calling between Lync2013 and standard H.323 and SIP endpoints
    • Lync2013 requires the use of either RTVideo or H.264SVC for high definition video.
    • Lync2013 does not support the older H.263 codec at all.
    • Calling from a browser-based WebRTC client to an H.323 or SIP endpoint
    • Google Chrome and Mozilla Firefox currently only support the VP8 video codec. Hardly any H.323 or SIP videoconferencing systems support this codec.
  • Calling from a browser-based WebRTC client to a Microsoft Lync client
    • Again, WebRTC uses VP8 which is not supported at all by any Lync client.

Clearly, gateways are required in most heterogeneous deployments, where there exist a variety of systems from different vendors. In particular, a mix of Lync and traditional H.323/SIP videoconferencing endpoints will always require a gateway. 

What is the problem with traditional hardware gateways?

Up until now, devices that provide gateway services between Lync and H.323/SIP video systems were delivered as hardware appliances. These devices were complex, and tended to be very expensive. Due to the high cost, typically a limited number of gateways would be installed in a single location – often the main data center. Until recently, this was an acceptable approach since the number of users was often limited.


Figure 1: Single gateway deployed in single location

Figure 1 shows an enterprise with headquarters in New York and a remote office in Singapore. The company has an H.323 room system in New York, and an H.323 desktop system in Singapore. All employees are Lync users.  Sometimes a Lync user in New York will want to dial into the room system in New York. In order to provide HD video quality, this call will be routed through the hardware gateway in the New York office. The result is an acceptable user experience (although some users will complain about hardware gateways not supporting Lync desktop sharing).

Consider what happens if a Lync user in Singapore wants to call the H.323 desktop system in the Singapore office. This call must also be routed through the gateway. However, with just a single gateway in one location, some key disadvantages become apparent:

  • Media is routed from Singapore to New York and back, adding about 200ms latency. This will result in a reduced user experience. Long latency makes a natural conversation flow difficult, resulting in interruptions, people talking simultaneously and so on.
  • Instead of keeping all media traffic inside the local office (Singapore), media has to be sent out over either the WAN (wide area network) which may be costly, or over the internet where quality of service is not guaranteed. The result is either increased cost (the WAN may have to be upgraded) or decreased user satisfaction due to limited bandwidth resulting in packet loss and poor video quality.

The conclusion is that for organizations that have employees in more than one location, a centralized deployment model has significant drawbacks. 

How a distributed gateway deployment is a better approach

The solution to the problems associated with the traditional centralized gateway is a software-based distributed gateway. This allows for a very cost efficient deployment of gateway resources in all required regions. The result is improved user experience because of reduced latency – with a local gateway resource in each region, there is no longer a need to hairpin media back to a centralized datacenter. The other obvious benefit is reduced WAN bandwidth usage – again due to not having to hairpin media. Reduced bandwidth usage will allow an enterprise to deploy more video systems without having to upgrade the WAN infrastructure, keeping costs low.

Figure 2: Simple distributed gateway deployment

In our example with the enterprise with headquarters in New York and a remote office in Singapore, Figure 2 now shows a distributed gateway deployment. A local gateway resource has been deployed on a spare server in the Singapore office, transcoding all calls between Lync clients and the H.323/SIP videoconferencing systems locally. Gateway calls no longer have to be routed back to the New York datacenter. The users in Singapore benefit greatly from this approach.

Not just a Lync-to-H.323/SIP gateway

The distributed gateway allows for a number of additional use cases. The example above showed interworking between Lync2010/2013 and traditional H.323/SIP video systems. Another new software-based technology is WebRTC which enables browser-based videoconferencing. The promise of WebRTC is quite exciting – simply use a browser for voice and video calling, without the complexity of additional downloads, plugins or account creation. However there is a challenge with WebRTC: existing WebRTC implementations use media codecs not supported by Lync, H.323 or SIP video systems. Hence calling between these different technologies becomes a problem.

A gateway is needed to interwork these calls.


Figure 3: WebRTC to H.323 and WebRTC to Lync interworking

In the figure above, one WebRTC user is calling into the H.323 room system in New York, and another WebRTC user is calling a Lync user in Singapore. In the first case, the gateway transcodes video (VP8) and audio (Opus) from the WebRTC client into a format acceptable to the H.323 room system (e.g. H.264 and G.722.1C). In the second case, the gateway transcodes video and audio from WebRTC into formats acceptable to the Lync client (which could be either RTVideo or H.264SVC for video, and G.722 for audio).

Again we see the benefit of the distributed gateway. Using technologies such as GeoDNS, the gateway located closest to the WebRTC user is selected. This helps in optimizing the media routing, which in turn ensures the best possible user experience.

Deploying a distributed gateway

Pexip Infinity runs as multiple virtual machines (VMs) on top of a bare metal hypervisor such as VMware® ESXi® or Microsoft Hyper-V®. Any off-the-shelf Intel-based server can be used, as long as it satisfies some basic CPU and memory requirements.

Pexip Infinity consists of two different VMs:

  1. The Management Node. A Pexip Infinity deployment, regardless of size, will have just one Management Node. When first installing Infinity, the administrator downloads an OVA file. After installing this onto the hypervisor, this VM becomes the Management Node. The purpose of the Management Node is to create and manage Conferencing Nodes. The Management Node is in neither the signaling nor the media path.
  2. The Conferencing Nodes. A minimal Pexip Infinity deployment will have one Management Node and one Conferencing Node. A distributed deployment will have two or more Conferencing Nodes. The Conferencing Nodes are responsible for both gateway calls and multi-party conferences.

Scaling up, scaling out

After logging in to the Management Node, the administrator can create any number of Conferencing Nodes in one or more locations. Regardless of how many Conferencing Nodes are created, there is a unique benefit in managing everything from a single Management Node: All gateway routing rules are pushed out from the Management Node to all the Conferencing Nodes; diagnostics data and event information is sent from the Conferencing Nodes back to the Management Node. There is never a need for the administrator to manage a Conferencing Node directly – all the aspects of the distributed gateway service are managed from a single portal. This centralized management ensures that the entire deployment is configured with a consistent data set – the entire deployment acts as a single application.

Scaling up

An administrator can easily scale a deployment up by creating several Conferencing Nodes in the same location (i.e. the same data center). Capacity can even be added “on the fly” – Conferencing Nodes can be added in a couple of minutes if more capacity is needed.

Scaling out

A typical Pexip Infinity deployment will consist of two or more locations. If a customer has three main offices such as New York, London and Tokyo, and a concentration of users in those locations, it will make sense to deploy Conferencing Nodes in all three locations. There is no inherent limit on the number of locations in a Pexip Infinity deployment. When additional locations need to be added, this can be done “on the fly” while the system is operating, with no impact on service availability.

Configuring a distributed gateway

The Pexip Distributed Gateway feature is configured as a series of Gateway Routing Rules which specify which calls should be interworked and to where. 
Options for each rule include:

Source of the call

  • Whether the rule applies to incoming H.323, SIP, WebRTC or Lync calls (more than one, or all, can be selected for a single rule)
  • Whether the rule applies to calls coming from a specified single location, or from all location

Destination of the call

  • Which calls should be interworked
    • Using regular expressions to match the dialed alias provides flexibility to apply the rule to a single alias, or all aliases in a domain, or those consisting of numbers only, or letters only - as just a few examples
  • Optionally, whether the dialed alias should be modified
  • The relative priority of the rule
  • Whether the call will be interworked to H.323, SIP or Lync
  • Whether the call will be placed via a specific H.323 gatekeeper, SIP Proxy, Lync server or alternatively whether DNS will be used to locate the alias.
  • What TURN server to use (if any) with this rule.

Conclusions

As enterprises start using a mix of different video endpoints, there is a need to make sure that an end user can place a call to anybody else without having to make sure the person they are calling has a compatible video conferencing device.
In particular, with the number of Microsoft Lync users increasing, it must be possible for Lync users to dial an H.323 or SIP videoconferencing room system directly.
The Pexip Infinity Distributed Gateway feature is unique in that it:

  • Allows for true ad-hoc video calling between different types of endpoints such as Microsoft Lync 2010, Lync 2013, WebRTC, H.323 video endpoints and SIP video endpoints.
  • Provides the best possible user experience by transcoding in real time different media codecs such as Microsoft RTVideo, H.263, H.264, H.264SVC, VP8 and RDP.
  • Provides not just HD video and wideband audio, but also allows for two-way screen sharing, by transcoding between SIP-BFCP, H.323-H.239, RDP and VP8.

Pexip Infinity’s distributed architecture underpins the gateway feature. By leveraging software and virtualization, a Pexip Infinity Conferencing Node can be deployed anywhere across the globe in minutes, ensuring that gateway resources can be deployed inexpensively where needed, improving user experience by reducing latency. This is a huge step forward from the old model of deploying a limited number of expensive hardware gateways in a centralized location.