Freeze one app state and one inbound attempt
Record the platform, operating-system version, exact Zoiper build and edition, SIP account, network, foreground or background state, screen-lock state and time since the last successful registration. Reproduce one authorized inbound call with synchronized PBX or provider signaling and client diagnostics. Compare foreground, background, locked, force-stopped, rebooted and post-network-change states one at a time.
A call that never reaches the device is not a codec fault. Do not alter media, port ranges or credentials until the signaling path and failure boundary are known, and do not place SIP passwords, push tokens or full telephone numbers in shared captures.
Classify never reachable versus reachable only briefly
Zoiper's incoming-call guidance separates calls that never work from calls that work immediately after registration and fail minutes later. The latter pattern can point to a registration or UDP NAT-binding lifetime; a never-working case can instead involve registration state, firewall policy, push state, or another device using the same account.
Capture the successful REGISTER and its effective expiry, the contact selected for the failed INVITE, transport, source and destination addresses and whether the PBX still considers the contact reachable. Do not treat the word Registered in the client as proof that an inbound request can still traverse the selected path.
Prove operating-system reachability before changing SIP
For Android, verify Zoiper's permitted background-data state, battery-optimization exception and any documented device-vendor power controls against the installed OS. For iOS, verify the app's cellular-data and notification access when those paths are required. Exact menu names vary by OS and vendor; use the deployed device's current controls rather than copying an older screenshot.
A force-stopped application, revoked notification permission, blocked background data or prolonged loss of connectivity can have different recovery behavior from a normal locked screen. Correct only the demonstrated control and retain the previous policy for rollback.
Identify direct registration or Zoiper Push Proxy
Zoiper says mobile operating systems restrict background execution and describes a Push Proxy path that routes SIP registration through its server without giving that server plaintext SIP credentials. A silent Apple or Google notification wakes the client so it can refresh registration before the call is delivered. Record whether this account and edition actually use that path, whether push enrollment completed and whether the device can reach the required Apple or Google service and Zoiper service.
Do not infer push entitlement from the presence of a settings label. Keep direct persistent registration, SIP keepalive, operating-system wake-up and Push Proxy as separate architectures with different owners and evidence.
Reconcile registrar expiry, NAT and network policy
Zoiper's current support text says a service-provider registration expiry below one hour can disrupt background delivery and that Push Proxy does not work below ten minutes. Its guidance also warns that shortening UDP registration expiry is not a reliable substitute for keepalive and can increase battery and signaling load. Record the registrar's negotiated value and the provider-supported range before proposing a change.
If direct UDP registration works briefly, correlate the failure with the NAT binding and use a provider-supported keepalive or a supported connection-oriented transport only after proving the owner. The Push Proxy article publishes network requirements, but its indexed modification date is January 30, 2023; confirm the current vendor range before creating a narrow allowlist. Never create a broad allow rule from an undated copy.
Follow one INVITE through wake-up and re-registration
For the failed call, correlate the PBX or provider INVITE, selected contact, Zoiper proxy receipt when applicable, push request, device wake-up, refreshed REGISTER and subsequent alert. Zoiper notes that another device registration can divert calls and that a phone unreachable around registration expiry or call arrival may require the app to be opened again. Inspect the registrar's contact selection rather than assuming the newest-looking device owns the account.
Separate a missing push, delayed push, failed wake-up, failed refreshed registration, discarded contact and INVITE that reaches the client but is not alerted. Retry only after the preceding attempt has a terminal outcome so the evidence does not mix multiple calls.
Accept ringing, answer and media as separate stages
After the device alerts, answer one authorized call and verify signaling completion, two-way audio, hangup and recovery after lock, reboot and a Wi-Fi-to-mobile transition. Push delivery proves only that the application was woken; it does not prove SIP routing, SDP, media reachability, audio-device selection or emergency-calling behavior.
Restore temporary logging, remove sensitive captures and document the confirmed owner, changed control and rollback. This diagnostic is based on first-party documentation and has not been validated in a Zoiper laboratory or customer environment.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Zoiper current downloads ↗
- Zoiper incoming-calls troubleshooting ↗
- Zoiper Push Proxy architecture and requirements ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.