Fresh on the heels of the recent Microsoft broadcast entitled Video Interop in the Cloud have come a number of questions from the overall community looking for further clarification on exactly what all this means. The summaries below also include various details from today’s announcements from Microsoft and some of their device partners at the Ignite 2016 event in Atlanta. Interoperability is a term which can been used in a few different ways throughout the industry, but the articles here attempt to separate the overall term between ‘native’ integration provided directly within a client or endpoint versus ‘interoperability’ which can be provided indirectly between systems by way of an intermediary component.
The concepts outlined here may look familiar as much of what was covered in this previous article has been applicable to on-premises Skype for Business Server (SfB) deployments for some time. The main differences since then are that the overall solutions have become more streamlined and feature-rich in the few years that have passed while knowledge of the back-end infrastructure is deemed less important as more of these components are moving into cloud-provided models.
The intent of this article is to clearly explain a few of the concepts and delivery models surrounding a topic of continuously growing interest: bringing traditional video teleconferencing (VTC) solutions into Skype for Business meetings. Note that in the past most of the interoperability requests were described more often as “bringing together standard conferencing and desktop conferencing systems.” More recently that need is specifically about getting the traditional solutions to play along in the Microsoft UC workflow.
The tide that seems to driving this is the ubiquitous usage and understanding of a very common workflow based on using Outlook to schedule a Skype for Business meeting. This familiar behavior was the figurative linchpin in the literal redevelopment of interoperability solutions like Polycom RealConnect back in 2014, later followed by other products like Pexip Infinity or Acano Dual Homed Conferencing (now part of Cisco Meeting Server) which began to use similar architectures pioneered by Polycom.
Video Conferencing can generically refer to the simple act of turning on the embedded video camera on a laptop or mobile phone while participating in a Skype for Business meeting, or walking into a traditional corporate conferencing room and expecting to join the same meeting using some level of in-room equipment providing a higher-end video experience. Practically it should refer to any and all scenarios in between these. The goal is to get away from disparate workflow that ultimately may limit end-users by forcing them to select from one of several different ways to collaborate, none of which may address all of their needs individually and also not be able to operate in conjunction. Thanks to the pervasiveness of readily available tools like Skype this demand is common-place and almost expected of by many information workers today.
In the present stage getting to this single holistic solution is a reality, and in more ways than one. The two available approaches can be leveraged independently or in conjunction, depending on the current state of an environment or the desired outcome.
The Interoperability route has several options and allows for the continued use of, or rekindled interest in, traditional standards-based video conferencing solutions available by a number of manufacturers. The Native approach is best suited for greenfield deployments or environments looking to refresh aging equipment that may be beyond its useful life. And of course a combination of both approaches can be used to leverage some of what may be in place today as well as start the journey towards replacing other solutions with compatible systems which can end up getting to a place where interoperability may no longer even be needed.
The simplest, yet often most expensive solution is typically to just go back to the drawing board. Scrap whatever what may have been shortsightedly tossed together or improperly designed and then inherited. Whether it is broken, perfectly functional, adequate but unpopular, out of warranty, disjointed, or in the event of equipping new office spaces there are many reasons to look at starting fresh to coincide with an established or emerging Skype for Business deployment.
End-users enabled in Office 365 will immediately have a range of conferencing options available to them across personal and corporate-owned devices. With the wide array of Android, iOS, and Windows clients available on mobile phones, tablets, Surfaces, laptops, and desktop computers any of these can be used to create or join either scheduled or instant, ad-hoc meetings and provide the ability to share their own video as well as see one or more active video streams from other participants.
So how does one bring this comfortable experience into the traditional conference room space now? On paper the easiest approach is to add or replace equipment in the room that uses the preferred solution and workflow. Something that natively and securely registers to the Skype for Business platform, can access Exchange mailbox information to retrieve meeting invitations, and uses the same protocols and codecs to communicate with Skype for Business clients and servers.
There are basically three device categories which addresses this approach: Optimized, Compatible, and Unsupported. Microsoft maintains a list of currently available partner solutions the Skype for Business Solutions Catalog.
The most obvious category includes systems that run on software that Microsoft has created. This includes solutions completely owned by Microsoft from development to sale, like the newer Surface Hub products. This also includes co-developed products where Microsoft owns the software while one or more of their technology partners develop and build hardware devices to run this software.
The original Lync Room System (LRS) products fall into this category as while Microsoft developed and maintains the core Windows Embedded software manufacturers like Crestron and SMART have developed the overall hardware packages, basically building appliances to run the Microsoft-provided software.
The native Lync and Skype for Business capabilities offered by these systems are inherent due to the fact they typically run some flavor of an embedded Windows operating system along with the actual Lync or Skype for Business desktop clients installed. The design and user interface can often obfuscate this fact but rest assured that the base Microsoft code is included in these software packages in some fashion. The goal is to provide the core functionality offered by using the native Microsoft software but in a less-personalized package that is well-suited for use in common areas like conference rooms.
Other well-known examples of these types of solutions are the popular Lync Phone Edition desk phones originally built by various partners like Aastra (now owned by Mitel), LG-Nortel, Snom (built for and sold by HP) and Polycom. It is worth pointing out that Microsoft has been moving away from the optimized model for IP phones for some time, relying on solutions in the next category to provide the next generation of IP telephony desk sets and conference phones. Note that by now those compatible phones have eclipsed the original optimized phones in terms of telephony capabilities.
An important distinction covering products in this category is that because they are true Microsoft software clients then they only work with the Microsoft platforms. A Lync Room System on its own cannot directly communicate with a standards-based H.323 or SIP platform, or the Lync Phone Edition device cannot register to a Cisco Call Manager environment. These are purpose-built solutions which require access to Lync Server, Skype for Business Server, Exchange Server, etc.
Other offerings are the upcoming room systems designed under the Project Rigel program which were announced at Enterprise Connect earlier this year. Microsoft just announced today at Microsoft Ignite 2016 that these products will officially be named Skype Room Systems, joining products like the previous Lync Room System (which is also referred to as Skype Room System) and Surface Hub products. This new Skype Room System platform will be running Microsoft-developed software on a Surface Pro 4 bundled with a purpose-built dock offered by the existing program partners of Crestron, Logitech and Polycom. The dock provides USB connectivity to certain qualified video and audio conferencing products already available today from these manufacturers, with more solutions to be brought into the fold later. The user interface created by Microsoft will be identical across the various vendors with the actual camera and microphone devices being the main differentiation between the various systems.
Microsoft will cover more details on these new Skype Room System solutions in their upcoming Ignite session Dive into Project Rigel and the Skype for Business Meeting Device Portfolio. Pre-production models of these will also be on display in the Ignite partner expo this week, like the Polycom MSR series.
‘Compatible’ is the term that Microsoft reserves for third-party products which undergo an official qualification process, hence these also being loosely referred to as ‘qualified’ or ‘certified’ solutions as well. In practice all of these terms are often used interchangeably but the critical identifier in this category is that these are solutions developed entirely by the partner, hardware and software, and are officially supported by both the manufacturer and Microsoft upon successful completion of a defined qualification process. This program can also sometimes be seen referred to as 3PIP, or Third Party Interoperability Program.
This can be a difficult category to understand based on the various terminology that in reality is not even used consistently throughout Microsoft’s own documentation. Even browsing between different categories in the device catalog like Meeting Peripherals versus Meeting Room Systems will display ‘Certified’ on one, yet ‘Compatible’ on the other. Improved clarity across these various programs and catalogs would no doubt be welcomed by all.
An example of a product in this category is the RealPresence Trio 8800 conference phone, which is designed and built entirely by Polycom. While the actual Microsoft Lync or Skype for Business client software is not included in these devices they do support an array of Microsoft protocols and codecs, providing the features and capabilities needed to pass the qualification requirements. This simply means that the manufacturers include native support for things like server auto-discovery, secure SIP registration, presence advertisement, voice calling features, video codecs like X-H264UC, and more.
Whereas the optimized solutions will only work with Microsoft UC platforms many of the devices in this category are not limited in that way. These products often support many different call control platforms, although not always concurrently. So the same device could register to Skype for Business or could register to a Cisco VCS or Call Manager platform, or possibly even both at the same time. The supported alternative platforms and capabilities will vary based on the products used but this flexibility can open the door for using a combination of approaches covered in this article.
Take the Polycom Group Series endpoints for example. This solution’s unique design allows it to communicate with concurrent disparate platforms by leveraging the SIP configuration to register to a Lync/SfB server while also using the H.323 configuration to participate in calls with other systems outside of the Microsoft UC platforms. The previous generation HDX products also supported this same dual registration model with Lync Server.
Furthermore there are modular solutions available today, like the Trio 8800, which are qualified in a specific configuration but not currently in others. To clarify the Trio is qualified for SfB as stand-alone audio conference phone but not when paired with a Visual+ module to provide connections to a display and camera. Then audio scenarios are still covered within the qualified realm but video conferencing and content sharing features fall into the remaining “supported but not certified” category.
The category is more of a catch-all then a specifically defined set of products. Basically anything not qualified or supported by Microsoft falls in here. This could include a product that the manufacturer performs extensive internal testing and officially supports it themselves with Lync or Skype for Business environments, yet Microsoft does not directly support or may even acknowledge the existence of. This could include products that barely function with Skype for Business and are not even supported by their own vendor. Generally these types are not recommended as the interoperability can come as a result of reverse-engineering processes as opposed to working directly through the Microsoft partner programs.
A number of different scenarios were covered in the previous article focused primarily with on-premises conferencing deployments but at this stage the clear favorite among users and administrators alike has been the cascading topology that allows the SfB platform to drive nearly every part of the meeting lifecycle yet still allow for typically incompatible room systems to join in. A meeting is scheduled, managed, and hosted using routine SfB tasks and all SfB clients are still connecting to their native environment for this experience.
This cascading experience was first developed by Polycom for use with Lync Server 2013 deployments and has since been adopted to the Skype for Business Server platform, with other vendors following suit and largely moving away from the legacy model of dialing directly into a Virtual Meeting Room (VMR) where the Microsoft UC clients would place calls directly into the standards-based bridges and not their own Lync/SfB meeting bridge.
Office 365 Offering
The Polycom RealConnect solution has been becoming more cloud-focused and this culminates with the addition of cloud video interoperability services directly in Office 365. The Skype for Business product team’s recent broadcast meeting on this topic provided further details as to what this service is intended to be. Basically this offering will be the Polycom RealConnect solution running inside of Office 365 and tied directly to the Skype for Business Online environment. Gone will be any requirements to host on-premises components to leverage this basic capability. Existing SfB Online users will continue to schedule meetings as they have done and the plethora of available standards-based conferencing systems can also join these same meetings. While the term “standards-based” can sometimes be a gray area the functionality is available for nearly every type of common video conferencing solution from manufacturers like Cisco/Tandberg, Polycom, and LifeSize.
For those keeping a keen eye on the space this solution was also announced during Microsoft’s Enterprise Connect keynote this year. It has since been referred to by various unofficial names including “Project Aqua”. Another announcement from today is the official name for this offering as “Polycom RealConnect Service for Office 365.” The public Skype for Business Preview program for this service will be made available later this year for select existing Office 365 tenants based in the U.S. Next year will see the service rolled out to globally in a similar manner as other Office 365 features have been in the past.
But what about the native Video Interoperability Service (VIS) that was provided in Skype for Business Server 2015? Why has Microsoft not simply leveraged software that is already in the sever platform today? While the VIS role is still available for on-premises server deployments it has not received any further development since the original RTM version of the server platform. VIS does not currently provide near the features or level of security that purpose-built third party solutions can offer today when integrating with SfB. By leveraging an existing complete solution rooted in the standards-based world that interoperability is desired with then a huge leap forward can be taken, yet still protecting the SfB user experience.
Because this embedded Office 365 service is not yet available to the general public then what about addressing immediate needs? The popular SfB interoperability solutions offer some level of capabilities today but the main limitation is these have not yet supported the preferred cascading topology with Office 365 users. Regardless of where the third-party software is deployed (on-premises or in a cloud service) they have not been able to allow SfB Online users to schedule normal meeting that any room system can join. Only the legacy VMR approach has worked with SfB user accounts which are homed in Office 365, meaning that those users must place a peer SIP call to something like “email@example.com” which terminates on the third-party Multiparty Control Unit (MCU).
The desired MCU cascading methodology has so far been limited mostly to on-premises Lync and Skype for Business server deployments, but Polycom RealConnect has also introduced support for Hybrid or Federated SfB scenarios. By utilizing SIP connectivity provided by on-premises Skype for Business servers (which no longer actually host any user accounts) the cascading meeting interoperability workflow can be provided to Skype for Business Online user accounts.
Understand that the upcoming Office 365 service discussed above is not simply taking a third-party infrastructure and hosting it into Microsoft Azure. The clear benefit of the upcoming native cloud interoperability service is allowing the ‘better together’ workflow which keeps the call control and majority of the moving pieces within the SfB platform by allowing for the cascading model to be used. Also, just as with best practices common with device selection, make sure to reference the Skype for Business Catalog to consider officially supported infrastructure solutions available from active Microsoft partners.
Basically the landscape is set to leverage several years worth of the RealConnect cascading workflow and experience for environments moving from on-premises SfB footprints, to hybrid, and eventually into Office 365 primarily.
Some of Both
The obvious question to come from all of this information is which approach to use: Native, Interoperability, or both? This can best be answered by understanding the current strengths or any existing limitations in each and weighing them against what is needed in the environment. Each can offer different experiences based on whether granularity of features or a focus on simplicity is more important.
When a video conferencing system is acting solely as a standards-based system, either by limitation (when it cannot register to SfB) or by choice (when available SfB registration capabilities are intently not enabled) then the interoperability model alone is used. Traditional VTCs fall into two types: those which support calendaring and those which do not. Many of the present-day VTCs from Polycom and Cisco support connecting to Exchange Server mailboxes to retrieve and display scheduling meeting information created by Outlook. When these invitations also include Skype for Business meeting details then these systems can provide a simple click-to-join experience whether driven by a remote control, touch panel, or even touchscreen displays.
The older systems which do not support calendaring are limited to continuing the legacy experience of dialing number strings to join any meetings. Yet this action can now end up in a Skype for Business Meeting instead of being locked into meetings that only the other similar VTCs can participate in.
Another important use-case when considering between the two options is whether meetings will need to allow external parties like partners or customer the ability to join from their own standards-based video systems. When looking at the native approach by deploying and/or upgrading all corporate conference rooms having an additional interoperability may seem unnecessary. But what about outside participants in room systems that are not equipped to handle native SfB communications? Leveraging an interoperability solution allows for this when desired by incorporating a perimeter network solution akin to the Edge Server that handles the communications protocols used by traditional VTCs.
Overall a fair amount of concepts and direction is included here yet without getting into the weeds on different products and their capabilities. It is important to spend some time investigating specific offerings to understand that there is not always a one-size-fits-all solution. The nuisances of each approach can either be ideal or cumbersome, depending on the desired outcome and overall flexibility to move away from workflows that are not working today and eagerness to adopt new and improved ways of doing old things.
Consider this post as an open forum to ask any questions via the comments section on this specific topic or if clarification is required on individual capabilities of any of the solutions or platforms covered above.