Identify the installed build instead of trusting one storefront date
Sipnetic is an Android SIP client, not a VoIP service. The developer's changelog lists version 1.1.11 dated September 25, 2026 with Android 16 or SDK 36 work, DNS over TLS and SIP-stack changes. The Google Play page observed on October 5 still displayed an April 2, 2026 update date and release notes that match 1.1.10. Treat those surfaces as mismatched metadata and verify the version actually installed on the test device.
The official listing recommends Android 7.0 or later, while the latest changelog mentions improved Android 16+ support. Neither statement proves compatibility with a particular handset, vendor build, work profile, mobile-device policy or PBX. Record the install source, app version, Android build and device model before acceptance.
Keep the app, SIP service and account owners separate
The developer states that Sipnetic does not provide VoIP service and requires a provider or PBX account with a server address, login and password. Multiple accounts and automatic account selection add another decision: record the selected account for each test rather than assuming the displayed contact or dialed digits identify the originating service.
A completed wizard or accepted REGISTER proves only that account's current registration transaction. Provider authorization, number formatting, caller identity, voicemail, SIMPLE presence, DTMF, hold and attended transfer require separate checks. Broad standards-compliance language is not a compatibility result for a chosen PBX, provider or feature.
Treat QR provisioning as credential delivery
The developer documents account creation by scanning a QR code. If the image contains a username, secret, server or policy, handle it as a credential-bearing onboarding artifact: generate it for the intended user, deliver it through an authenticated channel, limit retention and prove revocation or reprovisioning after a lost or replaced device.
Record every imported value and its source. A scan that completes is not proof that the destination, certificate policy, outbound proxy, registration interval, codec order or number-rewriting rule is appropriate. Confirm that a provisioning or backup process does not silently restore a retired secret.
Verify DNS, signaling, media and NAT independently
Version 1.1.11 adds an optional DNS-over-TLS setting, while 1.1.10 fixed DNS SRV lookup and some TLS failures. DNS transport, SRV selection, SIP transport, certificate validation and media protection are separate outcomes. If the app cannot register, preserve the selected target, address family, resolved records, port, transport and response sequence before changing codecs or NAT controls.
Sipnetic lists TLS, SRTP and ZRTP as well as STUN, TURN and ICE. Enabling one does not establish another. Confirm the installed premium entitlement where relevant, trusted certificate name and chain, negotiated signaling transport, offered and accepted media profile and selected candidate path. Feature presence is not proof of protected or interoperable communication.
Pilot background execution and network transitions
The reviewed first-party pages and current changelog do not document a push-notification registration relay or promise locked-screen delivery. The changelog instead records Auto-Start, Android-version background fixes and network-transition fixes over time. Keep foreground registration, Android process state, notification permission, battery policy, Contact expiry and provider reachability as separate evidence.
Test an authorized inbound call in the foreground, after screen lock, after extended idle, after an app and device restart, and after Wi-Fi-to-mobile and mobile-to-Wi-Fi transitions. Record REGISTER refreshes and inbound INVITEs as well as ringing and answer. A current registration does not prove that Android presents the call or that two-way audio follows the transition.
Close privacy, premium and emergency boundaries
The official privacy notice says the developer does not collect personal data and describes limited device information for crash reporting, while Google Play's developer-supplied data-safety panel says the app may collect personal information and contacts, cannot delete data and encrypts data in transit. Treat the discrepancy as a due-diligence item: review the permissions and actual policy presented to the user, plus contact access, diagnostic-log export and deletion on the selected build.
Google Play also says paid features can no longer be purchased there after a stated December 26 boundary. Confirm entitlement acquisition and support directly; do not infer availability or price. Validate emergency calling, registered location and the provider-approved test procedure separately. No app, device, entitlement, QR artifact, credential, PBX, provider, DNS result, transport, protected session, NAT path, background delivery, privacy behavior, emergency route, availability, price, audio quality or live call was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sipnetic developer site ↗
- Sipnetic Google Play listing ↗
- Sipnetic full changelog ↗
- Sipnetic privacy notice ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.