Anyone who uses video chat, voice call applications or file sharing from a web browser or mobile application, will most likely be doing so through WebRTC connections.
Communicating through platforms such as Google hangout, Google Meet, Google Duo, Facebook Messenger, WhatsApp and many more is possible because of WebRTC.
WebRTC, or Web Real-Time Communication is a collection of open-source communication protocols and Application Programming Interfaces (APIs) that make real-time communication and the ability to send and receive data over a peer-to-peer connection possible.
It allows users to communicate without the need for plugins or additional software. Instead it uses Javascript, APIs, and HTML5 to embed the communication technologies within the browser.
WebRTC is built into the Google Chrome browser (desktop & Android), Mozilla Firefox (desktop & Android), Safari, Opera (desktop & Android), Microsoft Edge and more - however, like any software, it can be prone to troublesome bugs.
In this guide, we'll discuss the best approaches to debugging, and ways to troubleshoot WebRTC issues so that users can maintain a successful connection on any remote machine or device.
Without a WebRTC connection, devices are unable to connect with each other without an intermediate server. Put simply, one device transmits the information to a server (network hardware), then the server delivers it to the second device. This requires both devices to have the same plug-in or software loaded for communication to occur.
Image source: StackFive
Over the last few years communicating in real time, particularly through video conferencing, has become mission critical to seamless unified communication and collaboration.
To address this, Google set about developing a way to achieve seamless data transmission on a standardized platform, without the need for third-party applications or plug-ins - using peer-to-peer connection instead.
Image source: StackFive
Mozilla, Microsoft, Opera, and Apple all embraced the technology, and today, WebRTC is an open-source project providing real-time communication (RTC) capabilities available to anyone.
As mentioned above, when two or more devices wish to communicate with each other, they use a server, through which all data is relayed.
This can become expensive to host, and has its own disadvantages, including latency when the server is hosted a long way from the devices. Another issue is scale. As more and more users begin to use the server, more resources are needed to handle this massive amount of constantly travelling data.
WebRTC operates with the support of various underlying protocols, including SDP (Session Description Protocol), the communicative language used by WebRTC devices, enabling them to establish real-time interactions even when they have varying capabilities or are positioned behind firewalls or Network Address Translators (NATs)
Even though WebRTC enables more efficient real time communication, WebRTC failures can happen for a variety of reasons. Let's look at some of the issues first, then discuss some common WebRTC troubleshooting solutions.
Network Connectivity: Network conditions such as firewalls, or NAT traversal issues can affect a WebRTC peer-to-peer connection between users, leading to connectivity problems or unreliable connections.
Browser Compatibility: Different browsers have different way of implementing a WebRTC connection. This means inconsistencies and compatibility issues can occur, particularly when working across different browsers, because of the way they implement WebRTC APIs.
Media Quality: Packet loss, or poor audio/video quality on each connecting device can be caused by synchronization problems attributed to network congestion, or misconfiguration in network setup.
Security Vulnerabilities: WebRTC has effective built-in security features such as encryption for media streams, however, security vulnerabilities are possible, so developers need to keep their WebRTC implementations current with updates, security patches and best practices.
For example WebRTC leaks can expose a device’s public IP address, which can be a serious issue, especially if using a VPN, which is designed to conceal your public IP address.
Most of today's web browsers include debugging tools that can be used to troubleshoot and debug a WebRTC connection.
These tools allow you to inspect network requests, monitor and analyze network session description packets, view console logs, and analyze performance metrics.
Chrome DevTools, Firefox Developer Tools, and Microsoft Edge Developer Tools are commonly used for debugging WebRTC apps.
It can be challenging and time consuming to establish a WebRTC connection on mobile devices, and one of the most common support topics involve apps that function well on WiFi but not on 3G or 4G.
Since you can’t use a debugging program like Wireshark on a mobile device and mobile Safari's interface is not user-friendly, debugging in such circumstances might be difficult.
In this case, a mobile internet dongle may be more useful for debugging WebRTC applications on a mobile device.
WebRTC APIs have a logging functionality that can reveal detailed information about the internal operations of the WebRTC stack. You can enable logging by setting the webrtcLogLevel property to a desired log level (e.g., DEBUG, INFO, WARNING, ERROR) in your JavaScript code.
Image source: MDN WebDocs
You can view real-time WebRTC connection statistics about video/audio bitrate, round-trip time (RTT), packet loss, and jitter, using tools like WebRTC internals in Chrome or about:webrtc in Firefox. Monitoring these metrics can help diagnose media quality issues.
Network analysis tools like Chrome's Network tab can inspect network traffic generated by WebRTC connections. This can help identify issues related to network connectivity, NAT traversal, and firewall configurations.
Tools like KITE (Keep It Tested End-to-end) or AppRTCare are open source test tools that can test the interoperability of WebRTC under different scenarios across browsers, and detect problems early.
You can log detailed information about the establishment and maintenance of peer connections by activating peer connection tracing in your WebRTC application. This can help identify issues with Interactive Connectivity Establishment (ICE) candidate packets and session data, or SDP (Session Description Protocol) exchange.
Image source: MDN WebDocs
You can handle failures and provide detailed error messages to users by implementing error handling in your WebRTC application. Common errors include ICE failures, media access permission errors, and unsupported codecs.
Image source: MDN WebDocs
Peer connection is the part of the WebRTC specifications that allows two applications on different computers to communicate - but before they can connect, both clients need to provide an ICE connection.
This could be either a STUN-server or a TURN-server, and their role is to provide ICE candidates to each client which is then transferred to the remote peer. This transferring of ICE candidates is commonly called signaling. A signaling server is needed to allow two peers to share how they should connect.
To connect to a web server, you only need to make a HTTP request. However, WebRTC provides a multitude of connection types, each of which may be tried in order to establish a successful connection.
The typ host represents connections to local network devices. The typ parameter is one of the more crucial components of ICE candidate SDP packets. Connections don't require a STUN server or TURN server, as there's no requirement for a local IP address-to-public IP address translation when connecting devices are on the same network.
Server Reflexive, also referred to as srflx, is about the acquisition of a public IP address. srflx stands for Peer-to-Peer connections that only require STUN. When both sides send an srflx packet, it indicates that both parties should be reachable using a STUN-only configuration, but not necessarily connect.
Typ relay is a TURN connection indicator, so in essence it should be possible to establish a connection when both sides send such a packet.
These packet types are not sequential so that a device might offer an srflx packet but not a relay packet or vice versa, and a connection won't be possible when both parties can't deliver compatible packet types.
Chrome WebRTC Internals are part of Google's Chrome's suite of debugging tools built into the Chrome browser.
The Chrome WebRTC internals tool provides the ability to view real-time information about the audio and video stream in a WebRTC call.
The WebRTC internals data includes details about the video and audio tracks, the codecs utilized, and the stream's general quality. This information can be very helpful for resolving problems with poor audio and video quality.
To access the WebRTC statistics, you can either open the webrtc-internals page in the browser making the call (on Chrome and Opera) or use the getStats API call.
getStats is a small JavaScript library using the WebRTC getStats API to break down calls to the rtcpeerconnection instances. It handles stats such as bandwidth usage, packets lost, local/remote IP addresses and ports, type of connection etc.
Always-on connectivity is crucial to the way we work. Real time communication and collaboration depends on a robust network connection, and even the smallest glitches like failed host connections, corrupt data or problems with different networks can de-rail business operations.
Downtime costs money, so organizations need a world class performance management solution like RemoteInsight to solve problems and provide insights into the health of their network.
RemoteInsight is a remote digital experience management solution, available as part of IR Collaborate. It enables a deeper level of insight into performance issues being experienced by users working from anywhere.