Freeze one account and one state chronology
Record the exact application and Liblinphone build, operating system, package, account label, network path and first failure time. Capture the ordered account callbacks as None, Progress, Ok, Cleared, Failed or Refreshing, including timestamp and message.
Do not delete and recreate the account before preserving its effective AccountParams and error evidence. A status spinner, red icon or user-facing message cannot show whether the first divergence was configuration, DNS, transport, authentication, registrar policy or refresh.
Validate identity, server, route and registration settings
Compare the SIP identity, authentication username or user ID, realm or domain, server address, route list, transport, registration enablement and expiry with the authorized service record. Correct only the first mismatch.
A displayed address can be right while the authentication identity or outbound route is wrong. An account can also remain unregistered because registration is disabled even though calling through a route is separately configured. Preserve those as different facts.
Follow DNS, destination, transport and trust before credentials
Resolve the configured registrar or proxy from the affected network and preserve the selected address, port and transport. For TLS, retain the expected name, certificate chain and trust result without publishing private account material.
If there is no response, prove whether the request left the device and whether a response returned. Do not rotate credentials to fix a failed DNS lookup, unreachable route, blocked transport, reset connection or certificate rejection.
Distinguish a challenge from terminal authentication failure
Preserve the first 401 or 407 challenge, its realm and algorithm, the AuthInfo selected by Liblinphone, the retry and the final response. A challenge is expected protocol flow; the failure boundary is a missing retry, mismatched identity or realm, unsupported algorithm, repeated challenge or explicit rejection.
Use the authentication callback only to supply authorized material to the matching account. Do not paste passwords, HA1 values or authorization headers into public logs, tickets or screenshots.
Correlate Failed, Progress and Refreshing with detailed evidence
For Failed, read the Account reason and ErrorInfo and correlate them with the last SIP or transport event. For prolonged Progress, distinguish no response from an unfinished challenge or retry. For repeated Refreshing, compare expiry, network transitions, contact changes and the final state of each transaction.
Do not treat a callback message as the packet trace or a terminal response as proof of the selected local configuration. Retain enough sanitized evidence to identify the first boundary, not every secret-bearing line.
Correct one layer and verify registration plus reachability
Correct only the demonstrated layer: account parameter, DNS record, route, firewall or NAT behavior, transport, certificate trust, AuthInfo match, credential, registrar policy or refresh timing. Re-run one clean transaction and require a bounded state sequence ending in the expected state.
After Ok, verify authorized inbound delivery, background wake or push, outbound calling, media and emergency behavior separately. Registration does not prove any of them. No Linphone build, account, credential, registrar, packet, media stream or 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.