Video meetings guest access: the new frontier of interoperability

There are different ways to deal with interoperability. With WebRTC, the one selected is relying on the browser and offer guest access. Interestingly, while the industry is headed in that direction, the elephants are also headed… elsewhere.

When I first started with this blog, over 7 years ago, I wasn’t really sure where I was headed with it. What I did know, is that I have to write something about WebRTC to get it off my chest. WebRTC was the reason I stopped working at RADVISION and moved on. You see, as a CTO of my business unit I was told there’s no budget to invest in researching what we can do with WebRTC. Somehow, the future wasn’t important enough, which got me to understand there’s no future for a CTO there either.

I ended up deciding to write three posts – what is WebRTC, why signaling is irrelevant, and what a future meeting room would look like.

That third article? Here it is, from March 2012: The Post-WebRTC Video Conferencing Room System

We’re still slowly crawling towards that goal.

A short history lesson: the early days

For many years video meetings were an in-company luxury. A dubious luxury at that.

All Most video conferencing systems were based on a signaling protocol called H.323 and were *supposed* to be “interoperable”. This didn’t work that well, and in the end, companies tended to purchase all of their hardware from a single vendor. Multi Vendor was possible, but always at a loss of features or capabilities – either because these were proprietary to begin with or because interoperability is such an elusive target.

What was a person to do when he needed to communicate with someone *outside* the company? Dial his phone number. If video was what was needed, then the IT department had to be involved – on both sides. Fooling around with dialing plans, checking that the video conferencing devices interoperate, and then hand holding the users throughout that session. This happened not only in regular companies but also when the companies in question were video conferencing vendors.

Most systems at this point were hardware based. You had to purchase “meeting rooms” and install them.

The system was totally broken.

Rise of the federation

At some point a new concept started cropping up. If I recall correctly, Microsoft came with it, in their Microsoft Lync service. The idea was create federations.

Microsoft Lync was a semi-standards based service. It was SIP based in nature, but different – connecting to it was harder than connecting to other SIP devices and services as a lot of the spec was proprietary. Being Microsoft, they had a largish software-based market share, but one that was left unconnected.

Each company installed, operated and managed its own Microsoft Lync service. You couldn’t just reach out to another user on another installation directly. What you could do is involve the IT people (on both ends – yes), and get them to configure both installations to be aware of one another. This was referred to as a federation.

Think about it.

Thousands and thousands of installations. Each an island of its own. Each time you wanted to reach out to someone from a new island, you had to ask permission and get it setup – to federate with that other island of install base.

And guess what? This never really worked either. Not in real life. And not even for the video conferencing vendors themselves.

The friction was just too high to make this useful for the workforce.

Introducing the software client

Until a couple of years ago, video conferencing was a thing for hardware devices.

20 years ago? These devices were mostly built around DSPs and weird embedded operating systems.

15-20 years ago? The vendors learned about Linux and were comfortable enough to use it (!) for an embedded application such as video conferencing. The main concern was usually the real time nature necessary in encoding and decoding video.

About 15 years ago, the notion of being able to use a software client on a Windows operating system to join a video conference (not conduct a meeting – just join one) started to crop up.

The idea was this:

• If your company had a video conferencing installation, it could theoretically get a PC to connect to the video conferencing system at lower media quality and still be able to communicate properly
• Towards that goal, one could install a video conferencing software client and use it

This brought with it the headaches of having to deal with unmanaged networks – having employees (mainly managers) connect from their home, coffee shops or the occasional crappy hotel network.

This new capability started changing the business model around video conferencing. How do you license the software in a world where what was sold was hardware through channels and VARs?

What it also did was change behavior patterns. People now didn’t go to meeting rooms to join a call – they joined from wherever they wanted. Once the video client was installed in their PC they were relatively free.

It had another use case to it: technically, you could get someone to connect as a guest to a meeting. All he needed to do was install the specific software client of the specific video conferencing vendor from the specific landing page of the specific enterprise who purchased the video conferencing system and connect.

If you conducted a meeting with a company who had an installation of a specific vendor, then meeting with another company using the same video vendor usually meant you didn’t have to install the client again – unless it needed an upgrade of sorts.

