A typical Internet voice call may use only around 100 kbps of media bandwidth — roughly 0.02% of a 500 Mbps line. So when a fast connection still produces bad calls, raw Mbps is often not the first thing to investigate. The better clues are which direction failed, whether video or audio failed first, whether Wi-Fi stayed connected, and what changed when you switched one variable.
During the next bad call, observe before you hang up
The useful evidence may exist for only a few seconds. Note four things:
- Which direction failed? Ask: “Can you still hear me?”
- What failed first? Video, audio, or the whole call?
- Did Wi-Fi disconnect? Or did it stay connected while the call broke?
- Did it recover by itself? Roughly how long did it take?
Route by what failed first
| What happened | Go directly to |
|---|---|
| They hear you badly; you hear them clearly | → 1. Upload congestion |
| Call degrades while you walk between rooms/APs | → 2. Wi-Fi roaming |
| Wi-Fi actually disconnects, then returns | → 2. Wi-Fi roaming or 7. Weak Wi-Fi |
| Both sides sound robotic or timing becomes erratic | → 3. Jitter / congestion |
| Call recovers by itself within seconds | → 3. Transient jitter / congestion or 4. Packet loss |
| Words disappear or both directions cut in and out | → 4. Packet loss |
| Call dies when screen locks or you switch apps | → 5. Android background restrictions |
| One-way audio repeats in the same direction | → 6. One-way audio |
| Fine near router, poor in usual calling spot | → 7. Weak Wi-Fi |
| Call stays dead until you redial, or only one app fails | → 8. App / service / route — after checking that the whole connection did not drop |
Eight patterns worth checking
1. Your upload path is congested
Cloud backup, photo sync, cameras and file uploads can fill a much smaller upstream even when download speed is huge. Your outgoing voice then waits behind bulk traffic. Confirm: pause uploads and repeat the call. If they suddenly hear you clearly, you found a strong lead. Turning video off is another quick comparison because it reduces upstream demand immediately.
2. Your phone is holding onto the wrong access point
In mesh or multi-AP homes, a phone can cling to a weak access point while a stronger one is nearby. The Wi-Fi icon may stay connected even as the call deteriorates. Confirm: failures happen while moving or just after changing rooms. Fix: keep one SSID where appropriate and enable the vendor's roaming/steering features if supported; do not change advanced radio settings blindly.
3. Jitter or queueing is breaking timing
Packets are arriving, but not evenly. Voice apps have only a small buffer to hide timing variation, so audio becomes metallic or choppy. Confirm: jitter rises during the failure, especially while somebody uploads or downloads heavily. If loaded latency also jumps, fix the queueing/congestion first.
4. Packet loss is removing pieces of the conversation
A live call cannot wait long to resend missing audio. Confirm: repeatable loss appears during the bad call and you can tell whether it begins locally or beyond the router. Around 1% sustained loss is already worth investigating. Rule out weak Wi-Fi before treating it as a provider-line fault.
5. Android is restricting the calling app
If the call dies when the screen locks, when you leave the app, or after the phone has been idle, the network may be innocent. Confirm: the pattern follows screen/app state while network measurements remain healthy. Check battery/background settings for that app and, if needed, allow unrestricted background use only for the affected app.
6. Persistent one-way audio
Do not diagnose CGNAT or SIP ALG from one symptom. One-way audio can involve the app, firewall/NAT behaviour, enterprise VoIP settings or the remote side. Confirm: note whether the same direction fails repeatedly, then compare a second calling app and another network. If several apps fail only on one home/office network, router or firewall behaviour becomes worth investigating. For managed SIP/VoIP, follow the provider's guidance before changing SIP ALG.
7. Wi-Fi is weak where you take calls
A signal around −67 dBm or better is a useful design target for real-time Wi-Fi; below roughly −70 dBm, retries and interference become much more important. Confirm: the same call becomes clean close to the router. That comparison is more useful than counting Wi-Fi bars.
8. The app, service or route is the problem
If one calling service fails while another unrelated one is clean on the same phone and network, do not force a home-network diagnosis. Check service status, updates, VPN/private-relay behaviour, and whether the same app fails on mobile data too.
Practical call-quality reference ranges
These are troubleshooting references, not universal pass/fail standards; apps use different codecs, buffers and recovery techniques.
| Measure | Generally comfortable | Investigate when repeated |
|---|---|---|
| One-way delay | < 150 ms | > 150–200 ms |
| Jitter | < 10 ms | > 30 ms |
| Packet loss | < 0.5% | 1% or more |
| Wi-Fi signal | −60 dBm or better | Below −70 dBm |
Write five things after a failed call
Time. Place. App. Network. Direction. Nothing more is required.
20:12, living room, WhatsApp, home Wi-Fi. I heard them clearly; my voice broke up for about 15 seconds, then recovered. Photo backup was running. The same call on mobile data two minutes later was clean.
That paragraph is diagnostic because it preserves the conditions and the comparison. A fast speed result taken half an hour later does not.
Wi-Fi Calling is a different case
If your phone shows Wi-Fi Calling during a normal carrier phone call, that is the mobile operator's voice service using Wi-Fi. It is not the same path as an app call such as WhatsApp or Teams. If the issue happens only with carrier Wi-Fi Calling enabled, compare one call with it on and one with it off under the same conditions.
Where Diagnostix360 fits
Diagnostix360 can compare Wi-Fi/mobile conditions, local-path behaviour, delay, jitter and reliability. It does not declare that an ISP or calling service is at fault. Its useful role is to preserve the measured conditions around the symptom, show where the first meaningful change appears, and let you repeat the same check after one controlled change.
Frequently asked questions
Why do calls fail when my speed is high?+
Because a voice call needs little raw bandwidth but consistent timing. High Mbps cannot compensate for repeated delay spikes, loss, weak Wi-Fi or a saturated upload path.
Why can they hear me badly when I hear them clearly?+
The two directions are not identical. Upload congestion or Wi-Fi transmission problems can hurt your outgoing audio while incoming audio remains usable.
Why does turning video off help?+
Video consumes much more upstream capacity than voice. If audio immediately stabilises, upload headroom, queueing or radio stability becomes a useful lead.
Bottom line
For a bad call, observe before you redial. Direction, media, Wi-Fi state and recovery time can tell you more than another speed test. Then change one variable and repeat under comparable conditions.
WhatsApp, Microsoft Teams and Messenger are named descriptively. Diagnostix360 is independent and is not affiliated with or endorsed by those services.
Check the connection where the problem happens
Run Diagnostix360 on the same Android phone, in the same place, while the problem is present. Make one change, then run the check again.
This article is general troubleshooting information, not professional, contractual, legal, security or SLA advice. The ranges are practical references, not certified pass/fail standards. Results vary with the target, application, device and network. Diagnostix360 describes conditions measured at that moment; it does not assign responsibility or replace provider-side or professional diagnostics where those are required. Read detailed reports before sharing them. See the Terms of Use and Privacy Policy.