Troubleshooting Common Softphone Issues

Almost every softphone support ticket arrives in the same shape. Somebody says the app “stopped working,” and what they actually mean is one of eight or nine specific failures, each with a different cause and a different fix. A missed call at 9am because the phone was asleep is not the same problem as a call where the caller can hear you but you cannot hear them, even though both get filed as “the softphone is broken.”

That matters because voice is unforgiving. ITU-T Recommendation G.114 puts the ceiling for one-way transmission delay at roughly 150 ms before most people start noticing that a conversation has gone wrong, and by 1% packet loss the audio is already audibly damaged. There is no graceful degradation in a phone call. It works, or the customer hangs up and calls a competitor from their mobile.

This guide is organized the way tickets actually arrive: by symptom. Each section states the complaint in the user’s words, explains what is really happening underneath, and gives you the checks that resolve it. We build a white-label softphone that VoIP service providers, ITSPs and MSPs resell to their own customers, so the patterns here come from the deployments and support conversations we sit in on, not from a generic list of tips.

One framing point before the symptoms. When people bring us softphone connection issues, they almost never describe the symptom first. They describe their stack. In early 2026 a genuine inbound customer reached us after asking an AI assistant for softphone alternatives that connect with the specific PBX platform they were already running, which is exactly how the technical buyers in this market think. They do not search “no audio.” They search for something compatible with the back end they already run. Keep that instinct when you troubleshoot: the first question is almost never “what broke,” it is “which two things are talking to each other, and do they agree.”

The Softphone Does Not Ring When the App Is in the Background

The complaint: “It rings fine when the app is open. If my phone has been in my pocket for an hour, the call goes straight to voicemail and I see a missed call five minutes later.”

This is the single most common of the common softphone problems, and it is almost never a network fault. It is a push notification fault.

Three terms carry this whole section:

• VoIP push is a special class of push notification that wakes a sleeping app specifically to handle an incoming call, rather than just drawing a banner. On iOS that is PushKit. On Android it is a high-priority Firebase Cloud Messaging message.
• Standard push is the ordinary notification path, subject to batching, delay and battery optimization. If your softphone is being woken this way, it will ring late or not at all, and no amount of network tuning will fix that.
• SIP registration is the periodic check-in where the client tells the PBX or SIP proxy “this is where to reach me.” Registrations expire, typically every 60 to 3600 seconds depending on how the platform is configured.

That expiry is the part people miss. A client that is asleep and cannot re-register silently falls off the platform. This is why “it stopped ringing after about an hour” is such a recognizable complaint in softphone troubleshooting: the registration interval and the failure window match.

Apple is explicit about the contract here. Its platform documentation for VoIP notifications states that for apps built using the iOS 13 SDK or later, PushKit requires you to use CallKit when handling VoIP calls, and it tells developers to set the push expiration header to zero or a few seconds so the system does not deliver a stale call alert long after the caller gave up. An app that accepts a VoIP push and does not immediately report the call to CallKit is not in a supported state, and the system will act accordingly.

Work through this order when the softphone is not ringing:

• Confirm the client is registered, not just logged in. A green icon in the app usually means the last registration succeeded, not that one is current. Check the registration table on the PBX and look at the expiry timestamp for that extension.
• Check whether push is provisioned at all. In many hosted platforms push is a per-tenant or per-application setting with its own certificate or key. An expired APNs key or a rotated FCM server key kills push for every user on that tenant at once, which is why this particular softphone issue arrives as a flood of tickets rather than a single one.
• Ask whether the app was force-quit. On iOS, an app the user swiped away from the app switcher can still receive VoIP pushes; on Android, force-stopping an app genuinely stops it until it is reopened. That difference explains a lot of “it works on my Android but not hers” arguments.
• Check battery optimization and Doze on Android. Aggressive OEM battery managers, particularly on some Chinese-market Android skins, will restrict background execution regardless of what Google’s own documentation says should happen, and they are behind a large share of Android softphone problems. The softphone needs to be excluded from battery optimization for that device.
• Look for a push proxy in the signalling path. Some SIP platforms use a push gateway that intercepts an INVITE, sends the push, waits for the client to re-register, then forwards the call. If that gateway has a short timeout and the device is slow to wake, the call reaches voicemail before the client is ready.

The honest version of this section: if you are running an open-source SIP client with no push infrastructure behind it, background ringing is not a bug you can troubleshoot away. Those clients keep a socket alive instead, which drains the battery and dies as soon as the OS suspends the app. That is a design trade-off, not a misconfiguration, and it is the one class of common softphone problems that settings alone will never resolve.

One-Way Audio, or No Audio at All

The complaint: “The call connects, I can see the timer running, but they cannot hear me.”