Since these were early days, there were many installation issues with these clients. When it worked it was great, but when it doesn’t…

Enter the cloud

At around the same point in time, cloud services started taking potshots at the video conferencing industry. They didn’t call it video conferencing but rather web conferencing. Why? Because the center of the service wasn’t an on premise hardware video system installation, but rather a software based cloud service.

It wasn’t as performant and the quality was lower, but it was easier to use. Sadly, video conferencing companies didn’t see it as an existential threat.

Anyway, these services assumed that all users download and install a software client to connect to these web conferences.

Since this was their bread and butter, the idea of having guests connect became more prevalent and acceptable.

At any given point in time, I had on my laptop at least 3 such software clients. Services like WebEx, GoToMeeting and AT&T Connect.

Two challenge these services faced:

1. The concept was around “a company licenses a communicate tool to use internally but allows guest to participate”. This still wasn’t about the guests
2. That software install is still friction, and something no one really wanted to experience (besides maybe the vendor behind that software client)

Zoom

Out of these two challenges, Zoom came and solved the first one. For the most part, the first experience of a user with Zoom is by being invited to a Zoom meeting. By someone. Not necessarily an employee in a company who licensed Zoom – just by someone.

The change in business model, as well as the focus on the first time experience (making it simple), got Zoom to where it is today.

The problem that remained though is the software installation piece. That’s friction, and the browser-based solution that Zoom is offering is still subpar to what can be done on a browser and shows the Zoom vulnerability.

The WebRTC guest access

In the past 5 years, what we’ve seen is that every video conferencing vendor except for Zoom has made it towards WebRTC.

Vendors still offer software clients for ongoing use of their service and for providing an improved experience, but all of them also have WebRTC access as well.

Need to have someone join a session? Create a calendar invite and get a meeting link. That link will allow you to either install a software client or just use the browser with WebRTC.

This has become the norm to the point that in many cases, I get invited to meetings just by receiving a URL on one messaging service or another.

Just in the last year we;ve seen UCaaS vendors joining this game by offering their own video conferencing services, usually called Meetings:

• 8×8
• Vonage

The race towards having video bolted on top of voice meetings and web conferences now relies on WebRTC support and guest access as key features.

The nice thing about this? There’s no need to interoperate, federate or connect the islands of services. Need someone to join a meeting? Just send them a link. They won’t need to install anything, just click and be connected. Magic.

Today – almost all services offer simple to use guest access via the browser using WebRTC.

Room systems “interoperability” in 2020

This all leads to this interesting announcement by Microsoft and Cisco. In two carefully crafted posts/announcements, the two companies appear to be collaborating more than ever. The plan?

Offer direct guest access for a room system of one vendor to meetings of the other vendor.

What does that mean? If you are invited to a Microsoft Teams session as a guest, you should be able to join it from a Cisco WebEx Room device. And vice versa.

This is no federation here – just pure use of an existing room system to join “any” meeting.

From Cisco’s announcement:

Cisco and Microsoft are working together on a new approach that enables a direct guest join capability from one another’s video conferencing device to their respective meeting service web app (WebRTC based).

From Microsoft’s announcement:

Cisco and Microsoft are working together on a new approach that enables meeting room devices to connect to meeting services from other vendors via embedded web technologies. Microsoft and Cisco will be enabling a direct guest join capability from their respective video conferencing device to the web app for the video meeting service.

A few interesting initial thoughts:

• This is provided not by interoperability of signaling protocols (my SIP can talk to your SIP, how about we federate?) but rather by making use of “web technologies” in Microsoft’s announcements, or simply using “WebRTC based” web app on Cisco’s announcement
• It will not work on older meeting rooms and legacy devices. This isn’t about interoperability. It is about the web
• Both Microsoft and Cisco rely here on WebRTC and web technologies. Their new devices use WebRTC internally and browser tech. They can now expose it by connecting using guest URLs
• Both companies are taking the first initial step of supporting a single type of guest access of a single other vendor. This is a controlled environment for them, and probably just a first step towards opening up the devices to “any” WebRTC based guest access

It is about time we got there.