Deltapath's O365 Connector Brings More Options to Hybrid

I recently had the opportunity & privilege to have a long-distance face-to-face sit-down with Deltapath's Founder & CEO, David Liu, to discuss a newly launched product: Deltapath O365 Connector. This product intrigued me, specifically because it provided a creative solution to an issue that I have personally seen several clients try to tackle. In this blog post I will aim to provide a brief overview of some of the features of the Deltapath O365 Connector, and will then go into the specific use case that it solves for that caught my attention.

Deltapath O365 Connector Overview

At its most basic level, the O365 Connector is a physical device that sits in an organization's physical datacenter. It provides connectivity between an organization's Skype for Business Online users and it's on-premises PBX and PSTN services. You may wonder why that functionality is different than CCE or other native hybrid Skype for Business Server solutions, and I will get to that in a minute.

The O365 Connector has multiple roles all wrapped into a single device, including a Session Border Controller (SBC), firewall, SIP Proxy, Call Routing Engine, and even an Endpoint-Provisioning Server. This is a lot to pack into a product, and accordingly, the functions and features of this device go well beyond the specific use case that I want to cover today. For that reason, I will provide a link to the product page so that you can dive a bit deeper on your own, at your own leisure:

https://www.deltapath.com/products/deltapath-o365-connector

Beyond the device's capabilities, Deltapath provides three different versions of its device, allowing organizations of various sizes to get a device that more closely matches its specific needs. The following chart from Deltapath highlights each size of the device, along with corresponding specs:

There are also a number of additional Modules that can be obtained and used with these devices. Per Deltapath's marketing materials, these modules include:

• Call Conversation Recording
• Inbound Contact Center
• Outbound Contact Center
• Serviced Office
• Call Billing
• Alarm Notification & Escalation
• Building Management System Integration
• Acute Hospital Communication

The O365 Connector can also be launched in a pair, as a cluster, introducing an element of redundancy.

Lastly, this device can be provisioned and configured with a simple and easy-to-use web GUI interface, easing administration concerns of introducing another device into an already complex on-premises telephony infrastructure.

Again, this post will not be diving into all of these features or modules, but I wanted to call them out for those organizations that may want be looking for these features in addition to the use case that I will be highlighting below.

Enhanced Hybrid Use Case

Consider the following scenario: an organization has an existing on-premises telephony infrastructure, including a PBX and PSTN services, and also has Skype for Business Online users in Office 365 that are licensed with E1 or E3. This organization wants to allow these Skype for Business users to have PSTN calling capabilities, but does not want to upgrade to E5 or purchase Cloud PBX add-on licensing. The reasons for this could be as simple as compliance restrictions of some sort that requires them to keep their PBX functionality on-premises, or a number of other reasons. So, how do they provide these non-Cloud-PBX Skype for Business Online users with PSTN capabilities using their own on-premises PBX and PSTN services?

This is the problem that O365 Connector provides a solution for, presenting yet another way to explore Hybrid for organizations that may not be able to go down some of the other more mainstream paths at this time.

The way that this solution works is actually quite interesting. The O365 Connector device resides in a perimeter network architecture. If used as a firewall, a public IP can be assigned directly to one interface of the device, with the other interface able to communicate with the internal LAN. Otherwise, the device can be behind a firewall, with a public IP NAT translating to the device's external interface on a private network. A public DNS record (for example, ms.demodomain.com) will resolve to the associated public IP of the device, and Office 365 Federation will be configured with the 'ms.demodomain.com' FQDN.

The device can have certain SIP endpoints (like Polycom VVX phones) register directly to it, but for non-SIP devices, the device will communicate with another device, like a Cisco Call Manager or other PBX. When a user from either type of device dials a phone number, SIP address, or an extension of a Skype for Business Online user, the O365 Connector sends the call to the Skype for Business user (it can also do sim-ring if that user also has a non-SIP endpoint).

How does a Skype for Business user dial a phone number, then, since again, they are not Cloud PBX users? Well, the Skype for Business user dials a regularly dialed phone number, or an extension, in the format: '15551234567@ms.demodomain.com', or an extension as '5555@ms.demodomain.com'. This reaches out via federation to the O365 Connector device at 'ms.demodomain.com', and the device will then send the call to the appropriate destination. Example:

Image Courtesy of Deltapath

This may be a bit confusing to read through, so I will refer to this very handy graphic created by

Deltapath to illustrate the various forces at work here:

To help understand each step in a color-coded way, the below Deltapath graphic explains the call flows a bit better:

As you can see, this solution provides a very unique bridge for environments that need/desire to provide PSTN calling capabilities to their Skype for Business Online users, without moving any of their call-control functionality into Microsoft's cloud.

Clearly, there may be a challenge with the fact that dialing is not done via a dialpad by the Skype for Business users. Instead, they must be trained to place these calls by using an email-like format. This does present a learning curve that an organization will have to plan appropriately for. Obviously, this is a fact that will have to be weighed as part of the strategy and decision-making process; organizations will have to decide if the learning curve is acceptable in relation to the unique problem that the device solves for.

In Conclusion...

The focus of this blog post was on a specific use case that the Deltapath O365 Connector provides a unique solution for: Skype for Business Online users, without Cloud PBX functionality, that need PSTN dialing capabilities through their organization's on-premises telephony infrastructure. In this regard, the solution does indeed tell a compelling story. It also helps that the device can meet other needs within the same solution, including things like firewall capabilities and endpoint provisioning. You can get more information about the product at the link provided above, and should even be able to schedule some sort of demo with their team. It never hurts to investigate all your options when 3rd-party tools are needed to fully meet your requirements!