One-way audio is a media path problem, and it is the softphone issue most often blamed on the wrong layer. Signalling worked, which is why the call connected at all. The RTP media stream did not.

Four terms, one line each:

• NAT traversal is the general problem. Your device sits behind a router with a private IP address, and it has to tell the far end a public address where media can actually reach it.
• STUN is the lightweight fix, a server that tells the client what its public address and port look like from outside.
• TURN is the fallback, a relay that carries the media when a direct path cannot be established.
• ICE is the negotiation process that tries the candidate paths and picks one that works.

If STUN is unreachable and there is no TURN relay configured, a client on a restrictive network will advertise an address nothing can route to, and audio flows in one direction only.

SIP ALG deserves to be named directly, because it silently causes more softphone call quality issues than anything else in a small office. SIP Application Layer Gateway is a feature in consumer and small-business routers that inspects SIP packets and rewrites the addresses inside them, trying to be helpful. It was designed for a world before modern NAT traversal, and its rewrites now routinely conflict with what the client and server already negotiated. The rule of thumb across the industry is straightforward: turn SIP ALG off. If disabling it fixes one-way audio instantly, you have your answer, and you should check every other router in that customer’s estate for the same setting.

Other checks when troubleshooting softphone issues that present as missing audio:

• Verify the app actually holds the microphone permission. On macOS and Windows this is a per-app privacy setting that can be revoked by a policy push without the user noticing.
• Check for asymmetric firewall rules. Outbound RTP allowed, inbound RTP blocked, produces textbook one-way audio.
• Confirm the RTP port range on the client matches what the firewall permits. Platforms differ, and a range that is open for the desk phones is not automatically open for the softphone.
• Test on a mobile data connection. If audio is fine on cellular and broken on the office WiFi, the fault is in that network, not in the softphone.

Calls Drop When You Walk Out of WiFi

The complaint: “I take a call at my desk, walk to the parking lot, and it dies about ten seconds after I get to the door.”

WiFi-to-cellular handoff is the moment the device’s IP address changes because it moved from one network to another. Dropped calls on the move are among the most common softphone problems in any mobile-first deployment, and this is why. The SIP session was negotiated against the old address. The media stream was too. Unless the client detects the change and renegotiates, the far end keeps sending audio to an address that no longer exists, and the call goes quiet before it times out.

A well-built softphone handles this by watching for the network change and issuing a re-INVITE with the new media address, or by performing an ICE restart to reselect a working candidate pair. It is not free, and it is not automatic. This is one of the clearest places where two apps registered to the same platform behave completely differently, because the difference lives in the client, not in the PBX.

What to check when troubleshooting softphone issues that only appear away from the desk:

• Reproduce it deliberately. Start a call on WiFi, disable WiFi on the device, and time how long the audio takes to come back. Under two seconds is good. Never coming back is a client that does not handle handoff.
• Look for a corporate WiFi that spans several access points. Roaming between APs on the same SSID changes the layer-2 path, and on some networks it changes the IP too, which produces the same drop indoors.
• Check whether the platform holds sessions open through a re-INVITE. Some session border controllers are configured to reject a mid-call address change as a security measure.
• Check the concurrent session count. This is the one people forget, and it comes straight from how this market is licensed.

That last point is worth expanding, because it is a quirk of how this market is sold. PBX providers and MSPs license numbers to companies with a fixed allocation of seats or sessions, and that allocation is how they bill. Sessions are a hard ceiling. When a customer reports that calls fail or drop at predictable busy times, and the network tests come back clean, check whether they are hitting the session limit their provider sold them before you spend another hour on packet captures. A capacity ceiling and a network fault look identical from the user’s chair, and plenty of softphone connection issues turn out to be the former.

Choppy, Robotic, or Underwater Audio

The complaint: “It sounds like they are talking through a fan.”

Now we are into measurable territory, which makes this the easiest part of softphone troubleshooting to resolve properly rather than by guesswork.

Three numbers to know:

• Jitter is variation in the arrival time of packets. Voice packets are sent at a steady interval, usually every 20 ms, and if they arrive unevenly the jitter buffer has to stretch or drop audio to compensate. Keep it under about 30 ms.
• Packet loss is packets that never arrive at all. Under 1% is usually tolerable with modern codecs. Above 3% the call is unusable.
• MOS, or Mean Opinion Score, is the 1 to 5 quality scale defined in ITU-T P.800. A score of 4.0 and above is what people describe as a good call, and anything under 3.5 generates tickets.

Codec choice is the other half of this.

• G.711 is uncompressed and predictable, roughly 64 kbps of payload plus overhead. It sounds fine when the network is healthy and has no resilience when it is not.
• Opus adapts its bitrate to conditions and handles loss far better, which is why it is the sensible default for a mobile softphone.

