Support Burden for Web Meetings, Video Conferencing Got You Down?

Even before COVID-19 upped the collaboration challenge ante, IT organizations probably found themselves spending more time than they wanted/expected to in support of video conferencing and web meetings. Among other things, IT has to distribute and update the unified communications or meeting clients for the conferencing services the company subscribes to. They also have to determine how much freedom to give users to download and install the clients required to join meetings via other services (such as when dealing with business partners and customers). These downloads, including updates to clients that may already be installed on end users’ PCs, often cause meetings to start late or without some attendees--and create lots of support calls. One way to reduce, if not completely eliminate, these headaches is to use entirely browser-based conferencing solutions based on WebRTC. 

Indeed, the issues with client-based video and web conferencing services extend beyond “just” the inconvenience of downloading a client. Users often have to wait for a client to load, and the applications themselves can behave badly. For example, some install unnecessary components, and some install the client so that it always loads at system startup. Security issues are not uncommon, nor are issues related to performance and bugs resulting in users losing work in open applications.

There are many conferencing applications that use WebRTC to transmit video and audio, as well as provide desktop sharing among participants, but do so through dedicated clients. In contrast, vendors such as OnePgr, Jitsi Meet and 8x8 offer services that work entirely within the browser. 

You should consider conferencing applications that work entirely within a web browser for a number of reasons. For example, they will work even when business partners have restricted/locked down desktop and mobile environments, they address many of the security concerns related to client-based systems, and they work in environments with a mix of Windows-based, MacOS-based and mobile devices.

With so much of the workforce now working remotely, all of this can help reduce the number of service desk calls related to web meetings and video conferencing.

WebRTC does have some issues, however. The biggest one to date has been browser support, particularly on mobile devices. But, even on the desktop, there can be differences in the user experience depending on the browser being used. This largely affects areas such as desktop sharing, with users having different experiences depending on whether they are using, for example, Google Chrome versus Safari. (Detailed information about browser support for WebRTC can be found on the “Can I use?” website.)

WebRTC needs a number of core components to deliver video conferencing and web meetings via the browser. These include browser APIs, SDP (Session Description Protocol), STUN (Session Traversal Utilities for NAT), TURN (Traversal Using Relays around NAT) and, optionally, MCUs (Multipoint Control Units).

The browser APIs provide access to video camera, speakers and microphone, as well as the necessary controls to allow users to grant or deny access to these devices. These APIs also handle desktop sharing via streaming video.

WebRTC inherently supports peer-to-peer connections, so users can quickly establish one-to-one or small video conferences. WebRTC establishes an end-to-end encrypted connection using DTLS (Datagram Transport Layer Security). SDP allows peers to exchange the signaling messages necessary to establish which codecs will be used. SDP is a core component of VoIP telephony and manages how one VoIP device communicates with another.

Of course, this works well when all the users in a video conference happen to be on the same network. STUN and TURN make it possible to connect users on different networks. For users who are connecting via routers, the STUN protocol can facilitate the process via a STUN server. When users have to traverse firewalls, a TURN server can be reached through its public IP address to manage user connections.

MCUs are optional because, as described earlier, WebRTC can deliver a video conference through peer-to-peer connections. But, this isn’t really practical because of the bandwidth required to send and receive multiple video streams to all participants. MCUs serve to reduce the number of connections each user has to make to send data. They just send the data once, and the media server distributes the data to the other participants. This breaks the end-to-end encryption of the peer connection because the media server has to decrypt the data to send it to the other participants. Currently, Jitsu is working on a way to ensure traffic is encrypted even when using a media server.

Stephan Thamm, one of the developers of the open source video conferencing application vorb.chat, has a more detailed explanation on gitconnected.com. His blog post also includes code samples that show how to call the APIs.