Device Availability

This category is as much about human factors as it is about technology and causes a significant number of real-time communication attempts to fail. You might assume that everyone would realize that a functioning webcam, microphone (unmuted), and audio output device (volume turned up) are essential to any successful video calling experience. You would be wrong. Users need to be made aware of the need to prepare properly for live video calls, just as they would for an in-person meeting, especially when they are planning to connect to a scheduled meeting with many other participants, where five minutes spent untangling headphone cords compounded by the number of other connections turns into a serious waste of valuable person-hours. Well-designed apps facilitate this process by leveraging the getUserMedia device enumeration capabilities to allow the user to select and test their microphone, speakers, and camera easily as part of the connection process.

Browser Capabilities and WebRTC Support

WebRTC is still only a Candidate Recommendation, and even when it is a standard, a browser will not need to implement the full range of possible features natively to be compliant. For example, screen-sharing capability is an optional part of the standard. The major browsers all differ in the range of WebRTC features that they support and the manner in which they do so. The "Is WebRTC ready yet?" website [5] gives an at-a-glance view of the current state of support across all major browsers. It also has a more detailed legacy view showing the state of various components within the different browsers (Figure 3). Although this particular view is out of date in one significant area (it doesn't reflect the fact that Safari 11 does have native support for WebRTC), it gives a good idea of what the different components all are and the quality of support in the different browsers.

Figure 3: Browser compatibility results example [5], not updated for Safari 11.

You will notice that Internet Explorer is completely absent from the table. WebRTC apps can be made to work in Internet Explorer by use of a plugin that implements a JavaScript polyfill. A couple of such plugins are available, the most common being the one from Temasys. The app includes Temasys's adapter.js script that prompts the user to download the plugin if the WebRTC APIs are not already present in the browser (Figure 4).

Figure 4: Plugin installation request for Internet Explorer.

All browsers require you to grant permission for camera and microphone access. The first time you attempt to access a WebRTC-enabled application, the browser will seek permission by means of a pop-up, which is the most obvious indication that the app is, in fact, a WebRTC app. Connection attempts commonly fail simply because many users are conditioned to ignore or cancel any sort of pop-up; if the website is not secured by a valid HTTPS certificate, Chrome will not even display the permissions dialog. Users should be aware that they do need to agree to pop-ups like those shown in Figures 5 and 6. The Firefox version allows you to select the specific camera and microphone, where a choice exists, so you should make sure to choose devices that actually work, as opposed to, say, the camera inside the closed lid of a docked laptop. I have personally witnessed the IT director for a global manufacturer abandon a WebRTC-based conference for this very reason.

Figure 5: Chrome device permissions dialog.

Figure 6: Firefox device permissions dialog.

Chrome requires you to install an extension for screen sharing (Firefox allows it natively), more for reasons of security than technology, because the extension can be implemented in about 10 lines of JavaScript. The extension needs to be packaged with the name of the website for which it is intended and that is explicitly listed in its manifest file.

The upshot of this is that users are best off using Chrome or Firefox for their WebRTC requirements, especially if they are required to share their screens (or application windows or browser tabs) during their call, and should be made aware that they need to allow all access/installation requests related to their session (Figure 7).

Figure 7: Chrome screen-share extension installation.

Setting Up a Signaling Channel

After access to suitable devices has been obtained, the call needs to be established, and creating the signaling channel is the first step. It must provide a path for full-duplex communication between both endpoints, but because no direct network connection yet exists between the two (ICE negotiation has not happened yet), it must be routed via an intermediary server. This server will often be the same server that is managing and delivering the app itself, and routing the signaling that way provides the additional benefit of that server being able to exert additional control over the call setup process. HTTP is a client-server protocol, not a full duplex communications channel, so it is no good for peer-to-peer signaling. WebSockets (wss:// ) is a common choice that uses well-known TCP ports, but it could equally be a socket.io connection using an arbitrary port.

If users are experiencing problems at this stage, you can make use of the Network tab in their browser's developer tools section to see exactly what IP address and port their browser is trying to connect to for signaling (Figure 8) and open up the firewall accordingly. The WebSocket Secure (WSS) default port is 443, so this should work in most cases. Web proxies should support the HTTP CONNECT method on port 443. Any proxy that inspects secure content will rely on a self-signed certificate to re-encrypt the content, and WSS signaling channels fail to connect if the browser can't establish a root certificate authority path for these certificates.

Figure 8: Using Chrome developer tools to find call control requests.

With the signaling channel established, the high-level call control traffic (the equivalent of SIP's INVITE, TRYING, RINGING, OK) can be exchanged by the JavaScript apps on both sides, followed by the SDP and ICE content that the app gets from WebRTC using the JSEP-related parts of RTCPeerConnection.

At this juncture, I will introduce Chrome's webrtc-internals page, a comprehensive WebRTC troubleshooting tool built right into the Chrome browser (which I hope you have realized by now is the go-to browser for the serious WebRTC practitioner). Opening a tab to chrome://webrtc-internals shows a real-time overview of all the WebRTC activity for that entire browser instance. If all you see is Create Dump , there is no activity. If you see WebRTC activity, a GetUserMedia Requests tab shows you all the active device access requests. For each current RTCPeerConnection, you'll see another tab that gives access to a bewildering array of information, most of which, fortunately, is not necessary for troubleshooting at the level of this article. Figure 9 shows an example of the webrtc-internals page from Chrome 64, with three points of interest highlighted: (1) parameters supplied by the app to RTCPeerConnection, which might include (although not in this example) the specific TURN servers to use; (2) a section that summarizes the results of the bandwidth estimation (BWE) process used by RTCWEB to estimate how much network bandwidth is available; and (3) detailed information about ICE candidate pairs that shows the IP addresses and ports being used for the media channels.

Figure 9: Some key parts of chrome://webrtc-internals.