Anchor the review to the installed package, not an update note
Google Play marked Sipnetic updated September 25, 2026. Its current What's new note says the release improves Android 16+ support with SDK 36, adds DNS over TLS under Settings > Network, prevents the active-call screen from reopening after a user closes it, and includes SIP-stack fixes and improvements. The first-party surface does not expose one numeric installed build, so record the version shown by Android, package source, Play update state, device model and Android build.
An update date and release note describe the store record, not the binary on a particular handset. “Android 16+” and “SDK 36” in that note do not establish compatibility with every Android 16 device, vendor image, work profile, mobile-device policy, headset, SIP service or PBX.
Keep the client, SIP account and provisioning owner separate
Sipnetic describes itself as an Android SIP client and says it needs an existing VoIP provider or PBX account. Record the exact account, SIP identity, authentication identity, server or domain, outbound proxy, selected transport and responsible service owner without publishing the secret. Multiple-account support means a saved account and the account selected for a call can differ.
The developer also lists QR-code account configuration. Treat a QR image that carries a server, username, password or policy as a credential-bearing artifact: authorize its recipient, restrict retention and preserve a revocation or reprovisioning path. A completed scan is not proof of the effective runtime values, successful registration or calling authorization.
Treat DNS over TLS as resolver transport, not SIP transport TLS
RFC 7858 defines DNS over TLS to protect DNS messages in transit between a client and a DNS privacy service. Sipnetic exposes its DNS-over-TLS control under Network settings. Record whether it is enabled, the configured resolver or service, connection result and the DNS answers returned from the affected network. Do not describe that control as encryption of SIP signaling or RTP media.
RFC 3263 separately explains how SIP clients can use NAPTR, SRV and address records to select a SIP server, port and transport. Preserve the queried name, record type, answer set, TTL, selected target, address family and fallback. A protected DNS session can still return no usable SIP target, while successful DNS does not prove that a later SIP connection or certificate succeeds.
Verify SIP destination, TLS identity and registration independently
After discovery, record the selected SIP destination, port and UDP, TCP or TLS transport. For SIP over TLS, preserve the expected service identity, presented certificate chain, validity window and trust result. RFC 5922 makes SIP domain identity a separate verification step; a successful DNS-over-TLS connection to a resolver does not authenticate the SIP proxy.
Then follow one complete REGISTER exchange under RFC 3261: request, challenge where used, authenticated retry, final response, Contact and expiry. A registered contact is a time-bounded location binding. It does not prove incoming delivery, background wake, outbound authorization, media, DTMF or emergency calling.
Keep background calling, NAT traversal and media as later stages
The first-party pages list STUN, TURN, ICE, TLS, SRTP and ZRTP capabilities, but the reviewed material does not document a push-registration relay or promise locked-screen delivery. For an authorized pilot, test foreground, locked-screen, extended-idle, app-restart, device-restart and Wi-Fi/mobile transitions separately. Preserve Android notification and battery-policy state plus the REGISTER and INVITE chronology.
For a completed call, retain negotiated codecs and media-security profile, candidate or relay selection and each RTP direction. Listed support, enabled settings and a SIP 200 response are not evidence of selected ICE paths, protected media or two-way audio. Paid-feature wording in the store is an entitlement boundary, not proof that the selected account can use the feature.
Close privacy, support and acceptance boundaries explicitly
Google Play's Data safety panel is a developer-supplied declaration. It says personal information and contacts may be collected, data is encrypted in transit and deletion is not available; those statements are not direct observation of the installed app, every processing path or the SIP provider. Review the policy shown to the user, requested permissions, contact access, diagnostic exports and organizational retention before deployment.
Accept one named package and account only after the authorized tests cover registration refresh, inbound and outbound calls, locked-screen delivery, network transition, two-way media, hangup, credential revocation and the provider-approved emergency procedure. Do not infer availability, pricing, support response or compatibility. No app, device, resolver, account, protected session, media stream, privacy behavior or 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.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.