Softphone rings only when open: trace registration and push wake-up

Reproduce one state transition instead of a generic missed call

Record one authorized incoming call with time and timezone, caller, called SIP identity or number, device, operating-system version, softphone build, SIP account, network and app state. Test foreground, ordinary background, locked screen, post-reboot and network-change states separately. A user-dismissed app, operating-system suspension and a deliberately force-stopped app are not interchangeable conditions.

Keep foreground SIP registration, background reachability, notification presentation, application wake-up, refreshed SIP contact, delivered INVITE, alerting, answer and two-way media as separate evidence. If calls work only while the app is visible, do not begin by changing codecs, RTP ports or the PBX dialplan; those later stages cannot explain an INVITE that never reaches a suspended client.

Identify who owns background reachability

A mobile softphone may keep a connection active, use an operating-system push service, register a vendor push proxy, rely on a SIP network implementing RFC 8599, or combine these methods. Write down the selected mode and each owner: app, APNs or FCM token, vendor service, SIP proxy or registrar, PBX route and mobile operating system. A push toggle in the app does not prove that the SIP service supports the same architecture.

Linphone's current FAQ says mobile push is enabled for Linphone accounts, not ordinary third-party SIP accounts, while its business offering can add a push-gateway path. SessionTalk documents multiple-registration, synchronous and single-register modes in which its push service assumes different registration responsibilities. Do not transfer one product's token format, proxy behavior or compatibility statement to another.

Prove token enrollment and the SIP binding separately

RFC 8599 describes a SIP user agent obtaining a push resource identifier from a notification service, carrying push parameters in REGISTER, and receiving network capability evidence in the successful response. Vendor architectures can use additional or proprietary enrollment. Preserve the app's notification permission, token-registration result, account identifier, push-service project or environment, SIP REGISTER contact and expiry without exposing the token or credentials in a shared ticket.

A current foreground SIP binding is not proof that the server retained valid push information for a suspended device. Likewise, an APNs or FCM token accepted by a vendor is not proof that the PBX routes the called identity through that vendor. Compare a working device or account while keeping account type, app edition, operating system and registration mode visible.

Follow the incoming INVITE through the wake-up chain

Trace the first INVITE from the provider or PBX to the entity that owns the sleeping device's contact. Determine whether that entity recognized the push parameters, retained the request or transaction, asked APNs or FCM to wake the right app instance, and received a refreshed REGISTER or connection before forwarding the INVITE. RFC 8599 names a request-holding bucket; SessionTalk documents a vendor flow in which its push server receives the INVITE, requests APNs or FCM delivery, accepts a secure client connection and forwards signaling.

Record the first missing boundary: no INVITE at the push-aware proxy, no push request, notification-service rejection, no device receipt, no app wake, no refreshed binding, expired retained request, no alert or an answer that fails later. A provider CDR marked missed, a PBX ring timeout or a visible notification does not identify which earlier stage succeeded.

Keep Apple and Android operating-system contracts visible

Apple defines the PushKit VoIP type for live call invitations and requires apps to report incoming calls promptly to CallKit; repeated failure can stop future VoIP launches for the app. Android restricts background foreground-service starts and while-in-use access such as the microphone, with version-dependent exceptions. Firebase distinguishes normal delivery, which can be delayed in Doze, from high-priority user-visible delivery and can deprioritize misuse.

These platform rules belong to the app developer and deployed app version. An administrator should verify notification permission, Focus or do-not-disturb policy, app-specific battery controls, data access, vendor status and supported release rather than disabling device security or optimization globally. A notification arriving silently can be a presentation-policy issue after successful push delivery; it is different from the app never waking.

Separate push signaling from call media and privacy

A push service may learn account, device and call-routing metadata, and some vendor designs proxy SIP signaling after wake-up. SessionTalk documents direct RTP between device and PBX in its push architecture, but that does not establish the media path for another client or one deployed account. Map where signaling terminates, which service stores tokens or pending requests, how long data is retained and which party operates each system.

After the app wakes and answers, confirm SDP, media addresses, protected signaling and media, RTP in both directions and normal hangup as separate stages. Do not collect notification payloads, tokens, credentials, full SIP messages or media beyond the authorized diagnostic scope. Push delivery does not prove audio, and two-way audio in the foreground does not prove background call delivery.

Correct one owner and run a lifecycle acceptance matrix

Correct only the demonstrated owner: account or entitlement, token enrollment, notification permission, vendor project, SIP push parameters, registrar or proxy support, registration mode, PBX route, certificate or network access, platform-compliant alert handling, or app release. Preserve the old state and rollback. Do not whitelist broad address ranges, weaken authentication or keep duplicate registrations merely to hide an unproven ownership mismatch.