Our own published guidance on building a VoIP client puts a single call at around 100 kbps in each direction once overhead is counted, and keeps one-way latency under 150 ms, which lines up with the ITU-T figure above.

Practical sequence for softphone call quality issues:

• Measure before you change anything. Pull jitter, loss and MOS from the platform’s own call detail records for the affected calls. Guessing at 11pm because a user said “it was bad earlier” is not troubleshooting.
• Check whether the problem is directional. Loss on the inbound leg and loss on the outbound leg have different causes and usually different owners.
• Look at what else is on the WiFi. A single 4K stream on a congested access point will produce exactly this symptom, and no codec choice will save it.
• Check the negotiated codec, not the configured one. A client set to prefer Opus that ends up on G.711 because the trunk only offers G.711 will behave differently than expected under loss.
• Test wired. If a laptop on Ethernet is clean and the same account on WiFi is choppy, stop looking at the softphone.

The App Registers but Calls Fail

The complaint: “It says connected. When I dial, it just says call failed.”

Registration and call setup are different transactions, and passing the first tells you almost nothing about the second. Softphone connection issues get misdiagnosed here more than anywhere else. The symptom is nearly always an interop mismatch between the client and whatever sits between it and the outside world.

Two terms are worth separating here. A SIP proxy routes signalling: it sits inside your platform and decides where a call should go. A SIP trunk is the connection between your platform and a carrier that hands calls to the public network. Understanding where the protocol ends and the app begins makes these failures much easier to read, because the fix lives at a different layer than most people first look.

When troubleshooting softphone issues at this stage, read the SIP response code before anything else:

• 403 Forbidden usually means credentials or a permissions rule, not a network problem. Check whether the extension is allowed to dial that destination class.
• 404 Not Found points at dialplan or number formatting. E.164 versus 10-digit dialing mismatches live here.
• 488 Not Acceptable Here is a codec or media negotiation failure. The two ends could not agree on anything they both support.
• 503 Service Unavailable points upstream, at the trunk or the carrier, and is often capacity rather than configuration.
• 407 Proxy Authentication Required repeating in a loop means digest authentication is failing, commonly after a password change that was applied on the platform but not on the client.

If registration holds and outbound calls fail on one carrier but work on another, you have a trunk-level interop problem rather than a client fault, which is a distinction worth making early in any softphone troubleshooting. Our own connecting a softphone to your PBX walkthrough covers the settings that most often need to match, and the same checks apply whether you are adding a client to an existing platform or migrating one.

Video Will Not Start

The complaint: “Audio works. When I turn on video, the other person sees a black square.”

Video sits on the same plumbing as everything else, so most of the common softphone problems above apply here too, with two extra failure modes: a much larger bandwidth requirement, and a second media stream that has to complete its own NAT traversal.

• Check camera permission separately from microphone permission. They are granted independently on every modern platform, and a user who approved one may have declined the other.
• Check for TURN over TCP 443. On restrictive corporate networks, UDP media is blocked outright and video only works if the platform can relay over TCP on port 443. Audio sometimes squeaks through where video does not because the bandwidth profile is different.
• Check the negotiated video codec. A client offering only VP8 against a platform expecting H.264 produces a connected call with no picture.
• Check available uplink. A user on a saturated home connection can hold an audio call at 100 kbps and fail entirely at the 1 to 2 Mbps a decent video stream wants.
• Check hardware acceleration on desktop. An outdated GPU driver on Windows produces black video far more often than anyone expects.

Platform-Specific Quirks: iOS, Android, Windows, macOS and Linux

The same account on the same platform behaves differently across operating systems, and knowing where each one bites cuts softphone troubleshooting time in half.

• iOS is the strictest about background execution and the most rigid about the PushKit and CallKit pairing. It is also the platform where a VoIP push arriving without a CallKit report gets the app into trouble. Do Not Disturb and Focus modes are a frequent false alarm here.
• Android is the most fragmented. Stock Android behaves as documented; OEM battery managers frequently do not. Add the app to the never-restrict list before you conclude push is broken.
• Windows is where audio device selection causes the most tickets. A headset that disconnects and reconnects can shift the default device mid-session, and the app keeps sending audio to a device nobody is wearing.
• macOS enforces per-app microphone and camera privacy at the OS level, and a managed device policy can revoke those permissions without a visible prompt.
• Linux is where audio subsystem differences show up, particularly across PulseAudio and PipeWire configurations. Fewer users, but the tickets take longer.

When the Problem Is the Softphone, Not Your Network

Some softphone problems are not fixable at the network layer because they are properties of the client. It is worth being direct about this, since teams can lose weeks tuning a firewall for a limitation that was designed in.

