Why Your Salesforce Calls Sound Bad: Jitter, Packet Loss, MOS Scores and the Network Checks That Actually Fix It

Would you call it a good conversation if you have to work hard just to hear it clearly? Missed words in between, incomplete sentences at times, and repeating yourself all over again. All these distractions may appear trivial, but combine them in a dialogue and you’ll get a puzzle that people at both ends find difficult to piece together. When every sentence needs to be repeated simply for clarity, this becomes an exercise of patience, rather than an interaction.

Now imagine dealing with that across an entire contact center. Agents lose their rhythm, customers repeat information they've already shared, and simple interactions take longer. When these problems surface in Salesforce, the frustrating part is that the call may still connect, the console may still work, and nothing obvious may explain the broken audio.

The reason is that connecting a call and delivering clear audio are two entirely separate processes. VoIP call quality is dependent on what happens to the voice packets while they are traveling from one endpoint to another, and there are various factors that may disturb this process without terminating the call itself.

What is VoIP Call Quality?

Making a call through Salesforce is not the same as making a call on a traditional phone line. On a phone line, your voice travels as a continuous signal. Through Salesforce, it travels as packets — small chunks of digital audio, each covering about 20 milliseconds of speech, moving across the internet and reassembled at the other end into the voice the caller hears. This digital process also supports features such as real-time call transcription, allowing conversations to be converted into text as they happen.

Voice over Internet Protocol (VoIP) handles the entire process from microphone to speaker. VoIP call quality is the measure of how well these packets are delivered. If the packets arrive in the correct form and sequence, the call is seamless. However, if not, then the audio is disrupted. In such a situation, the person on either end hears speech, pauses in between, and inconsistencies in clarity, in such a way that leaves absolutely no evidence in Salesforce.

What Do Jitter and Packet Loss Do in a Voice Call?

Two things disrupt smooth packet delivery. The first is call jitters. Jitter is inconsistency in the time between packet arrivals. Jitter is the gap between the arrival time you expected and the arrival time that actually happened. Send a packet every 20 milliseconds and receive them at 22ms, then 31ms, then 19ms, then 40ms — that irregular rhythm is jitter in action. A jitter buffer sits at the receiving end and compensates. Packets come at their own times and leave the buffer at a constant speed to provide constant sound flow. In case a packet comes too late for its play slot, the buffer discards the packet rather than playing it out of order. The audio has a gap.

Packet loss works differently. The audio is transported via RTP (Real-Time Transport Protocol), which is fast, though not reliable when it comes to delivery. Unlike a file download that can request missing pieces, RTP does not go back for lost packets. Packet loss concealment steps in instead — the receiving device generates a short audio estimate by analysing what came immediately before and after the silence. For jitter and packet loss in calls at low loss rates, this estimate is convincing enough that most people would not notice the substitution.

Jitter and packet loss together are the leading factors in degraded audio quality and choppy audio in the Salesforce system, and they occur at the same time due to network congestion.

What Does a MOS Score Measure?

Mean Opinion Score, or MOS, rates perceived call quality on a scale from one to five. A MOS score for VoIP of 4.0 is considered toll quality — equivalent to a traditional landline call. A rating from 3.5 to 4.0 is acceptable, though a caller can tell something's wrong. Anything below 3.5 is poor-quality audio. Below 3.0, holding a conversation requires genuine effort.

Modern MOS measurement uses algorithmic models — the most common being PESQ (Perceptual Evaluation of Speech Quality) and the E-model — which estimate what a human listener would score based on measurable network conditions including packet loss rate, jitter, and end-to-end delay.

While MOS has a number of positive traits, it does have a significant negative trait, and that is that it gives a measurement of the overall quality of the call but does not identify the specific factors that contributed to that quality. A score of 3.1 does give us confirmation that the audio quality was bad. But what we don’t get is a reason why the audio quality was bad. For example, did the caller experience packet loss, was there jitter, or was there delay? In our article on Call Transcription Accuracy Explained, we mentioned that there is a definite relationship between bad audio quality and the transcription of the call. In this instance, analyzing the data points that support the network should give us the information that we are looking for.

The Network Checks That Actually Fix It

Call quality troubleshooting from the wrong layer produces nothing valuable. A speed test is good for general speed only and will give no information on what is happening to the voice packets because quality of voice calls cannot be measured in terms of bandwidth. The diagnostic work has to start where voice packets actually travel.

1. Check the WebRTC internals first.

   Salesforce Service Cloud Voice provides its audio via Web Real-Time Communication (WebRTC), which is a browser-based technology that provides voice communication using Chrome or Edge. It uses a protocol called ICE (Interactive Connectivity Establishment) to route media between the agent's browser and the other endpoint.

   To resolve the real-time audio and connection problems related to browser-based calls, troubleshoot the WebRTC engine in Chrome. Find the active candidate pair for the audio stream and check the candidate type. If it shows host or srflx, audio is taking a direct path. If it shows relay, audio is being routed through a TURN server — a middleman used when firewalls or network address translation prevent a direct connection. TURN relay adds latency and creates a congestion-sensitive point in the media path. This Salesforce-specific failure is what generic VoIP troubleshooting consistently misses.

2. Measure packet loss and jitter to the right destination.

   What matters for VoIP call quality in a Service Cloud Voice environment is the connection quality specifically to the Amazon Web Services region hosting your Amazon Connect instance — not general internet performance. Send continuous test packets to a specific destination and measure packet loss, jitter, and latency over time. Run a five-minute test pointed at your Connect instance’s AWS region during a known problem window. Consistent loss throughout the test suggests a path problem. Loss that spikes in short bursts points to congestion at a specific network point during peak usage.

3. Check your AWS region selection.

   For instance, agents located in India who are connecting to a Connect instance based in the US are likely to have delays due to audio being sent over a longer distance. Comparing the level of delay with the Voice AI Latency Benchmarks will make it easier to identify areas of concern. In case you notice slow call times despite having low jitter and packet loss, then it may be time to look at your Connect instance.

4. Isolate browser resource contention.

   A call that sounds clear on a test machine but deteriorates on a production agent’s desktop is not always a network issue. WebRTC audio processing shares CPU resources with other browser activities, including open tabs, Salesforce Lightning components, background scripts, and screen recording tools. Even Salesforce Call Flow Management may need to be evaluated alongside these factors when troubleshooting call quality. Press Shift + Esc in Chrome to open the browser task manager while the affected call is active. The solution here would be decreasing the amount of work that your browser is doing, not changing anything in your network settings.

Conclusion

A call that has established a connection is not the same thing as a call that works just right. Jitter disrupts the call timing. Packet loss removes audio permanently. TURN relay adds a congestion-sensitive middleman to the media path. Browser resource contention mimics network failure from inside the device. Each produces the same symptom — broken, choppy audio — and each requires a different fix. The monitoring that catches these problems early is not complex to build. Most contact centers simply need to develop the habit of checking the right layer. Effective Salesforce Call monitoring helps identify network-related issues before they affect call quality. The application itself is not the problem; it’s the underlying network that makes the difference