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

Capture one transition and the exact first failure

Record the softphone and operating-system build, account, old and new access type, VPN state, change time and first failed action. Distinguish Wi-Fi loss, Wi-Fi-to-mobile handover, mobile-to-Wi-Fi handover, captive portal, VPN connect or disconnect, address-family change and return from sleep. A status icon after the event does not prove that the old signaling flow is usable.

Preserve the last successful keepalive, last request on the old flow, operating-system path change, DNS result, new local address, transport establishment, REGISTER request and response, contact set and first inbound and outbound attempt. This chronology separates an undetected stale socket from a rejected replacement registration or a later media problem.

Keep network availability and SIP reachability separate

Android documents callbacks for dynamic connectivity changes, and Apple's NWPathMonitor reports path updates. Those are application inputs, not SIP registration or provider acceptance. A newly available network can still require captive-portal completion, DNS, VPN policy, IPv4 or IPv6 reachability, certificate validation and a new transport before SIP succeeds.

Record what the softphone did after the callback. Do not treat a working browser, a connected Wi-Fi icon or a mobile-data indicator as proof that the registrar, outbound proxy, push service or media relay is reachable from the new path.

Identify the old SIP flow and how failure is detected

RFC 5626 defines a flow as the transport association used for SIP Outbound and describes keepalives for refreshing NAT or firewall bindings and detecting failure. It also says a user agent that detects a failed or changed flow needs to re-register on a replacement flow. Capture whether the account negotiated SIP Outbound, the transport, flow token or instance identity, server Flow-Timer when present, keepalive method and last response.

A TCP or TLS socket object can remain locally open after its network path is gone, while a UDP mapping can change with the device address. A configured keepalive interval is not proof that keepalives were sent, returned or interpreted. Do not shorten every interval until the first missing boundary is known; aggressive probing can increase battery and signaling load without repairing replacement registration.

Prove replacement DNS, transport and registration

On the new network, preserve SIP DNS resolution, selected address and transport, local socket, proxy or registrar connection, certificate result where applicable, REGISTER Contact, expiry, reg-id or instance identity when used, response and the registrar's resulting contacts. A 200 response belongs to that transaction; confirm that the accepted contact and flow are the ones used for later requests.

Keep old-contact cleanup, contact maximums, replacement policy and push enrollment visible. A server may retain the old binding until expiry, reject an additional binding, replace the wrong device or route an INVITE to a stale flow. Those outcomes require registrar or PBX evidence rather than deleting all contacts or raising a maximum as a generic fix.

Follow inbound and outbound behavior independently

After the replacement REGISTER, place an authorized outbound call and separately send an inbound call to the exact identity. For inbound service, trace the selected contact or push-aware path and the first INVITE. For outbound service, retain the route, authorization response, dialog and final outcome. Registration, push wake-up, outbound authorization and inbound routing are different states.

If the call alerts but audio fails after the network change, continue with SDP and RTP on the new addresses. Do not change codecs or media ports to solve a signaling flow that never recovered, and do not report restored registration as proof of two-way audio or emergency location.

Correct the demonstrated owner and run a mobility matrix

Correct only the demonstrated owner: application path-change handling, supported SIP Outbound or keepalive policy, DNS, VPN route, certificate, proxy reachability, NAT or firewall state, registrar contact policy, push enrollment or account authorization. Preserve the previous configuration and rollback. Do not weaken TLS validation, open broad firewall ranges or retain duplicate credentials to mask an unknown failure.

Retest Wi-Fi to mobile, mobile to Wi-Fi, VPN on and off where supported, sleep and wake, restart and an ordinary stable-network control. Record recovery time, replacement registration, contact selection, inbound alert, outbound completion, both media directions and hangup. Use provider-approved emergency validation only. No device, path, flow, registration, push service, media stream, availability, battery result or call was tested for this guide.

Keep Zoiper wake-up and mobility evidence together

If the affected client is Zoiper, use the Zoiper background incoming-call diagnostic alongside this transition workflow. It records whether direct registration or Push Proxy owns reachability, then correlates the new network, refreshed registration and the first inbound INVITE.

Keep network recovery separate from push recovery

When the affected app is PortSIP ONE, continue with the product-specific mobile diagnostic. It distinguishes a stale SIP flow after a network change from a missing token, push request, operating-system wake, replacement registration or replacement INVITE.

Keep Bria Push Service recovery separate from network re-registration

When Bria Mobile fails only after backgrounding or a network transition, continue with the Bria Push Service diagnostic. It keeps direct client registration, Push-server registration, Contact routing, APNs or FCM delivery and the wake-up tunnel as separate owners.

Separate Linphone signaling recovery from ICE recovery

A refreshed Linphone registration after a network change does not prove that the media candidates, checks and selected path were rebuilt successfully. Use the Linphone ICE diagnostic when signaling recovers but audio does not.

Separate Linphone path recovery from push wake-up

After a Linphone network transition, determine whether the app observed the new path and refreshed registration while awake. If calls fail only after suspension, continue with the Linphone push diagnostic and prove the proxy request, device wake and replacement registration independently.

Separate SessionTalk direct registration from the sleeping push binding

A foreground network transition can repair the app binding while the push-server path remains unavailable. The SessionTalk diagnostic compares both registrations and their owners before changing NAT or media settings.

Apply the Blink-specific registration trace

For Blink, use the 408 and 503 diagnostic to re-resolve the next hop and retain the selected transport and response.