Freeze the exact mobile client, account and background state
Record the Linphone application or Liblinphone build, iOS or Android version, account identity, SIP service, network, timestamp and call direction. State whether the app was foregrounded, merely backgrounded, suspended after an idle period, removed from the recent-app view, force-stopped, battery-restricted or restarted after a device reboot. Those states are platform- and release-sensitive; do not publish one successful background call as proof of every lifecycle state.
Linphone also ships desktop clients, but Liblinphone documents push availability as an Android and iOS concern. Keep desktop registration and mobile push conclusions separate. A feature shown by the Linphone product page or SDK is a candidate capability, not evidence that one distributed client exposes the same control or that a third-party account accepts it.
Separate permission, library capability and account configuration
Check the operating-system notification permission, the running library's push availability and enabled state, and the affected account's effective push parameters as three different observations. Liblinphone 5.4 AccountParams says its push controls determine whether push information is added to Contact parameters; the PushNotificationConfig holds provider, parameter and push resource identifier values. A visible permission toggle does not prove that the app obtained a current token or inserted it into a REGISTER.
Preserve which component owns each value: application package, signing or project identity, operating-system push service, runtime Core, account object or remote provisioning. If configuration APIs, user settings and provisioned state disagree, resolve the effective account object before changing the SIP server or device-wide power policy.
Prove what the REGISTER advertised without disclosing the token
RFC 8599 defines pn-provider, pn-prid and, when required, pn-param Contact URI parameters for requesting SIP push notifications. Flexisip documents the same three required values for its implementation. Capture whether the REGISTER for the affected binding contained the expected parameter names and whether the registrar accepted and retained the binding; redact the values because the push resource identifier addresses a particular application instance.
A locally generated token, a configured PushNotificationConfig or a 200 response to an unrelated binding does not prove that the effective Contact stored the current push information. Re-enrollment, app reinstall, device restore, package or signing changes and account replacement can change ownership. Compare bounded hashes or suffixes only when needed to correlate client and registrar evidence.
Require the SIP service to participate in the wake path
RFC 8599 places a push-capable SIP proxy in the registration and incoming-request path. When an initial SIP request targets a suspended user agent, the proxy requests a push, the push service wakes the application, the user agent refreshes its REGISTER and the proxy then forwards the waiting request using normal SIP routing. A standard third-party SIP login or successful foreground registration does not establish that the service implements this sequence.
Flexisip documents one concrete implementation and says it stores push parameters with the contact, holds the incoming INVITE, requests the push and sends the pending INVITE after the client creates a new registration path. Other providers can use different supported mechanisms. Obtain the provider's current statement for the exact account rather than assuming that general SIP interoperability includes push.
Correlate push request, delivery, wake and refreshed registration
Build one timestamped chain: inbound INVITE reached the responsible proxy, the proxy matched the intended stored binding, requested a push for that binding, the platform accepted or rejected the request, the device received it, the application was awakened, and the client sent a refreshed REGISTER on a usable path. Liblinphone 5.4 Core documents processPushNotification for manually handled notifications and says it ensures proxy configurations are registered so the associated call or message can be delivered.
Do not compress this chain into “push worked.” A provider acceptance is not operating-system delivery, a notification is not an application wake, and an app wake is not a successful registration. Preserve clock offset and stable call or transaction identifiers while excluding message payloads, full device tokens, credentials and unrelated user data.
Keep the INVITE, call interface, answer and media as later results
After registration recovery, prove that the retained or retried INVITE reached the correct Linphone binding, the client presented an incoming-call interface, the user could answer, SIP dialog establishment completed and two-way protected media followed the negotiated path. RFC 8599 notes that push wake-up necessarily adds delay; compare timing against the caller and service transaction limits rather than attributing every late failure to notification permissions.
Repeat each required background state over Wi-Fi and mobile data, after network transition and after restart without changing several controls at once. Correct only the demonstrated owner: permission, app state, token enrollment, account Contact parameters, registrar retention, proxy push action, platform delivery, client processing, refreshed path, INVITE routing or later call and media handling. This guide is documentation-derived and makes no background reliability or emergency-calling claim.
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.