VoIP.infoThe independent guide to business communications.
VoIP.info Client research

MizuDroid: release channels, SIP push and background-service boundaries

Separate the public Play and APK artifacts from customer builds, then prove whether incoming calls use provider push, Mizutech's gateway or a foreground service.

Reviewed 2026-10-09Mizutech's Android release-channel, background-availability, push-gateway, public-download, user-guide and Google Play material reviewed October 9, 2026; no application, APK, custom build, Android device, permission, battery policy, token, push gateway, SIP account, PBX, registration, INVITE, media stream, protected session, availability, compatibility, price, audio result or call was inspected or testedIntermediateDocumentation based · not lab tested

Keep the public and customer release channels separate

Mizutech's release record identifies MizuDroid 4.6 dated June 7, 2026 as a major SIP and media-stack release, but explicitly says that build is available through APK download or new custom-branded work and will not refresh the public Play demo. The same record says customer stable builds can be produced monthly while public demo releases are updated about yearly. The Play listing observed for this review says it was updated July 31, 2026 without exposing one comparable installed version in the page text.

Do not report one universal latest MizuDroid version. Record the package name, installer or store source, exact version and build displayed by Android, signing identity, distribution owner and whether it is the public app or a custom-branded artifact. A higher customer-branch number does not prove that a Play installation received that code, and a store update date does not prove the v4.6 feature set.

Choose one background-reachability owner

Mizutech documents three paths: direct push supported by the SIP server, a Mizutech SIP-push proxy for a public SIP server that lacks push support, or an Android background service when push is not possible. The app may select a path automatically, and administrators can also change push and background-service controls. Those paths create different registration sources, permissions, battery behavior, logs and revocation work.

For one account, capture the selected app setting, provider capability, registrar address, Contact set and registration source while foregrounded, backgrounded and after restart. Do not enable both push and continuous background service merely to hide an unidentified delivery fault. A current REGISTER or active push binding does not prove Android presented an incoming call.

Treat the Mizutech gateway as an extra signaling leg

When MizuDroid uses the Mizutech gateway, the documentation says REGISTER is also forked through the gateway. The SIP server can therefore show an extra registration sourced from that gateway even while the app is closed. On an incoming call, the gateway sends an FCM wake-up before forwarding the INVITE. Token enrollment, gateway registration, FCM delivery, application wake-up, forwarded INVITE, ringing, answer and media are separate evidence states.

The push page says a binding can be disabled in the app, removed manually by support, or expire after a few days of inactivity; uninstall is not detected immediately. An old gateway contact after uninstall is therefore not proof that the retired device remains usable. Revoke the SIP account when required by policy, remove the binding through the documented path, and verify the expected current device rather than deleting contacts blindly.

Keep protocol claims bound to the installed artifact

The current first-party materials list IPv4 and IPv6, UDP, TCP and TLS, DNS SRV, SRTP-related behavior, multiple accounts, media codecs and NAT traversal. The release record also documents RFC 8599 support in an earlier major branch and later SIP, TLS, push and network-recovery changes. Those are product or branch statements, not an observed negotiation or compatibility matrix for every public and custom package.

Capture the exact transport, resolved target, certificate result, SDP offer and answer, selected media profile and observed packet path for an authorized call. TLS registration does not establish SRTP, and a direct encrypted MizuDroid-to-MizuDroid claim does not establish protection through a PBX, SBC, provider or PSTN boundary.

Diagnose locked-screen failure in evidence order

Start with one transition: foreground, screen lock, extended idle, force stop, device restart or network change. Correlate the expected registration or push binding with one inbound INVITE, push receipt, wake-up, user-visible alert and answer. If the app only rings while open, use the background-ringing diagnostic and preserve whether the account selected direct server push, the Mizutech gateway or a background service.

For a service path, record notification permission, foreground-service state and battery policy instead of treating a battery-optimization exception as a universal fix. For push, prove the current device token and binding before changing SIP expiry, NAT or codecs. Media and two-way audio are tested only after signaling reaches the app.

Run a bounded acceptance and removal test

With an authorized non-emergency account, test foreground and locked-screen inbound calls, outbound calling, two-way audio, DTMF, hold and transfer if required, Wi-Fi and mobile transitions, reboot and credential revocation. Record the exact package, build, Android version, device, account, background path, observed registrations and call timestamps.

Then test offboarding: disable the selected push or service path, remove or retire the account, confirm the expected Contact or gateway binding ages out or is removed through the documented channel, and verify that an unrelated active device still rings. Confirm emergency location and provider-approved test procedure separately. No application, package, device, push path, registration, media stream 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.

Continue your research