Free tiers and open-source SIP clients frequently ship without hosted push infrastructure, which brings back the background ringing problem in the first section. Many do not implement ICE restart, so WiFi-to-cellular handoff drops the call every time. Some support a single simultaneous registration, so a user with a desktop and a mobile client will find one of them silently stops ringing. None of that makes those clients bad. It makes them a different tool.

Here is the fastest test we know for separating the app from everything behind it, and it comes directly from how we build our own product. Our softphone sits on top of the PBX a reseller already runs, as an add-on rather than a replacement, so the back end stays exactly where it is and only the end-user experience changes. That architecture is also a diagnostic. Register a second, different client to the same extension on the same PBX from the same network. If the second client behaves and the first does not, the fault is in the app, and no further network work will help. If both fail identically, the fault is in the platform or the path.

Run the three-step version of softphone troubleshooting when you need an answer fast:

• Step one, change the network. Same device, same account, cellular instead of WiFi. If it clears, the customer’s network owns the problem.
• Step two, change the client. Same network, same account, different softphone. If it clears, the app owns the problem.
• Step three, change the account. Same device, same network, a known-good extension. If it clears, the fault is in that user’s provisioning, not in anything shared.

Whoever is still failing after those three swaps is where the fix belongs, and that is most of softphone troubleshooting in one paragraph. For resellers evaluating what to hand their support desk, our guidance on what to look for before you commit covers the client-side capabilities that quietly remove whole categories of ticket.

Frequently Asked Questions

Why does my softphone stop receiving calls when the app is in the background?

This is the classic softphone not ringing case. It happens because the app is being woken by an ordinary push notification instead of a VoIP push, or because its SIP registration expired while the device was asleep and nothing re-registered it. VoIP push wakes the app immediately and is the only reliable path on a modern mobile OS; standard push is batched and delayed by the operating system, which is exactly the delay users report as a missed call.

Do I need push notifications if I use an open-source SIP client?

You still need something to wake the app, and without hosted push the usual answer is a persistent connection that keeps the client awake. That works, and it costs battery, and the operating system will eventually suspend the app anyway. On a desktop that is a fair trade. On a phone that a field engineer carries all day, it is the reason the battery is at 20% by lunchtime.

What is SIP ALG and should I turn it off?

SIP ALG is a router feature that inspects and rewrites SIP messages as they pass through, on the assumption it is helping with NAT. In practice it conflicts with the address negotiation the client and server already performed. Turn it off. It is one of the highest-yield single changes in softphone troubleshooting, and the symptoms it causes (one-way audio, calls that connect then go silent) look exactly like problems people spend days chasing elsewhere.

How do I test whether the problem is my network or my provider?

Run three calls and record jitter, packet loss and MOS for each. On the customer’s WiFi, on cellular, and on a wired connection if one is available. If jitter stays under 30 ms, loss under 1% and MOS above 4.0 on cellular but not on WiFi, the local network owns it. If all three paths show the same degradation, escalate to the platform or carrier, because the fault is upstream of anything you control.

Can I fix common softphone problems without replacing my PBX?

In most cases, yes. Registration, push behaviour, NAT handling and handoff are client-side and platform-side concerns that can be addressed without touching the underlying phone system. That is the whole basis of the add-on model: resellers running their own voice service can change the end-user app while keeping the infrastructure, numbers and billing exactly as they are.

Key Takeaways

• Sort by symptom, not by feature. Background ringing failures, one-way audio, handoff drops and choppy audio have nothing in common except the ticket title.
• Push is the first thing to check when a softphone is not ringing. VoIP push plus a current SIP registration, or the phone stays quiet.
• SIP ALG is the highest-yield single fix for one-way audio. Turn it off on every router in the estate and retest.
• Measure before you tune. Jitter under 30 ms, packet loss under 1%, MOS above 4.0, one-way delay under 150 ms. Numbers end arguments.
• Read the SIP response code. 403, 404, 488 and 503 each point at a different owner and cut an hour out of any softphone troubleshooting session.
• Swap one variable at a time. Network, then client, then account. Whichever swap clears the fault names the culprit.
• Some limits are design, not defects. A client with no push infrastructure will never ring reliably in the background, and that is a procurement decision rather than a support one.

Where This Leaves You

Most softphone connection issues are not mysterious once you stop treating “the app is broken” as a diagnosis. They are a small set of well-understood failures with well-understood fixes, and the reason they feel chaotic is that they all arrive through the same support queue wearing the same words. Build the symptom list into your tier-1 script, put the three swaps at the top of it, and the volume drops.

If softphone troubleshooting is quietly consuming your support hours, the iotum Communicator is the white-label softphone we build for VoIP service providers, ITSPs and MSPs who want a better end-user app on the PBX and carrier they already run. Teams who would rather build their own can start from our build call handling into your own app documentation instead. Book a demo to learn more about our solution.