Repeat approved incoming tests in foreground, background, locked-screen, after device restart, after app update, on Wi-Fi and mobile data, and after one network transition. Record alert time, answer result, SIP dialog, both media directions, hangup, battery policy and recovery from a missed push. No mobile device, application, token, notification service, push server, SIP account, PBX, registration, INVITE, alert, media path, availability, battery result or call was inspected or tested for this guide.

For MizuDroid, identify direct push, gateway push or service

MizuDroid documents three background paths: direct push from a capable SIP server, a Mizutech gateway that keeps an extra registration and forwards the INVITE after FCM wake-up, or an Android background service. Preserve the installed package and selected mode. The gateway documentation says uninstall is not detected immediately and an unused binding can remain for a few days, so an old Contact does not prove current token delivery or a reachable device. Disable or remove the binding through the documented path and verify one expected active handset.

Use Zoiper's documented registration and Push Proxy boundaries

The Zoiper-specific diagnostic adds the vendor's distinction between calls that never work and calls that fail after a few minutes, its documented Push Proxy wake-up path and its registration-expiry constraints. Confirm all current client labels and network requirements against the deployed build.

Check 3CX subscription age before replacing the push path

For a 3CX mobile client, use the push-subscription expiry diagnostic to compare the last app connection with the lifetime belonging to the installed PBX update. Preserve the old subscription evidence before generating a fresh QR enrollment.

Use the Acrobits branch when the wrong device wakes

If Groundwire or Acrobits Softphone wakes an unexpected, duplicate or supposedly removed handset, use the product-specific device-lifecycle diagnostic. It follows PBX contacts, SIPIS instances, token pairs and documented push-status stages.

Follow the PortSIP ONE replacement-call sequence

For PortSIP ONE on a supported PortSIP PBX, the focused mobile diagnostic traces the vendor-documented token, push, wake, new REGISTER and new INVITE states without treating a foreground registration as background-delivery proof.

Use the Bria registration-mode branch

For Bria Mobile, the product-specific diagnostic distinguishes Continuous, Standard, Single Device Takeover and Single Device Emulation registration behavior, then follows the unique Push-server Contact, notification, WebSocket wake-up tunnel and first SIP response.

Use the Linphone-specific branch for account Contact evidence

When the affected client is Linphone, use the Linphone background-call diagnostic to read Liblinphone Core and AccountParams state, correlate the stored push-aware Contact and follow the proxy wake sequence before changing media settings.

Use the SessionTalk mode-specific branch when push is enabled

For SessionTalk, continue with the mode-specific diagnostic to distinguish an intentional extra binding, failed registration handoff, blocked push server, missing APNs or FCM delivery and later app presentation.

Keep provisioned push state separate from the live wake path

Use the Linphone provisioning guide to prove the effective setting, then test registration, proxy push, device wake and INVITE delivery independently.

Require reachability evidence after registration Ok

The Linphone registration guide prevents Ok from being treated as proof of push, wake or INVITE delivery.

Keep a Linphone update separate from push-path proof

The Linphone guide records 6.2.4, but an installed build still does not prove push enrollment, proxy retention, device wake, refreshed registration or delivered INVITE.

Keep Sipnetic registration separate from Android presentation

The Sipnetic diagnostic checks registrar Contact, INVITE arrival, Android lifecycle and UI presentation before answer and media. The Android 16 update note is not proof of background delivery.

Apply Wave-specific background controls

For Wave Mobile, use the focused diagnostic to prove UCM policy, desktop-active suppression, background data, battery restrictions and app wake.

Use the RingCentral-specific notification and push branch

The RingCentral diagnostic separates provider attempt, call handling, OS delivery, wake, alert, answer and media.

Check Zoom entitlement and call handling before background-delivery assumptions

The Zoom Workplace diagnostic separates service routing, shared or queue state, app path, alert, answer and media.

Use the NextivaONE foreground and background branch

The NextivaONE diagnostic compares notification, wake, alert, answer and the documented tablet-browser active-tab limit.

Use the Teams service, notification and endpoint branch

The Teams Phone diagnostic follows routing, mobile and desktop notification choices, ringer, answer and final endpoint.

Use the Dialpad route, notification and endpoint branch

The Dialpad app diagnostic follows call handling, browser permission, app alert, ringtone, answer and final endpoint.

Use the 8x8 route, DND and notification branch

The 8x8 Work diagnostic follows target, route decision, presence, notification, ringtone, answer and final endpoint.

Use the VBC route, mute and notification branch

The VBC diagnostic follows route decision, DND, continuity, client mute, notification, ringtone and final endpoint.

Trace the Aircall distribution and notification chain

The Aircall diagnostic follows assignment, availability, background state, browser or operating-system notification, ringtone and final endpoint.