Freeze one missed call and the exact lifecycle state
Record one authorized incoming attempt with timestamp and timezone, caller, called extension, PortSIP PBX and SBC versions, PortSIP ONE build, iOS or Android version, device model, network, app state and expected alert. Distinguish a locked screen, backgrounded app, operating-system eviction, user force-close, device restart and sign-out; they are different lifecycle events even when the user says the app was closed.
Capture whether foreground calls still arrive, whether a notification appears without a call screen, whether accepting it opens the app, and whether the PBX later sends an INVITE. Do not reset the extension or reinstall the app before preserving the token, registration and call evidence that separate those states.
Confirm the supported client and server generation
PortSIP documents PortSIP ONE for PortSIP PBX 22.0 or later and says it does not support PBX 16.x. Confirm that the installed mobile app is PortSIP ONE rather than the legacy PortSIP Softphone, and record the distribution channel and exact build. A successful foreground login does not remove that generation boundary.
The current 10.9.4 notes are dated September 28, 2026. They also record earlier Android push fixes in 10.9.1 and several 10.9.4 call and network changes. Those entries justify version capture and a controlled update review; they do not prove that an uninspected device has the fix or that every background failure shares the recorded cause.
Prove token issuance and the X-Push registration
PortSIP describes the mobile app obtaining a device token from Apple Push Notification service or Firebase Cloud Messaging, then including device platform, token, application identifier and push preferences in an X-Push header on SIP REGISTER. Preserve PBX and client evidence that the affected installation received a current token and submitted a registration for the intended extension.
A normal SIP Contact, a valid account password and a visible online label do not prove that push metadata exists or remains current. Treat app reinstall, account re-enrollment, restored phone backup, operating-system migration and notification-permission changes as possible token-lifecycle events, then correct only the first demonstrated divergence. Do not publish the token or credentials in a ticket.
Follow APNs or FCM delivery before changing SIP timers
For an app that is not running, PortSIP documents a PBX push request through APNs or FCM before the operating system wakes and alerts the device. Correlate the incoming PBX call, selected extension, retained push-capable registration, push-request result, platform delivery evidence and device notification state.
A reachable PBX, an unexpired SIP registration or a foreground call does not prove delivery through the platform push service. Likewise, an Android or iOS notification setting cannot prove that the PBX submitted a valid request. Avoid shortening registration, keepalive or NAT timers as a generic cure when the missing state is the token or push path.
Separate wake-up, replacement REGISTER and replacement INVITE
PortSIP’s documented call flow says the operating system launches the app after the user accepts the pushed call, the app sends a new SIP REGISTER and the PBX sends a new INVITE to the updated Contact. Record those as ordered evidence. A displayed notification without a replacement REGISTER points to a different boundary from a successful REGISTER that never receives the replacement INVITE.
If the INVITE reaches the app, continue separately through alert presentation, answer, SDP and media. Do not report push as repaired merely because the app opened, and do not diagnose APNs or FCM from a later one-way-audio or codec failure.
Retest a bounded state matrix and revoke stale instances
After the supported correction, test one foreground call, locked-screen call, backgrounded-app call and the exact previously failing closed-app state on the authorized extension. Add Wi-Fi and mobile-data transitions only when they belong to the incident. Record notification, app launch, new registration, INVITE, alert, answer and two-way media as separate outcomes.
Confirm that retired or reinstalled device instances no longer alert and that another approved endpoint still works. Keep emergency calling, battery impact, delayed delivery, operating-system policy and carrier-network behavior outside this result unless independently accepted. This workflow is documentation-derived and was not reproduced on a customer or laboratory system.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- PortSIP ONE release notes ↗
- PortSIP PBX mobile-push architecture ↗
- PortSIP ONE mobile app and PBX generation boundary ↗
- PortSIP ONE desktop sign-in paths ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.