Irish technology company Spearline acquires Callstats from 8x8.  Learn More

How to use to troubleshoot Underwater Sound

By callstats on September 28, 2021
The 🌍 is now more accustomed than ever to meeting other people via Video and not only is the world conducting more and more business in this way but we’re all using it to build and maintain relationships with people.  Water cooler chats, coffee machine hangouts, daily catchups with friends, family and colleagues.  With all this increased usage comes an even higher level of expectation of what the quality of these experiences should be like.

These 1:1 calls, meetings and events should all look and sound perfect, all the time, right? 

With crystal clear audio for everyone?

What happens when it’s not? 🤨

When someone on the call sounds like they’re talking to you from underwater, who or what is to blame? 🧐


The all too familiar blame game starts with everyone quickly blaming your service or perhaps pointing fingers at WiFi and Internet connectivity.  If this was your service, how would you defend yourself and help to educate your customers at the same time? 


With you could, read on to find out how.


Understand the fundamentals: What can cause that Underwater Sound?

When people complain about an underwater-sounding experience packet loss and/or bandwidth-constrained links will exacerbate the issue but they are not normally the root cause.  The underlying issue is typically related to multiple audio conversions.

What’s an audio conversion and why would it happen?

Most commonly audio conversions occur for any user/s dialling into a conference using their mobile phone or from the PSTN network.  Audio conversions also take place when someone is using an older analogue phone connected via an ATA device or perhaps the call is being routed through an intermediary VoIP platform such as the IP PBX being used at a place of work.  To join an online video conference, these types of calls require the original audio to be converted, either from analogue-to-digital signal and/or from one codec to another codec.  Depending on the scenario and exact call path, the original audio may get converted multiple times before it even enters your video conferencing service! enters the game!

Not everyone can be a real-time communications expert and even if you are an expert, where would you start and what data would you use to prove the issue? can quickly and easily help you identify how each person is connecting to calls on your service.  This enables you to identify this type of problem whilst providing real data to back you up! 


Let’s take a look at a small conference, where several people complained that a colleague sounded like they were talking underwater.

Identifying different access methods

When someone reports hearing another person sound like they’re talking underwater, you need to start by identifying how the user in question is accessing the call.  

Using that's quick and easy to discover!  

First, you need to use the search filters and identify the correct call and open it up.  By default the ‘general’ tab will open, scrolling down a little way you will see the list of participants on the call.


Fig 1. Participant list.

In Fig1. you can see 4 participants.  This example call is running on top of JaaS (Jitsi As A Service) where Jagasi is being used to interop with SIP trunks for external PSTN/Mobile access.  

Here we can see there are two people joined using software applications (8x8 Work & 8x8 Meet) and the other two are joined via Jigasi.  The latter ‘Jigasi’ users are both coming in from the PSTN/Mobile network.  This is confirmed by the source callerID number being displayed for each of those participants.

When the user dialling in via PSTN reports an issue with audio, it is most likely a transcoding issue. In this case, the user accessing the service using an endpoint that is external to your service (much more likely) it will either be down to your SIP trunk partner and the interconnect/gateway used to connect the call from its point of origin into your service or the issue is completely external to your services, such as the user using their own ATA or IP PABX as described earlier.  

To narrow things down, you can ask the user to try an alternate access method, such as using your own application/browser app instead of dialling in via the PSTN/Mobile network and see if that resolves the issue for them.

Using the same audio/video codecs throughout your service wherever possible to minimise any codec translations and selecting a strong partner to provide the PSTN/Mobile network access is paramount to the quality of your service and eliminating this particular issue.

This feature is part of 8x8's call quality initiative.


This blog post was written by Matthew Rogers, EMEA Solutions Engineer - CPaaS.

Tags: WebRTC, Smart Connectivity Test, QoE, changelog, root-cause analysis