Video meetings guest access: the new frontier of interoperability

12/11/2019

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.

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.

Responses

Stuart says:
November 12, 2019

Great summary Tsahi! Hard to believe it’s been 7+ years that WebRTC has been an available alternative. I wouldn’t exactly say CSCO and MSFT are “racing” towards supporting it.

A couple of things I have observed. Zoom has really “normalized” video meetings for the masses. That is a good thing! It used to be that only big corporations and associated meeting participants used video. With Zoom as an option, people have 1-1 meetings with their accountants, therapists, and other professionals. Small biz uses it to interview candidates before bringing them in for face to face sessions. Normalizing video as a medium will help drive demand and hopefully that will help speed WebRTC adoption at some level.

Second, Apple, the Iphone and Facetime have also made video a mainstream service but that have also delayed its maturity by locking the service into their hardware/software ecosystem. The glacierly slow adoption of WebRTC in Safari has really held back mobile adoption. Zoom was smart to capitalize on this by offering a fairly seamless experience between desktop/room and mobile devices (albeit it client based).

Reply
    Tsahi Levent-Levi says:
    November 12, 2019

    Thanks for the insights Stuart!

    While I agree with almost all of it, CSCO and MSFT have adopted WebRTC already. I’ve been in calls of both services in the last 2 years via guest access from Chrome browsers without any installs, and the new announcement is wrapped around the premise of WebRTC being both available and an important component of their room systems.

    Stay tuned for the Kranky Geek videos from Friday this week – there will be some interesting sessions there that touch how leading vendors are integrating WebRTC into devices and applications 🙂

    Reply
Silvia Pfeiffer says:
November 12, 2019

Do I understand correctly: are you saying that MS would offer a Cisco WebRTC url in their system as an alternative to a Skype url to join a meeting if the meeting is hosted on a Cisco system? Or does this mean a Skype url can join a Cisco meeting? In the latter case, surely they still need to integrate their signalling to set up the call.

Reply
Ham says:
November 13, 2019

Great Article Tsahi!

I’ve mainly lived in Zoom enviornments over the last few career stops and never had an issue with Zoom’s WebRTC experience (though limited in feature parity to its desktop).

Interestingly Zoom also was earlier than MS or Cisco on bridging non federated to third party systems (WebEx, BJ) although riding H. 323 not through a WebRTC realm, and I believe Zoom just recently commited a similar commit to non federated interop with Teams.

Thanks for the insight!

Cheers,
Ham

Reply
Philipp Hancke says:
November 13, 2019

Originally “federation” described the email-like world where all the stuff you describe wasn’t necessary. Sad that Microsoft took over the term…

Reply
Aswath Rao says:
November 20, 2019

As you point out guest access has been available for a while. I think the noteworthy item is that the downloaded call control JS can drive the other system’s UI.

Reply

Comment