Reproduce one lifecycle state and keep a foreground control
Choose one Linphone mobile build, account, caller, network and timestamp. First prove the foreground call, then reproduce the exact failing state: background, suspended after idle, recent-app removal, force-stop, battery restriction, reboot or Wi-Fi-to-mobile transition. Record the earliest difference—registration expired, no push request, push rejected, no device delivery, no wake, no refreshed REGISTER, no INVITE, no call interface, failed answer or no media.
Do not reinstall the app, clear storage or toggle several device policies before preserving the failed chain. Those actions can replace the token, account object and registration binding, erasing the evidence required to identify the owner.
Read permission, Core and account state separately
Confirm the operating-system notification permission and app-specific background or battery policy for the affected state. Then read whether push is available and enabled in the running Liblinphone Core and whether the effective AccountParams allows the expected push information. A notification setting that looks correct is not a token, and an enabled Core is not proof that the affected account advertises that token.
If provisioning manages the account, compare its source, applied object and runtime value. Avoid disabling device-wide security or power controls as a first test. Make one bounded, reversible change only after the failing layer is visible.
Compare the current push identity with the stored Contact
Inspect a sanitized REGISTER from the affected account and the registrar's stored binding. Confirm the presence—not the public disclosure—of the expected pn-provider, pn-prid and required pn-param values, plus the Contact expiry, transport and path. Compare a bounded correlation value with the current application instance and determine whether an older device, restored app or previous install owns the retained binding.
A 200 response proves acceptance of that REGISTER transaction, not that an incoming proxy selected the intended binding later. If the Contact lacks push parameters, remains stale or expires before the call, stop at registration ownership rather than changing codecs, audio devices or media relays.
Prove the proxy requested the push for the intended binding
At the SIP service, follow the incoming INVITE to the target address of record and the selected stored contact. Preserve whether the proxy recognized a suspended or unreachable client, held the INVITE, requested a push using that binding and received a result from the push service. Linphone's Flexisip documentation provides one such sequence, but a third-party registrar needs its own documented support and evidence.
A packet capture at the phone may show no push because platform push delivery is not ordinary SIP traffic. Conversely, a provider log saying the request was accepted does not prove device delivery. Keep the proxy, platform and device observations as adjacent but distinct stages.
Correlate device delivery with wake, REGISTER and INVITE
Use synchronized timestamps and bounded identifiers to show the platform notification reached the device, the app processed it, Linphone refreshed the affected registration and the proxy routed the waiting or retried INVITE to the new path. When the app handles notifications manually, the Liblinphone 5.4 Core reference ties processPushNotification to ensuring registration and waiting for the related MESSAGE or INVITE Call-ID.
If opening Linphone repairs the call, compare what the foreground transition changed: token enrollment, account activation, network path, registration or only presentation. Treat a refresh that succeeds after the caller times out as a timing result, not as background-call success.
Correct one owner and repeat the complete acceptance matrix
Correct the first failed stage only: operating-system permission or lifecycle policy, application push state, token enrollment, account configuration, stored Contact, registrar retention, proxy push request, platform delivery, app processing, refreshed registration, INVITE routing or call presentation. Preserve a rollback and do not expose token values or calling identities in shared diagnostics.
Acceptance requires the intended app state, push request and delivery, wake, refreshed registration, INVITE, call interface, answer and two-way media, repeated on each required Wi-Fi, mobile and lifecycle condition. Record failures independently from emergency-calling or guaranteed-availability claims. No Linphone client, device, account, provider, notification, SIP transaction, packet path or call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Linphone softphone product features ↗
- Linphone supported platforms and downloads ↗
- Linphone SIP account and interoperability FAQ ↗
- Linphone Flexisip push-notification specification ↗
- Liblinphone 5.4 AccountParams push controls ↗
- Liblinphone 5.4 PushNotificationConfig ↗
- Liblinphone 5.4 Core push processing ↗
- RFC 8599: Push Notification with SIP ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.