Freeze one failure before changing account or resolver
Record the device, Android build, Sipnetic version shown by Android, package source, Play update state, account label, network, foreground or locked state and first failure time. Export only authorized, sanitized evidence and preserve the effective Network and account settings before toggling DNS over TLS, recreating the account or clearing application data.
Classify the first missing outcome: DNS query, DNS answer, selected SIP target, transport connection, TLS trust, REGISTER response, Contact, INVITE, visible alert, answer, SDP, RTP or hangup. “Not working after the update” does not identify which layer changed.
Confirm what the September 25 update did and did not establish
The current Play note identifies Android 16+/SDK 36 work, a DNS-over-TLS setting, active-call-screen behavior and SIP-stack fixes. Verify that the affected handset actually installed the corresponding store release. Do not assign a numeric version from an unofficial catalogue or assume that every recorded fix applies to this device and symptom.
Compare one controlled reproduction on the same account, network and Android state. If an older authorized reference device exists, treat it as comparative evidence rather than proof of universal regression. Preserve rollback and re-enrollment constraints before changing a managed device.
Isolate the DNS-over-TLS resolver path from SIP discovery
Record whether Sipnetic DNS over TLS is enabled, the selected resolver or service, TCP and TLS connection result, expected resolver identity and query outcome. RFC 7858 uses a DNS privacy connection, conventionally on port 853 unless otherwise agreed; that path can fail before any SIP packet is sent.
Next preserve NAPTR, SRV, A and AAAA answers relevant to the configured SIP name, including TTL and selected target. Compare with the authorized DNS service record. Do not leave DNS privacy disabled as a blanket cure or change SIP credentials to fix a resolver connection or empty answer.
Trace the selected SIP transport and certificate separately
Using the actual RFC 3263 result or configured proxy, record destination, address family, port and SIP transport. For TLS, compare the intended SIP domain with the presented certificate identity and retain the chain and validation result. DNS over TLS protects the resolver exchange; it neither selects SIP-over-TLS nor authenticates the SIP proxy.
If the connection fails, distinguish timeout, refusal, reset, protocol negotiation and certificate rejection. Correct only the demonstrated DNS, route, firewall, transport or trust boundary before proceeding to REGISTER.
Follow registration, call signaling, background wake and media in order
Preserve one REGISTER transaction, any authentication challenge and retry, final response, Contact and expiry. If registration succeeds, place one authorized call and retain INVITE, provisional and final responses, ACK and BYE. For inbound failure, compare registrar Contact selection, INVITE arrival, Android notification or UI presentation and answer as separate events.
After answer, verify SDP, selected codec and media-security profile, candidate or relay path and packets in both RTP directions. Registration, ringing and SIP success each stop short of proving two-way audio. A screen that no longer reopens after the user closes it is UI behavior, not evidence of call teardown or media state.
Correct one layer and run a bounded acceptance set
Change only the first failed layer: installed package, Android permission or lifecycle state, resolver configuration, DNS data, SIP destination, transport, certificate trust, account parameter, registrar policy or media path. Re-run the same reproduction, record the new first divergence and keep a reversible configuration record.
Verify refresh, inbound and outbound calls, locked-screen delivery, restart, Wi-Fi/mobile transition, two-way media, normal hangup and credential revocation. Use the provider-approved emergency procedure separately. No Sipnetic package, Android device, DNS-over-TLS service, SIP account, PBX, packet, privacy behavior, media stream or live call was inspected or tested.
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.