Through the power of WebRTC, millions of people connect face-to-face with colleagues across continents, collaborate on virtual whiteboards in real-time, share their screens with support teams, and much more. However, when issues arise, identifying the root cause within the complex web of connections can feel like searching for a needle in a haystack. 

While challenging, troubleshooting WebRTC applications can be made more manageable. With the right diagnostic tools and a systematic approach, you can quickly identify and resolve connection issues before they impact your users. In this post, we’ll explore common troubleshooting scenarios, show you how to leverage data effectively, and introduce essential tools that streamline the debugging process. 

The Importance of Data

Despite the best efforts of development teams to build robust and resilient software applications, unforeseen circumstances, changing requirements, and edge cases inevitably arise over time. When they do, they often expose vulnerabilities or limitations that lead to failures. Due to their inherently complex architecture, WebRTC applications are particularly prone to encountering such issues.

This makes it crucial for software developers to implement measures that can effectively address incidents when they inevitably occur. Ideally, such measures would include automated recovery mechanisms, but at least they must provide clear and actionable information to help identify and resolve the underlying issue.

The data generated by the WebRTC application itself plays a crucial role in troubleshooting issues. Data allows development teams to understand the root cause of problems and guides them toward the implementation of a proper solution.

For this reason, the first step in troubleshooting WebRTC applications is to implement a mechanism that collects relevant data, stores it, and presents it in a way that facilitates diagnosing and correcting any problem that may arise.

Navigating Common Issues In WebRTC Applications

While every WebRTC application is different, these tend to experience common issues that usually fall in one of the following categories:

• Connection failures at start up
• Connection failures after start up
• Issues with media devices
• Video and audio quality issues

Let’s see how data plays a huge role in navigating through these issues.

Connection Failures at Start Up

The most common causes of connection failures at startup are problems with the signaling process or ICE server configuration. It’s important to highlight that while signaling is not part of WebRTC, it can still cause failures. 

Further reading: Networking Basics for WebRTC: Signaling and Media Exchange 

When troubleshooting signaling issues, we need to be able to check SDP offers and answers, and the ICE candidates that each peer receives. Any missing or corrupted information indicates a problem with the signaling channel.

In the same vein, ICE servers provide peers both with candidates and a relay mechanism when a direct connection is not possible. If these servers are unavailable or not working properly, peers won’t be able to connect, so one of the first things we should check are the kind of ICE candidates that peers are gathering. For example, if only host candidates are available, it means that neither STUN or TURN servers are available for that peer. 

The above suggests that to diagnose and fix connection failures at start up, it is crucial to have a record of the events that each peer performs to establish such connection, and the information it sends and receives.

Connection Failures During Call

Network conditions can change after a successful connection, leading to connection failures. For example, a user might switch from a wifi connection to a mobile connection with a poor signal, or the application might fail to renegotiate ICE candidates during the network switch. 

Further reading: Networking Basics for WebRTC: Delivery and Addresses

Same as before, maintaining a clear record of events is essential for troubleshooting. For instance, we can track iceconnectionstatechange events in order to get the status of the connection, and update the UI accordingly.

Issues with Media Devices

When an application cannot correctly access media devices, it may not function as intended. This could be due to a malfunctioning camera or improper management of device permissions and/or IDs.

The application can gracefully manage unsuccessful situations by obtaining details from getUserMedia() API calls and implementing proper exception handling. This approach helps to maintain a positive user experience even when issues arise, and at the same time it provides developers visibility over issues with media devices.

Video and Audio Quality Issues

Video and audio quality issues are often related with network congestion, where multiple users and applications compete for the same network resources and cause things like packet loss, increased latency and jitter. But network is not the only factor affecting media quality, the actual user devices can also be a bottleneck for quality. 

For example, when the architecture of the application involves the use of a Selective Forwarding Unit (SFU) media server, each peer is responsible for encoding and decoding the media they send and receive, respectively. Certain low-end devices might not be able keep up with processing all the media appropriately, resulting in quality degradation issues.

In both cases, recording key metrics that provide visibility over the status of the network and the device, is crucial in understanding the root causes behind any problem related with media quality.

Tools to Troubleshoot WebRTC Applications

Now that we understand the troubleshooting process and the required information, let’s explore the tools available to facilitate this process.

WebRTC-Internals

The first line of defense in troubleshooting WebRTC applications is the chrome://webrtc-internals tab. As you may have guessed by the url, it’s a utility included in Google Chrome and chrome-based browsers.

The webrtc-internals tab displays real-time data about WebRTC connections taking place in the browser. This includes connection status, ICE candidate pairs tested, events during connection establishment, and statistics & graphs for key metrics (e.g., jitter, packet loss). Additionally, it provides basic information about sent & received media.

However, such a large amount of information makes the tool overwhelming and difficult to interpret at first. Additionally, it requires opening the tab in advance to capture events, making it impractical for production environments, i.e. relying on end-users to open the tab and relay the necessary information is not realistic most of the times.

In such scenarios, it’s better to have this information available without any user intervention, which leads us to the next tool.

getStats

The getStats method of the RTCPeerConnection interface provides granular information about the status of peer connections and media tracks. Software developers can use such a method to extract valuable information from the application and send it their preferred analytics tool without any action from the user.

Using the getStats method, developers can gather detailed information about the performance and configuration of a WebRTC connection. This includes data on codecs (e.g., the mimeType “video/VP8” and clockRate of 90,000 Hz for video encoding and decoding), media quality (e.g., frame resolution of 480×360, 30 frames per second, and metrics like jitterBufferDelay), and network performance (e.g., currentRoundTripTime of 0.001 seconds, bytesSent and bytesReceived, and packetsLost).

Additionally, the getStats API can provide insights into candidate pair connectivity, such as a state of “succeeded” and the local and remote candidate details (e.g., local IP 192.168.0.14 with protocol udp). It also reports encryption and transport settings, including the DTLS cipher suite (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256), SRTP cipher (AES_CM_128_HMAC_SHA1_80), and connection state (connected).

These metrics enable developers to troubleshoot issues, such as identifying quality degradation caused by limited bandwidth (qualityLimitationReason: bandwidth), monitoring retransmissions (retransmittedBytesSent: 0), or verifying compliance with security standards through fingerprint and certificate data.

The downside is that development teams need to manually collect such information in the code and build appropriate visualization tools, which can be a daunting task without the proper expertise.

Third-party Tools

There are also third-party tools that can be used to troubleshoot WebRTC applications. CPaaS providers usually include some sort of dashboards or analytics tools within their offering. These can be used to analyze and troubleshoot applications that use their services. In a previous blog post, we discussed how to monitor WebRTC applications built with Daily.

Another option is to use a service such as Cyara testRTC; this will not only provide visibility on user behavior and experience but also automate testing of WebRTC applications with specialized tools.

When you need to dig deeper …

When you’ve addressed the low-hanging fruit and basic troubleshooting isn’t enough, it’s time to dig deeper. Persistent issues might stem from architectural inefficiencies, suboptimal server configurations, or even flaws in the UI/UX that hinder user workflows. Resolving these more complex problems requires expertise and a fresh perspective.

At WebRTC.ventures, our experts are here to help with a comprehensive application assessment, providing actionable insights into your architecture, design, and overall implementation. Additionally, engaging our Managed Services can ensure your WebRTC application is continuously monitored and maintained, so you can focus on delivering exceptional user experiences without worrying about unexpected issues.

Let us help you take your WebRTC application to the next level. Reach out to WebRTC.ventures today!