Freeze one call and identify every device that reacted
Record one authorized incoming call with timestamp and timezone, caller, called SIP identity, account label, Groundwire or Acrobits Softphone build, operating system, handset, network and foreground, background or locked state. List every device that rang, displayed a notification, logged a rejected call or remained silent. Preserve PBX contacts and the app settings before deleting anything.
A notification, a native call screen, a SIP ring, an answered dialog and two-way media are different outcomes. A removed handset can disappear from a user inventory while an account credential, PBX contact, SIPIS instance or device-token pair remains elsewhere, so start with identity and lifecycle evidence rather than a broad credential reset.
Prove the effective incoming-call mode for each account
Acrobits documents both a global Incoming Calls control and an account-specific control. Record the effective setting for the affected SIP account on every current device. Push mode lets SIPIS maintain the SIP registration on behalf of the app, while Standard mode keeps registration on the device; those are different owners and can coexist with other legitimate contacts if the PBX permits them.
Match the exact SIP username, domain, outbound proxy and transport without exposing the password. A handset showing the expected account label does not prove that it uses the expected identity or mode, and a PBX registration from a SIPIS address is not proof that one particular handset is the current token target.
Inventory PBX contacts and SIPIS instances separately
Capture the registrar contact set for the called identity at the incident time: contact URI, source, expiry, user agent where available and recent transition. Then identify which contact belongs to an on-device Standard registration and which is maintained by SIPIS. Do not assume that two contacts are duplicates until the service policy and authorized-device inventory say only one should exist.
SIPIS stores persistent instance data and can register on behalf of a device. Its cleanup documentation describes an instance moving to Off, stopping registration and being deleted only after it becomes idle. A short-lived Off state and a stale PBX contact can therefore be adjacent but are not the same object or timestamp.
Follow one INVITE and its push progress
Trace the incoming INVITE to the selected registrar contact. Acrobits documents SIPIS provisional X-Sipis-Push-Status values that separate trying to alert devices, platform acceptance of a push notification and a device making progress. Retain those headers and the terminal response where the authorized trace exposes them.
Push-Notification-Sent means the platform-specific service accepted the notification; it does not prove delivery to the intended handset, application wake-up or a user answer. Device-Making-Progress shows that a device started responding, but the later SIP connection, answer, bridge and media still require their own evidence. PBX forking can also send the same call to another valid contact outside SIPIS.
Use token cleanup and reinstallation evidence cautiously
Acrobits documents cleanup after age limits, invalid or expired push tokens and iOS reinstallation. On reinstallation, a PushKit VoIP token can remain the same while the ordinary APNs token changes; SIPIS says it removes the older conflicting token pair to prevent duplicate pushes and earlier-installation registrations. It also turns an instance off after its last usable pair disappears.
These behaviors are lifecycle evidence, not a promise that an uninspected wrong-device incident has already converged. Record uninstall or reinstall time, last app communication, current app identity and the later registration set. Do not expose raw push tokens in a shared ticket or force repeated reinstalls to manufacture cleanup.
Correct one owner, revoke deliberately and retest the matrix
Correct only the first demonstrated divergence: wrong account identity, unintended global or per-account mode, an unauthorized device, a still-valid credential, a stale PBX contact, a failed token cleanup path or provider forking policy. Use documented app, PBX or provider controls, preserve rollback and rotate a credential when its confidentiality or device ownership is no longer trustworthy rather than treating contact deletion as revocation.
Retest foreground, background and locked delivery on each authorized handset, then confirm the removed handset does not receive a notification or call. Include restart, network transition, answer, both media directions and hangup. Protect call metadata and credentials. 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.
- Acrobits SIPIS architecture ↗
- Acrobits SIPIS incoming-call handling ↗
- Acrobits SIPIS push-status indication ↗
- Acrobits SIPIS instance cleanup ↗
- Acrobits push-notification architecture ↗
- Acrobits incoming-call modes ↗
- Acrobits push versus Standard registration ↗
- Groundwire incoming-call settings ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.