Surfacing audio and network issues using Twilio Client JS 1.4 and later

In our experience, almost all Client SDK call quality issues are either due to local network conditions (things like high latency or packet loss)  or hardware issues (microphone input not being passed to the browser, or audio output from the SDK not reaching the speaker).

If you're not surfacing audio warnings when USB mics aren't delivering audio to the browser, or letting users know when network conditions could be causing audio issues, we highly recommend doing so, and starting with Client 1.4, Twilio gives you some tools to accomplish this:

  • Use the warning event emitters to surface things like constant audio input/output levels (one-way audio/local hardware issues), high RTT (latency), and high jitter/high packet loss (network connectivity trouble) to the users.
  • Use the volume handler to display a waveform of the mic input and speaker output to provide instant visual feedback to the user that something might be amiss with their local audio hardware; e.g. microphone plugged in but no waveform, output waveform but no sound to your headset, etc. We've got some examples on using this functionality here.

Our SDK contains sensors that are dependent on WebRTC APIs, which are in turn dependent on the browser, which get its audio information from the operating system, which gets its audio information from audio hardware drivers. Our visibility extends only to the Twilio SDK level, so scenarios where a browser gets into an inconsistent state and stops passing microphone audio to the WebRTC APIs would look the same to us as call where the physical microphone hardware failed: we would see no input at the SDK sensor level, and raise a constant-audio-input-level warning. Our warning events can tell you when the SDK isn’t receiving audio, but not why. To view these events in detail or in aggregate, and to know which users are getting affected, Twilio Client Insights provides account-wide metrics as well as individual call-level insights.

Users may still report issues, but surfacing these details in your application gives users actionable information to try to address in real time instead of letting them get frustrated because they don't know why their call is experiencing issues.

Our go-to recommendation for troubleshooting audio issues for Client calls is always to restart the browser; barring any legitimate hardware failures or intractable network performance issues a simple restart of the browser will likely eliminate any transient call quality issues. On the subject of network issues, we provide a network test tool with the ability to place a regional test call to verify  two-way media and a bandwidth test to illustrate network capacity.

If you have any questions about any of the topics discussed  above, or have call quality issues you would like help investigating, please contact support.

Have more questions? Submit a request
Powered by Zendesk