Hub · Primary softphone documentation reviewed through October 10, 2026; app, package, browser, mobile-wrapper, Windows audio and PBX interoperability not lab tested

Softphone research

Choose a desktop, mobile or browser calling client by SIP account, provisioning control, encryption and reliable call delivery.

Explore topic →
Guide · Primary mobile-softphone, operating-system, push and signaling documentation reviewed through October 9, 2026; app, device and PBX interoperability not lab tested

Mobile softphones: background calling and emergency boundaries

Research iOS and Android client behavior across push notifications, changing networks and account location.

Read guide →
Client research · Sipnetic developer site, 1.1.11 changelog, privacy notice and Google Play listing reviewed October 5, 2026; no installation, device, PBX, provider or call test

Sipnetic for Android: release, account and background-call boundaries

Evaluate Sipnetic 1.1.11 as an Android SIP client while keeping store metadata, account ownership, DNS, security, background execution and call acceptance separate.

Read guide →
Client research · SessionTalk's platform, mobile setup, SessionCloud provisioning, push architecture and registration-mode documentation plus current Apple and Google store surfaces were reviewed October 6, 2026; no app, entitlement, device, SIP account, credential, provisioning project, push server, PBX, mobile network, protected session, media path, emergency workflow or call was inspected or tested

SessionTalk Softphone: mobile SIP, upgrade and push-proxy boundaries

Evaluate the generic iOS and Android SIP client by exact store release, optional feature entitlement, account setup and the vendor push server's registration and signaling role.

Read guide →
Hub · Vendor-neutral endpoint workflow plus Acrobits Cloud Softphone platform provisioning documentation reviewed October 8, 2026; exact parameters and precedence remain product-, service- and deployment-specific and no device or application was tested

Phone provisioning: repeatable endpoint deployment

Build a controlled path from a newly connected phone to the right identity, firmware and calling policy.

Explore topic →
Protocol reference · RFC 3261 SIP, RFC 3711 SRTP, RFC 4568 SDP Security Descriptions, RFCs 5763 and 5764 DTLS-SRTP, and current Asterisk PJSIP documentation reviewed October 6, 2026; deployed endpoints, intermediaries, certificates and calls require direct verification

SIP TLS and SRTP: what each protects

Distinguish adjacent-hop signaling protection, SRTP media protection, SDES and DTLS-SRTP keying, and the actual termination points on every call leg.

Read guide →
Guide

PBX logs and packet captures: useful evidence with limited exposure

Collect enough to diagnose a call while protecting identities, secrets and audio.

Read guide →
Troubleshooting · Current Asterisk res_pjsip NAT, object-relationship and configuration references plus SIP flow guidance reviewed October 1, 2026; no endpoint, PBX, AoR, Contact, NAT device, firewall, VPN, signaling exchange, call, RTP stream or emergency workflow was tested

Remote extension works locally but fails away from the office

Trace a remote endpoint from DNS and transport through registration, stored Contact, inbound delivery and media without treating one green state as call proof.

Read guide →
Guide

Planning emergency calling for a VoIP deployment

Assign responsibility for location, routing and outage procedures before rollout.

Read guide →
Troubleshooting · RFC 8599 SIP push, current Apple PushKit, Android background-service and Firebase guidance, vendor push architectures including MizuDroid's direct, gateway and service paths reviewed October 9, 2026; no device, application, token, gateway, SIP account, registration, INVITE, alert, media path, battery result or call was inspected or tested

Softphone rings only when open: trace registration and push wake-up

Separate foreground registration, push-token state, proxy ownership, APNs or FCM delivery, application wake-up, refreshed SIP reachability and the retained INVITE.

Read guide →
Troubleshooting · RFC 3261 and current Asterisk res_pjsip registrar, authentication, outbound-registration and troubleshooting documentation reviewed October 5, 2026; no endpoint, PBX, registrar, binding, transport, packet path or call was inspected or tested

SIP registration loops after an apparent success

Classify normal refresh, repeated authentication, binding replacement, transport restart and outbound-registration retry before changing timers.

Read guide →
Diagnostic · RFC 5626 SIP Outbound, RFC 6314 NAT traversal, current Android connectivity guidance and Apple NWPathMonitor reference reviewed October 7, 2026; no device, application, operating-system callback, Wi-Fi or mobile network, VPN, DNS response, NAT mapping, SIP flow, keepalive, registration, push service, PBX, provider, media path, availability, battery result or call was inspected or tested

Softphone loses registration after Wi-Fi or mobile-network change

Trace the old network path, SIP flow, keepalive, detected failure, replacement flow, REGISTER result and inbound route after a device changes connectivity.

Read guide →